Replace raw vector

[clusty]

This is a pre-requisite refactor for a crash / memory coruption bug. The RawVector implementation is unsafe: in debug bounds are not checked leading to memory corruption. Also empirical tests seem to make STL Vectors slightly faster. RawVectors used a custom allocations that were 32bit aligned (for SIMD math). on 64bit Architectures all STL vectors are guaranteed to be 32 bit aligned as well.

@cguer Pls check no regressions appear:

• Try using: mesh (with/without vertex colours), point and curve data.
• Please do your tests on Win/OSX

[unity-cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[i-saint]

I just noticed this PR. I want to explain why I added RawVector. I don't intend to stop this change, but I just want you to know. there were two reasons:

1. for faster resize(). std::vector::resize() initialize newly added elements. POD types like float3 are zero cleared. zero clear for huge vertex arrays is surprisingly slow. I realized the fact by profiling with VTune, and it was the big reason to add RawVector.

2. for 32 byte align. malloc()ed memory is guaranteed to 16 byte aligned , but not guaranteed to 32 byte aligned (on Windows). aiSIMD.ispc uses AVX-512 if available and in that case, non 32 byte aligned memory causes a crash. I think this is still the case, but this problem can be easily avoided by removing avx512skx-i32x16 target (CPUs with AVX-512 are quite rare) or adding a custom aligned allocator for std::vector.

[clusty]

I just noticed this PR. I want to explain why I added RawVector. I don't intend to stop this change, but I just want you to know. there were two reasons:

1. for faster resize(). std::vector::resize() initialize newly added elements. POD types like float3 are zero cleared. zero clear for huge vertex arrays is surprisingly slow. I realized the fact by profiling with VTune, and it was the big reason to add RawVector.
2. for 32 byte align. malloc()ed memory is guaranteed to 16 byte aligned , but not guaranteed to 32 byte aligned (on Windows). aiSIMD.ispc uses AVX-512 if available and in that case, non 32 byte aligned memory causes a crash. I think this is still the case, but this problem can be easily avoided by removing avx512skx-i32x16 target (CPUs with AVX-512 are quite rare) or adding a custom aligned allocator for std::vector.

Hey,

Unfortunately this PR is agonizing for a very long time so who knows when it will get merged.... I am encountering a a bunch of crashes with RawVectors because they write out of bounds and this makes it very hard to debug (the stl vector is checked for bounds I think when building in debug).

Empirical checks have shown that the StlVector is a tiny bit faster compared to RawVector (granted I checked only briefly on my OSX)

Thanks a lot for the heads up regarding alignment: I have a buggy aligned allocator already implemented but did not push it. I thought I read that "int" is always 4 byte aligned on 64bit systems.

[lucillecaillaud]

We have no intention to put more effort into this for now. This PR is linked in the related JIRA ABC-76 in the comment and can be re-opened when appropriate.