Actually C++ is compiled to machine code, just like Assembler is. There might be some assembler in the intermediate output, but there might also not be, it's all up to the compiler.

And if you want to go down this route, the CPU does not actually execute any of these instructions directly but instead transform them into μops, so if you want, you can see the CPU as one large VM that interprets x86_64 instructions.

In any case though, C# is without a doubt slower, mostly because of all the high level affordances it gives you, whereas C++ is designed with completely different goals in mind. What is better is up to you, at the end of the day though, C# is most likely not your performance bottle neck. Not with todays CPUs, where you are most likely to get IO bound.

Oh, and by the way, C# is compiled to byte code, yes, but that is actually compiled on the target machine to machine code. So actually the CIL compiler has the option to perform platform specific optimizations that a general C++ compiler targeting multiple different platforms can't do. It's the same idea behind Apple's bitcode, where the binary contains LLVM IR which is then optimized for the different platforms. That doesn't mean Objective-C is suddenly an interpreted language running in a VM.

All of that being said, I do like me my C++ and it does have its performance benefits over high level languages like C#. However, if you want to milk the most out of C++ in terms of performance, you will have to pass up on a lot of very nice abstractions that you could otherwise benefit from. However the case though, even hand knitted assembler tuned for one CPU micro-arch only will not perform 6000 times faster than C#, especially _NOT_ for an IO bound operation like reading files, unless gross incompetence is at play.