3 ms·
To get any reasonable performance benefit out of 32+ cores the code running on those cores would have to be >75% parallelized.[1] I know very little about threa
by meshenna 8y ago
To get any reasonable performance benefit out of 32+ cores the code running on those cores would have to be >75% parallelized.[1] I know very little about threading and such, but that seems like it would be a difficult thing to do for many (most?) applications. Point being that I doubt consumer CPUs will have that many cores until there's a clear benefit to it, and thus far there isn't. Even 8-16 cores is pushing it. If anyone reading this has more insight into the matter, I'd love to hear what you think.
[1] https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law
- pdimitar 8y ago> To get any reasonable performance benefit out of 32+ cores the code running on those cores would have to be >75% parallelized. Exactly this, yes. But for that we need a language that enforces and guarantees pure functions and disallows global state mutation. For now C is king in systems programming but I wonder if certain chips are made with a very different idea from the get go, then can we have a systems functional language? I also am not very informed on this front, never had enough time to dig deeper. (I did like the idea of the LISP machines several decades ago though.)
- twtw 8y agoThe real-world progression of software run over time on processors doesn't always match the assumption in amdahl's law. Frequently people want to solve harder/bigger problems in the same time, not just the same problem in less time. See, for example, how slack has taken over doing what IRC could do, just with much higher resource requirements. For that, see https://en.m.wikipedia.org/wiki/Gustafson%27s_law https://en.m.wikipedia.org/wiki/Gustafson%27s_law.