5

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.

Jonathan Rupp
  • 15,522
  • 5
  • 45
  • 61
  • 1
    Why use .net if memory timing is tight? Would c++ not be better? – gbn Apr 20 '09 at 12:42
  • Timing is tight, but dev time still matters. Plus, we have a number of already-developed .Net libraries we need to link to. Building this part in C++ and calling it via PInvoke isn't out of the question, but must be proved out by perf numbers. I'm trying to get the .Net code to perform as good as possible before we 'give up' and go that route. – Jonathan Rupp Apr 20 '09 at 14:39

3 Answers3

5

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

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

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
0

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.

grover
  • 2,265
  • 1
  • 16
  • 15
  • That defines the ECMA model - the .NET model is slightly stronger, and thus easier to write for. – Jon Skeet Apr 20 '09 at 12:49
  • as a side note the x86 and x64 JIT's actually just diverged quite a bit (previously the x64 was superior in most ways, now its a bit more interesting) hopefully they will get more inline with one another (excuse the pun) – ShuggyCoUk Apr 20 '09 at 13:04
  • But only with respect to the quality of the code they produced. – grover Apr 20 '09 at 13:42
0

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.

ShuggyCoUk
  • 36,004
  • 6
  • 77
  • 101