[vector] question - should vectors be long lived?

[Vladimir Ivanov]

> I've written a SIMD RNG, which can generate me a float or int 
> pseudo-random number for each lane. Currently it stores the seeds (half 
> a long per lane) as a LongVector field in the RNG class. This RNG is 
> sampled from hundreds or thousands of times before it's thrown away and 
> recreated at the start of the next iteration. As a consequence this 
> LongVector is quite long lived, which probably means it's being boxed 
> and unboxed.
> 
> I've got a few questions along these lines:
> - Is it sensible to have a long lived vector in the current implementation?

Yes, it's a perfectly valid scenario for constants.

Probably, for your particular use case, it's worthwhile to keep the 
vector in long[] array and avoid boxing when storing into it. Otherwise, 
for every update of the seed new box would be allocated.

> - Is it sensible to do this in the future when Vector is a value and so 
> shouldn't have boxing 
Currently long-lived vectors can cause boxing issues in some cases due 
to limitations of vector box elimination analysis. Full-blown value 
types should solve it. There'll still be corner cases when vectors have 
to be placed in memory (for value types it's called "buffering" instead 
of "boxing"), but it shouldn't limit JIT-compiler ability to optimize 
away those buffers.

Best regards,
Vladimir Ivanov


> - If it's never a good idea to do this, is there any way to make it 
> obvious it's a bad idea?
> 
> The reason my code has an RNG like this is that it allows me to 
> essentially treat the AVX unit the way I treat a GPU in CUDA, as a 
> fairly wide multithreaded computation engine. It's not the best idea to 
> do this in CUDA (the same way it's not a great idea to do it in the 
> Vector API) without realising it's just a big SIMD underneath, but it 
> does make some programming tasks simpler. Having the SIMD accelerate a 
> single thread of computation rather than running multiple "threads" 
> essentially independently is a lot harder for certain classes of 
> algorithms.
> 
> Thanks,
> 
> Adam
>