an opencl binding - zcl/panama

[Maurizio Cimadamore]

On 27/01/2020 00:41, Michael Zucchi wrote:
> 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?

Not much we can do... this is the reason as to why both Unsafe and also 
ByteBuffer have both single access operation and bulk operations. When 
you transfer bulk you exploit data parallelism in ways that are just not 
possible if you just to element by element access.

Maurizio

>
>
>
>
>