an opencl binding - zcl/panama

Michael Zucchi notzed at gmail.com
Mon Jan 27 00:41:11 UTC 2020


On 27/1/20 10:50 am, Maurizio Cimadamore wrote:
>
> On 26/01/2020 04:52, Michael Zucchi wrote:
>> public static <T extends Native> MemoryAddress toLongV(Allocator 
>> frame, long[]array) {
>>         MemoryAddress list = frame.alloca(8 * array.length);
>>
>>         for (int i=0;i<array.length;i++)
>>             setLong(list, i, array[i]);
>>
>>         return list;
>>     }
>>
>> vs
>>
>>     public static <T extends Native> MemoryAddress toLongV(Allocator 
>> frame, long[]array) {
>>         MemoryAddress list = frame.alloca(8 * array.length);
>>
>> MemoryAddress.copy(MemorySegment.ofArray(array).baseAddress(), list, 
>> 8 * array.length);
>>
>>         return list;
>>     }
>>
>> Yeah sorry, that really isn't selling it for me!  Even if i didn't 
>> have issues with the design it's more typing and harder to read. For 
>> the one taking Native[] I need a loop anyway and i like a consistent 
>> look to related functions that do consistent things. These functions 
>> are for argument setup only and for small buffers, for potentially 
>> large buffers i'm mostly using asByteBuffer() at the moment (mostly 
>> because of api familiarity).
>
> To clarify this point - just to make sure the message is clear - my 
> observation about MemoryAddress::copy is not about code clarity - the 
> performance model of the two versions is radically different. The 
> former copies element one by one - the second makes a bulk transfer. 
> If you do a benchmark there's just no comparison between the two 
> versions.
>

Well I mean if the api is that much slower ... really shouldn't it be 
improved?







More information about the panama-dev mailing list