[HN Gopher] I want a good parallel language [video]
___________________________________________________________________
I want a good parallel language [video]
Author : raphlinus
Score : 43 points
Date : 2025-11-04 06:35 UTC (1 days ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| ChadNauseam wrote:
| Raph and I also talked about this subject here:
| https://www.popovit.ch/interviews/raph-levien-simd The discussion
| covers things at a relatively basic level as we wanted it to be
| accessible to a wide audience. So we explain SIMD vs SIMT,
| predication, multiversioning, and some more.
|
| Raph is a super nice guy and a pleasure to talk to. I'm glad we
| have people like him around!
| SamInTheShell wrote:
| Went in thinking "Have you heard of Go?"... but this turned out
| to be about GPU computing.
| nasretdinov wrote:
| Well, they said "good" :). Go we already have, that is correct.
|
| P.S. I'm joking, I do love Go, even though it's by no means a
| perfect language to write parallel applications with
| fifilura wrote:
| SQL.
|
| It is a joke, but an SQL engine can be massively parallel. You
| just don't know it, it just gives you what you want. And in many
| ways the operations resembles what you do for example in CUDA.
|
| CUDA backend for DuckDB or Trino would be one of my go-to
| projects if i was laid off.
| drivebyhooting wrote:
| My issue with SQL is lack of composability and difficulty of
| debugging intermediate results.
| asadm wrote:
| is it a language problem though? it's just lack of tooling.
| theLiminator wrote:
| The dataframe paradigm (a good example being polars) is
| another good alternative that's more composable (imo).
| dvrp wrote:
| If you want to work in data engineering for massive datasets
| (many petabytes) pls hit me up!
| v9v wrote:
| There were a few languages designed specifically for parallel
| computing spurred by DARPA's High Productivity Computing Systems
| project. While Fortress is dead, Chapel is still being developed.
| zokier wrote:
| iirc those were oriented more towards large HPC clusters rather
| than computation on single node?
| Jtsummers wrote:
| Chapel, at least, aims for both. You can write loops that it
| will try to compile to use SIMD instructions, or even for the
| GPU: https://chapel-lang.org/docs/technotes/gpu.html
| convolvatron wrote:
| the distinction matters less and less. Inside the GPU there
| is already plenty of locality to exploit (catches,
| schedulers, warps). nvlink is a switch memory access network,
| so that already gets you some fairly large machines with
| multiple kinds of locality.
|
| throwing infiniband or IP on top is really structurally more
| of the same.
|
| Chapel definitely can target a single GPU.
| cubefox wrote:
| Unfortunately his microphone did not cooperate.
| abejfehr wrote:
| Bend comes to mind as an attempt at this:
| https://github.com/HigherOrderCO/Bend
|
| Disclaimer: I did not watch the video yet
| dandanua wrote:
| I think a good parallel language will be the one that takes your
| code written with tasks and channels, understands its logic,
| rewrites and compiles it in the most efficient way. I don't feel
| that I have to write something harder than that as a pity human.
| convolvatron wrote:
| mapping from channels to SIMD seems kind of intractable, its a
| kind of lifting that involves looking across the producers and
| the consumers.
|
| going the other direction, making channel runtimes run SIMD, is
| trivial
| Munksgaard wrote:
| Interesting talk. He mentions Futhark a few times, but fails to
| point out that his ideal way of programming is almost 1:1 how it
| would be done in Futhark.
|
| His example is: sequence .map(|x: T0|
| ...: T1) .scan(|a: T1, b: T1| ...: T1)
| .filter(|x: T1| ...: bool) .flat_map(|x: T1| ...:
| sequence<T2>) .collect()
|
| It would be written in Futhark something like this:
| sequence |> map (\x -> ...) |> scan (\x y -> ...)
| |> filter (\x -> ...) |> map (\x -> ...) |>
| flatten
| Munksgaard wrote:
| Also, while not exactly the algorithm Raph is looking for, here
| is a bracket matching function (from Pareas, which he also
| mentions in the talk) in Futhark:
| https://github.com/Snektron/pareas/blob/master/src/compiler/...
|
| I haven't studied it in depth, but it's pretty readable.
| pythomancer wrote:
| (author here) check_brackets_bt is actually exactly the
| algorithm that Raph mentions
| Munksgaard wrote:
| Thanks for clarifying! It would indeed be interesting to
| see a comparison between similar implementations in other
| languages, both in terms of readability and performance. I
| feel like the readability can hardly get much better than
| what you wrote, but I don't know!
| raphlinus wrote:
| Right. This is the binary tree version of the algorithm,
| and is nice and concise, very readable. What would take it
| to the next level for me is the version in the stack monoid
| paper, which chunks things up into workgroups. I haven't
| done benchmarks against the Pareas version (unfortunately
| it's not that easy), but I would expect the workgroup
| optimized version to be quite a bit faster.
| convolvatron wrote:
| I've been playing with one using scans. too bad that's
| not really on the map for architectural reasons, it opens
| up a lot of uses.
| MangoToupe wrote:
| prolog?
| swatson741 wrote:
| So he wants a good parallel language? What's the issue? I haven't
| had problems with concurrency, multiplexing, and promises.
| They've solved all the parallelism tasks I've needed to do.
| pbronez wrote:
| The audio is weirdly messed up
| raphlinus wrote:
| Yes, sorry about that. We had tech issues, and did the best we
| could with the audio that was captured.
| awaymazdacx5 wrote:
| Lower-level programming language, which is either object-oriented
| like python or after compilation a real-time system transposition
| would assemble the microarchitecture to an x86 chip.
___________________________________________________________________
(page generated 2025-11-05 23:00 UTC)