After being prodded to finally fix the bit rot that was preventing Clue 0.5 from working, I've just released version 0.6 of my C to Lua, Javascript, Java and Perl compiler. http://cluecc.sourceforge.net/ New in this release: a Lua 5.2 dialect target which uses goto. (Thank-you! Thank-you!) This has more than doubled performance using the stock Lua interpreter from Lua 5.1, which has to emulate goto using what amounts to a switch statement. Of course, LuaJIT falls upon this code with cries of glee. Backend Interpreter Whetstone gcc comparison (larger is better) (gcc) 2500 100% lua LuaJIT jon 2500 100% c gcc 2400 96% java Sun Java 6 790 32% lua LuaJIT joff 155 6.2% js node.js (V8) 110 4.4% lua Lua 5.2.1 84 3.4% lua Lua 5.1.3 29 1.2% perl5 Perl 5 2.7 0.11% Now, don't get too excited; the Whetstone benchmark is wholly synthetic and not indicative of anything much. But, yes, some of the subbenchmarks (and some of the other test loads I'm running) *are* running on LuaJIT faster than they run when compiled directly with gcc (with -Os). I suspect this is mostly due to loop unrolling, which is a bit unfair. I'm also running some of the CLBG tests, which are slightly more real-world (although only slightly). The results of the Mandelbrot test look a bit more realistic: Time Factor (smaller is better) gcc 0.098 1.000 clue -> c 0.149 1.514 luajit2-jon 0.376 3.835 java 1.011 10.299 luajit2-joff 3.487 35.520 js 4.281 43.610 lua52 6.454 65.749 lua51 11.050 112.566 perl5 42.619 434.153 If anyone can suggest any more real-world test loads that are worth trying, I'd like to give them a go --- although bear in mind that Clue's C environment is *distinctly* weird, although mostly standards-compliant, and the runtime library is almost non-existent. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ "Of course, on a sufficiently small planet, 40 km/hr is, in fact, │ sufficient to punt the elastic spherical cow into low orbit." --- │ Brooks Moses on r.a.sf.c
Attachment:
signature.asc
Description: OpenPGP digital signature