Differences between x86/x64/ia64 memory models on .NET

Question

I'm looking for a reference on the differences between the memory models used by the .NET CLR/JIT on x86/x64/ia64. I know there's some differences between x86 and ia64 (instruction reordering, instruction removal, etc.), but I haven't found a reference on the differences between x86 and x64.

I have an application that is aiming for some very tight latency numbers, and will only run on x86 at this time, and maybe on x64 (definately not on ia64). I'm wondering if I can rely on some artifacts of the x86 JIT implementation and still be relatively safe on x64, or if I should be programming to the looser ia64 JIT (which will require more fields be volitile and memory barriers be inserted in several places).

Thanks in advance for any pointers.

Answer 1

The .NET memory model is specified in the ECMA specification ISO/IEC-23271. Specifically in Partition I: Concepts and Architecture, Chapter 12.6 "Memory model and optimizations".

This standard defines the boundaries a JIT may operate in. If you want to be neutral to the architecture, you should follow this standard and not utilize any specifics of the x86/x64 JITs.

Additionally x64 is an evolution to x86, it consists mostly of additional instructions, registers and some extensions (SSE2) being defined as baseline for all x64 compliant processors. There's been almost no change to memory models, except for the additional address space and additional addressing modes (instruction pointer relative data access.) So optimizing for the x86 JIT should yield good results on x64 too.

Answer 2

Two articles on the .NET memory model (which is stronger than the ECMA model, btw):

• Vance Morrison (detailed)
• Joe Duffy (set of rules based on the above)

Joe Duffy's book, Concurrent Programming on Windows, is also a great source of information on this topic.

Answer 3

This may be far too low level you you but some older AMD 64 bit cpus do not have CMPXCHG16B (Source) if you were relying on that as a hardware non-blocking instruction.

Also there seem to be changes in the memory model for C++ which may be relevant so you may have to keep an eye out if you are doing very low level code.

The memory model 'specified' by the CLR is an ongoing topic of debate within Microsoft (discussed openly at least as far back as 2003). As a side note Chris Brumme states in that article that the model of x64 is the same as x86 which I would assume is an accurate statement for the purposes of CLR hosted code.

Unless your target users explicitly include Itanium I would think that simply including a fallback, slower but simple and safe, implementation for that architecture would be sufficient for correctness. There is then no need to indicate that your software is broken on that platform, just that it operates in a slower fallback mode. If people subsequently want to use the platform seriously you can code to that much looser model.

Note that the x64 JIT is different to the x86 JIT (significantly so since 3.5 SP1) so any Release Mode testing on one is not representative of the other and vice versa. Test as appropriate.