[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: LuaJIT - Trace aborted again
- From: Benjamin Segovia <segovia.benjamin@...>
- Date: Wed, 20 Jul 2011 10:16:30 +0000
Basically, I think the issue is somehow:
if you have a very long instruction stream with no branch inside a
deeply nested branch, there is a problem to generate traces.
Something like that.
I will try to make a self contained code tomorrow.
Ben
On Wed, Jul 20, 2011 at 10:05 AM, Benjamin Segovia
<segovia.benjamin@gmail.com> wrote:
> ... and conversion is of course the behaviour we want since in Lua,
> every computation is done with double. But still, maybe that may make
> sense to notify this point
>
> On Wed, Jul 20, 2011 at 10:03 AM, Benjamin Segovia
> <segovia.benjamin@gmail.com> wrote:
>> It is more complicated to generate the code like that because there
>> may be a lot of "break instruction" (the machine supports native
>> structured branch instructions) and this will require to _nest_ more
>> and more successive basic blocks into if statements.
>> In C, you will just use goto. Here I really try to simulate a forward branch.
>>
>> Also, LuaJIT really behaves strangely. Because using lot of branches
>> to simulate forward jumps does not seem to be really the problem. The
>> weird thing is that for some reason, if a sequence of _lua_ statements
>> with no branch at all is too _big_ then no trace is compiled. If I add
>> for loops for each statement (I do _not_ unroll the vector
>> computations), then the for loops are compiled and performance is way
>> better.
>>
>> Also, when I do:
>> vec2[i] = vec1[i] + vec0[i]
>>
>> vec2.vec1 and vec0 also are ffi arrays (allocated with ffi.new(...))
>> and sse conversions instruction must be issued back and forth (for
>> reads and writes) since vec* are used to simulate register files with
>> different element size (byte,word,dword...)
>>
>>
>> Ben
>>
>>
>> On Wed, Jul 20, 2011 at 9:47 AM, Tony Finch <dot@dotat.at> wrote:
>>> Benjamin Segovia <segovia.benjamin@gmail.com> wrote:
>>>
>>>> I need to handle forward jumps with the idiom:
>>>>
>>>> while true do
>>>> {... a lot of compute ...}
>>>> if some_condition_on_the_lane_of_the_simd_vector then break end
>>>> {... a lot of compute ...}
>>>> break -- this one is to exit anyway
>>>> end
>>>
>>> Why not this?
>>>
>>> {... a lot of compute ...}
>>> if not some_condition_on_the_lane_of_the_simd_vector then
>>> {... a lot of compute ...}
>>> end
>>>
>>> Tony.
>>> --
>>> f.anthony.n.finch <dot@dotat.at> http://dotat.at/
>>> Tyne, Dogger: Variable becoming northeast, 3 or 4. Slight or moderate.
>>> Thundery showers. Good, occasionally poor.
>>>
>>>
>>
>