HN user
The immutable design came from the class library folks (not my team [the JIT folks]). I believe the analogy to atomic types (integers aren't mutable) is pretty sound. The API really was cleaner by making them immutable. If you want to allow mutation, the API surface area really explodes, resulting in dramatically more JIT work to make them perform well.
How would you like shuffles exposed? One of the things we really tried to do with this design is make sure it's NOT tied to one particular hardware implementation of SIMD.
NGen invokes the JIT compiler, so your install time (and .NET servicing time) should be quite a bit lower, once we release RyuJIT as part of the full .NET Runtime. Probably less important, but still important enough for a lot of customers to complain :-)
Programs that are pointer-heavy tend to be a little slower. There's really not that much 64-bit arithmetic going on in the average application, so the more data per clock cycle only helps in a particular class of apps. Cryptography tends to do significantly better, for that exact reason. You do seem to be conflating code quality with compiler throughput, though. I'll try to clarify in much more detail in a CLR Codegen blog post soon.
NGen doesn't help too many folks with asp.net, since it just doesn't work. And for a class of x64 applications, NGen is a terrible solution because it takes so long to precompile the entire application. I'm going to put together a more detailed article for the Codegen blog regarding motivation, history, all that fun stuff...
My next big perf task is to get the Roslyn self-build as a test for RyuJIT. It's a pretty interesting combination of JIT compiler throughput, and generated code quality.
Which compiler are you talking about? The JIT compiler is 64 bit, the C++ x64 targeting compiler is available as both 32 & 64 bit. Roslyn is 32 bit because, well, the x64 JIT is dog slow :-)
Can you expand on what you mean by "confusing x86/x64 message"? I'd love to help clear it up. Are you saying that people will believe that the reason the JIT is so much faster is because it's 64 bits? That's the exact opposite of reality: 64 bit programs tend to be slower, because they have to manipulate more data (all pointers take twice as much space, the Win64 ABI requires a minimum of 48 bytes of stack per non-leaf function, etc...)