Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fundamental flaws of SIMD ISAs (2021)

bitsnbites.eu

Post reply on HN
Print view View original

141–146 of 146 posts

Re: Fundamental flaws of SIMD ISAs (2021)

#141

Post by immibis »

kevingadd wrote: post #34
cjbgkagh wrote: post #7

Earlier quoted context omitted.

I have similar thoughts, I don't understand the push for variable width SIMD. Possibly due to ignorance but I think it's an abstraction that can be specialized for different hardware so the similar tradeoffs between low level languages and high level languages apply. Since I already have to be aware of hardware level concepts such as 256bit shuffle not working across 128bit lanes and different instructions having ver…

Part of the motive behind variable width SIMD in WASM is that there's intentionally-ish no mechanism to do feature detection at runtime in WASM. The whole module has to be valid on your target, you can't include a handful of invalid functions and conditionally execute them if the target supports 256-wide or 512-wide SIMD. If you want to adapt you have to ship entire modules for each set of supported feature flags and…

You can write code that runs on many processors or code that takes advantage of the capabilities of one specific processor - not both. Is portability (write once, run anywhere) no longer a goal of WASM? Or will every SIMD instruction be slowly emulated when run on "wrong" processors? What if the interpreter is too old to support the instruction at all?

Re: Fundamental flaws of SIMD ISAs (2021)

#142

Post by adgjlsfhk1 »

gpderetta wrote: post #100
dzaima wrote: post #43

Earlier quoted context omitted.

The limiting thing isn't necessarily speculating, but more just the number of branches per cycle, i.e. number of non-contiguous locations the processor has to query from L1 / uop cache (and which the branch predictor has to determine the location of). You get that limit with unconditional branches too.

Indeed, the limit is on taken branches, hence why making the most likely case fall through is often an optimization.

The tricky part here is that compilers are pretty bad (without PGO at least) of knowing what side of the branch matters.

Re: Fundamental flaws of SIMD ISAs (2021)

#143

Post by thierry_src »

codedokode wrote: post #85
derf_ wrote: post #49

Earlier quoted context omitted.

> I code with SIMD as the target, and have special containers that pad memory to SIMD width... I think this may be domain-specific. I help maintain several open-source audio libraries, and wind up being the one to review the patches when people contribute SIMD for some specific ISA, and I think without exception they always get the tail handling wrong. Due to other interactions it cannot always be avoided by padding.…

I think that SIMD code should not be written by hand but rather in a high-level language and so dealing with tail becomes a compiler's and not a programmer's problem. Or people still prefer to write assembly be hand? It seems to be so judging by the code you link. What I wanted is to write code in a more high-level language like this. For example, to compute a scalar product of a and b you write: 1..n | a[$1] * b[$1]…

An old attempt to this was SWAR-C, (SIMD within a register - C), that could target Neon, altivec and MMX/SSE.

I think SWAR-C nailed the syntax (a vector ?: operator, for example).

(https://aggregate.ece.engr.uky.edu/SWAR/Swarc/Scc.html)

Re: Fundamental flaws of SIMD ISAs (2021)

#144

Post by thierry_src »

One of my worry about the presented ideas, and this is present in RISC-V vector ISA if I'm not mistaken, is that register-size-independent vector instructions have random execution times depending on hardware register width.

I remember seeing presentations of extensions to AVX (during probably a supercomputing related event in Spain years ago ?) that some complex, matrix to matrix instructions could have data dependent execution time, in addition to possible hardware register size dependencies.

In some contexts, and for overall security, this could be very problematic. Has this been discussed?

Re: Fundamental flaws of SIMD ISAs (2021)

#145

Post by dzaima »

thierry_src wrote: post #144

One of my worry about the presented ideas, and this is present in RISC-V vector ISA if I'm not mistaken, is that register-size-independent vector instructions have random execution times depending on hardware register width. I remember seeing presentations of extensions to AVX (during probably a supercomputing related event in Spain years ago ?) that some complex, matrix to matrix instructions could have data depende…

RISC-V does have a Zvkt extension that requires that the set of instructions useful for crypto have data-independent timing. (it includes requiring that shuffle timings are independent of table data, but allows timings to vary across different index inputs)

Re: Fundamental flaws of SIMD ISAs (2021)

#146

Post by kjs3 »

magicalhippo wrote: post #131
kjs3 wrote: post #109

Earlier quoted context omitted.

I paid attention and I don't see where Daniel claimed that this a complete UTF-8 decoder. He's illustrating a programming technique using a simplified use case, not solving the worlds problems. And I don't think Daniel Lemire lacks an understanding of the concept or needs an AI to code it.

Agreed, but the points raised by GP are valid in terms of using that article as an argument that AVX-512 can decode UTF-8 well. It might be fast, but it's not a UTF-8 decoder. It's a transcoder to a fixed, and very limited, target encoding.

I though it was pretty clear the GP was talking about Daniels article, not the blog post, but I guess I can see two readings.
Post reply on HN