#To SIMD and beyond: Optimizing a simple comparison routine

1 messages · Page 1 of 1 (latest)

grave sentinel
tawdry finch
#

nice, i saw you messing with this the other day and was curious what it was about

#

a couple things, you dont need to @intCast when upcasting, const left_vec: @Vector(4, u8) = .{ left.a, left.b, left.c, left.d }; works fine
and on godbolt you should set either an explicit target or cpu, since zig compiles for native by default and godbolt might move to a different machine across compilations you might get wildly different results with any random change to the source

rough portal
#

i previously thought vectors only got bit-packed for element types smaller than a byte
seems like that's not the case

karmic frigate
# grave sentinel https://zig.news/inspectorboat/to-simd-and-beyond-optimizing-a-simple-comparison...

"Calculate a - b, and see if overflow occurs."
I'm unsure if "simply computing a-b" works (portably), because the underflow/overflow might spill to neighboring registers.
The typical approach is to use a dedicated instruction or check the overflow flag of the cpu or reserve leading bit to handle over/underflow gracefully.
(either input1 or input2 must have input range clamped).

This is a design tradeoff/problem of compiler/cpus, because they allow no introspection which registers are assigned to which cpu memory (dynamically or statically), because CPU cores have different number of ports with different functionality to parallelize computations.

The conclusion sounds like LLVM can not estimate gains for SWAR or low level bit shuffling techniques, which was also observed by Validark in these issues: https://github.com/llvm/llvm-project/issues/created_by/Validark as fallout of https://github.com/Validark/Accelerated-Zig-Parser. Notably, LLVM has no SWAR fallback for architectures without SIMD support.

Were SIMD vs SWAR optimizations reported to llvm issue tracker?

#

That aside, the article looks great.

karmic frigate
#

That said, I'm not sure overflow will wrap, especially on inlining the fn. It might just be optimized further somewhere in an undefined way.

primal garnet
#

hmm I think regardless of whether or not you have tooling for the register mapping, there's not much you can deduce from that in a general sense because modern CPU's map the ISA register to whatever they do internally which is more than likely 4 redundant internal registers than can be used