"JIT" complete application?

[Christoph Wienands]

Hello,

I'm currently wondering if it is possible to JIT a complete application at
start-up. The problem is that I have a very time-critical application, which
should be able to shoot out of the halter, and this from the first shot on.

I know that there is the possibility to use NGen. However, in several posts
I read about the trade-offs like less optimized code. Since start-up time is
not critical, my idea was to look for a way to tell the JIT compiler to
compile EVERYTHING at once in contrast to method-by-method JITting during
runtime.

Anybody any ideas?

Thanks, Christoph

 

[Manoj G [MVP]]

There are trade offs with NGEN, but it isnt that bad in all cases. You can
try adopting Pre-JITting in your case and see if this is feasible.
Using a custom CLR host, I suppose things like GC can be tweaked, I dont
think JIT compilation can be.
Moreover, even if you were to be able to JIT compile everything in one go
somehow...(it wouldnt be called JIT anymore!), a lot of optimizations could
not be possible and we would land back into square one.

 

[Alvin Bruney]

why don't u just write a warmer application/service which sits on the server
firing web requests every ohhh 20 minutes or so to make sure everything is
nice and jitted. this works very well for me and applications suffer no
delayed start up times since they are always nice and toasty. it really is
about 5 lines of code. you cant go wrong there.

the code i wrote sifts thru the virtual directories calling every aspx page
recursively. the benefit is mind boggling.

 

[Christoph Wienands]

Hello Alvin,

why don't u just write a warmer application/service which sits on the server
firing web requests every ohhh 20 minutes or so to make sure everything is
nice and jitted. this works very well for me and applications suffer no
delayed start up times since they are always nice and toasty. it really is
about 5 lines of code. you cant go wrong there.

Unfortunately my application is a desktop application. As far as I know the
JIT compiles on a method-by-method basis. Because of the complex structure
of the application it is kind of tricky to ensure that 80-90% of the code
was executed at start-up as a warm-up. I was just wondering if there is a
better way...

Thanks, Christoph

 

[Christoph Wienands]

Hello Manoj,

Moreover, even if you were to be able to JIT compile everything in one go
somehow...(it wouldnt be called JIT anymore!), a lot of optimizations could
not be possible and we would land back into square one.

Well, I think a complete JIT at start-up should produce the same code as the
JIT does now on a method-by-method basis. At start-up all parameters like
processors, base address, etc. are known in contrast to NGen, which produces
a persistent image of the generated machine code before executing the
assembly. So I don't think there is any argument standing against the
theoretical possibility of a 100%-JIT, I guess there is just no switch for
it.

One idea might be a class that uses reflection to loop through all classes,
call methods and properties with 0's and nulls and ""'s. However, this
arises the problem of a possible corrupted application state. Maybe not such
a good idea :-(

Thanks anyway,

Christoph

 

[Tian Min Huang]

Hello Christoph,
possibility of a 100%-JIT, I guess there is just no switch for it.

Please kindly note that there are several optimizations that are only
available at run time:

1. Processor-Specific Optimizations¡ª At run time, the JIT knows whether or
not it can make use of SSE or 3DNow instructions. Your executable will be
compiled specially for P4, Athlon or any future processor families. You
deploy once, and the same code will improve along with the JIT and the
user's machine.

2. Optimizing away levels of indirection, since function and object
location are available at run time.

3. The JIT can perform optimizations across assemblies, providing many of
the benefits you get when compiling a program with static libraries but
maintaining the flexibility and small footprint of using dynamic ones.

4. Aggressively inline functions that are called more often, since it is
aware of control flow during run time. The optimizations can provide a
substantial speed boost, and there is a lot of room for additional
improvement in vNext.

For more information on .NET application performance, please refer to the
following articles:

JIT Compilation and Performance
http://www.codeguru.com/net_general/Insights_NGen.html

Performance Considerations for Run-Time Technologies in the .NET Framework
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/ht
ml/dotnetperftechs.asp

Performance Tips and Tricks in .NET Applications
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/ht
ml/dotnetperftips.asp

I look forward to your feedback.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Alvin Bruney]

So I don't think there is any argument standing against the theoretical

possibility of a 100%-JIT, I guess there is just no switch for it.

I can't find an argument against this. I think he is right. It looks quite
possible, in theory at least, to JIT a whole program instead of functions on
a call stack. Granted the start up time would absolutely suck. But I'm here
thinking that theoretically, an application is made up of functions
basically to which the JIT is applied when needed. What's to stop the JIT
from going after the whole thing assuming there was such a pill/switch?

intense speculation here.

 

[Christoph Wienands]

I can't find an argument against this. I think he is right. It looks quite

possible, in theory at least, to JIT a whole program instead of functions on
a call stack. Granted the start up time would absolutely suck. But I'm here
thinking that theoretically, an application is made up of functions
basically to which the JIT is applied when needed. What's to stop the JIT
from going after the whole thing assuming there was such a pill/switch?

At least one here who understands me ;-)

I know about NGen and the trade-offs to compile BEFORE the app is started.
I'm talking about doing the whole JIT process when the app is starting (and
do it again at every start-up). Well, it wouldn't be a JIT anymore but an
ASU, AtStartUp compile (not to confuse with the pre-ASU compile that NGen
does). The IL of the starting assembly is already loaded into memory and I
don't see why the JITter could not compile everything at once.

And yes, the start-up time would suck but for specialized applications I'd
absolutely be willing to take that into account if it is ensured that the
application will react as fast as possible afterwards.

Any comments from MS side on this?

Christoph

 

[Scott]

My undertstanding is that NGen stores both IL and executable code in the
same file. On startup, the loader checks to see if the machine has changed
to much to determine if it should load the executable code or the IL. How
about being able to serialise JITed code in the same way? This wouldn't
affect the run-time optimising but the next time the exe was started it
wouldn't have to go through the whole process again.

I can't help thinking that if I'm JITing something for the 500th time on the
same machine, CPU, mem, O/S, etc, that's not Just In Time - it's 499 times
too late.

 

[Scott]

My undertstanding is that NGen stores both IL and executable code in the
same file. On startup, the loader checks to see if the machine has changed
to much to determine if it should load the NGen'd executable code or the IL.
How about being able to serialise JITed code in the same way? All the
run-time optimising can still occur as normal, but the next time the code
starts it won't have to go through the entire process again.

I can't help thinking that if I'm JITing something for the 500th time on the
same machine, CPU, mem, O/S, etc, that's not Just In Time - it's 499 times
too late.

I confess to being a complete newbe, so perhaps some enlightened soul could
point out why this doesn't make sense.

 

[Tian Min Huang]

Hello Christoph,

Thanks for your feedback and I will report it to our Developer Team to see
if there is any chance that we can provide AtStartUp compile option.

In the meantime, as you know, a method is not JITed until it is called, and
then it is never JITed again during the execution of the program. So I am
afraid there are still some optimizations that will not be applied to ASU
compiler.

Please feel free to let me know if you have any concerns.

Have a nice day!

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Christoph Wienands]

Tian, thanks for the reply.

Yeah, I guess it's just not possible with the current DotNet framework, but
I hope MS will include some tweaking options in future releases

Until then I'll have to try to build an initialization procedure that calls
as many of the methods as possible.

Christoph