Re: Performance (was Re: Selenophobia)

[Tim Hill <drtimhill@...>]

> 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.

—Tim