Re: LuaJIT2 performance for number crunching

[Josh Haberman <jhaberman@...>]

Mike Pall <mikelu-1102 <at> mike.de> writes:
> Josh Haberman wrote:
> > Mike Pall <mikelu-1102 <at> mike.de> writes:
> > > Rule #437: Never hoist out constants (if possible)!
> > 
> > This seems like a big limitation to me -- is there any way to
> > work around it?
> 
> You are overdramatizing. I've given advice on how to speed up your
> code. You can happily ignore that, but then please don't complain.

I'm sorry if my message came off as complaining; it was not
my intent.  I wanted to understand the nature of the difficulty.
I am so delighted and impressed with LuaJIT overall that if I
didn't restrain my effusiveness I would probably embarrass you.

> Recognizing single-assignment requires per-module analysis of the
> bytecode. That would cover number or string constants.

That is the case we were talking about in this thread.  Do you
currently do any per-module analysis when you are compiling Lua
source into your IR?  If so, would it be reasonable to do this
number/string-constant analysis then?

> But the far
> more interesting case is to treat something like this as const:
>   local sin = math.sin

I can recognize that this is much more difficult to infer
constness from.  But this isn't as big of an issue IMO because
hoisting an assignment like this doesn't make the code *less*
efficient (AFAIK), as it currently does with a number or string
constant.

  for i=1,n do
    foo(math.sin)  -- if I hoist this, efficiency is >= status quo.
    foo(1/5)       -- if I hoist this, efficiency gets worse!
  end

Just solving the number or string constant case would be a big and
very welcome improvement IMHO, because it would mean that hoisting
(which in the source code looks intuitively efficient) won't
actively harm performance.

Josh