Stream: ideas

Topic: Parallelization


view this post on Zulip Wolfgang Schuster (Oct 21 2022 at 15:24):

I was watching https://www.youtube.com/watch?v=2PxsyWqZ5dI and wondering if anyone had done anything with parallel execution in Roc. Not sure if this would belong in core or more in a platform though. My initial thought was platform, but I'm not certain

view this post on Zulip Anton (Oct 21 2022 at 15:36):

Yes, @Brendan Hansknecht has done some exploration in this area.

view this post on Zulip Brendan Hansknecht (Oct 21 2022 at 15:37):

I guess I need to watch that talk at some point so I can comment. It's on my list, just havent gottent to it.

view this post on Zulip Brendan Hansknecht (Oct 21 2022 at 21:16):

This talk is quite interesting and kinda stuck in between the app and platform boundary.

The platform controls threads and anything async. The app is just a blob of code to the platform.

We hit a big issue that the platform can't split up and parallelize a roc app. Given it is just a block of instructions and might even mutate data in place, that wouldn't work.
On the other hand, as things currently stand, roc itself is always single threaded without returning something to the platform that kicks off in another thread. Our current split might make doing something like this very hard.

That said, some sort of async style roc platform and app combination is definitely doable. The question is, how do we minimize all of the dance of wrapping and returning things in ways that end up cutting up parallelization or making it very verbose.

view this post on Zulip Brendan Hansknecht (Oct 21 2022 at 21:17):

We have talked about doing some forms of batching, but all of it is currently pretty explicit.

view this post on Zulip Brendan Hansknecht (Oct 21 2022 at 21:18):

A really nice solution to this will likely require a mix of platform and roc compiler working together. That way the platform can be a runtime/execution engine with clean split points and plans around parallelization that the compiler somehow gives to it.

view this post on Zulip Qqwy / Marten (Oct 22 2022 at 19:36):

I think it should be possible to create a library (or maybe a platform or 'plugin' for another platform) similar to the Accelerate library that exists in Haskell. It is quite a nice abstraction, where code snippets build up a recipe that can be compiled-and-executed to CUDA, OpenCL and co.

view this post on Zulip Asier Elorz (he/him) (Jan 06 2023 at 21:50):

Hi,

I have very recently read a paper about a new reference counting algorithm that was developed in 2018 that attempts to tackle the problem of atomic reference counting operations being comparatively slow while still keeping the possibility of sharing objects between threads: biased reference counting. Although the paper is from 2018, I have not seen anybody mention it in this conversation, and some of the conversation around selection between atomic and non-atomic instructions at runtime that was had last March and April seems to me now as trying to reinvent this paper with no luck. I don't know if the topic is still of interest, since it has been almost a year since the conversation I am mentioning, but the paper may be worth reading.

The paper: https://dl.acm.org/doi/pdf/10.1145/3243176.3243195

The authors implement the algorithm as the reference counting strategy of the Swift language's runtime, and the numbers they present are quite impressive, even if it is not the panacea since just using non-atomic operations is still faster. Their initial numbers, when measuring Swift benchmark programs with the default reference counting (always atomic), seem to confirm Brendan's numbers where some programs were taking almost half of their time in atomic reference counting operations, which also makes me think that maybe Roc's problem situation with respect to reference counting could be similar to Swift's and their solution could be applicable to Roc.

view this post on Zulip Brendan Hansknecht (Jan 07 2023 at 00:05):

Definitely still a topic of interest. The language is still young and this is a space that will probably want a lot of exploration as we get further along.

Anything now of course is super experimental, but ideas and testing is needed to enable these features in the future. For some platforms/applications, I'm sure this will be critical for performance.


Last updated: Jun 16 2026 at 16:19 UTC