5 ms·

I am glad to see Intel still pushing faster single-threaded performance. Many (most?) important workloads are not meaningfully improved by adding cores.

by jl6 3y ago

Asraelite 3y ago
> 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.
constantcrying 3y ago
>Many (most?) important workloads are not meaningfully improved by adding cores. Absolutely. No browser can use more than a single core. And in any case, who in their right mind uses more than a single thread at a given time anyway? I certainly never open more than a single appliation at a time. In all honesty, this is one of the more delusional comments I have seen on here...
- Clamchop 3y ago
  And this is one of the least charitable readings of a comment I have seen before.
  - constantcrying 3y ago
    Is it? Literally every single workload is improved by adding more cores. Even single threaded applications benefit, as they can have more time on their core, without having loosing their cache.
ksaj 3y ago
I have probably too many cores on my music production Mac, and I definitely would rather have faster single-threaded performance, even if it meant half the cores I currently have available. I mean, I'm pretty happy with it. But the workload is only marginally faster/smoother than it would be with half the cores, and still sometimes feels sluggish. Law of diminishing returns, for sure. It never hangs on a hard load though, but I feel that would be the same with fewer but faster cores anyway.
- musicale 3y ago
  Music production seems like a great "embarassingly parallel" application since instrument voices tend to be independent and effects chains are readily pipelined. Multicore should provide direct benefit in terms of more tracks, more instrument voices, and deeper effects chains. What is the single-threaded workload that is sluggish? Is it something like encoding or compression?
  - deleted 3y ago
    [deleted]

I am glad to see Intel still pushing faster single-threaded performance. Many (most?) important workloads are not meaningfully improved by adding cores.

by jl6 3y ago

I am glad to see Intel still pushing faster single-threaded performance. Many (most?) important workloads are not meaningfully improved by adding cores.

Asraelite 3y ago

> 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.

constantcrying 3y ago

>Many (most?) important workloads are not meaningfully improved by adding cores. Absolutely. No browser can use more than a single core. And in any case, who in their right mind uses more than a single thread at a given time anyway? I certainly never open more than a single appliation at a time. In all honesty, this is one of the more delusional comments I have seen on here...

Clamchop 3y ago
And this is one of the least charitable readings of a comment I have seen before.
- constantcrying 3y ago
  Is it? Literally every single workload is improved by adding more cores. Even single threaded applications benefit, as they can have more time on their core, without having loosing their cache.

ksaj 3y ago

I have probably too many cores on my music production Mac, and I definitely would rather have faster single-threaded performance, even if it meant half the cores I currently have available. I mean, I'm pretty happy with it. But the workload is only marginally faster/smoother than it would be with half the cores, and still sometimes feels sluggish. Law of diminishing returns, for sure. It never hangs on a hard load though, but I feel that would be the same with fewer but faster cores anyway.

musicale 3y ago
Music production seems like a great "embarassingly parallel" application since instrument voices tend to be independent and effects chains are readily pipelined. Multicore should provide direct benefit in terms of more tracks, more instrument voices, and deeper effects chains. What is the single-threaded workload that is sluggish? Is it something like encoding or compression?
- deleted 3y ago
  [deleted]