Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

DrGUI

Why does JIT have to do everything?

This topic is 5278 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Why, why, why? Firstly, I would like to know where some of you find out about all the optimization the JIT makes. Why does the JIT have to do things like dead code removal, loop invariant hoisting and constant copy propagation? The compiler should do this from the IL (though if you''re a neat coder, you should not really have declared unused variables in the scope of the loop). What are the patterns for the JIT to recognize vector and matrix ops so 3DNow and SSE/SSE2 can be used? There should be a force inline keyword so that IL is actually inlined rather than JIT doing all the work. I could understand loops with uninitialized variables being slower than with the variables being declared outside the loop because of the automatic setting of 0 to them, however initialized variables are still set to 0 before initialization (though I hear this is likely to change). I am soon going to gradually move to C# from VB .NET BUT... DirectCast in VB unboxes value types 10x faster than CType. C#''s cast (casttype) is most likely identical to CType in IL. Is there a way in C# to unbox variables 10x faster? I could not find anything. Any help on this?

Share this post


Link to post
Share on other sites
Advertisement
The "optimizations" that JIT compilers make are questionable in some cases, but they usually are correct.

The only real way to completely avoid it is to *drum roll* - use a fully compiled (or scripted) language. Or, if you have enough weight to throw around, complain to the VM vendor.

Share this post


Link to post
Share on other sites
the IL optimisation doesnt do stuff like dead code elimination? i''m pretty sure it would...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Technically there''s no reason why a JIT can''t do the optimisations properly, apart from the fact that its time-consuming. Other than that presumably the reason why some optimisations aren''t done at runtime is because they have been felt to be potentially hardware dependant (just because its better in one case it may not be in the next case).

Share this post


Link to post
Share on other sites
Consider templates:
C++ templates are metaprograms -- programs that produce programs that are executed. However, it slows compile times greatly and can lead to some executable size increases. Thankfully most compilers are smart enough to combine duplicate template instantiations to reduce the impact.

C# generics are handled by the JIT instead of generating runtime code, thus speeding compile times and lowering the size of executables.

This isn''t a fair comparison, because C# generics are crippled when compared to C++ templates (looks like we won''t ever see something like Loki#), but it gives you an idea of why the JIT is utilized.

JIT has a considerable advantage over conventional compilers: it can tailor programs to run in the exact environment under which they are to execute. This is more than just processor and Windows versions, it could change heap allocation strategies based on the amount of available free memory. It can automatically use SSE/3DNow! as necessary.

Even though it seems like anathema to all the high schoolers writing their MMORPG in C++ (and currently stuck in the design phase), it is feasible that a JIT executable could run faster than a natively compiled one.

Share this post


Link to post
Share on other sites
It''s technically feasable that a JIT compiler could run faster than native code, but there isn''t a VM on the market that actually achieves this in practice.

In a few more years, that may no longer be the case, but right now JIT is just too young a technology to put too much faith behind.

JIT is a wonderful technology, though, for most applications. I personally think there is no longer any reason to develop anything, save the most speed-critical applications, or things that truly require you to deal with low-level memory management and whatnot, without using JIT, be it in the form of .Net or Java technology.

Share this post


Link to post
Share on other sites
quote:
Original post by Etnu
It''s technically feasable that a JIT compiler could run faster than native code, but there isn''t a VM on the market that actually achieves this in practice.



Such a wonderful well informed OPINION . To bad its blatantly wrong; Java beats gcc:

http://www.osnews.com/story.php?news_id=5602&page=3

Share this post


Link to post
Share on other sites
quote:
Original post by DrGUI
DirectCast in VB unboxes value types 10x faster than CType. C#''s cast (casttype) is most likely identical to CType in IL.


What makes you think that? IIRC, CType comes from the VB backwards-compatibility layer.

I have no doubt that the C# cast mechanism maps as closely as possible to the underlying IL.


--
AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.
[Project site] [Blog] [RSS] [Browse the source] [IRC channel]

Share this post


Link to post
Share on other sites
yes, lets hope we don''t go down that path yet again.

the big thing, as the AP pointed out, is hardware dependency...a lot of all the wonderful optimizations that can be made depend on everything from chip to endian-ness. granted, most of those are not made yet, but might as well keep the concept cohesive.

inline code is somewhat different...statically inlining things (except in the most obvious cases like a max function or a lerp) limits you as far as dynamic compilation goes...no use in precompiling something when it might be recompiled differently by the VM and it (if its is called often) will most likely be inlined JIT anyways.

for that matter, its just byte code anyways...so wouldnt a forced inline just be a glorified preprocessing step?

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!