[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Re: Performance (was Re: Selenophobia)
- From: Frank Kastenholz <fkastenholz@...>
- Date: Mon, 27 Mar 2017 08:51:00 -0500 (CDT)
On 03/26/17, Tim Hill wrote:
>> On Mar 26, 2017, at 7:35 AM, Frank Kastenholz <firstname.lastname@example.org> 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).