Re: At the edge of LNUM patch

[Asko Kauppi <askok@...>]

In my view, Mike's results are in line with the Core Duo results I had  
measured.

What cannot be done is treat x86 as a single optimization target. It  
is not.

Then again, modern x86's are utterly fast on FP, which they calculate  
as fast as integers. The goal with them is to not slow down unpatched  
performance, and it is not totally clear to me where the -2..-8%  
slowdown actually comes from. I will have a look.

-asko


Bogdan Marinescu kirjoitti 27.3.2008 kello 10:45:
> Also, your results seem to be in contradiction with the benchmarks  
> posted here :
>
> http://luaforge.net/frs/?group_id=214
>
> Personally though I'm much more worried about the segfaults, as I  
> plan to use LUA on a standard ARM7TDMI core without a FPU, and I  
> don't even have to run a benchmark, I know LNUM will give a huge  
> improvement performance-wise. But I'm also curious about the  
> 'desktop' results.
>
> On Thu, Mar 27, 2008 at 2:32 AM, 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