ref: Restore explicit vectorization in the Vc AoS plugin

[niermann999]

This refactors the Vc AoS plugin to use explicitly vectorizing Vc types again. Also adds it to the benchmarks and tests. Since not all functionality is implemented, yet, I split the test suite into three blocks, so that new plugins can be implemented incrementally with testing enabled. Finally, I harmonized the naming between this plugin and the new SoA plugin.

Also removes the warmup from the bencharmks, since google benchmark can be configured to do that for us.

Edit: I refactored the vc_aos::transform3 and matrix44 types, so that are shared between Vc AoS and SoA now

[niermann999]

Based on #97 , so that the storage vector type can be reused and vc_array4 replaced with something more generic. This will be helpful for generalizing the plugin to higher dimensional types later

[beomki-yeo]

It seems Vc AoS gets slower with double for some cases, is that normal?

[niermann999]

It seems Vc AoS gets slower with double for some cases, is that normal?

It is expected for vectorized code to be about half as slow in double precision as in single precision (half the number of values fits into the same number of bits in the registers). I believe that the cmath plugin is slower in double precision could be hint that it is in fact partly autovectorized. Why Vc AoS is so much slower than cmath in double precision I don't know, but this is what I have seen before as well.

[beomki-yeo]

Yes I was asking why Vc double is slower than cmath double (not w.r.t float). Thanks for the answer

[niermann999]

These benchmarks are a bit outdated though (and also done with CPU scaling, so that e.g. addition and subtraction show different results). It works much better running:

./bin/algebra_benchmark_array_vector --benchmark_min_warmup_time=1000 --benchmark_repetitions=50 --benchmark_time_unit=ms --benchmark_display_aggregates_only=true --benchmark_enable_random_interleaving=true

with CPU scaling disabled

[niermann999]

The CI failure does not seem to be related to this PR, see #123