If memory serves me right, Dan Sugalski wrote: > This sounds pretty interesting, and I bet it could make things > faster. The one thing to be careful of is that it's easy to get > yourself into a position where you spend more time optimizing the > code you're JITting than you win in the end.
I think that's not the case for ahead of time optimisations . As long as the JIT is not the optimiser , you could take your time optimising. The topic is really misleading ... or am I the one who's wrong ? > You also have to be very careful that you don't reorder things, since > there's not enough info in the bytecode stream to know what can and > can't be moved. (Which is something we need to deal with in IMCC as > well) I'm assuming that the temporaries are the things being moved around here ?. Since imcc already moves them around anyway and the programmer makes no assumptions about their positions -- this shouldn't be a problem ?. The only question I have here , how does imcc identify loops ?. I've been using "if goto" to loop around , which is exactly the way assembly does it. But that sounds like a lot of work identifying the loops and optimising accordingly. To make it more clear -- identifying tight loops and the usage weights correctly. 10 uses of $I0 outside the loop vs 1 use of $I1 inside a 100 times loop. Which will be come first ?. Gopal -- The difference between insanity and genius is measured by success
