RE: Running BoundsChecker on 5.0.2

["Richard Ranft" <rranft@...>]

Funny how things work now, isn't it?  Things that used to be more efficient
are now the slowest way to do things because it's faster to just move the
whole thing than to figure out what you want to move....

Rich

> -----Original Message-----
> From: lua-bounces@bazar2.conectiva.com.br
> [mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Mike Pall
> Sent: Sunday, February 26, 2006 6:02 AM
> To: Lua list
> Subject: Re: Running BoundsChecker on 5.0.2
>
>
> Hi,
>
> Michael Abbott wrote:
> > Just for interest sake, how much memory of this type is getting copied
> > around?
>
> Very often. Assignments, function calls and returns are the most
> common causes. Just look for the setobj (and variant) macros in
> the source.
>
> > I would have though that copying around data that just gets
> > overwritten again / never used would have been a bad sign (from an
> > efficiency standpoint)?
>
> Not really. Copying a TObject (TValue in Lua 5.1) struct is
> cheap. This is 3 loads and 3 stores on a 32 bit platform (with
> lua_Number = double). Most of it is in the L1 D-cache. Reordering
> is easy because there are no data dependencies.
>
> The alternative would be a switch statement which copies only the
> needed parts depending on the type. This takes between 1-3 loads
> and 1-3 stores. But it includes one unpredictable branch and several
> instructions for range checking and computing the branch target.
> And branches to join the control flow, too.
>
> The unpredictable branch alone is worth between 10-20 cycles on
> recent x86 CPUs. This is more than the whole struct copy. And the
> I-cache would be hit really hard if you inlined all of this. Also
> reordering is more difficult. Summary: this would be dead slow.
>
> More info about optimizing code for modern CPU architectures:
>
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech
> _docs/25112.PDF
>   http://www.agner.org/assem/
>   http://arstechnica.com/articles/paedia/cpu.ars
>
> Bye,
>      Mike