3 ms·

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

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.

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.