3 ms·

I find it rather queer that, for the author, two data points are enough to "put performance into proper perspective". Now that performance is gained from scalin

by andos 16y ago

I find it rather queer that, for the author, two data points are enough to "put performance into proper perspective". Now that performance is gained from scaling, it matters like never before.

wladimir 16y ago
Well, you have to see this article from a pre-2004 perspective. Back then, clock speeds were still increasing like crazy, like it'd never stop. This luxury made people think things like "performance doesn't matter, processors will get faster than we can optimize the code". The mindset that eventually led to Vista. We're wiser now. These days, performance can only be increased by adding more cores, not by clocking up. Scaling up actually costs development effort. This makes optimization very important. See also this 2005 article from Dr Dobbs: http://www.gotw.ca/publications/concurrency-ddj.htm http://www.gotw.ca/publications/concurrency-ddj.htm . That's when the big change of perspective began.
- andos 16y ago
  You are right. I kept that in mind all along while reading the post, though I perhaps showed less sympathy in my remark. I really regret if I sounded like a smart-arse. The link you posted is great; the chart alone speaks volumes! Already at that point in time one could notice how the trend with power and CPU frequency was changing, while transistor count kept on growing. James Hague would have had second thoughts, I believe, if he had seen that chart. Moore's Law suffered quite a plot twist the last decade. (Curiously, Herb Sutter is the secretary of the C++ standards committee. They finally finished the standardization of basic threading — among other stuff — 5 years after the Dr. Dobbs article!)
  - wladimir 16y ago
    Nah, I had the same reaction while reading the article. Then I realized that it was from 2004. The slow push for standardization is indeed curious. Standardizing threading would only be the beginning, as threading is (for most things) a much too low-level abstraction. It is very hard to scale threading, with the locking and other synchronization it usually entails, to large number of cores (soon, >16 won't be that strange). And it's very bug-prone. I think it's disappointing that more high-level primitives such as co-routines, work queues, task-based parallelism, map/reduce and such are finding such slow adaption in mainstream languages. You'd say that making the writing of parallelized code faster and more robust is an important goal.
- rdtsc 16y ago
  At the same time I would point out that the author has probably made the right choice learning and using Erlang. He _might_ be in a better position to take advantage of multiple cores, in some cases by just adding more cores to his system.
  - andos 16y ago
    This could explain the supposed disregard for the new trend. Concurrency was just not an issue for him.

by andos 16y ago

I find it rather queer that, for the author, two data points are enough to "put performance into proper perspective". Now that performance is gained from scaling, it matters like never before.

wladimir 16y ago

Well, you have to see this article from a pre-2004 perspective. Back then, clock speeds were still increasing like crazy, like it'd never stop. This luxury made people think things like "performance doesn't matter, processors will get faster than we can optimize the code". The mindset that eventually led to Vista. We're wiser now. These days, performance can only be increased by adding more cores, not by clocking up. Scaling up actually costs development effort. This makes optimization very important. See also this 2005 article from Dr Dobbs: http://www.gotw.ca/publications/concurrency-ddj.htm http://www.gotw.ca/publications/concurrency-ddj.htm . That's when the big change of perspective began.

andos 16y ago
You are right. I kept that in mind all along while reading the post, though I perhaps showed less sympathy in my remark. I really regret if I sounded like a smart-arse. The link you posted is great; the chart alone speaks volumes! Already at that point in time one could notice how the trend with power and CPU frequency was changing, while transistor count kept on growing. James Hague would have had second thoughts, I believe, if he had seen that chart. Moore's Law suffered quite a plot twist the last decade. (Curiously, Herb Sutter is the secretary of the C++ standards committee. They finally finished the standardization of basic threading — among other stuff — 5 years after the Dr. Dobbs article!)
- wladimir 16y ago
  Nah, I had the same reaction while reading the article. Then I realized that it was from 2004. The slow push for standardization is indeed curious. Standardizing threading would only be the beginning, as threading is (for most things) a much too low-level abstraction. It is very hard to scale threading, with the locking and other synchronization it usually entails, to large number of cores (soon, >16 won't be that strange). And it's very bug-prone. I think it's disappointing that more high-level primitives such as co-routines, work queues, task-based parallelism, map/reduce and such are finding such slow adaption in mainstream languages. You'd say that making the writing of parallelized code faster and more robust is an important goal.
rdtsc 16y ago
At the same time I would point out that the author has probably made the right choice learning and using Erlang. He _might_ be in a better position to take advantage of multiple cores, in some cases by just adding more cores to his system.
- andos 16y ago
  This could explain the supposed disregard for the new trend. Concurrency was just not an issue for him.