lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 3/26/08, Mike Pall <mikelu-0803@mike.de> wrote:
> Miles Bader wrote:
>  > Asko Kauppi <askok@dnainternet.net> writes:
>  > > The easiest way to achieve this is to only use the int32 mode. It would
>  > > boost performance on non-FPU platforms, and cause absolutely no
>  > > behaviour or accuracy changes on double+int32 configured desktop
>  > > machines.
>  >
>  > Is there any real _advantage_ on typical desktop machines (there's an
>  > obvious disadvange, which is code bloat)?
>
>
> Well ... draw your own conclusions:
>
>  Here are some benchmarks for Lua 5.1.3 vs. Lua patched with LNUM
>  260308 (double/int32) on an Intel Core 2 @ 2.13 GHz. Both are
>  compiled with GCC 4.1.2 -O3 -fomit-frame-pointer.
>
>  Benchmark    | LNUM better (+) or worse (-) than Lua
>  -------------+--------------------------------------
>  binarytrees  |  -2%
>  chameneos    |  -3%
>  cheapconcr   |       LNUM: Lua error
>  cheapconcw   |       LNUM: Lua stack overflow
>  fannkuch     |  -4%
>  fasta        |       LNUM: Segmentation fault
>  knucleotide  |  -4%
>  mandelbrot   | -20%
>  nbody        |       LNUM: Segmentation fault
>  nsieve       |  -3%
>  nsievebits   |  -9%
>  partialsums  | -12%
>  pidigits     |       LNUM: Segmentation fault
>  recursive    |  -3%
>  regexdna     | +-0%
>  revcomp      |  -8%
>  spectralnorm |  +1%
>  sumfile      | +14%  (this mainly measures strtol vs. strtod)
>  SciMark      |       LNUM: Segmentation fault
>
>
>  --Mike

Mike,
thanks for hard evidence! This confirms what I thought all along --
there is no point to LNUM on x86.

--Leo--