4 ms·

> not meaningfully improved by adding cores. This is true and I hate it, because it doesn't have to be this way. Almost all existing workloads are theoreticall

> not meaningfully improved by adding cores. This is true and I hate it, because it doesn't have to be this way. Almost all existing workloads are theoretically parallelizable to at least some significant degree, developers just don't do it because it's so difficult. (I'm talking about large scale systems, not individual algorithms) I think more research needs to go into designing new programming languages and paradigms to make multithreading easy and automatic. There's been some improvement here in the last few years, e.g. coroutines, move semantics, but there's still a long way to go. It's silly that people are buying 32-core CPUs that basically only get used for video rendering.

fennecfoxy 3y ago
I was gonna say, the issue is definitely that conscious thought and planning has to be put into it, and even then issues still crop up. We really need a new language that self-parallelises with zero effort from developers.
vlod 3y ago
>I think more research needs to go into designing new programming languages It was my understanding that golang supports multi-core? [0] https://pkg.go.dev/github.com/jeffdecola/my-go-examples/goroutines/goroutines-multi-core#section-readme https://pkg.go.dev/github.com/jeffdecola/my-go-examples/goro...
gregors 3y ago
How we program multicores - Joe Armstrong https://www.youtube.com/watch?v=bo5WL5IQAd0 https://www.youtube.com/watch?v=bo5WL5IQAd0
rewmie 3y ago
> (...) developers just don't do it because it's so difficult. I don't think this is true, or at least generalizable. I've been involved in a few tickets to turn problematic sync calls to async calls or background tasks. In all of them, the root cause was the same: * Let's add a handler that does nothing of note, such as setting a flag or logging something or emitting a metric. * We have another feature, and it requires something being triggered by the handler. Let's add it next to the logger/metric call. Let's also clean this up and extract a function out of this code. * We need to tweak that feature to do one more thing. Calling that function from the handler under rare cases can add a bit of lag and block stuff. We can live with it, so let's keep it like that. * Oh it turns out that member function can render the app unusable. We can't live with it anymore, and we need to refactor it.

fennecfoxy 3y ago

I was gonna say, the issue is definitely that conscious thought and planning has to be put into it, and even then issues still crop up. We really need a new language that self-parallelises with zero effort from developers.

vlod 3y ago

>I think more research needs to go into designing new programming languages It was my understanding that golang supports multi-core? [0] https://pkg.go.dev/github.com/jeffdecola/my-go-examples/goroutines/goroutines-multi-core#section-readme https://pkg.go.dev/github.com/jeffdecola/my-go-examples/goro...

gregors 3y ago

How we program multicores - Joe Armstrong https://www.youtube.com/watch?v=bo5WL5IQAd0 https://www.youtube.com/watch?v=bo5WL5IQAd0

rewmie 3y ago

> (...) developers just don't do it because it's so difficult. I don't think this is true, or at least generalizable. I've been involved in a few tickets to turn problematic sync calls to async calls or background tasks. In all of them, the root cause was the same: * Let's add a handler that does nothing of note, such as setting a flag or logging something or emitting a metric. * We have another feature, and it requires something being triggered by the handler. Let's add it next to the logger/metric call. Let's also clean this up and extract a function out of this code. * We need to tweak that feature to do one more thing. Calling that function from the handler under rare cases can add a bit of lag and block stuff. We can live with it, so let's keep it like that. * Oh it turns out that member function can render the app unusable. We can't live with it anymore, and we need to refactor it.