lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


 
 

On 03/26/17, Tim Hill wrote:

>> On Mar 26, 2017, at 7:35 AM, Frank Kastenholz <fkastenholz@verizon.net> wrote:
>> 
>> On 3/25/17 4:48 PM, Tim Hill wrote:
>>> 
>>> In our project, we avoided the “Lua is too slow” issue by providing a
>>> robust set of fast C libraries that did all the heavy lifting, leaving
>>> Lua to do business logic and decision making. I presented it as “C =
>>> muscle, Lua = brain”, which seemed to work out ok. However, developing
>>> that C library was not made easy by some of the design decisions in the
>>> Lua C API.
>> 
>> This was a separate problem, in a different area of the app.
>> The results were non-intuitive.
>> 
>> In our project, there was some manipulation of very large arrays
>> (10's to 100's of thousands of entries). At first the inclination
>> was to do exactly what you suggest -- we imported Torch7, which has
>> some good array manipulation functions in C, into the system and the
>> app writers used it. What the ended up writing was (basically)
>> 
>> intermediate_result_1 = torch7.func1(input_array)
>> intermediate_result_2 = torch7.func2(intermediate_result1)
>> intermediate_result_3 = torch7.func3(intermediate_result2)
>> final_result = torch7.func4(intermediate_result3)
>> 
>
>We faced the same problem, and attacked it with an SIMD
>library wrapped inside a simple interpreter. The result was you
>could chain together sequences of operations/transforms into a 
>single C API call. Depending on available hardware and SIMD 
>support this would either run “vertically” (doing each operation on 
>each array element) or “horizontally” (doing each set of operations 
>completely for each element). The goal was to minimize intermediate 
>arrays and allow zero copy SIMD operations. Overall we got pretty good
>results, approx 3-5x faster than Lua.

we did some prototype/quick-and-dirty work along these lines, just to see
if it would yield good performance ... if i recall our predictions, we would have
got numbers similar to yours ... afraid I do not have that info handy anymore.

but doing a proper job wasn't an option for us (no funding, and the other work
got things "good enough" for our final customer). 

Frank