> This is (done at install time) because ngen is optimized for processor
> and OS. 

I think there needs to be an "in theory" caveat in there somewhere.  How
many different CPU/OS families does the .NET JIT compiler actually support
discretely?  And does it really make a difference anyway?

Delphi code compiled for "generic x86 processors" still seems able to run
circles around C# code.

Part of that will be that it's not just a question of "code", but also
framework semantics that affect performance.  Moving bytes around and
manipulating them is likely to be just as fast as native code, but invoking
methods and even simple things like type-casting will incurr overhead that
the managed runtime imposes to ensure that the code isn't doing something it
shouldn't.


Someone did some benchmarking not so long ago where the test conditions were
set by some C# guys - it was essentially an open benchmarking challenge with
invitations to submit optimal solutions in various languages. I forget the
details but the last I heard the C# code struggled to get anywhere near the
Delphi code.

I wish I could remember a link to it - it made for interesting reading
generally.

It was someone's blog I think.  Can anyone help out with a reference?


> NGen means the resultant assembly is faster. 

I thought it mostly affected apparent loading time, since all assemblies are
"compiled" before executing.  NGen allows this compilation "hit" to be
incurred during installation (or even prior to distribution) rather than
during startup, but once loaded the assembly won't be faster per se.

As for why NGen isn't popular, that might be because there are so many
things that can cause the resultant compiled assembly images to become
invalid, which presumably negates the benefit.

http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.71).aspx

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: 
unsubscribe

Reply via email to