[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: New LuaJIT benchmark results (was Re: [ANN] LuaJIT-2.0.0-beta3)
- From: Thomas Lavergne <thomas.lavergne@...>
- Date: Fri, 12 Mar 2010 18:34:01 +0100
Le 9 mars 2010 à 23:48, Mike Pall a écrit :
> Peter Cawley wrote:
>> Is it acceptable to use to inside-out structures strategy for the
>> benchmark, and hence implement each object as entries in three tables,
>> rather than each object being a table containing three entries?
> Nope. The idea is to be able to compare different languages using
> the same algorithms and the same approach.
On the other hand, these benchmark are a lot biased and as all other benchmarks will never anything except what we want to see in the numbers ;-)
Just an example. If you take the fankuch benchmark, the algorithm used in the Lua version is more clever than the one used in the C one. Just to see, I've made a dirty conversion of the Lua program to C and compared it with the ones on the website :
Lua algo in C 0m44
Ref1 algo in C 1m07
Ref2 algo in C 1m09
The Lua in C version is the attached one, it's really a straight conversion in very bad unoptimized C in a luaish style (1 based array). Ref1 and Ref2 are the two versions on the shoutout site with threads disable for ref1. Numbers are best of five runs of fankuch(12) but time was alway in a 1s window.
So in this benchmark at least, the algorithm probably contribute "somewhat" to the lua performances.
This is not to say LuaJIT is slow and win only by clever algorithms in bench, but just to say that the shoutouts benchmarks doesn't do always the same things, and this can have a big impact on the results.
Description: Binary data