3 posts • joined Tuesday 29th July 2008 15:22 GMT
Couple of observations:
- On the "lazy developer" issue, for sure developers are less careful to eke performance out of systems than before. I actually started on a ZX81 many years ago and wrote a graphical data analysis app that fit in 16k (and evaporated every time I nudged the RAM pack.) At that time a lot of time was spent on micro-optimizations just because hardware resources were so limited. Now there is no need to tune to that level. Faster hardware is not just for faster performance, it also allows developers to work more quickly by using higher level abstractions and spending less effort on tuning. If the applications do not need ultimate performance, this is a Good Thing. Hardware is cheap, developers are not.
If/when Moore's Law does grind to a halt then you may see the balance shift again and more resources are spent on tuning.
- On the article itself, I think it is a very insightful analysis and I'm disappointed that some here dismiss it with a wave of the hand and a "they'll think of something" comment. Clearly the current course is not sustainable, and it is not at all clear that something will come along just in time to save the day. Although it is possible, I prefer not to live by faith, and it is worth seriously considering the possibility that performance improvements will fall off dramatically in the future. That will lead to a very significant realignment of priorities in the industry, and may actually be a good thing.
Threading IS hard
Excellent article, much appreciated, particularly the humour content.
I've been looking into TM for a while now and it does look like a very promising alternative to the nightmare of locks. Intel's STM compiler is a good way to get started with it.
For anyone who still claims threading is easy, I can only assume they have not really been doing very much. We are still finding bugs in our threading libraries written a decade ago and gone over with a fine toothcomb several times since. It is insanely hard. As further proof, I would offer up the fact that almost every threading library or toolkit I have used, be it native threads, OpenMP or other, has contained threading bugs that I have hit. If you consider that the guys writing these libraries and implementations do this stuff full time and still get tripped up, it shows how hard it is.
The best example I have is that one of the third party tools we use to search for race conditions was not working for us. The vendor finally fixed it and reported, with some embarrassment, that the problem was a race condition in the tool itself.
In terms of grammatical peeves, I agree with the "could care less" griping, and I raise it with a "lowest common denominator" when they really mean highest common factor.