I want a good parallel language [video] • Hacker News Board

Re: I want a good parallel language [video]

#61

Post by seanmcdirmid » Fri, Nov 07, 2025, 4:25 AM UTC

rramadass wrote: post #60

jerf wrote: post #55

Earlier quoted context omitted.

There's no need for research. The answer is simple: You can't run Erlang concurrency on a GPU. GPUs fundamentally get their advantage by running the same operations on a huge set of cores across different data. They aren't just Platonically faster than CPUs, they're faster than CPUs on very, very specific tasks. Out of the context of those tasks, they are in fact massively, massively slower . Some of the operations E…

Not what i meant (these are superficialities). Erlang is a concurrency-oriented language though its concurrency architecture (multicore/node/cluster/etc.) is different from that modeled by GPUs (Vectorized/SIMD/SIMT/etc.) Since share-nothing Processes (so-called Actor model) are at the heart of the Erlang Run Time System(ERTS)/BEAM it is easy to imagine a "group of Erlang processes" being mapped directly to a "group…

The biggest issue I think is utilizing massive GPU memory bandwidth, you really need SIMD or your GPU is just going to generate a lot of heat to do only a bit of work.

Re: I want a good parallel language [video]

#62

Post by rramadass » Fri, Nov 07, 2025, 4:26 AM UTC

icandoit wrote: post #58

rramadass wrote: post #46

Earlier quoted context omitted.

Yeah, i too was looking for Erlang. The thing i would really like to see is some research on how to run the Erlang concurrency model on a GPU.

Something like vine lang or something built on interaction nets might be close to what you are looking for. It can run on GPU.

Right; but since Erlang is already concurrency-oriented i was thinking it might be easier to add the GPU model to its runtime. See my other comment here - https://news.ycombinator.com/edit?id=45843523

Re: I want a good parallel language [video]

#63

Post by snthpy » Fri, Nov 07, 2025, 4:29 AM UTC

Munksgaard wrote: post #11

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 ) .collect() It would be written in Futhark something like this: sequence |> map (\x -> ...) |> scan (\x y -> ...) |> filter (\x…

Very cool. I have seen Futhark mentioned before but I don't know anything about it.

The example you showed is very much how I think about PRQL pipelines. Syntax is slightly different but semantics are very similar.

At first I thought that PRQL doesn't have scan but actually loop fulfills the same function. I'm going to look more into comparing those.

Re: I want a good parallel language [video]

#64

Post by rramadass » Fri, Nov 07, 2025, 4:32 AM UTC

seanmcdirmid wrote: post #61

rramadass wrote: post #60

Earlier quoted context omitted.

Not what i meant (these are superficialities). Erlang is a concurrency-oriented language though its concurrency architecture (multicore/node/cluster/etc.) is different from that modeled by GPUs (Vectorized/SIMD/SIMT/etc.) Since share-nothing Processes (so-called Actor model) are at the heart of the Erlang Run Time System(ERTS)/BEAM it is easy to imagine a "group of Erlang processes" being mapped directly to a "group…

The biggest issue I think is utilizing massive GPU memory bandwidth, you really need SIMD or your GPU is just going to generate a lot of heat to do only a bit of work.

But SIMD has got nothing to do with language per se. In Erlang everything is in a module and hence i can imagine annotating a module with SIMD/SIMT attribute which would then be the hint for the ERTS to map all the processes in that module to a warp on a GPU using SIMD vectorization as needed. Of course my Erlang processes must be written to take advantage of the above and thus cannot be a general-purpose (i.e. MIMD) process.

Re: I want a good parallel language [video]

#65

Post by coffeeaddict1 » Fri, Nov 07, 2025, 12:07 PM UTC

I was expecting the author to at least mention Halide https://halide-lang.org/.

Re: I want a good parallel language [video]

#66

Post by SamInTheShell » Sat, Nov 08, 2025, 12:58 AM UTC

nasretdinov wrote: post #8

SamInTheShell wrote: post #3

Went in thinking "Have you heard of Go?"... but this turned out to be about GPU computing.

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

Haha, yeah. Idk any other language where I practically get a free parallelization+concurrency sandwich. It's kept me coming back to Go for a decade now, despite them using a signal that prevents using it for system level libraries. They literally broke my libnss-go package years ago when they selected the signal to use to control the concurrency portion of the runtime.

Re: I want a good parallel language [video]

#67

Post by pdimitar » Sat, Nov 08, 2025, 3:38 AM UTC

SamInTheShell wrote: post #66

nasretdinov wrote: post #8

Earlier quoted context omitted.

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

Haha, yeah. Idk any other language where I practically get a free parallelization+concurrency sandwich. It's kept me coming back to Go for a decade now, despite them using a signal that prevents using it for system level libraries. They literally broke my libnss-go package years ago when they selected the signal to use to control the concurrency portion of the runtime.

Elixir.

Parallelism is trivial and front-and-center.

And no it's not a niche language. Don't listen to the army of Python technicians.

Re: I want a good parallel language [video]

#68

Post by SamInTheShell » Sun, Nov 16, 2025, 2:28 AM UTC

pdimitar wrote: post #67

SamInTheShell wrote: post #66

Earlier quoted context omitted.

Haha, yeah. Idk any other language where I practically get a free parallelization+concurrency sandwich. It's kept me coming back to Go for a decade now, despite them using a signal that prevents using it for system level libraries. They literally broke my libnss-go package years ago when they selected the signal to use to control the concurrency portion of the runtime.

Elixir. Parallelism is trivial and front-and-center. And no it's not a niche language. Don't listen to the army of Python technicians.

There seems to be about the same level of effort with Elixir as there is for a language like Kotlin.

The free sandwich I'm referring to with Go is the ability to just do `go funcnamehere()` and that's running concurrently and in parallel. If I need coordination of those goroutines, I can still do that with any number of locking patterns. It's extremely convenient, making the trade off of having a runtime baked in worth it imo.

Re: I want a good parallel language [video]

#69

Post by pdimitar » Tue, Nov 18, 2025, 3:27 PM UTC

SamInTheShell wrote: post #68

pdimitar wrote: post #67

Earlier quoted context omitted.

Elixir. Parallelism is trivial and front-and-center. And no it's not a niche language. Don't listen to the army of Python technicians.

There seems to be about the same level of effort with Elixir as there is for a language like Kotlin. The free sandwich I'm referring to with Go is the ability to just do `go funcnamehere()` and that's running concurrently and in parallel. If I need coordination of those goroutines, I can still do that with any number of locking patterns. It's extremely convenient, making the trade off of having a runtime baked in wor…

Well, almost exactly the same goes for Elixir. You have to declare a supervisor first but from then on it's trivial, almost on the level of `go doThisThing()`.

That's why I made Elixir my main language. A lot of the tech sphere stubbornly pretends we don't live in a world with multicore CPUs, even to this day.