The CLR x86 JIT, an overview

re: The CLR x86 JIT, an overview

Lorenzo Dematte — Tue, 26 Oct 2004 15:50:00 GMT

Very interesting. What algorithm did you chose for registry allocation? Why is necessary control flow analisys? I think this phase could be done by the compiler that emits MSIL

re: The CLR x86 JIT, an overview

Andrew Shuttlewood — Tue, 26 Oct 2004 16:06:00 GMT

How long does all this take?

I imagine that some bits are faster than others, and you're only working with a single method, but I imagine it still has an impact of a kind.

Is there a good guide to .NET IL? I'm (probably far too much) familiar with Java bytecode, and I'm curious as to how .NET differs radically.

Another question, do you process method by method, class by class, or assembly by assembly?

Sorry, I'm just very curious :)

re: The CLR x86 JIT, an overview

Andreas Häber — Tue, 26 Oct 2004 16:22:00 GMT

Andrew: Checkout http://weblogs.asp.net/kennykerr/category/7140.aspx for a quick intro to MSIL.

re: The CLR x86 JIT, an overview

Panos Theofanopoulos — Tue, 26 Oct 2004 16:34:00 GMT

Some background before the actual question

Constants (const in C#) are used only by the
compiler, using the value they have at compile
time, so a change in some constants is leaving
us with a version problem (we must recompile
all depended assemblies)

Default parameters having the same version
problem as the caller actually use the compile
time values.
The solution that C# team is providing is
overloads, this is actually a semi-workaround,
since they don't capture the developer's
intention (which is just some default values)
and they are maintenance problem (we must
synchronize the attribute's definitions and xml
documentation of the method)

Now the question :)

How difficult is to add the constant resolution
in the first steps of JITing ?

That will solve problem #1 and if the default
parameters values could be encoded as some
internal constants (so the caller use them
instead of the actual values) will solve #2
also

I think that JITter already does much more
complicated things, than a simple Find and Replace

Regards

re: The CLR x86 JIT, an overview

Dmitriy Zaslavskiy — Tue, 26 Oct 2004 17:10:00 GMT

David, could you comments on the differences in JIT and NGEN in v2

re: The CLR x86 JIT, an overview

Eric Wilson — Tue, 26 Oct 2004 18:23:00 GMT

To Panos Theofanopoulos: Why not just use public read-only fields instead of public constants? With read-only fields, I am pretty sure that the compiler does not just hoist the value out at compile time.

re: The CLR x86 JIT, an overview

Eric Wilson — Tue, 26 Oct 2004 18:26:00 GMT

I'm confused why the JIT does heavy-weight optimizations like common sub-expression elimination. Shouldn't those be done by the compiler? I can understand the range check optimization because the JIT and CLR already have special understanding of these types.

re: The CLR x86 JIT, an overview

David Notario — Tue, 26 Oct 2004 19:52:00 GMT

Lorenzo:

The IL doesn't have information about control flow and liveness. Certainly, some compilers do it to remove dead code, but because IL doesnt have it, we need to recompute it.

Andrew: Jitting is per method

re: The CLR x86 JIT, an overview

Luc Cluitmans — Tue, 26 Oct 2004 21:20:00 GMT

David, can you comment on differences between JITters for different CPUs, and differences between JIT in different framework versions?

I have noticed a few times that, when doing performance tests (in C#) to decide what architectural principles to use for a problem, and trying two different approaches, one approach may be faster on the Intel (P4) processor in the desktop at my office, while the other approach was faster on my AMD (Athlon XP+) processor in my computer at home.

Describing the whole test I happened to do this morning leads a bit too far here, but I tried two approaches to a signal processing problem. Both versions were about equally intensive on floating point calculations, but one focussed on employing virtual method calls to get a 'cleaner' architecture, while the other approach tried to trick the JIT into optimizing the code as much as possible by using nonvirtual methods (called from a large code-generated method instead of a simple loop) and using method arguments (backed by local variables) instead of explicit state variables.
I was surprised that on 3 out of 4 test situations (AMD vs Intel and .Net 1.1 vs. .Net 2.0.40607) the 'clean' solution was actually (much) faster than the 'optimized' one.

Can you give guidelines on what things to do or not to do to let the JIT do its work optimally? I am thinking about things like the effect of 'sealing' a class, virtual vs. nonvirtual methods, interfaces vs. delegates, passing data to a method as fields in its class vs passing the data as method arguments, the implications of 'ref' and 'out' parameters, etc...

re: The CLR x86 JIT, an overview

Omer van Kloeten — Tue, 26 Oct 2004 22:41:00 GMT

Simple, quick question: According to the times it takes for the JIT engine to emit a method, what is better: many small methods (these stages occur more often and the optimizations are scarse) or few large methods (these stages occur fewer times, but optimizations are heavier)?

re: The CLR x86 JIT, an overview

Panos Theofanopoulos — Tue, 26 Oct 2004 23:35:00 GMT

Eric : And what's the use of const then ? :)

The answer is that the static field's value (even if it's readonly) cannot be "inlined" by the JITter

by inlining i mean the following

class AsmA {
public const int myConst = 4;
}

the statement
return 4 / AsmA.myConst;

will generate a
MOV EAX,1

and the statement

return a / AsmA.myConst

test eax,eax
jns positive
add eax,3
positive:
sar eax,2

David Starts Blogging

.Net Security Blog — Wed, 27 Oct 2004 21:47:00 GMT

re: The CLR x86 JIT, an overview

Daniel Moth — Sun, 31 Oct 2004 17:49:00 GMT

Great Stuff! I know you have stated upfront the x86 focus, but I would be interested in any info you have with regards to JITing and the Compact Framework.

Don't Deny SkipVerification

.Net Security Blog — Fri, 11 Mar 2005 04:41:00 GMT

Release IS NOT Debug: 64bit Optimizations and C# Method Inlining in Release Build Call Stacks

ASPInsiders — Thu, 25 Oct 2007 23:48:37 GMT

Just a reminder: Release builds are not Debug builds. Seems obvious, but it's worth saying again. Release

David Notario s WebLog The CLR x86 JIT an overview | Green Tea Fat Burner

David Notario s WebLog The CLR x86 JIT an overview | Green Tea Fat Burner — Sat, 13 Jun 2009 04:25:08 GMT

PingBack from http://greenteafatburner.info/story.php?id=5587