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