Nicolas, How will your JIT code work. I presume you have to generate op codes for intel and power pc code for mac & windows? Or are you just supporting intel. Or do you have some other more clever plan up your sleeve that is somehow processor neutral?
I am curious about this because I am a little worried about the performance issues that alex has described here. I am going to be running neko in an embedded environment on a 140mhz coldfire (68k) processor. I havent been able to run any benchmarks yet because I will not have prototypes for another month. But if it looks like the performance isnt as good as thought, it might effect my application. This thread just sent a shiver down my spine. Regards Hank On 7/1/06, Alex Drahon <[EMAIL PROTECTED]> wrote:
>> I'm still playing with some benchmarks, mostly from the shootout. >> I made a tentative implementation of a file_read_line function in >> neko's std lib, which allowed me to write a File iterator for haXe. > > http://shootout.alioth.debian.org/debian/benchmark.php? > test=sumcol&lang=gcc > > file_read_line in C is implemented a lot more trivialy. > It's not "correct" since it limits the line size to 128 but it > seems acceptable for the shootout. > ok, it's just that it's a limiting factor to not have it in neko > Other thing, it that you're not benchmarking Neko there, but haXe. > There's additional things done in haXe : > - wrapping the Neko string into the object String > - iterators > I know, I'm not trying to make an 'honest' benchmark but to get a general feeling of the performance I would get. That's why I'm not trying to optimize everything to the max > var s = 0; > try { > while( true ) > s += Std.parseInt(f.readLine()); > } catch( e : Dynamic ) { > neko.Lib.print(s); > } It's a little convoluted... >> As far as benchmarking is concerned, neko feels on par with >> Python, which is to say not very fast compared to VM based >> language like Java or even Lua. Lua is certainly the fastest >> interpreted language there is. > > It depends a lot what you're benchmarking and how. The main > difference between Lua and Neko VM are : > > a) Neko has different data structures (object, array, string, > integer) with different representations, this should perform better > and allow more strictly typed program > > b) I think Lua VM is using threaded code optimizations (only > available on GCC) which can speedup opcode dispatching by 50%. It > has not been added on Neko yet. > > On which platform are your running your benchmarks ? Which which > compiler did you compiled Neko ? > I'm testing on OS X, everything is compiled with GCC 4. I'm comparing with Lua because you've been pretty dismissive of its performance on many occasions. I also ran some of your neko programs in the bench directory and most of the time neko is 3 times slower than Lua (except for binary-trees where neko is almost as fast as java). >> I'm still playing with these not so serious benchmarks to get a >> feel of the platform's strengths and weaknesses, right now I'm a >> little surprised not to see any gains over Python... > > If you post your code and results, I'll have a look and try to > explain why. Neko might indeed need some optimizations, but they > will come with JIT this summer. Keep your benchmarks so you can run > them again at this time ;) The problem with posting results is that it can be a little misleading due to the varying conditions in which the test are run. I'm not that interested about performance but you've talked a lot about the performance of Neko, so I wanted to have a feel of it. Have you compared your Neko bench programs with Lua? Cheers Alex -- Neko : One VM to run them all (http://nekovm.org)
-- Neko : One VM to run them all (http://nekovm.org)
