This makes a tremendous (2x with SSE2, 3x with AVX2) difference on big
datasets on my system, but this may be hardware-dependent (e.g.
instruction cache sizes).
Naturally, this also results in somewhat larger code for the large-data
case (~75% larger).
This includes various minor things that didn't seem right or could be
improved, including:
- XXH3_state is documented to have a strict alignment requirement of 64
bytes, and thus came with a disclaimer not to use `new` because it
wouldn't be aligned correctly. It now has an `#align(64)` so that it
will.
- An _internal proc being marked #force_no_inline (every other one is
#force_inline)
- Unnecessarily casting the product of two u32s through u128 (and
ultimately truncating to u64 anyway)
This uses compile-time features to decide how large of a SIMD vector to
use. It currently has checks for amd64/i386 to size its vectors for
SSE2/AVX2/AVX512 as necessary.
The generalized SIMD functions could also be useful for multiversioning
of the hash procs, to allow for run-time dispatch based on available CPU
features.
The prior behavior was adjusting the tag size based on the alignment of
the types in the union, even when the union has a custom alignment
specified with `#align`. This changes the behavior so that a custom
alignment, if specified, takes precedence over the alignment of the
types.
The check seems to have been assuming that rune comparisons are
unsigned, but they're signed. This was causing an assertion failure for
certain input characters (anything with an ASCII value less than
'+'/43).
The new reduce_add/reduce_mul procs perform the corresponding arithmetic
reduction in different orders than sequential order. These alternative
orders can often offer better SIMD hardware utilization.
Two different orders are added: pair-wise (operating on pairs of
adjacent elements) or bisection-wise (operating element-wise on the
first and last N/2 elements of the vector).
The indices proc simply creates a vector where each lane contains its
own lane index. This can be useful for use in generating masks for loads
and stores at the beginning/end of slices, among other things.
The new reduce_add/reduce_mul procs perform the corresponding arithmetic
reduction, in different orders than just "in sequential order". These
alternative orders can often be faster to calculate, as they can offer
better SIMD hardware utilization.
Two different orders are added for these: pair-wise (operating on
adjacent pairs of elements) or split-wise (operating element-wise on the
two halves of the vector).
This doesn't actually cover the *fastest* way for arbitrarily-sized
vectors. That would be an ordered reduction across the native vector
width, then reducing the resulting vector to a scalar in an appropriate
parallel fashion. I'd created an implementation of that, but it required
multiple procs and a fair bit more trickery than I was comfortable with
submitting to `core`, so it's not included yet. Maybe in the future.
The initial allocation for the slice is limited to prevent untrusted
data from forcing a huge allocation, but then the dynamic array was
created with a capacity of the unlimited length, rather than the actual
capacity of the allocation. This was causing a buffer overrun.
This can be important if matrices or SIMD vectors are being used in
global or static variables, as otherwise it may result in crashes due to
aligned instructions accessing misaligned variables.
The lower bound of the `bit_set` was only being applied *after*
searching for a matching enum value, so values wouldn't line up if the
minimum value of the enum wasn't 0.
The existing `mem.make_map` passes a capacity, but the builtin
`make_map` no longer takes a capacity--it was separated to
`make_map_cap` to allow for making a map without an allocation (#4340).
`core:mem` was not updated to reflect this, so any usage of `mem.make`
to make a map will currently result in a compile error.
Comparing SIMD vectors with `==` was checking that the mask of elements
that matched was not 0, meaning it succeeded if *any* element was equal,
rather than if *all* elements were equal.
This allows `*` to be used in C fashion, without specifying an argument
index to use. Like C, this results in the argument *preceding* the value
for the format specifier itself.
This affects `runtime.Arena` and `virtual.Arena`, but not currently
`mem.Arena`. These changes allow the last allocation that has been
made to be resized to a larger size by just extending their
allocation in-place, when there's sufficient room in the memory block to
do so.
Shrinking in place and re-using the rest of the allocation can be
supported using almost the same logic, but would require the memory to
be zeroed. Since this would add a additional cost that isn't currently
present, shrinking has not been changed.
Translation matrices use the w components of the matrix to apply the
transform, and thus only work when the w component is 1. In the
original raymath implementation, the multiplication is done manually
and adds the translation components directly to the result, as if w is
1, but in the Odin binding this is done with a matrix multiplication.
However, the w component is set to 0 instead of 1, resulting in the
translation not being applied.
Translation matrices use the w components of the matrix to apply the
transform, and thus only work when the w component is 1. In the
original raymath implementation, the multiplication is done manually
and adds the translation components directly to the result, as if w is
1, but in the Odin binding this is done with a matrix multiplication.
However, the w component is set to 0 instead of 1, resulting in the
translation not being applied.
Removed underscores from the AVX-512 names in `CPU_Feature` to make them match their equivalent LLVM target features. Removed 4FMAPs and 4VNNIW as there aren't matching LLVM target features.
Barinzaya
