Re: Can C# be as fast as C++?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

There's a significant possibility that the machine specific optimizations
are only done during JIT, as NGEN places the result in a file which can
be
moved around.

I believe the ngen'd file has a record of various machine-specific
attributes (such as processor type) and will be ignored if they're
wrong. However, I've *also* heard that ngen doesn't have all of the
optimizations of the normal JIT - I'm not sure how to square these
two. I suppose the normal JIT is able to do cross-assembly inlining
which could be tricky in ngen, etc.

This also depends. NGEN is different for both 64-bit and 32-bit Intel/AMD
CPU's. The JIT for 32-bit was written by the C# team, IIRC, and the C++
team wrote the JIT/NGEN for 64-bit so its much more in-tune with the C++
optimimizer <grin>. IIRC, the 64-bit JIT/NGEN was written from scratch. At
least this is what I read and I read it a while ago just before Whidbey was
released.

However, when I look at the code generation for C# on both 32/64-bit
versions, the C# compiler doesn't seem to produce as much optimal IL
instructions as the C++/CLI compiler (for obvious reasons). What is
interesting that if I hand-tuned some IL instructions from C# programs (for
example, changing some things in ways that would remove, say, 8 out of 49 IL
instructions, or simply rearrage the sequence of instructions, on 32-bit
JIT, during profiling, would produce worse for some reason but on 64-bit
performs better. Hard to know exactly why. I figured that the 32-bit JIT
looked for patterns that C#/VB.NET (nearly identicle output) produce and
optimizes that and by hand-tuning some IL it broke the pattern recognition
but, in reality, I have no idea whether that is the truth.

Having written my own C# compiler that allows me to dynamically add new
syntax and language features on a per-project or per-assembly
(referenceable) basis, I've sound ways to write IL that produce good
results. I had to spend insane amounts of time looking at what C#/VBn/C++
CLI produced and figured out what works best. In the end, I produce my own
opcode sequences in some areas where I found advantages in doing so.

Now all we need is a way for IL to express something that very easily maps
to SSE2/3/4//altivec/etc.. so I can optimize some of my numericals.


Thanks,
Shawn


.

Relevant Pages

  • Re: interpreter vs. compiled
    ... there is a process that runs product instructions, ... I would take 'compiler' to mean, ... the notion that JIT technology compiles code. ... The bytes of machine language will come ...
    (comp.lang.python)
  • Re: interpreter vs. compiled
    ... there is a process that runs product instructions, ... the notion that JIT technology compiles code. ... my C implementation a compiler. ... new machine language for each one. ...
    (comp.lang.python)
  • Re: Can you write code directly in CIL ???
    ... >>> JIT that has more to do with optimisation IMO. ... Many of the instructions would ... The JIT probably does all the processor specific optimizations. ...
    (microsoft.public.dotnet.languages.csharp)
  • misc: lang effort, performance
    ... I added a define that allowed me to enable/disable ref counting to see what ... a c implementation of the algo takes about 110ms (generic compiler options). ... I had started to consider the possibility of jit compilation. ... of course, thinking of it, some optimizations (those which I had originally ...
    (comp.lang.misc)
  • Re: any JIT compilers for Prolog?
    ... I know you need to take care of different platforms when doing JIT, ... into C and calling the C compiler at runtime is not my option. ... for a Java based Prolog like http://www.binnetcorp.com/Jinni ... that avoids Java objects and encodes everything as integers. ...
    (comp.lang.prolog)