[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: At the edge of LNUM patch
- From: "Leo Razoumov" <slonik.az@...>
- Date: Wed, 26 Mar 2008 20:50:52 -0400
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--