Faster Chips Are Leaving Programmers in Their Dust
nytimes.com
nytimes.com
There are categories of "embarrassingly parallel" problems that have been solved for years using multiple cores: video rendering, 3D graphics rendering, etc... In short, anything that does repetitive processing on large datasets.
Now, people are upset, because we're not going to be able to improve the software for the average user with multiple cores, and they are correct if they want word processing and email to get better with multiple cores. The question that we need to be asking, is this: how can embarrassingly parallel problems make user software better?
How can we use multiple streams of video in software? How can 3D rendering improve my software? Or, what sort of very large datasets can I process with multiple cores on the desktop?
The companies that answer those questions (e.g GOOG) are companies that will make a lot of money in the next decade.
At least half of the "dilemma" is pure, unadulterated marketing. In this article, the marketer is Microsoft, which is trying to convince end users that there's some kind of big problem, one which no mere mortal can comprehend, that is somehow preventing our expensive new Vista machines from being any better than the XP boxes they replaced. It certainly has nothing to do with Microsoft's incompetence, nor with their slavish devotion to Hollywood-approved, mind-mangling, box-breaking DRM. And it's certainly not their insistence on foisting incompatible proprietary crap like IE on the industry. No, it must be a Fundamental Problem of Computer Science that is holding us back. Naturally, this problem can only be solved by the big academic brains that work for... Microsoft!
The email example is a dead giveaway... it's laugh-out-loud funny:
"In the future, Mr. Mundie said, parallel software will take on tasks that make the computer increasingly act as an intelligent personal assistant."
Ah, the intelligent personal assistant -- it's the application of the future, and it always will be.
How do we know that intelligent email processing is not being held up by the lack of suitable coding techniques for eight-way parallel processors? Because I have a dual-core processor right now, and it spends the night contemplating its digital navel and counting to 2^64 by fives for fun. If there was something smart it could be doing with my email, why isn't it working on it right now? I am drowning in unused processor cycles.
The Microsoft personal assistant example is just cracking me up. Firstly, Microsoft has been selling the whole 'automated assistant' thing to us for YEARS. Clippy is just one hideous example.
Secondly, automated inbox processing has been around for _years_. My POPFile open source program is now over 5 years old and there are older examples than that (I was doing automated emailing sorting in the late 90s and others before me). So multi-core machines are what's holding this back? What a joke.
Thirdly, it mentions features (looking at who I correspond with) that are already available (see Xobni and others). And automatic response systems are also around to deal with customer service.
Sorry, for the rant put two pages of fluff about multi-core processors with some freak out speculation about email processing that's been available for a long time.
How about talking about something interesting, like parallel aware languages (Occam, erlang, ...)?
For another, I've never had a problem with any DRM on Vista because I just don't have DRM'ed files, and like 99.9% of America, don't have an HD-DVD or Bluray drive. It's certainly not box-breaking by any sane definition.
And lastly, but most importantly, Microsoft (and any other consumer OS maker) has no choice. See http://arstechnica.com/articles/paedia/hardware/hdcp-vista.a... for details. We may all hate DRM, but it isn't Microsoft who is at fault. Not that any of that is at all relevant to the NYT article.
I talked to a dude with an OR background, and he said that in the 80s people laughed at the notion of using this kind of math to solve business problems. Processing power increases the opportunities for programmers, without question.
Anyway, fun to read, just a very strange take on the relationship between programmers and cpu speed.
(Of course, this isn't the first time some programmers have resisted change. I remember a great rant about how if you program in assembly and never hit in the cache, the Pentium 4 was no faster than the Pentium III and thus useless. That guy probably quit programming entirely when multicore arrived.)
Well there you go, left behind.
What a smart OS would do was watch you for a while and notice what you do, and then make a decision based on the statistics: let's say 85% of the time, your keys are in the vide poche and you find them immediately, and the other 15% of the time they're somewhere else and it takes you 5 minutes to find them. Then it would warp them to the right place (the place your actions showed them was right) with a note and an option to "always do this". I shudder to think of MSFT's implementation of this (Clippy), but if a smart company along the lines of Humanized did it, and used statistics instead of some clever algorithm (didn't we just read about Google doing that?), it could be a godsend for average users.
Don't underestimate the value of saving every user 5 seconds each time they use your app.
weird I thought it was called erlang
http://en.wikipedia.org/wiki/Amdahl's_law
The non-parallel portion limits the available speedup.
Maybe I should explain my terse comment. But first, I agree that it's a submarine PR piece for Microsoft. How many software companies are cited in that article? How many technologies are mentioned and/or explored? In short it says "Multi-core processors have potential, and [only] Microsoft has the best minds trying to exploit that potential."
Parellelism has been available in less local forms for decades. Supercomputers, clusters, more recently grid computing. These aren't new problems for computer science, they are only new problems for desktop software developers that have always assumed a simpler processor architecture.
So imagine a program that could identify parallelizable sequences of instructions in other programs, and split the program accordingly. Such a program may be able to exist, but it appears to be a very hard problem (it's even a hard problem for humans). Vista is definitely NOT this program.
your 1st comment had a -1 point on it
Servers could use the cores to process more connections and lessen the need for more servers. I guess virtualization could be used.
A sure fire recipe for missing the boat.
Honestly, which would you rather have, more power in your hand or a faster pipe to the rest of the world?