6 ms·

Is multicore hype or reality?

34 points by iamelgringo 17y ago

mishmash 17y ago
Here's the print link, let me know if this isn't cool here on HN. http://embedded.com/columns/technicalinsights/205918952?printable=true http://embedded.com/columns/technicalinsights/205918952?prin...
- ambition 17y ago
  It's generally preferred to submit the print link in the first place when available. So, yes, it's cool here on HN.
nazgulnarsil 17y ago
beyond the aforementioned embarrassingly parallel problems I don't think we'll see much performance increase once we reach the point where each app/process is running on its own core.
- jrockway 17y ago
  Well, sure. Most apps are waiting for IO -- waiting for the network, waiting for the disk to read a file, or waiting for the user to do something. No multi-core processor is going to speed that up. However, many algorithmic problems parallelize well. It's just that it doesn't really matter for "desktop users". (See also: the popularity of netbooks.)
  - nazgulnarsil 17y ago
    OTOH I do fully expect software to continue to bloat as developers increasingly do less with more.
    - joe_the_user 17y ago
      Well, this is standard behavior but ... "Doing less with more" has often been cost-effective given the relative cost of programmers versus machines. A change in that cost-equation will quite possibly result in different decisions being made. Demand for more efficient programming seems likely to thus increase.
- JulianMorrison 17y ago
  On my Linux machine, not even a server but just a desktop, there are 111 running processes. There's room for growth in multi-core yet.
  - tl 17y ago
    How many of those processes are small / simple enough that you can fit dozens of them on a single core with no performance loss? On my dual-core box, top shows very few programs registering 1% of CPU usage. Of those, only firefox needs it often.
  - wmf 17y ago
    Don't you mean there are 111 sleeping processes? It's unlikely that a desktop would have so many runnable processes.
    - JulianMorrison 17y ago
      Ah, my use of "running" was misleading. That's just a crude line count of the "ps ax" listing. (And I probably counted the header line - d'oh!) Yes, most are sleeping.
spitfire 17y ago
The more interesting point made in that article wasn't about multicore. But was actually about the distance from the CPU that memory is from the modern CPU. Remember when programmers were hand counting instruction timings and code size on their 386? Well that's become even more important today. If you can get your code size into L2 (or even better L1), you can win a factor of 1000x speedup. One reason why I still use a compiled language.
- Hexstream 17y ago
  "One reason why I still use a compiled language." Nitpick: There's no such thing as a "compiled" or "interpreted" language. A specific language implementation (a runtime) might be more interpreted than compiled or vice-versa, but even if some language traditionally only provides interpreting or compiling implementations, there's nothing preventing someone from writing one in the other style, though the nature of the language might make some approaches less appropriate. Isn't there this IronRuby that runs Ruby, a traditionally interpreted language, on the JVM in compiled fashion? Also, I'm sure Lisp was considered for a long time an interpreted language but today there are fast compiling implementations available such as SBCL. I'm sure there are many more examples. A compiler is really just a partial evaluator (correct me if I'm wrong?).
  - oconnor0 17y ago
    IronRuby is for .NET. JRuby is for the JVM.
- Retric 17y ago
  A slight difference being the ginormous size of L2 and still respectable size of L1 on new CPU's. L2 sizes ranging from 3 to 12 MB are considered normal, which is about the same range as most 386's had RAM. IMO the real trick is to access RAM sequentially as there is a lot of bandwidth if you can avoid the latency hit. But, it's hard to guess how much L2 cache the machine is going to have. PS: Looking at RAM the way you looked at the HDD on a 386 seems strange considering the amazing increase in speed, but it's a reasonable approach.

34 points by iamelgringo 17y ago

Here's the print link, let me know if this isn't cool here on HN. http://embedded.com/columns/technicalinsights/205918952?printable=true http://embedded.com/columns/technicalinsights/205918952?prin...

ambition 17y ago
It's generally preferred to submit the print link in the first place when available. So, yes, it's cool here on HN.

nazgulnarsil 17y ago

beyond the aforementioned embarrassingly parallel problems I don't think we'll see much performance increase once we reach the point where each app/process is running on its own core.

jrockway 17y ago
Well, sure. Most apps are waiting for IO -- waiting for the network, waiting for the disk to read a file, or waiting for the user to do something. No multi-core processor is going to speed that up. However, many algorithmic problems parallelize well. It's just that it doesn't really matter for "desktop users". (See also: the popularity of netbooks.)
- nazgulnarsil 17y ago
  OTOH I do fully expect software to continue to bloat as developers increasingly do less with more.
  - joe_the_user 17y ago
    Well, this is standard behavior but ... "Doing less with more" has often been cost-effective given the relative cost of programmers versus machines. A change in that cost-equation will quite possibly result in different decisions being made. Demand for more efficient programming seems likely to thus increase.
JulianMorrison 17y ago
On my Linux machine, not even a server but just a desktop, there are 111 running processes. There's room for growth in multi-core yet.
- tl 17y ago
  How many of those processes are small / simple enough that you can fit dozens of them on a single core with no performance loss? On my dual-core box, top shows very few programs registering 1% of CPU usage. Of those, only firefox needs it often.
- wmf 17y ago
  Don't you mean there are 111 sleeping processes? It's unlikely that a desktop would have so many runnable processes.
  - JulianMorrison 17y ago
    Ah, my use of "running" was misleading. That's just a crude line count of the "ps ax" listing. (And I probably counted the header line - d'oh!) Yes, most are sleeping.

spitfire 17y ago

The more interesting point made in that article wasn't about multicore. But was actually about the distance from the CPU that memory is from the modern CPU. Remember when programmers were hand counting instruction timings and code size on their 386? Well that's become even more important today. If you can get your code size into L2 (or even better L1), you can win a factor of 1000x speedup. One reason why I still use a compiled language.

Hexstream 17y ago
"One reason why I still use a compiled language." Nitpick: There's no such thing as a "compiled" or "interpreted" language. A specific language implementation (a runtime) might be more interpreted than compiled or vice-versa, but even if some language traditionally only provides interpreting or compiling implementations, there's nothing preventing someone from writing one in the other style, though the nature of the language might make some approaches less appropriate. Isn't there this IronRuby that runs Ruby, a traditionally interpreted language, on the JVM in compiled fashion? Also, I'm sure Lisp was considered for a long time an interpreted language but today there are fast compiling implementations available such as SBCL. I'm sure there are many more examples. A compiler is really just a partial evaluator (correct me if I'm wrong?).
- oconnor0 17y ago
  IronRuby is for .NET. JRuby is for the JVM.
Retric 17y ago
A slight difference being the ginormous size of L2 and still respectable size of L1 on new CPU's. L2 sizes ranging from 3 to 12 MB are considered normal, which is about the same range as most 386's had RAM. IMO the real trick is to access RAM sequentially as there is a lot of bandwidth if you can avoid the latency hit. But, it's hard to guess how much L2 cache the machine is going to have. PS: Looking at RAM the way you looked at the HDD on a 386 seems strange considering the amazing increase in speed, but it's a reasonable approach.