an opencl binding - zcl/panama

[Michael Zucchi]

On 28/1/20 11:10 pm, Maurizio Cimadamore wrote:
> So, I took a better look and I have some news.
>
> The first thing tripping the benchmark up is this:
>
>         int len = (int)(seg.byteSize() >>> 3);
>
> If you replace it with:
>
>         int len = ((int)seg.byteSize() >>> 3);
>
> Or, even better, with:
>
>         int len = ((int)seg.byteSize() / 8);
>

A bit pedantic perhaps but the first allows a maximum equivalent long 
length of 0x7fffffff entries (matching long[].length max).  The second 
0x1fffffff, and the third 0x0fffffff.

>
> Then the segment version comes out on top:
>
>   0.497758726 array
>   0.836574479 bb stream
>   0.446651107 segment
>   0.482202441 bb index
>   2.767206835 bb over segment
>
> Of course I'm not suggesting that the code you wrote doesn't make 
> sense - I think this shows that (a) segments have the potential to be 
> very fast but (b) we have some work to do on the VM side to smooth out 
> the performance side of things.
>
Nice!  And thanks for the detail.

I guess it means the bulk interface isn't really necessary if it isn't 
otherwise more convenient or you're doing more than a copy. (with the 
obvious caveat that bulk copies can hide internal / jvm specific details 
like the long opcode issue).