Potential performance issue

Potential performance issue

[Dibyendu Majumdar]

Hi Dave,

I have not yet had the time to try out replacing union with struct to
check performance. Hope to do this soon. But I did try another change
and was somewhat surprised by the result.

As you know currently I take the address of a Lua stack value and then
use the pointer to manipulate the value. This is hangover from the
LLVM port as there it has to be a pointer. But in the libgccjit world,
we actually do not need the pointer unless the pointer needs to be
passed to a function. So most of the time we can just work off the
value array directly.

That is instead of:

(&base[1])->value.tt_

I can just use
base[1]->value.tt_

I was hoping that this might help performance somewhat as presumably a
pointer (going by your change to get_address) may not be optimisable.
To my surprise however the performance dropped by half after the
change. So of course I have not committed this change.

This is just an FYI as I don't intend to investigate this right now (I
have saved the changes so that I can look at this at some time in the
future).

Regards
Dibyendu

Re: Potential performance issue

[Dibyendu Majumdar]

On 15 July 2015 at 20:30, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> Hi Dave,
>
> I have not yet had the time to try out replacing union with struct to
> check performance. Hope to do this soon. But I did try another change
> and was somewhat surprised by the result.
>
> As you know currently I take the address of a Lua stack value and then
> use the pointer to manipulate the value. This is hangover from the
> LLVM port as there it has to be a pointer. But in the libgccjit world,
> we actually do not need the pointer unless the pointer needs to be
> passed to a function. So most of the time we can just work off the
> value array directly.
>
> That is instead of:
>
> (&base[1])->value.tt_
>
> I can just use
> base[1]->value.tt_

I meant base[1].value.tt_ above (sorry for the typo!)

>
> I was hoping that this might help performance somewhat as presumably a
> pointer (going by your change to get_address) may not be optimisable.
> To my surprise however the performance dropped by half after the
> change. So of course I have not committed this change.
>
> This is just an FYI as I don't intend to investigate this right now (I
> have saved the changes so that I can look at this at some time in the
> future).

Re: Potential performance issue

[Dibyendu Majumdar]

On 15 July 2015 at 20:47, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
>> As you know currently I take the address of a Lua stack value and then
>> use the pointer to manipulate the value. This is hangover from the
>> LLVM port as there it has to be a pointer. But in the libgccjit world,
>> we actually do not need the pointer unless the pointer needs to be
>> passed to a function. So most of the time we can just work off the
>> value array directly.
>>
>> That is instead of:
>>
>> (&base[1])->value.tt_
>>
>> I can just use
>> base[1]->value.tt_
>
> I meant base[1].value.tt_ above (sorry for the typo!)
>
>>
>> I was hoping that this might help performance somewhat as presumably a
>> pointer (going by your change to get_address) may not be optimisable.
>> To my surprise however the performance dropped by half after the
>> change. So of course I have not committed this change.
>>

It turns out that I had the build set to Debug build. This threw me as
the Ravi build setting should have no impact on the JIT compiler (as
it has its own setting) so not sure why the performance was degraded.


Apologies for the false alarm.

Regards
Dibyendu