Re: A Tale of Two Memory Managers (long)

From: Eric Grange (egrangeNO_at_SPAMglscene.org)
Date: 06/08/04 

Date: Tue, 08 Jun 2004 12:11:37 +0200

> B) Others argue that current JITters simply don't do a good job at
> efficient compilation against current day native compilers; and will never
> do better than deliberately hand optimized code.

Current .NET JITter doesn't do as well as pure Delphi code with no hand
optimized asm, which doesn't itself does as well as top-of-the line C++
compilers (Intel, MS and specialty ones like VectorC). There are a few
*structural* issues rooted in .Net that will have to be fixed before it has
any hope of competing:
- array accesses, not only are they always range-checked (even when static
   and accessed with static indices, because .Net doesn't know about static
   arrays to begin with), but the JIT also generates atrocious code.
   Multidimensional array access is even worse. Register allocation...
   they've heard of it.
- stack based call convention, with no support for 'const', which has far
   deep implications for performance as every structure goes through the stack.
   One alternative is to use 'ref' (var), but that isn't possible with function
   results, constants or expressions (not to mention that using 'var' when
   you mean 'const' isn't exactly good practice). The other is to use objects,
   but then, you lose the ability to assign (which becomes a copy of reference
   instead of a copy of value), and also get added performance penalty from GC
   allocation and management overhead. The JIT codegen for objects isn't
   always as efficient as the one for ref structs (often adds a bunch of
   unnecessary register shuffling).
- incomplete operator overloading capability, which in addition to the stack
   based convention makes operator overloading useless performance-wise.
- no support for intrinsics, custom ASM or vectorizing patterns, significant
   call overhead to native DLLs, meaning you can't easily bypass the limitations
   without wrapping huge chunks of code (instead of a few key functions).
- inlining, which is able to alleviate some of the previous issues,
   is out of the developper control.

Current .Net 1.1 JIT also generates a lots of unecessary push, pops and register
traffic (apparently it likes a lot to place temporaries in EDI/ESI, and seems
willing to throw everything else away to achieve that goal).

In practice, the first issue hurts any array-based algorithm, and multi-
dimensionnal arrays are brought into snail realm. The Collections and Array
classes are even less effective, and when boxing kicks in, the JIT enters
the same class as PHP or Javascript performance-wise.
The call convention issue means that vector, complex or small matrix classes
also have a very hard time under .Net, as you won't be limited by floating point
computations but by the stack instructions.

For Delphi 8, there is also the issue of FPU state checks, which cripple performance
and could only be turned off with (at the time) an undocumented directive.

Eric

Relevant Pages

  • Re: bug or mistake?
    ... compared that to the stack limit, ... heap allocation so that the program can continue execution. ... all fortran compilers should behave this way, ... going to be a potentially, but infrequently, large automatic array ...
    (comp.lang.fortran)
  • Re: Microcontroller Project
    ... I'd then suggst you take a look at some more modern compilers perhaps. ... When the stack overwrites the ... registers (memory mapped) all sorts of fun things happen. ... When the stack overflows you don't see any allocation errors. ...
    (sci.electronics.design)
  • Re: Microcontroller Project
    ... I'd then suggst you take a look at some more modern compilers perhaps. ... When the stack overwrites the ... that hard to avoid unless your program is doing something very strange. ... There is no real reason to avoid C on any micro when good compilers ...
    (sci.electronics.design)
  • Re: [OT] Funny
    ... matter of what is likely to happen in practice than what the standard ... Or more precisely, mixing f77 and f90. ... That's because f77 had no concept of array stride (i.e. noncontiguous ... to do was pass its starting address...and that's all most compilers ...
    (comp.lang.fortran)
  • Re: Statement on Schildt submitted to wikipedia today
    ... However, what Schildt described was not an abstract stack, but a specific ... but not true -- many compilers will ... support the contention that the standard was designed "to protect profits". ... "Sequence points" were designed to protect profits, ...
    (comp.lang.c.moderated)