←back to thread

Concurrency in Haskell: Fast, Simple, Correct

(bitbashing.io)
193 points ingve | 3 comments | 14 Apr 25 10:47 UTC | HN request time: 0.682s | source
Show context
kookamamie ◴[17 Apr 25 14:23 UTC] No.43717304[source]▶
> 1. Compose the program into several threads of execution, traditionally scheduled and ran by the operating system

The step 0 is missing:

Compose the program into several lanes of execution, traditionally executed via SIMD.

This is a massive piece of performance left on the table on modern computer architectures, by assuming threading is the first manifestation of concurrency.

replies(1): >>43717801 #
1. jayd16 ◴[17 Apr 25 14:54 UTC] No.43717801[source]▶
SIMD has been somewhat of a massive failure in this regard. Unlike threads, most languages seem to ignore its existence and abdicate its usage to the sufficiently complex compiler.

I wish there was better author time feedback to the developer on where they're getting such a perf boost. As far as I'm aware there's no popular linting or blue squiggle to guide you in the right direction.

In games it seems like the popular pattern is to rewrite everything entirely in an entity component system framework.

replies(1): >>43719226 #
2. kookamamie ◴[17 Apr 25 16:38 UTC] No.43719226[source]▶
Agreed completely. Most auto-vectorization approaches are hit-miss and you still cannot have big-binaries, where instruction set is decided dynamically, trivially.

ISPC comes close, but does come with a learning curve.

replies(1): >>43725954 #
3. SleepyMyroslav ◴[18 Apr 25 07:52 UTC] No.43725954[source]▶
I would say that Highway [1] comes close. Can't say anything about ISPC because in gamedev work it never even came into consideration for multiple platforms.

1. https://google.github.io/highway/en/master/