Ted...
Their benchmarks also show that many applications are not able to exploit 4 cores very well, never mind 8. Now, where did I leave that Erlang disk image....We're busy cramming everything into a common language runtime. Shared memory, critical sections, locks, common object models... it's the wave of the future?
Well, it's a tsunami that is catching up with us while we're busy cramming everything into a common language runtime.
Update: Steve Dekorte writes that no language will save these high core count MISD systems from the Von Nuemann bottleneck.
But the advantage of a shared-nothing programming model like Erlang's is that systems can more easily accomodate multiple shared-memory cores as well as multiple shared-nothing nodes. The languages that assume there is no shared memory are better positioned to get around the Von Nuemann bottleneck.
Common language runtimes that assume shared-memory are a diversion at this point. But I think it will be another five years or so before the JVM and CLR leaders start to think about this. Ideas just take a long time to catch on. With JRuby and such now, we're seeing the beginning of the fruition of an idea that has been around as long as the JVM. The JVM itself was the fruition of UCSD Pascal byte code from the early 1980's.
From what I have seen the hardware manufacturers have a difficult time getting their heads around this direction too. They understand that a single, faster CPU is not going to sell. And so they understand the reason for putting multiple CPUs on a core. I am not sure they know what to do with them in software... Maybe web services?
1 comment:
"""They understand that a single, faster CPU is not going to sell."""
Strictly speaking, thay have observed that trying to make a single CPU core faster provides diminishing returns, so they have adopted parallelism and punted the problems to the software system designers.
Post a Comment