| |||||||||||||
GCC Explorer - an interactive take on compilationGCC Explorer - an interactive take on compilationPosted May 25, 2012 6:59 UTC (Fri) by gughur (guest, #83256)In reply to: GCC Explorer - an interactive take on compilation by khim Parent article: GCC Explorer - an interactive take on compilation
That's a good example where a JIT could significantly outperform
a traditional compiler. It could figure out that printf is being called with the same locale and same format string all the time and generate special case fast path code for that.
(Log in to post comments)
GCC Explorer - an interactive take on compilation Posted May 25, 2012 10:50 UTC (Fri) by dgm (subscriber, #49227) [Link]
Except that it is not. The locale can change at anytime, so the jitter has to include a test for locale before the "fast" path. Pooof!, your improvement just (almost) went away and you added a whole lot of complexity to the machinery.
Beware of silver bullets.
GCC Explorer - an interactive take on compilation Posted May 25, 2012 11:50 UTC (Fri) by gioele (subscriber, #61675) [Link]
> Except that it is not. The locale can change at anytime, so the jitter has to include a test for locale before the "fast" path. Pooof!, your improvement just (almost) went away and you added a whole lot of complexity to the machinery.
Except that it is still possible in most cases. For example the JRuby JIT + Java JIT will optimise various paths and functions and keep these optimised versions around until the "environment" changes. In that case it stops the world, throws away the old compiled units and create new ones taking into account the current situation. In practical terms this means that using `eval` works flawlessly but kills your performance.
GCC Explorer - an interactive take on compilation Posted Jun 13, 2012 8:15 UTC (Wed) by massimiliano (subscriber, #3048) [Link] The V8 Javascript VM does the same...
|
|||||||||||||