Inside Intel's $20M Multicore Research Program

An anonymous reader writes "You may have heard about Intel's and Microsoft's efforts to finally get multi-core programming into gear so that there actually will be a developer who can program all those fancy new multicore processors, which may have dozens of core on one chip within a few years. TG Daily has an interesting article about the project, written by one of the researchers. It looks like there is a lot of excitement around the opportunity to create a new generation of development tools. Let's hope that we will soon see software that can exploit those 16+core babies. 'The problem of multi-core programming is staring at us right now. I am not sure what Intel's and Microsoft's expectations are, but it is quite possible that they are in fact looking at fundamental results from the academic centers to leverage their large work force to polish and realize the ideas that come forth. It calls for a much closer collaboration between the centers and the companies than it appears at first sight.'"

Comments

It's easy

[Anonymous Coward]

./configure --num-cores=16

Re:It's easy

[Anonymous Coward]

Actually it's almost as simple as that if you use openMP. You just throw in some pragma tags and add an option to gcc or some other compatible compiler. Someone (intel?) also has a multicore debugger supposedly.

Most PCs are fast enough

[OrangeTide]

The thing is, most PCs have plenty of computing power as a single core system. The hard sell is getting people to upgrade those machines mainly used for email and browsing and video playback. I think as time moves on and quad core becomes the "low-end" you will see less demand for higher end hardware. Unless the next version of Windows requires a core dedicated to the OS or something in the future.

Re:Most PCs are fast enough

[sdsucks]

I think the current generation of windows (vista) pretty much does need its own core to run well.

Re:Most PCs are fast enough

[pla]

Unless the next version of Windows requires a core dedicated to the OS or something in the future.

So, uh, you haven't Vista yet, I see...

Re:Most PCs are fast enough

[betterunixthanunix]

The software currently in use does not involve computationally complex problems, and so the computers appear to have "plenty of computational power." This is likely to be the case for a very long time, but there are useful but complex tasks computers might do. For example, a computer that might interact with its user purely by voice -- more advanced voice and language recognition systems are likely to require significantly more cores and computational power than is currently in wide use. Even more advanced might be a system that can interpret visual data, such as facial expressions. These systems are desirable, but need a lot of work, and won't be widely deployed for a long time (decades at least).

Re:Most PCs are fast enough

[avandesande]

It's a valid point.... if the 'speed' of cars increased at the rate it did during the beginning of the century, we'd be driving 400mph cars around.
We are certainly capable of making cars that are that fast, but they wouldn't really be any more useful or provide more utility than a slower car.

Re:Most PCs are fast enough

[KillerCow]

The thing is, most PCs have plenty of computing power as a single core system

And 640k ought to be enough for anyone.

I think as time moves on and quad core becomes the "low-end" you will see less demand for higher end hardware.

My last purchase (6 to 8 months ago) was a "low-end" machine. I chose carefully to make sure that it was low-end and not bargain-basement. It has two cores. I don't think it's even possible to buy a single core machine through mainstream channels anymore. Today's low-end (multi-core) is more than adequate for most users to use over the next few (read: four) years.

Unless the next version of Windows requires a core dedicated to the OS or something in the future.

You do not understand how the scheduler works.

Re:Most PCs are fast enough

[bhima]

I wish I could count the number of times I've heard variations of this. I think the first time I heard it was when Intel released the 80387. Didn't seem to be accurate then either.

Pretty soon social networking will include 1080p video mail or 50 megapixel photos of Jr. or there will be another DOOM II or something like that golf game that had every executive upgrading their Windows 95 'business' computers. Or perhaps the latest 4x1080p 3D media encoder will have us all wanting something faster.

But that's just at home. At work I do a lot of molecular modeling and a lot of very large data set manipulation... we'll be pushing that 24 month upgrade cycle for the foreseeable future.

Oh and BTW... I would by an extra core or even an extra PC if I could use it for dedicated PC housekeeping and free up the rest of the resources for doing work when I want the damn thing to do work.

Re:Most PCs are fast enough

[Anonymous Coward]

With many people looking into the future, namely this 16:9 HD future, single cores aren't enough for HD video playback. My single core P4 3.2ghz could barely play 720p video at 30fps. On this computer, a dual-core AMD 4400+, I needed to pay for the CoreAVC H.264 codec that splits load across both cores to be able to play 1080i video. At least on the video playback front consumers will need dual cores.

Re:Most PCs are fast enough

[peragrin]

Yes but voice processing is done best by dedicated hardware rather than generic. would a voice chip that can do that processing and only that processing be far more efficient? Call it the VPU, it can go next to the GPU, PPU. or it can be one of the 8 cores surrounding a cell processor. The trend that generic processors can do everything will end. maybe a plug and pray architecture where you can pick which cores you want installed on your system.

Re:Most PCs are fast enough

[play_in_traffic]

The thing is, most PCs have plenty of computing power as a single core system. . . . Rather than multi core technology resulting in elegant new software to take advantage of it, I suspect that software will get worse (think loop until done, rather than schedule an interrupt). Faster processors have not made software, better rather they have resulted in an abundance of bad software!

Re:Most PCs are fast enough

[Kaptain Kruton]

I do agree with you that as computers become more powerful, the demand for more powerful systems will decrease, if current software development methods stay the same. However, I do not believe that the decrease will be as obvious as you imply. I can also think of a couple of things that could counter the decrease in demand for more powerful systems. First, AMD and Intel do not want to let the other get an unbeatable edge over the other. Even if people do not want a more powerful system, Intel will continue to innovate to prevent AMD from surpassing them and AMD will do the same in regards to Intel. If one company gained an obvious advantage over the other, that company would get all of the contracts with the computer manufacturers. Second, as other hardware becomes faster, cpu speeds will become more obvious. Right now, one of the biggest bottlenecks in your computer is the hard drive. However, as hd's switch to solid state and other I/O devices gain speed, the bottlenecks caused by the cpu and related hardware will become more obvious. Finally, I think there a Slashdot article a while ago discussing ray tracing and the benefits of multi core cpu's. I believe the article stated that by using cpu's to handle raytracing, one could see a linear correlation between the number of cores and the performance. In other words, 16 cores would have 8 times the performance of a dual core cpu rendering the same scene with ray tracing methods. If future games start using raytracing to render scenes then the power of 16 cores could become very useful.

Re:Most PCs are fast enough

[bberens]

I think you're absolutely right in the short to medium term. We'll need another technology revolution in order for more than 1-2 cores to be really beneficial to the average home user. Outside the web/db server market there's not a lot of use that isn't somewhat fringe. Of course, the web/db server market is huge.

Re:Most PCs are fast enough

[Belial6]

That's just untrue. The only issue with not having faster cars is safety. Turning a hour each way commute to an eighth of the time would definitely change the world. That would give a very large number of people an extra 1:45 hours a day. That's 35:00 daylight hours of extra free time. To me, that would be WAY more useful.

Re:Most PCs are fast enough

[HungSoLow]

Multi-core gives you absolutely nothing for web-surfing, web-developement, office related stuff and anything else the majority of people use their computers for.

When game programmers catch up and generate scalable game engines that take advantage of all N cores, we'll see the majority of users benefit.

Right now, there is a small niche of users that are shitting themselves happy with the multi-core concept. Any scientific or engineering professional is absolutely in love with multi-core platforms. I started my grad studies with a single core, and was satisfied. 6 months in I switched to a dual-core platform, and I was smitten. I'm now running two PCs with Quad-cores, and I'm able to run 8 simulations at the same time, or split a single simulation into 8 parts and combine afterwards. I'm EE, so I don't code explicitly for parallel processing but I'm sure SE and CS grads can attest to my claims and exclaim even louder. Believe me, if someone offered me an 8-core, 16-core, 32-core, you name it, I would take advantage of it.

Re:Most PCs are fast enough

[Anonymous Coward]

Though with current technology speeds that high are very fuel inefficient and the air resistance increases as the cube of the velocity.

Re:Most PCs are fast enough

[Klaus_1250]

You can wonder whether it is sane to control your computer by interfaces which chew the bulk of your available computing power. But I think that when such system enter the market, they will have one or two dedicated cores for them (though, while facial expression may seem complex, language recognition interpretation really is a lot harder) and leave the rest of the cores alone.

Re:Most PCs are fast enough

[gadders]

Fast enough for home based tasks, but not for PCs used in banks either on a trader desktop running complex maths, or as part of a grid. To take full advantage of multiple cores (4 for now, but going to 96 or so in the not to distant future) we really need tools that developers used to programming single core systems can pick up easily and use .

Re:Most PCs are fast enough

[pete-classic]

No production car can even approach 400mph. Not even close. You'd be doing very well to spend half a million on a "production car" that can crack 400kmph.

That leaves out the questions of range (you'd be lucky to get three miles to the gallon), and, you know, being able to actually maneuver on the public roads at that speed.

You're nuts.

-Peter

Re:Most PCs are fast enough

[CowboyNealOption]

I can see uses for extra cores: One for the OS, one for the browser, one for antivirus software, one for DRM, one for "genuine advantage[sic] licensing", etc

Re:Most PCs are fast enough

[OrangeTide]

It's not entirely a safety issue. It's that you physically cannot drive fast when everyone is slamming on their brakes during rush out.

Turning a hour each way commute to an eighth of the time would definitely change the world. Get an apartment near your work.

Re:Most PCs are fast enough

[OrangeTide]

mpeg4 decompression is far more complex than voice recognition. The processing involved is simply not that great, even for "more advanced voice and language recognition". The difficulty lies in better algorithms to do it. Turns out dynamic voice control and interpretation is not something that can be brute forced.

Game physics needs computational power. but I'm not considering game systems.

Scientific and Engineering projects need computational power and benefit from cost reduction in high performance processing.

The home user differs. I suspect dual core cpus is just a way for Intel to sell us twice as many cpus as we really need.

Re:Most PCs are fast enough

[PitaBred]

We've gotta get the bandwidth before 1080p is even remotely possible for video mail. The thing is, for the VAST majority of people, there is no killer app that will require an upgrade right now. A low-end machine will push 1080p in H.264 no problem. A 50MP picture of junior would again require more bandwidth, and a bigger monitor. Not a faster machine.

Re:Most PCs are fast enough

[OrangeTide]

And 640k ought to be enough for anyone. funny you quoted my response to that issue immediately after: "I think as time moves on and quad core becomes the "low-end" you will see less demand for higher end hardware."

I don't think it's even possible to buy a single core machine through mainstream channels anymore. Conroe-L's are still shipping. And Intel has a single core ultra low power chip on the horizon designed to compete with ARM. Your phone, pda, heart monitor, etc won't be symmetric multiprocessor any time soon.

You do not understand how the scheduler works. xbox 360 already works this way. three cores. 2 for the game, 1 for the OS.

As a professional kernel developer, I realize that locking cores into specific tasks is a lot easier than writing a general purpose scheduler that performs equivalently.

Re:Most PCs are fast enough

[Locutus]

I think it has more to do with the lack of multi-threading in applications. Imagine you have a graphics app which pegs the CPU doing some particular image processing and you see the Windows hour-glass for 5 minutes. So you go out and get a dual-core system and fire up that same app but still see a 5 minute wait. Because that application is not or is poorly multi-threaded, the 2nd CPU is doing very little to help speed things up when one program is doing the CPU hogging. Ofcourse, the poor design of Windows could still prevent a multi-threaded application from doing any better since IIRC, in the 90's Windows could not spread threads across CPU's while OS/2 could. Nobody cared back then because only servers used dual+ CPU boxen. Also, it's probably not known but OS/2 application developers were forced to write multi-threaded applications because of how the GUI APIs were designed and therefore many OS/2 applications were quite smooth on one CPU and typically showed 30% or more performance boosts on dual CPU systems.

Back in 90's, Windows 95 really sucked at multi-threading and Windows NT was just really bad at it. So, what you got was hardly any Windows developers writing multi-threaded applications. Now, almost 15 years later, Windows probably still sucks at multi-threading, Windows applications are probably mostly single-threaded or poorly multi-threaded, or worst, the NT core of Windows XP or Vista still can't spread a processes threads across CPUs( or cores ) and so Microsoft is trying to fix the problem by trying to make some magic tool to spread apps across CPUs/cores.

BTW, the first time I got my hands on Windows NT, I was blown away at how much I got the hourglass just using the OS and the default utilties. I went and checked out how many threads things were using and it became obvious why. So there you have it, about 15 years of providing a poor platform for multi-threading and now it is time to start doing something about it because it is a marketing problem.

If only Microsoft were a technology company first and a marketing company second.

LoB

Re:Most PCs are fast enough

[SlashWombat]

Most PC's are fast enough for current applications. But, 16+ cores could easily change that, allowing applications that haven't even been thought of yet. (and not just a better gaming experience)

It wasn't that long ago where people were under the impression that 640k of memory was more than enough.

Re:Most PCs are fast enough

[OrangeTide]

scientific and engineering are a completely different market. Although a lot of us do modeling on equipment that has less powerful processors than our desktops these days.

The thing is people don't really need a more powerful machine. The hardware is capable of handling the workloads you described. And when someone said that we won't need anything faster than a 387 fpu, or more than 640K, or whatever. They were right. And were never proven wrong. Just because a market is out there for flashy gadgets that don't really work any better than 20 year old technology doesn't prove the naysayers wrong.

I think we're very close to a point of diminishing returns. Where 16 to 64 cpus won't really make a difference in a computer's capabilities from the point of view of a home user. And most of us would rather have 1 cpu that runs 16x faster than 16 cpus. Because like it or not, we don't really run very many active contexts simultaneously. Generally threads in a home PC are just waiting on a resource, and the load average stays below 2.0.

Numbers don't lie. If your loadavg is not bigger than the number of cpu cores, then you will see minimal performance improvements. (ie you have too many idle cores for your workload)

ps - don't get me wrong. i love the idea of cheap multicore. And as a developer, I love my 4-way and 8-way machines. But if I thought it was going to make Flash and AJAX run better I would be kidding myself.

Re:Most PCs are fast enough

[betterunixthanunix]

Well there is also going to be a shift in the way computers are thought of and used. For example, right now you use a computer like a tool...a very complex, very delicate tool, but a tool nonetheless. A future system that responds to facial expressions would be an entirely different way to view a computer, since your facial expressions aren't very useful for controlling something like a web browser. In that case, the computer, or at least that facet of the computer, would be invisible to the user...

Re:Most PCs are fast enough

[OrangeTide]

It wasn't that long ago where people were under the impression that 640k of memory was more than enough. 640K was more than enough .. for the sorts of things you could do in DOS. When it was said there were already systems that could support up to 8MB and 16MB of RAM. And university and the aerospace industry were building maxed out configurations. It's absurd that you would interpret it as meaning that for all cases, all situations and all people that 640K is enough. It's as absurd as trying to think it means the entire world could share 640K between a billion people.

640K RAM (and a harddrive) is plenty for spreadsheets, non-wysiwyg documents, non-graphical interfaces, and even TCP/IP for email/newgroups.

If a home user's needs move beyond email, web, videos, chatting, etc. Then we can rethink how much hardware they need. But until then, my Mom does not need a 16-way Intel to make her Internets faster.

I think smaller and cheaper with novel packaging and interfaces is likely the wave of the future, and not processing power. I suspect home computers will eventually become obsolete. You will be able to literally phone-in your work and write/dictate all the spreadsheets you want. And in 20 years, outside certain business/industry sectors, there might only be a few "power users" who bother getting a laptop, even.

ps - I'm kind of sick of the whole "and people said man would never fly" type of argument. Seems pretty weak.

Re:Most PCs are fast enough

[Nikker]

Defiantly bandwidth is needed but as far as 1080p compressed or uncompressed I was actually surprised when I tried to play that on my 2.53Ghz P4 and it choked, I was getting about 10fps. That is really the only reason I currently have for shopping for a new system.

Re:Most PCs are fast enough

[gallwapa]

lets not forget the potholes on the roads. Hit one of the monster sink holes on I5 at 400 mph...I can see it now:

"Car flies into air at 400mph, does a 1080, lands in school yard 2 miles away and kills 19 children."

P.S. Don't forget potheads, either. People don't drive safely at 5mpg with their cellphones, makeup, DVDs, nav systems, iPods, McDonalds...you get the idea

Re:Most PCs are fast enough

[Belial6]

"Get an apartment near your work."

Terrible, terrible idea. Definitely not thought out.

Re:Most PCs are fast enough

[bradkittenbrink]

That sounds like a great way to continue to sell hardware at a premium, and allow vendors to keep making money off of moore's law.

It doesn't sound like a very good way to allow end users to make efficent use of their hardware.

If users want a cost effective piece of hardware that's good for a lot of things, I don't see how generic hardware that can be load balanced isn't a win.

Re:Most PCs are fast enough

[pjabardo]

Actually the drag increases as the square of velocity: F = Cd.A.1/2.rho.V^2

Re:Most PCs are fast enough

[Anonymous Coward]

Some people would rather feel superior in a hybrid and drive 60 miles to work than on a bicycle riding 2 miles. Go figure.

Re:Most PCs are fast enough

[treeves]

...maybe a plug and pray architecture ...

Is AMD doing so poorly that that's their only hope?

Re:Most PCs are fast enough

[Jeremi]

And most of us would rather have 1 cpu that runs 16x faster than 16 cpus.

Sure, anyone would. Barring some major breakthroughs in superconducting circuits, however, it's not going to happen anytime soon.... well, not unless you want to run one of those liquid-helium cooled machines.... :^)

Re:Most PCs are fast enough

[espressojim]

You need a half way decent video card - they do a lot of the heavy lifting for HD video compression now.

Re:Most PCs are fast enough

[espressojim]

You forget about those of us using compute farms to do work. My place has 700 blades that are dual core right now. If we had 8 or 16 cores, that's a lot more available compute time - I often see 10-20K jobs pending to hit the farm, so having more compute to dispatch all those processes to would be great, and it wouldn't take up more server room (which is a big issue when space becomes limited.)

Re:Most PCs are fast enough

[GaryOlson]

I realize that locking cores into specific tasks is a lot easier...

Would you please show McAfee how to lock their anti-virus processes to unique non-shared cores so I can get some work done? Thanks

Re:Most PCs are fast enough

[Anonymous Coward]

Mod this guy +1 Informative!

Re:Most PCs are fast enough

[Wordsmith]

So what you're saying, is he should offload the processing from his system's one core to another core ... just on the video card.

Re:Most PCs are fast enough

[boteeka]

Guess you're just filling the gap for the necessary car-analogy... Good point BTW.

Re:Most PCs are fast enough

[electrictroy]

>>>"The thing is, most PCs have plenty of computing power as a single core system

>"And 640k ought to be enough for anyone."

No not really, but I think PCs will follow a progression similar to cars. When cars were first available they were a mere 10-20 horsepower. As the technology developed, engineers learned to make better cars until the 1950s when a family car might have 400-500 horsepower. In theory engineers could have continued building more-and-more powerful cars, so that we would have 4000-5000 horsepower today, but there simply was *no need* for anything more than 400-500 hp, so that's where the power curve stabilized for family cars. (And eventually dropped as fuel economy became a higher priority than power.)

Same with PCs.

I've watched them progress from 1 megahertz to almost 4000 megahertz with 4 cores... but now we are reaching the point where PCs have more power than what most people need. We are coming to the top of the power curve where engineers will be able to build 10-20,000 megahertz machines (someday), but there simply won't be the need to buy anything higher than 4-5000 megahertz. The average consumer will buy just enough power to play the latest High-Def movies.

Same way that today's average consumer buys a car with just enough power to get to work & back home.

Re:Most PCs are fast enough

[electrictroy]

Or else buy a CPU that's not 6 years old. ;-) He's got the same CPU I bought back in 2002! Of course a 2002-era CPU can not handle 1080p. I don't even think 1080p existed back then, and 1080i was mainly just a pipe dream reserved to only $10,000 TV sets, not PCs.

However a modern 2007-designed CPU should be able to handle that movie just fine.

So why upgrade if the 2007-designed CPU can play 1080p movies flawlessly? What possible *real world* (not star trek) application could make someone want to get a faster cpu.

Re:Most PCs are fast enough

[electrictroy]

>>>"when someone said that we won't need anything faster than a 387 fpu, or more than 640K, or whatever. They were right. And were never proven wrong. Just because a market is out there for flashy gadgets that don't really work any better than 20 year old technology doesn't prove the naysayers wrong."

Well...

I gotta disagree. It's a nice modern feature to be able to hear REAL music instead of sid-music (C=64) or watch REAL movies instead of 5-minute graphics demos (Commodore Amiga). There have been quite a few improvements over the technology that existed twenty years ago. As much as I enjoyed SID music and Amiga "movies" back in the 80s, I still prefer getting the real deal with MP3s and MPEGs on a modern multi-megabyte machine.

Re:Most PCs are fast enough

[Anonymous Coward]

xbox 360 already works this way. three cores. 2 for the game, 1 for the OS. Really? As an Xbox 360 developer, that's news to me! I'd better go and rewrite my game that uses all 3 cores then...

Re:Most PCs are fast enough

[avandesande]

This is my point exactly. CPU manufacturers right now are shooting for pointless engineering goals, just like a 400mph car would be.

Re:Most PCs are fast enough

[jwo7777777]

I can drive my tractor safely at 5mpg...

Re:Most PCs are fast enough

[OrangeTide]

"scientific and engineering are a completely different market."

You need more cores for your reading comprehension.

Re:Most PCs are fast enough

[OrangeTide]

People used records and tapes if they wanted to listen to REAL music and watch REAL movies.

Right now a cheap ass 1Ghz single core system can play HD video content (don't argue, we do it already), and 5.1 channel music at 48kHz+. About the only thing lacking in today's PC's are Blu-Ray drives.

What do you do at home that more computing power is going to suddenly make better? Drive my car, yes absolutely want that but I don't think my desktop PC will be doing that task. A 8-way core in every car, makes perfect sense to me, but that's completely different from a general purpose desktop home computer.

ps - the DACs on the Amiga were capable of playing "REAL music". And you could play audio CDs just fine on it if you had a drive.

Re:Most PCs are fast enough

[TheLink]

"For example, a computer that might interact with its user purely by voice -- more advanced voice and language recognition systems are likely to require significantly more cores and computational power than is currently in wide use."

I actually think very few people want to talk all day.

I'd rather interact with my computer via "thought macros". I pick macros, and the computer learns them (if it's too hard for the computer, I pick a different one, the top software will find it easier to reliably recognize a variety of thought macros), and also by an auxiliary video in (either implant or just a normal screen or microscreen).

This way, the computer becomes a super extension of me. So I can think: [computer][calculate]145656/1.15[/calculate][/computer], and the computer will calculate the answer for me or [computer][past_recall][associated brain pattern/state][/past_recall][/computer], then the computer will try to retrieve its records of the rough time and date when I set that associated brain pattern or state, naturally for lower latency i could think of [back] or [forward] before doing [/computer] in order to find the incident I want to recall.

Voice is quaint ;).

Seriously voice recognition is klunky as a primary method of control. Voice recognition will still be useful, but more so that I can ask the computer "Whose voice is that?", or "let me know if you hear XYZ's voice anywhere".

The military would be interested in: "Let me know if you see a gun muzzle/possible danger item, and highlight it to me", "turn on automatic crack-thump location of snipers now".

Given all this I don't see the real need for doing the parallel processing the way they are talking about, one core for gun muzzle, one core for heli, one core for audio/video preprocessing etc, it all adds up even if you single thread the processes.

You give me the cores, I can think of lots of ways to use them.

Re:Most PCs are fast enough

[TheLink]

You know what really bothers me?

It's when you stick in a CD/DVD into the optical drive and Windows freezes for a significant moment.

Same goes for other cases where the UI pauses and I don't get to do other stuff, even though there's PLENTY of CPU left, and even for a single core low end CPU.

The rest of Win2K/XP doesn't bother me as much.

In fact Firefox 2 has been very annoying, more annoying than IE. I can launch IE in multiple different processes but I can't do that with Firefox. If an IE instance hangs or uses too much memory, I can kill it without affecting my other IE instances. Same if an IE instance crashes - doesn't affect the rest. Can't seem to do that with firefox 2, unless you create X different users to run X different instances, which is ridiculous.

So when one tab out of 40 causes the entire firefox to hang, I have to kill firefox (and thus every tab etc) and restart again, and often it doesn't resume all the sessions properly (especially when you have more than one window, each window having multiple tabs). When firefox starts to use 1GB of RAM, I have to kill everything, not just close one tab, or one window. If the firefox developers can't get things right, they should design it to fail better.

m$

[elzurawka]

"You may have heard about Intel's and Microsoft's efforts to finally get multi-core programming"

So, In other words, a language for Windows.

Re:m$

[Anonymous Coward]

Sing#

UFC's next fight

[Archangel Michael]

In the new octagon (8-way processors), a battle of the ages, Crapware vs AntiCrapware

Most of the new cores are being used to isolate crapware and anticrapware in a Battle Royal.

And it looks like Crapware is going to win in a submission tapout at the current rate.

Le Roi Est Mort Vive Le Roi!

[introspekt.i]

The big deal will be when we (the user masses) get to use something that's not x86. Don't get me wrong, more cores are way cool, but there's always other ways to improve. Backwards compatibility :'(

Re:Le Roi Est Mort Vive Le Roi!

[Anonymous Coward]

> The big deal will be when we (the user masses) get to use something that's not x86.

You might as well acquiesce to the fact that it ain't gonna happen. Unless a company comes along that is influential enough to "get things done."

Re:Le Roi Est Mort Vive Le Roi!

[introspekt.i]

Hence the crying :'''(

Re:Le Roi Est Mort Vive Le Roi!

[Jerry Coffin]

You might as well acquiesce to the fact that it ain't gonna happen. Unless a company comes along that is influential enough to "get things done."

There is no such company.

Microsoft originally designed Windows NT to be portable, and ported it to most of the popular architectures, including MIPS, PowerPC and the DEC Alpha (and probably SPARC, though it never made it to market). All of those have died, because they didn't sell well enough to stay on the market. Right now, Windows is available for the Itanium, but I certainly don't know anybody who's running it on one.

Intel has tried as well -- the Itanium is only the latest attempt at superseding the x86. In fact, the 8086 was originally designed specifically to be clumsy to program, in the hope that it would leave room for the iAPX432 to take over the market when it became available. Intel failed on both counts: the 432 as buggy as sin, and by the time it was available at all, the IBM PC had already taken the market so completely that Intel never produced a 432 that worked worth anything.

Of course, quite a few others have tried as well -- at one time, Sun pushed the SPARC as the architecture that would kill the x86. Sun still sells SPARC boxes, but they sell x86 servers as well.

From a slightly different viewpoint, the masses have already moved onto something else -- but gained very little from doing so. None of the current game consoles uses an x86. While the PS3 and Xbox 360 both have a lot of computing power, the Wii (with substantially less than either one) is what really gets a lot of people excited. The excitement isn't over the CPU though -- it's over the controllers.

The masses also buy a lot of CPUs in cell/portable phones. For this market, the ARM is the dominant architecture. It has excellent power consumption characteristics and such, which is nice, but in the end nobody really cares all that much that it's an ARM.

If, for example, Motorola 680x0 had dominated the market instead of the x86, life would be a bit nicer for those of us who still hack out a bit of assembly language now and then, but the reality is that most people would hardly notice or care. Apple has switched from the 680x0 to the PowerPC to the x86, and most users hardly batted an eye as they did so. To the typical user, CPU architecture is about as relevant as the brand of pipes used to bring water into their house.

Re:Le Roi Est Mort Vive Le Roi!

[PitaBred]

Do you even know WHY you dislike the x86 architecture? Seriously... so many people bitch about it, and I get the feeling that they don't understand what they aren't missing.

Don't get me wrong... I've used Power-based machines, etc. I've programmed on them. With the way that x86 is designed, it's pretty much a RISC core with an x86 wrapper, which gives the programmers and compilers a much easier time optimizing, as well as still running fast.

Seriously... what is this x86 hatred that's flying around so much? Is it like the AMD fans that refuse to think that Intel might produce something worthwhile?

Re:Le Roi Est Mort Vive Le Roi!

[introspekt.i]

Easy there, tiger. I do know why I dislike it so much. Learning to program ASM for it introduces you to N layers of nasty. Compared to other alternatives the entire system seems way more complicated than it has to be. I'm not really hating on the thing..but it almost seems like it has been doing something it was never really intended to do...though that's the story with a lot of things (the Internet for example). I don't even know what you're talking about with this x86 hate talk, either.

For the record, I think AMD and Intel both do cool things, too. No hates. Kthxbai.

Re:Le Roi Est Mort Vive Le Roi!

[mikael]

From the 80x86 days (the 1980's), the Intel architecture had a segmented memory architecture. The register set consisted of a handful of register (AX,BX,CX,DX) and a bunch of segment registers (BP,SP,SI,DI), all of which constrained programmers to work in 64K blocks. This led to there being at least six different compiler models for applications (tiny, small, compact, large and huge), each of which was different permutation of 16-bit vs 32-bit addressing modes for data, stack and code execution.

Even using the programming languages at the time (Pascal, C), any memory allocate operation was still constrained to just under 64K (16 bytes lost due to memory management using double linked lists). Memory was convoluted using Conventional memory, high memory areas, upper memory area, extended memory, and expanded memory instead of simply having a flat continuous architecture. Some people resorted to manually reordering the location of device drivers , while others used Dos Extenders to improve performance.

For anyone doing image processing work, meant they had to rewrite their algorithms so that images were read in row by row, processed and written out row by row. Everyone had to write lots of little command line programs to do operations one at a time.

At the same time, all the RISC CPU's used by the UNIX systems of the time had a least 8 general purpose 32-bit registers with no need for segment registers. Systems came with a luxurious 8 Megabytes of memory. Any large data file could just be memory-mapped into an area of virtual memory or just read into an arbitrary sized block of memory allocated with a single 'malloc'.

So it was relatively easier to write applications. You didn't have to worry about whether the extended memory drivers were the latest version or not.

Will more cores help me decipher this run-on?

[alta]

I am not sure what Intel's and Microsoft's expectations are, but it is quite possible that they are in fact looking at fundamental results from the academic centers to leverage their large work force to polish and realize the ideas that come forth. Maybe my brain needs a new compiler. This must be a multi-core sentence.

Re:Will more cores help me decipher this run-on?

[Ceriel Nosforit]

Lets form a cluster instead. - My WU returns:

Take research result from universities, give them to Marketing.

Re:Will more cores help me decipher this run-on?

[jwo7777777]

Mine returned:

Take Marketers, shoot them.

Multicore Programs

[Ironsides]

Software that will exploit 16+ cores already exists. The problem is, it is not consumer (home/office) software. There does not yet exist an application that people use that really needs multiple cores. Video encoding is getting there, but most people will never use it.

Re:Multicore Programs

[MrKevvy]

re: "There does not yet exist an application that people use that really needs multiple cores."

This one does. Well, not need multiple cores, but it will happily use as many cores up to full utilization that you can throw at it. I see plenty of 8-core servers at the top of the projects' stats sorted by machine. This is an application that plenty of people who aren't IT pros are running.

Re:Multicore Programs

[Abcd1234]

I think by "that people use", he probably means normal applications one would use and interact with (as opposed to mesh-network distributed computing applications, which clearly fit in a very different problem domain). And in that light, the OP is, I think, absolutely correct.

Re:Multicore Programs

[Anonymous Coward]

Well, I have to do encoding for video for my iPod....maybe thats how video encoding could take off

Re:Multicore Programs

[Xafier]

The software I am currently working on, VenturiOne, uses as many cores as you can throw at it, its been written from scratch with multi-threading in mind. Our demo machine currently has dual quad-cores in it and 8Gb of ram. It will evenly distributing the computation amongst all cores thats available... compared to our competitor's software it can be tens of times faster depending on the files being analysed :) Its very difficult to multi-thread legacy code correctly, if you want to implement multi-threading effectively then it really has to be a decision being made at the beginning of an application, the same can be said for undo/redo... its one of the great advantages to starting a completely new project.

Re:Multicore Programs

[Ironsides]

Let me know when you have something for home use and not business, research and developement.

Re:Multicore Programs

[eh2o]

Dunno about the UIUC side, but a significant part of the UCB/ParLab grant includes research into applications.

There is also a recent paper that shows how the MapReduce pattern can be easily applied to just about every machine-learning algorithms with near-linear speedup. This stuff isn't just going to be used to make the next Clippy, but for more interesting stuff like video processing, speech recognition, sensor fusion in "smart" handhelds, etc.

The applications and the need exist, but so far they have not been practical, at least in part because of computing limitations.

Re:Multicore Programs

[ChrisA90278]

Apple's multi-touch track pads will let us see if getures are a good way to control computers. If it is then I can see that the nest step will be to do away with the touch pad and just move finger n the air while a web-can type device watches. That could use use a few cores. Watching a user's eyes to see what part of the screen is being read could be usful too. What about sorting my library of photos by object, for example finding all the ones with a give person in them? There are lots of uses for computing power. And then there is alwys voice

Re:Multicore Programs

[spacefiddle]

I think parent and gp are partly right, but... i also think availability begets use.

Like with music, streaming video, and other forms of content creation, people who'd never really think of producing their own stuff (and maybe shouldn't :D ) give it a try.

There are web comics, indie movies, the Machinima crowd... i can see high-end CGI rendered shorts becoming as common as Flash animation.

Yeah it's only one example, but i guess my point is that lots of things happen that aren't thought of before they occur. There's a *lot* of people out there. Give them tools they never had before, and it won't be long before we get a surprise.

Re:Multicore Programs

[Anonymous Coward]

Well you are right, but in a few years there will be programms with a lot of features and so the will need multicore computers. http://www.multicorepower.eu/ is a community just about multicore

I hope they do better then GPU manufacturers.

[Brit_in_the_USA]

I hope they do better at getting useful coding tools into the hands of home coders than GPU manufacturers have to utilise the parallel programmable nature of modern GPU's.

Multi-threaded qsort() anyone?

[mi]

It should not be very hard... The algorithm begs for multi-threading — once you divide your array, you apply the same algorithm to the two parts, recursively. The parts can be sorted in parallel — this has a potential for huge performance gains implications in database servers (... ORDER BY ...), etc.

Anyone?

Re:Multi-threaded qsort() anyone?

[MOBE2001]

I agree. Qsort is a perfect candidate for parallelism. Check out the COSA parallel quicksort page.

Re:Multi-threaded qsort() anyone?

[Anonymous Coward]

What if you have only 10 (or 100) elements to sort. At what point it becomes faster to use the multicore approach?
Not everything is faster or worth doing in parallel.

Re:Multi-threaded qsort() anyone?

[Yokaze]

You mean something like parallel_sort in libstdc++, since GCC 4.3.0?

One of several parallelised standard algorithms.

Re:Multi-threaded qsort() anyone?

[Anonymous Coward]

Do you like it when people talk in broad strokes about what Jews are up to? Fucking bigot.

Re:Multi-threaded qsort() anyone?

[adonoman]

I'm pretty sure that any serious database is already taking advantage of multiple cores. With servers in general, you get nearly free parallelism by processing each request on its own thread. Because of the way caches work on the average multi-processor desktop, it's generally better to keep different processors working on separate data, so the threads aren't continuously invalidating each other's caches.

Quicksort is parallelizeable to a degree, but you quickly lose efficiency as you add more processors - with 16 processors, you can only get something like a 8x speed-up. There are other parallel sorts that utilize extra processors more efficiently (you can combine an N-way mergesort at the top level, to split the data up for multiple threads, and then let each thread run a quick sort on a given chunk, and then merge all the results back in.)

Re:Multi-threaded qsort() anyone?

[johannesg]

And how does that help? Any dataset that fits in memory can be sorted almost instantaneous using a single core. And datasets that do not fit in memory don't benefit from having more cores since they are IO-bound anyway.

Re:Multi-threaded qsort() anyone?

[mi]

Any dataset that fits in memory can be sorted almost instantaneous using a single core.

Even in 128Gb of memory? Even if the comparison function (qsort()'s last argument) takes a while to complete?

Re:Multi-threaded qsort() anyone?

[mi]

You mean something like parallel_sort in libstdc++, since GCC 4.3.0?

Uhm, yes, something like that... But it ought to be transparent to the caller — I just want to keep calling qsort() from my (portable) code and have it take advantage of the multiple CPUs, when available.

Re:Multi-threaded qsort() anyone?

[Yokaze]

Then go for:
CXXFLAGS="$CXXFLAGS -D_GLIBCXX_PARALLEL -fopenmp"
this will lead redirect calls like:
std::sort(begin, end)
to
__gnu_parallel::sort(begin, end)

Exceptions are not standard comform anymore, as the code is now parallelised.

Re:Multi-threaded qsort() anyone?

[mi]

Uhm, maybe... Anything for C, though?

Sun?

[Anne Thwacks]

Of course some of you will know that Sun have had 8/16/32 cores for quite a while, and that Solars, *BSD, and probably even Linux support this stuff just fine.

Its only you peasants that persist in using old-hat Wintel stuff that are so last-year. Get with it people! You too could be runningNetBSD on your toaster (it will probably out perform Windows Vista in a 4-core Pentium anyway). Hell it might even eat Nandos peri-peri Vista for breakfast!

Re:Sun?

[GreggBz]

Of course some of you will know that Sun have had 8/16/32 cores for quite a while, and that Solars, *BSD, and probably even Linux support this stuff just fine.

The NT kernel has supported SMP for 10 years. So what?

It's all about the applications. Sure, there's some development tools in *nix for multicore. I doubt they are efficient and accessible though. Can y'all tell me how great GCC is with 16 cores and thread level parallelism? I'm sure some academic and or low level solutions exist everywhere. However, it's undoubtedly a PITA whatever platform you work with. Everyone could use better tools for the future. Especially for making desktop apps.

Re:Sun?

[Anonymous Coward]

Actually, Sun released already their T2 with 1 cpu x 8 cores x 8 threads, so it runs 64 threads in parallel. We have those at work, and scalability on Solaris10 is simply _amazing_.

Re:Sun?

[Locutus]

The NT kernel has supported SMP for 10 years. So what? It sucked at it compared to OS/2 and probably Solaris 10+ years ago and because of how poorly it did threads, most Windows apps did what Microsoft did and pretty much stayed away from threading. And to be relevant to the current discussion, Windows threading did not cross CPU/core boundries while OS/2's threading did 10+ years ago.

So, are you saying that Windows( XP and/or Vista ) threading can cross core boundries? If so, why would Microsoft be trying to come up with a way to get developers to target multi-core hardware when all they'd have to do is push multi-threading because the OS supposedly took care of the CPUs for the developers?

It's about the really bad OS design IMO.

LoB

Re:Sun?

[setagllib]

Firstly, NT supports SMP, but it doesn't scale well to utilise it. Windows Server 2008 might be tolerable, but it's not going to compete with current, let alone future, Linux, and the higher the core count, the bigger the divide gets.

Secondly, GCC doesn't care about threading scalability. It's all up to you as the application architect to design a parallel system.

Academic and real-world examples are well known. Once you get the basic ideas down, the vast majority of throughput bottlenecks parallelise out very well, and those that don't never will anyway (e.g. Dynamic Programming algorithms).

Re:Sun?

[Anonymous Coward]

10 years ago Intel/NT was finally capable of real SMP. Mostly 2 way systems with some 4. Theoretically 32 were possible but it wasn't like you could go out and buy one. Meanwhile companies like IBM, Sun, Fujitsu, etc have been building large SMP servers for much longer.

I don't know if GCC supports TLP yet, but it is not the only compiler available. Sun Studio does well in this area. It should considering the company's been on the edge of SMP and multicore/multithreaded processor technology.

Re:Sun?

[drsmithy]

It sucked at it compared to OS/2 and probably Solaris 10+ years ago and because of how poorly it did threads, most Windows apps did what Microsoft did and pretty much stayed away from threading. And to be relevant to the current discussion, Windows threading did not cross CPU/core boundries while OS/2's threading did 10+ years ago.

What do you mean by "cross CPU/core boundaries" ? Windows NT has been able to schedule artbitrary threads onto arbitrary processors since *at least* NT 4.0 (and probably 3.1).

It's about the really bad OS design IMO.

There's nothing wrong with NT's design. It's leagues ahead of OS/2 (as it was designed to be).

Re:Sun?

[drsmithy]

Firstly, NT supports SMP, but it doesn't scale well to utilise it. Windows Server 2008 might be tolerable, but it's not going to compete with current, let alone future, Linux, and the higher the core count, the bigger the divide gets.

Benchmarks ?

Re:Sun?

[Anonymous Coward]

Just a small correction. There are no 4 core Pentiums. Pentiums stopped at 2 core (PentiumD).

The new Intel Atom(TM) Toasters are supposedly Vista capable though.

Re:Sun?

[Locutus]

What do you mean by "cross CPU/core boundaries" ? Windows NT has been able to schedule artbitrary threads onto arbitrary processors since *at least* NT 4.0 (and probably 3.1). you are right since I found a couple of pages which say that NT threads can cross CPU boundaries. Interesting since when I was working on OS/2 and NT apps in the mid 90's, NT performance was really bad on dual CPU systems with a heavily threaded app. It was explained to me at the time that the NT kernel didn't let a process's threads spread out across the CPUs. Whatever it was, the OS/2 port was much faster on the same dual CPU system as the NT port and that was before any 32bit data structure alignment was done since the Pentium Pro wasn't optimized for unaligned structs as much as aligned ones. I did read that in a comparison with Solaris, NT did not do so well when there were more threads than there were CPUs for each process. So a dual CPU system would mean 2 threads/process and after that performance starts going down. That's understandable and this is probably where OS/2 did better than NT and apparently Solaris did also.

I did read that NT has something called fibers which are not handled by the scheduler. I wonder what that was all about? Maybe some cooperative tasking mechanism left over from the DOS/Windows days.

So all this big deal about parallelism seems to be about building multi-threaded applications? Why is that making headlines?

LoB

Re:Numba One!

[Anonymous Coward]

Fail.

Show me the money Intel.

[stratjakt]

SMT processors of this type are only useful for accelerating a certain type of problem set, and useless for most general computing.

We've had SIMD multicore PC's forever, and they're useless as desktops. I write this from a quad xeon machine, repurposed as my dev box, as CPU1 grinds away at about 75% all day long, the rest idle. It's been like that for more than a decade, it'll be like that until MIMD hits the street with a whole new paradigm of programming languages behind it - a handful of C compiler #pragma directives from intel isn't going to make this work.

It's not simply a matter of "coders don't know how to do it." It's a matter of these multi-core "general purpose" CPUs are only really useful for a fairly limited set of specific problems.

Eg; writing a game engine with a video thread, audio thread and an input thread still leaves 13 cores idle. You really cant thread those much farther (the ridiculously parallel problem of rendering is handled by the GPU).

Simply starting processes on different procs doesn't help all that much, since they all fight over memory and I/O time. The point of diminishing returns is reached fairly quickly.

But hey, if all you do is run Folding@home so you can compare your e-cock with the other kids on hardextremeoverclockermegahackers.com, well I have some good news!

As for me, I'm seeing AMD's multiple specific purpose core approach as being more viable, as far as actually making my next desktop computer perform faster.

Savain says it best at rebelscience.org: "Even after decades of research and hundreds of millions of dollars spent on making multithreaded programming easier, threaded applications are still a pain in the ass to write."

Re:Show me the money Intel.

[BoChen456]

Just because today's software paradigms can't utilize mutlicores very well doesn't mean multicore architecture is fundamentally flawed. As far as we know, our own brains are a vastly parallel system, and we seem to be flexible enough to solve most problems.

Re:Show me the money Intel.

[rickb928]

"Eg; writing a game engine with a video thread, audio thread and an input thread still leaves 13 cores idle. You really cant thread those much farther (the ridiculously parallel problem of rendering is handled by the GPU)."

Woopsie. I think you presume that games don't need more processing before the GPU so much.

What if you could thread out, and preprocess the video? We don't know, cause it's not yet practical. The tools to write that software don't exist.

Actually, if we get enough cores as CPU, when do we start to need less GPU? The real question will be if the multi-cored CPU feeding the GPU frames is the answer, or is Intel's http://www.pcper.com/article.php?aid=534&type=expert&pid=3 GPU vision the answer?

I suspect we could turn video card development on its head by processing the raster on a 16-32 core CPU array, leaving 1 core for audio, 1 core for game engine, 1 core for AI, and 1 core+ for physics.

But the bottom line is that games will drive multicore development, with imaging/graphics/video (same thing as games, really) also on board.

Re:Show me the money Intel.

[adonoman]

So parallelize the AI - you can give more and more smarts into NPCs.
With the right memory architecture, you can reduce memory contention between processes on different processors (at the cost of slowing down inter-process communication).

Re:Show me the money Intel.

[everphilski]

a handful of C compiler #pragma directives from intel isn't going to make this work.

That's OpenMP, and depending on the program, it can work wonders. In an hour I parallelized 90% of a finite element CFD code with it. Yes, it sucks for fine-grained parallelization.

Intel's product is Threaded Building Blocks, and is not built around pragmas, and is both commercial and OSS. It's pretty slick and will let you do the more fine-grained optimizations.

It's a matter of these multi-core "general purpose" CPUs are only really useful for a fairly limited set of specific problems.

Not entirely true, it's just useful for problems that need a processor.

I write this from a quad xeon machine, repurposed as my dev box, as CPU1 grinds away at about 75% all day long, the rest idle.

... obviously, you have more processor than you need. I, on the other hand, have a quad core Opteron that is currently over 350% utilization. I tank it almost 24/7.

the ridiculously parallel problem of rendering is handled by the GPU

Not for long. Raytracing is making a comeback.

As for me, I'm seeing AMD's multiple specific purpose core approach as being more viable, as far as actually making my next desktop computer perform faster.

If you can't even tank one core of your Xenon, it's doubtful.

"Even after decades of research and hundreds of millions of dollars spent on making multithreaded programming easier, threaded applications are still a pain in the ass to write."

I'd caveat that by saying "threading arbitrary program X is a pain in the ass." There are plenty of useful programs that are easily parallelized.

Re:Show me the money Intel.

[tinkerghost]

Actually, if we get enough cores as CPU, when do we start to need less GPU?

When CPU's get better at churning out FP math solutions. The whole purpose of the GPU is it's a massive net of FPUs. I think Cell style technology is going to be more similar to the type of chip we see in 10 years than an Intel C Core w/ 100 Pentium type cores in it. Ideally, I think you are looking at a processor 'office' for each thread - 1 supervisor core, multiple FPUs, a couple of CPU cores, perhaps 1 or 2 GPUs & a few FGP units, and a 'Tasking Core' to govern all of the 'offices'.

Think about it, if you have some FGP units in the 'office' you can purpose each 'office' for specific tasks that currently work best with secondary chips - AES encryption, HD video decryption, voice & video processing, etc. They might not be as fast as a custom burned chip, but w/ 90% of the speed combined with infinite flexibility it's a whole lot cheaper than trying to cram 10-20 custom chips into the system. Need to do voice recognition with that system, the software requests a thread & passes in the FGP structure. The Tasking core passes it to an unused 'Office supervisor' which passes it to a FGP unit. Now all the requests for voice recognition pass through the tasking core to the 'VR office'. If the queue builds, the 'office supervisor' passes the FGP setup to another FGP unit under it's control & starts running multiple threads of it's own.

If elements are built with thread safe API's there's not a lot of reasons that this can't work.

Re:Show me the money Intel.

[Rhys]

The desktop PC should be idle most of the time. User input is really slow and in general the machine is waiting on the user, not the other way around. However, ask yourself who's time is more valuable, the machine you bought for $1,500 that lasts 3 years (at least, that's hardware update cycle around my work), or the person you pay $150,000 over a similar time frame? (give or take on location, entry-level position) Pay 10% more ($150) for the computer to save the person 0.1% ($150) of their time? That's an even trade at least. That 0.1% of the person's time, by the way, is 28.8 seconds per (8-hour) workday.

How often has a site locked up your web browser? How much time do you spend waiting on a on-boot virus scanner (memory, boot sector, enable on-access-scan) to run against your machine? I'm not bothered when beagle fires up an auto-index on a multi-core machine. I never notice the performance hit of it. How long does an entry-level developer spend kicking their shoes back while a compile runs (trivial to parallelize to some degree)?

Speaking of the developer, if he's writing games, there better be each of the 13 other available cores busy running AIs. The more cycles you can throw at them, the better they can play without blatant cheating. Some games get an exception to this (mostly online MMOs, but also puzzle/etc games) but even there there can be useful things to do. How about voice chat software (MMOs) that does open-mic-feedback analysis and automatically filters out anything it is sending to the speakers?

Just IMHO. No, desktops can't really currently make good use of a 8+ core machine. The jury is out on quad cores at the moment, but dual-cores are a performance boon over singles.

Re:Show me the money Intel.

[smallfries]

You seem to be wrong on just about every point that you've tried to make. Take a look at the previous article on multithreading that made the slashdot frontpage (I think about a week ago). Somebody tried the same argument as you and was shot down quite forcefully in the largest thread in the discussion.

None of the people that argued could come up with a single real-world problem that couldn't be hacked into working on multi-core systems. When you say "SMT" I assume you've made a typo and mean SMP. SMP is a very general class of parallel systems and is certainly not "useless for most general computing". Name a single real application that cannot take advantage of multiple cores.

You don't seem to know the difference between SIMD and MIMD. Here's a clue: multi-core systems are MIMD, although they typically have SIMD instructions within each core.

Your game example is weak; it sounds as if your game has no internal logic. Once you add AI and some sort of world simulation there is plenty of scope for using those 16 cores.

Lastly, quoting Savain just makes you sound like a retard. The guy is a crank and has been pushing that bullshit on his webpage for years. It only shows that he doesn't understand language design or computer architecture as well as he thinks, and that he should really start taking some form of medication.

Re:Show me the money Intel.

[Anonymous Coward]

Why 1 core for AI and 1 for physics?

Threaded, have 1 thread for each AI object, and 1 for each physical object? :D

40.000 threads, all bouncing around them there 13 remaining cores should keep them (and the scheduler) busy!
. /G

Re:Show me the money Intel.

[Anonymous Coward]

Two Words for parent:
gmake -j4

For everyone else who asks "Oh, what ever will I do with 16 cores!?"
answer> gmake -j16

Re:Show me the money Intel.

[Jeremi]

We've had SIMD multicore PC's forever, and they're useless as desktops. [...] it'll be like that until MIMD hits the street

Those acronyms, I don't think they mean what you think they mean. SIMD refers to a Single Instruction operating on Multiple Data values in parallel... think Altivec or SSE. MIMD is Multiple Instructions, Multiple Data... i.e. the multiple CPU machines you and I have been running for years.

Re:Show me the money Intel.

[kgilpin]

It's a matter of these multi-core "general purpose" CPUs are only really useful for a fairly limited set of specific problems.

Not necessarily. Long-running code can be compiled to run in many threads (CPUs) at the same time. For example there is this MIT Cilk project that was fairly recently spun out as a funded startup

http://supertech.csail.mit.edu/cilk/

Naturally, if you have a highly multi-threaded program then having many cores is useful. But even for single threaded programs, a multi-core toolkit can compile/interpret a compute intensive function to run across many cores.

Cilk is focusing on C++. I think interpreted languages have a real edge here because the parallelization can be built into the interpreter; the JVM for example.

Re:Show me the money Intel.

[__aailob1448]

Eg; writing a game engine with a video thread, audio thread and an input thread still leaves 13 cores idle. You really cant thread those much farther (the ridiculously parallel problem of rendering is handled by the GPU).

Hi! My name is AI, I'll be happy to eat any number of cores you throw at me!

NOT SO FAST, AI! I'm RAY, RAY TRACING AND....

Anyways, you get the picture. 640k ram yadda yadda.

Re:Show me the money Intel.

[master_p]

The problem is that current programming languages don't use a programming paradigm like the Actor model, which makes every object a separate thread. If such was the case, each new core would increase parallelism, as permitted by the underlying algorithm.

Re:Show me the money Intel.

[Anonymous Coward]

But the bottom line is that games will drive multicore development, with imaging/graphics/video (same thing as games, really) also on board.

And how long has it been since that's held true? All home users (or 'gamers', in this case) do is reduce the price of hardware through impulsive upgrades. Meanwhile, the ones driving actual progress are doing actual work (and enjoying the constantly-lowering prices of CPUs).

Hardware description to parallel programming lang?

[Anonymous Coward]

The structure of VHDL is inherently parallel as all processes (blocks of hardware) run at the same time. Only the code within the processes is evaluated sequentially (in most cases).

Although VHDL is a hardware description language, couldn't similar concepts be used to make a parallel centric computer programming language?

stupid much?

[ILuvRamen]

Instead of trying to convince everyone on Earth to change all existing software, why doesn't Microsoft just make the next version of Windows have a process handler that can process single threads on multiple cores at once? Actually technically I think Intel could do that internally on their processors too sort of like RAID for cores. It seems really difficult and inefficient but if they finally got it right so it worked, all software would run faster on multi-core chips! Talk about a selling point! Cuz right now the 90% of my software that only processes its resource intensive code in a single thread actually runs slower on a 1.8GHz quad core than on a 2.6 GHz dual core!

Re:stupid much?

[adonoman]

Individual threads are already being parallelized just about as much as they can. Your processor will happily run two sequential operations simultaneously if it detects that it won't cause trouble. It will even re-order operations if that will help in parallelizing things.
Add pipelining into the whole deal, you can easily have more than a dozen operations being processed at any instant on a single thread of execution.

Re:stupid much?

[Jerry Coffin]

Instead of trying to convince everyone on Earth to change all existing software, why doesn't Microsoft just make the next version of Windows have a process handler that can process single threads on multiple cores at once? Actually technically I think Intel could do that internally on their processors too sort of like RAID for cores.

Intel's been doing that (to some degree) since the Pentium, and they increased it a lot in the Pentium Pro/Pentium II. It works reasonably well up to a point (modern chips typically execute an average of two instructions per clock cycle) but definitely has limits.

Compilers to automatically detect when instructions can be executed in parallel have been around for years. Cray had vectorizing compilers by the late 1970's, and within rather specific limits, they worked perfectly well. Just for example, if you wrote a loop like:

for (int i=0; i<256; i++)
a[i] = b[i] * c[i];

they'd break the loop down into four actual executions of a loop, each of which worked on 64 items in parallel. It had independent execution units, so at a given time it'd normally be loading one set of 64 items into one set of registers, executing multiplications on a second set of 64 items, and storing results from a third set of 64 registers.

That has a couple of problems though. First of all, if you're not careful, it's pretty easy to create loops with (apparent) dependencies from one iteration to the next, so the compiler can't parallelize the code. Second, this works well for vector processors, but probably not nearly so well for a large number of completely independent processors (which have higher communication overhead, meaning that starting up things to happen in parallel is more expensive).

If you're willing to provide the compiler with a little help, it can do quite a bit more, such as with MPI. The standard MPI interface is pretty low-level, but if you want to do the job in C++, Boost.MPI helps out quite a bit (cheap plug: if you want to know more, consider attending Boostcon '08).

We do it already

[Colin Smith]

We all already have networks of servers all running in parallel. Multi core processing is simply squashing the network onto a little bit of silicon.

Re:We do it already

[geekoid]

Really? that's what you think? it's the same thing squished down?

Re:Sun? 8-Core 64 Threads

[hostguy2004]

Sun T2 uses 8-Cores & 64 Threads, like HyperThreading on steroids. This processor comes to its own running applications that can take advantage of thread-level parallelism (TLP) http://en.wikipedia.org/wiki/UltraSPARC_T2

We have already seen this one, it ended badly

[jmorris42]

Didn't we already see this one? Intel (this time AMD also) develops radical new processor arch that will be insanely great once a quantum leap in developer tools is made to utilize it.

Itanic crashed, burned and sank against the rocks of the compiler tech not being able to keep up. I see it happening again.

Yes we will find ways to make a quad core system stay busy enough to sell em to corporate desktops and home users. Hell, you can assign one to the virus/crapware scanner. Waste another or two doing ever more Movie OS like 3D effects on the desktop. Most apps can (and will be ) be rewritten to keep a couple of threads busy, even if it is less efficient than the older single threaded version. But sixteen or more? We better get cracking on natural language voice recognition, direct brain interfaces or something to keep the chipmakers profitable because traditional desktop apps won't ever keep that many cores busy.

Re:We have already seen this one, it ended badly

[turgid]

Itanic crashed, burned and sank against the rocks of the compiler tech not being able to keep up

There is a fundamental flaw in the itanic design philosophy that no compiler will ever be able to make up for. There are some optimisations that have to be done at run time. They can't be done at compile time. itanic was conceived out of 1970's supercomputer research before out-of-order, speculative execution, dynamic branch prediction RISC processors had been invented.

There was in itanic fore-runner back in the 80s that suffered from all the same problems. Somehow, the crackpots persuaded the PHBs at HP and intel that it was the Way Forward.

itanic style designs (in much simpler form) are useful as Digital Signal Processors.

Re:We have already seen this one, it ended badly

[Anonymous Coward]

What you don't think we can have another excel hack? Come on excel code base 55 megs and 55 gigs for the AI accountant easter egg.

Re:We have already seen this one, it ended badly

[earthforce_1]

About the time the 386 was still considered a high end PC, a former roommate of mine who was doing a software engineering related Master's degree was convinced that no home user would ever find a use for multi-threading, except for printer spooling. He was as obviously wrong as Bill was with his 640K comment.

Even your humble word processor can be broken into hundered of threads, I would bet OpenOffice has dozens. Today, threads are considered expensive as RAM once was, but in the 16 core world they will be considered cheap. For example, separate threads could easily be dedicated to handling:
Screen & Window rendering & management
Controls management (scroll bars)
Local mouse tracking
Keystroke entry
Printing
Menu command dispatcher
Page breaks
Paragraph breaks
Automatic hypenation & indentation
Footnotes & references
Font kerning
On the fly spell checking
On the fly grammar checking
Gathering statistics such as word/paragraph/page counts, readability level, etc.
Undo/Redo list management
Disk drive I/O management
Autosave management
Dynamic links with other documents or web
Macros

And this is just a simple word processer, never mind what else is going on in the background - web page updates, streaming audio/video, downloads, kernel processes, TCP/IP stack handling, etc. Running "top" on my desktop shows 129 tasks, and I don't think I am an atypical user. Sure, only a small fraction of these need to be doing useful work at any given time, but I am not running any CPU intensive apps at this instant. If I start ripping CDs in the background or assembling .rar files into a DVD the CPU gets hammered pretty quickly. Imagine if I could rip each track simultaneously? What if each .rar component could be reintegrated in parallel? What if my screen was broken into 16 or more parts, each rendered by separate core, communicating only what they need to over shared memory.

Checking programs for race conditions/deadlock and other contentions will get very tough, I can see help coming here from automated code analysis tools. And I can see C/C++ eventually giving way to inherently parallel languages, or being extended.

languages designed for smp scalability

[barnacle]

from my point of view "multi-core" programming is just "SMP" programming - the programmer doesn't care where the cores are distributed on which chips.

there are two interrelated parts to designing languages for SMP scalability in my opinion: designing the programming interface (the syntax - the concept of how the programmer works with the language) and making the right implementation in the compiler or virtual machine to achieve SMP scalability, i.e. maintaining maximum efficiency of usage of each core while providing maximum flexibility in manipulating data.

The first part is more art and the second more technical; both make up the overall language solution.

I've designed the qore programming language for SMP scalability, however using a more traditional approach to threading - as opposed to interesting techniques such as those taken by Erlang or Scala

Basically in qore there are a lot of optimizations aimed at reducing the amount of cache invalidations while still providing as much shared state as possible between threads. It's basically a dynamically-typed language where global variables and objects are shared between all threads and local variables are thread-specific. For such nice and easy-to-use (i.e. thread-safe) access to data it has very good performance, even on single-threaded code (particularly upcoming version in svn trunk which has a completely re-written type system and some massive new optimizations).

While the art of design of the programming language in this case is not as exotic or interesting as scala or erlang, for example, the more traditional approach and the fact that the entire language was designed to be thread-safe and scalable on SMP machines can serve to make it easier for some programmers to write multi-threaded code.

Qore supports deadlock detection and will throw exceptions on outright threading errors as well to make multi-threaded programming a little easier to work with in comparison to some other languages.

Qore supports a pretty unique feature set, in that it's designed to support embedding (and arbitrarily restricting) code, interfacing, and SMP scalability in a dynamically-typed language.

It also supports native XML and JSON de/serialization, powerful and very easy-to-use database drivers (including a DatasourcePool class that offers transparent datasource pooling on a per-thread basis), perl5 regular expressions, and a lot more.

the new version (coming "real soon now" :-) ) in svn trunk has a qt4 module (just starting working on the opengl support :-) ) and a documented (with doxygen) and stable API.

Anyway, if anyone's interested in checking it out, the homepage is:
http://qoretechnologies.com/qore

and the project is also hosted on sourceforge:
http://sf.net/projects/qore

-David

Dozens of core

[Anonymous Coward]

...which may have dozens of core on one chip... Does hardware come in flavors of "core," like music? So, what would be the hardware equivalents of hardcore, grindcore, thrashcore, gothcore, nerdcore, etc.?

Re:Hardware description to parallel programming la

[MOBE2001]

Although VHDL is a hardware description language, couldn't similar concepts be used to make a parallel centric computer programming language?

Excellent suggestion. This is precisely what the COSA software model is about. A pulsed neural network is my preferred metaphor for an ideal model of parallel computing. Intel and the others are on the verge of losing billions of dollars because they are already deeply committed to the hard to program multithreading model, a complete failure even after decades of research. To find out why multithreading is not part of the future of parallel programming, read Nightmare on Core Street.

Moving the bottleneck...

[MarkEst1973]

Forget software not being written for multi-cores, the entire infrastructure around the computer needs to "go wide" for massive parallelism, not just the software. This includes disk, memory, front-side bus, etc./p>

I'm doing highly concurrent projects (grid computing) for my company and we're finding that some things parallelize just fine, but others simply move the pain and bottleneck to a piece of infrastructure that hasn't quite caught up yet.

For example, my laptop has a dual-core 2.2Ghz processor, which you'd think is great for development. It's no better than a single CPU machine because my disk IO light is on all the time. IntelliJ pounds the disk. Maven and Ant pound the disk. Outlook pounds the disk. Even surfing the web puts pages into disk cache, so browsing while building a project is slow. Until I get a SCSI drive, you're still limited on disk IO, so those extra cores don't help that much.

All the cores are great on the server, though. I've recently completed a massive integration project where I grid-enabled my company's enterprise apps. All those cores running grid nodes is giving us very high throughput. Our next bottleneck is the database (all those extra grid nodes pounding away at another bottleneck resource...)

Terracotta Server as a Message Bus. It's been a very interesting project.

Re:Moving the bottleneck...

[geekoid]

well, dual-core 2.2 that tells us everything we need to know for your point to be valid~

Re:Moving the bottleneck...

[Prune]

Get two 10000 RPM Raptor drives and run them in Raid 0. The difference over a regular, single 7200 rpm drive is immense and I've never seen as big one from any other upgrade. Sure, they're only 150 GB but I use slower drivers for video etc.
I also found that getting faster RAM makes more difference than a faster CPU, which suggests that too many programs have poor cache behavior.

Re:Moving the bottleneck...

[Anonymous Coward]

It wouldn't be disk I/O, but seek time. Compiling lots of little files that exist all over the place and are changed regularly (e.g. fragmenting) is the problem. That's where SCSI would fit in nicely, since they are optimized for this environment, whereas consumer disks are optimized for sequential reads (e.g. videos).

One potential gain is to overboard on memory, which is what ZFS does. That just moves the pain, as you said, or at least for me since the application servers generally consume their fair share. I've seen massive improvements moving between filesystems. For example, ext2/ext3 are horrible performance-wise. By moving to UFS2 (soft updates), compilation time dropped by over 1/3rd.

Btw, I'm having fun being a core member developing my employer's distributed frameworks too. I would, however, never touch Terracotta. I've been to their tech presentations and dug through the code. I very much prefer writing frameworks specifically to solve the problems, rather than extending the JMM to be cluster wide. Terracotta isn't a good JMS replacement, for among other things, there can be only one active server (thus, hacks to communicate between distinct clusters). I'd prefer an in-process + out-process caching layer rather than a superviser that coordinates it. I'd prefer a framework dedicated towards distributed processing (e.g. master/slave, fork/join, map/reduce) rather than making locks cluster-wide by changing what synchronization means. That said, they have beautiful code and I've interviewed former employees. I'd hire them, just not use that stack. :)

Re:Moving the bottleneck...

[ModMeFlamebait]

Get two 10000 RPM Raptor drives and run them in Raid 0.

Just back up your data before, while you still have it.

Re:Moving the bottleneck...

[Prune]

You should have backups regardless.
I've been running this configuration myself for over two years without a hitch.
Your comment is typical Slashdot troll fearmongering.

Virtualization

[Bryansix]

The solution is right in front of our faces. If you use virtualization then you can easily make use of a 16 core system. I can have IIS, Exchange, a Linux Apache Server, and a Terminal Server all on the same physical machine.

Re:Virtualization

[DaveInAustin]

This is exactly what Intel is trying to avoid. They want people to do more computing, not consolidate their purchases. The need to sell more PC's with more CPU's. They want people to find uses for the extra computing power. In business, there are plenty of uses for that power. If people's applications are using just one core at at time, the consolidation effect will occur and Intel's sales will plummet. If applications make good use of the multiple cores, the applications themselves become more useful the competitive advantage people who use those applications have over people who don't will increase, and Intel's sales will actually increase.

Re:Virtualization

[Abcd1234]

Man I hope this was a tongue-in-cheek post. Virtualization, used in this manner, is precisely equivalent to scheduling multiple processes across cores, only you also get the virtualization overhead. It's most definitely not a solution to the problem Intel is trying to solve (making it easy for developers to write individual pieces of software who's problems can be naturally broken down and distributed across multiple cores).

Re:Virtualization

[Bryansix]

Virtualization, used in this manner, is precisely equivalent to scheduling multiple processes across cores, only you also get the virtualization overhead.

Obviously you've never used a Microsoft product before. They aren't exactly stable. The virtualization means that one thing doesn't take down another. Also certain apps don't get along. MSSQL for instance running with anything else gives you headaches. Plus I mentioned running multiple operating systems (Windows Server / Linux) on the same machine.

It is a Problem with Problems, not Developers

[essinger]

Yeah, I agree with this view. Multi-threaded programming isn't really hard. I would think by now most coders are quite comfortable with the concept and the implementation. Multi-user application are no-brainers -- most are well-threaded. From my experience the trouble is that most single-user applications are ill-suited to it. Unless you have many processes occuring at once or a particularly well-suited type of static math problem (like video encoding) it tends to be useless.

There is also

[Anonymous Coward]

Data Parallel Haskell.

Cheers.

Why not sponsor Scala?

[matsh]

Scala is a JVM based language that has good features for working well with multiple cores (Actors, immutable collections, functional language, etc), so why not sponsor it?

Mats

Intel already HAS autoparallelizing tools

[whistl]

About 10 years ago, Intel bought Kuck and Associates, Inc (where I used to work), which for years sold "The KAP" auto-parallelizing C and Fortran optimizing compilers. Many of the KAP programmers still work in Intel's compiler group today. Intel has had access to these tools for years. The KAP worked fine on 20 cpu Sequent computers back in 1993, so why are these tools "new technology" 15 years later?

Intel already has some good threading tools

[Glasswire]

...for Linux, Mac and Windows supporting multicore and also cluster architectures.
Obviously it would be better if these worked better and were easier to use, but many people are unaware of the tools that are available right now.

20 million?

[spatley]

You can't blow your nose for less than 20 million at either Intel or MS. I know lots of stories of 50-100 million dollar projects that led to absolutely nothing. And these are companies that are taking in billions every year.
This must be very low priority for them.

Seriously Folks

[Nom du Keyboard]

Seriously, Folks, who can do anything for a mere $20M today, let alone change the entire programming paradigm of the last 65 years?

Re:Seriously Folks

[geekoid]

The current programming paradigm isn't 65 year old. In fact, that's been changed. I am of course tlaking about newer wide use systems. Do you know how program was done 25 years ago?

I do, and it's not even remotely the same.

Re:Seriously Folks

[Nom du Keyboard]

Do you know how program was done 25 years ago?...I do, and it's not even remotely the same.

Yes. My C.S. degree was awarded in 1977, and I was programming 7 years prior to that.

Oh, guess what? I've been doing it even longer than you have, and I know how similar the approach to single-thread, and even multiple-thread one-instruction-after-the-previous-one still is.

Re:Hardware description to parallel programming la

[Jerry Coffin]

Although VHDL is a hardware description language, couldn't similar concepts be used to make a parallel centric computer programming language?

Sure. In fact, VHDL is based (closely) on Ada, which allows pretty similar things. The relevant differences are less between the languages than how they're used. Ada that was written in the same style as most VHDL would have a high level of parallelism as well.

That's rarely done though, because designing hardware in VHDL (or Verilog, etc.) is expensive, largely because designing things this way is difficult. Virtually nobody's willing to put up with the long lead times and extremely high initial expense of such a design for software, unless it's doing something that really gains a tremendous amount from doing so.

Of course, that hasn't stopped people from trying. The Transputer was one early attempt. The Ambric is on the market now, and apparently sells pretty decently into a few specialized markets (e.g. video encoding/decoding) but I've never heard of anybody even advocating that it was a practical tool for a typical desktop computer.

This is around for years, no results

[sainttX]

Just like AI, nothing worth a real prize. Look at what we expect, no compromise, machine learning is NOT real AI, similarly, what we have now is not real parallel. Can we build the parallel machine? Program it easily? Why are we not satisfied with MPI? Usability...

Re-thinking Cores

[olemarc]

What if there was a Core of a say Quad or Hex or Octo etc. processor that only parted out processes to the other Cores. It's sole job would be to part out and reconcile various operations. This would make the other Cores much more efficient by getting them the right information completely separate from software.

How to deliver ever improving performance?

[gothmogged]

How does Intel persuade people to buy new CPUs if there is no benefit delivered to the buyer?

How does Microsoft sell you new licenses if you don't buy a new computer?

Virtualization at the OS image level only allows you to run multiple different applications. Running more applications at once isn't the primary goal of the average user. They want the application which has the focus of their attention to be slick and fast.

Multicore CPUs do not allow you to run a single application faster. Intel's PC market and Microsoft's empire were built in a feedback loop based on the promise that you can buy a new machine every two years and your applications will run significantly faster. This held true until a few years ago when semiconductor technology hit the heat density wall on ramping up clock frequency. Now, and for the forseeable future, if you buy a new machine your single threaded application will run NO faster than it did on the old hardware.

That in a nutshell is the multicore problem. Most existing software is not written to exploit parallel processors. Most software developers cannot write a correct parallel code. The promise of "buy a new one, it is faster and better!" becomes a lie if the the software cannot exploit the extra cores.

No one has the solution to this in their pocket. Threads aren't the answer because they are a ridiculously hard to use correctly outside of very coarse grain contexts. Automatically parallelizing compilers have never delivered the goods in the general case. New languages face extremely slow adoption. The answer probably lies in languages, but the adoption problem is an extremely tough nut to crack. The recent successes here are Java (basically C++ with garbage collection) and Javascript+AJAX, which I don't think any heralds as a radical leap forward in language design.

I am involved in this research personally, so I'm not just pulling these assertions out of the air.

Multiple Programs is the focus

[GroovinWithMrBloe]

There does not yet exist an application that people use that really needs multiple cores.

People need to stop thinking that 'I don't have a program that uses 16 cores (16 real threads), so I don't need a 16 core system).'

Chances are you have at least 16 programs running and each of those is run in a thread. User Applications aren't the only things that need CPU time. It's only the touching the surface.

People are not creating multicore systems with the idea that a single program will use all the cores. Some programs will be more multithreaded than others, but that's not the point.

With multiple cores, you give the user the feeling of a more responsive system (due in some part I'd imagine from the CPU scheduler having far more real threads to work with than a single core system). Resource allocation of cpu time becomes more generous/less taxing for the OS.

The end result is that your MP3 player will run happily along in the background doing its thing, while your file download manager is downloading many files off the net, and the user is sitting down writing his word document, which has real-time spell checking that doesn't pause while it scans the large document. Oh, and Gmail is running on your web browser. Your IM client of choice is somewhere around there too.

All these programs have multiple threads (I won't even bother mentioning the plethora of operating system/system utilities and services and their threads).

Imagine splitting the CPU cycles of 1 core for all these tasks, and sharing them fairly, against splitting the cycles of 2..4..16 cores.

why so much disk I/O?

[Chirs]

Outlook I can understand. It needs to flush the emails to disk before replying back to the server.

However, there's no reason why the web browser needs to ensure that the data hits the disk cache right away, so it should be just fine sitting in RAM until the disk frees up. Similarly, intellij, maven, and ant should be slow the first time but faster later on since they should be reading from the page cache.

There's no reason for your disk I/O light to be on unless you don't have enough RAM or the disk algorithm in windows blows chunks.

I do linux kernel development, and once I do an initial pass through the source tree the whole thing generally stays in RAM and I rarely have to hit the disk. I have 3GB of RAM, but this isn't excessive nowadays.

Faster CPU's are not the problem

[EEPROMS]

I've got a dual core machine sitting on the desk before me and the cpu rarely goes above 20% load. The strange thing though is it is still slow when loading programs and this is due to the hardisk (SATA II) being the bottle_neck on my system. I could fix this to some degree with a RAID setup but the real question is why isnt this being looked at more closely ?

Re:Faster CPU's are not the problem

[Mista2]

Slow because spinnning platters tkae time to read data. If is is a single platter large capacity drive, the seektimes will be low. Highspeed fibre disks are usually mulitple platters, multiple heads and have lots of hardware based cache working with them on a SAN, These are fast. To make applicaitons load fast, you just need to write with a small binary for the user interface, and have other parts of the program load in the background. That way it seems fast to the user. That is why windows presents a login box as soon as possible, but still takes a couple of minutes to actually log you in and load all the other startup cruft. 8)

Re:Faster CPU's are not the problem

[TheNetAvenger]

due to the hardisk (SATA II) being the bottle_neck on my system

And people tried to make fun of Vista using free RAM for advanced HD Caching... Weird how Microsoft was on top of that, and even stranger is the Linux project to mimic the intelligent caching of Superfetch, all the while SlashDot people were making fun of it, until a few people realized how beneficial it was to overall performance.

BTW HD bottleneck technologies are being looked at more closely, as on a Vista system with I/O priority and intelligent caching, your HD becomes a much less important impact on performance, and as Flash and other solutions are designed to do addition prefetching and replacing slower HD technology, Vista's mechanisms are also designed to take advantage of these emerging technology replacements.

Also with x64 becoming more and more standard (especially in the Vista x64 market), having 16-128gb of RAM will not be so uncommon before long, and then technologies like Superfetch really go to town virtually eliminating all HD performance constraints. (This is why and how Vista continually gets faster and 'scales' up as more RAM is added, so there are performance gains even from 8gb to 16gb, even though your running applications are only using 400-900mb.)

Re:Faster CPU's are not the problem

[ZerdZerd]

You'll probably want to buy an SSD, when they get cheap enough.

Re:Hardware description to parallel programming la

[Anonymous Coward]

Perhaps you could please explain COSA. I fail to see any difference between it, and any other existing component framework, or GUI based language. More importantly, how do you ever intend to implement COSA, and keep threads out of it? Support from the CPU manufacturers is the biggest long shot ever, their job is only to provide a CPU, not accommodate any language. And in reality, any existing compiled language could just as easily make use of such a CPU, at such a low level, its really all up to the compiler, no matter what language you use. Sure, some languages might give the compiler more insight, but its still not really going to be super faster. Any higher level implementation and its no real diffrent then existing component/parallel programing models, which must use OS provided features to achieve parallelism, such as[especially] threads.

As I already pointed out, the OS is what will determine how to parallelize things. Its true threads are quite horrible, but that cant be helped. If you really want to achieve easy parallelism, then what feature(s) would you demand from the OS to achieve it? Because no matter what new language you come up with, the fact remains that the OS runs the computer, and the compiler handles the CPU, and there are no other locations where its possible to take advantage of parallelism.

You missed a huge marketplace

[Nursie]

Business driven server systems.

We love multiple threads and in some cases multiple processes and/or multiple machines. DBMS's, transaction processing systems, web servers, middle tier data servers....

The code is already in place and the more cores you throw at us the faster we can run. It's not mathematically complex tasks but it is workhorse stuff that parallelises beautifully, though not in a particularly fine-grained way.

There's more to computing than consumer desktops and science/engineering departments. Think about the infrastructure of the world - the financial markets, the credit card networks... all sorts of other things that don't instantly spring to mind :)

To which I respond...

[SiegeTank]

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re:Hardware description to parallel programming la

[MOBE2001]

As I already pointed out, the OS is what will determine how to parallelize things.

Not at all. The processor should be designed for the software model, not the other way around. All of our current processors are designed for the algorithmic software model, which that was created 150 years ago by Charles Babbage. It's time to change. Like it or not, the computer industry will be dragged kicking and screaming into the 21st century.

Re:Hardware description to parallel programming la

[Anonymous Coward]

Indeed, but then just how do you encode a COSA style datastream for execution by the processor? No matter how hard I try, I simply cant figure out a better way (or rather: any other practical way) then algorithmic code for the CPU level of computation (which itself is pretty much the same as the abacus). Sure, you can have procedural based CPU's, or function based, or recursion based, but I cant figure out how a object based method would look, let alone how to program it.

Re:Hardware description to parallel programming la

[earthforce_1]

I had actually proposed this here more than a year ago. I think this is the way to go, perhaps alternatively with Verilog or System C. Too bad they don't have a search capability of your old postings or I would have linked to it.

CPU is not bottleneck on desktop

[ToasterMonkey]

People need to stop thinking that 'I don't have a program that uses 16 cores (16 real threads), so I don't need a 16 core system).' On a desktop PC, the IO system is going to be the source of contention a far more often than the processor(s). How often do most people run several CPU bound tasks simultaneously on a desktop anyway? Extremely rarely.

Imagine splitting the CPU cycles of 1 core for all these tasks, and sharing them fairly, against splitting the cycles of 2..4..16 cores. If the CPUs you currently have aren't being heavily utilized, then having more of them isn't going to give you any perceptible improvements. This is really a matter of scaling horizontally as opposed to vertically, and they both suit entirely different workloads. The average workload of a desktop PC is shifting slowly in one direction, and not much at all in the other.

Netlogo?

[Anonymous Coward]

why can't we have something like netlogo, except based on a real language? netlogo is pretty awesome as it is, but why can't we have a dialect of Python that makes parallelism that easy?

Beowulf?

[jakepmatthews]

imagine a Beowulf cluster of ...!

Re:Hardware description to parallel programming la

[Anonymous Coward]

Sortof. There are parallel functional languages that describe portions of a parallel program, and some magic system will figure out how to map those to hardware. Those never worked very well for most types of applications though. Thus noone uses them.

$20 Millon Man

[JavaBasedOS]

We can build him. We have the technology.

Yesterdays Paradigms

[krischik]

Indeed, before "Worse is better" took off computer science hat better ideas. Have a look at some ideas about multi core / multi threading form 1983:

http://en.wikibooks.org/wiki/Ada_Programming/Tasking

But you can use them - just use "gcc -x ada" ;-) [1]

Martin

[1] You need a fully installed GNU Compiler Collection for it to work.

All ready done: Ada

[krischik]

Well, VHDL is based on Ada, so why not use Ada then? Have a look:

http://en.wikibooks.org/wiki/Ada_Programming/Tasking

Martin

Why not use what's already?

[krischik]

As I and other already pointed out VHDL was modelled after the Ada programming language - and as such Ada already has the multitasking features you are looking for:

http://en.wikibooks.org/wiki/Ada_Programming/Tasking

Martin

Re:Hardware description to parallel programming la

[master_p]

It can be done via the Actor model.

Re:Hardware description to parallel programming la

[dargaud]

It's called LabView ! Where spaghetti code actually looks like spaghetti...

A bit offtopic.

[Corporate Troll]

As the technology developed, engineers learned to make better cars until the 1950s when a family car might have 400-500 horsepower.

Family cars had that kind of power in the fifties??? I'm just asking, I wasn't born. It does sound extremely strange a since highest end Porsche 356 only has 130HP. We're talking sportscar produced from 1948 to 1964: the timespan you describe.

Not being all that informed about American cars, I headed over to wikipedia "Ford" (American right?), took a "full-sized" category car from the fifties: the Ford Fairlane (Hey, I know that car from GTA!) and it's only mentioned power in the article says rated 225HP. Not bad, far from the 500HP you claim. I also clicked on the link to the "Chevrolet Bel Air" (which according to the article "overshadowed" the Fairlane) goes up to 195HP. (In the sixties there is a 409HP model which is a collectors vehicle now)

So, either you're looking at the fifties in roze coloured glasses, or I'm looking at the wrong category of "family cars".

As a final note: the engineers behind the Bugatti Veyron had to overcome quite a lot of obstacles to reach those 1001HP the car is rated at. How theBugatti Veyron works.

Re:A bit offtopic.

[electrictroy]

My numbers may be a little off, but the point I was making is still relevant. Engineers could put NASCAR engines inside modern cars, and give everyone ~1000 hp, but it would be overkill for the family car.

Likewise I expect computers will also reach a point where they run at ~15,000 megahertz, but that too will be overkill for the family computer.

Re:A bit offtopic.

[Corporate Troll]

Your point stands, but I wasn't arguing your point. The fact is: no, one cannot simply put a 1000HP engine from a NASCAR car in a production car. You should have read the "how stuff works" article I linked to: it explains in simple words why we don't have 1000HP engines and it's purely because engineering that is very very hard.

As for 15GHz processors... Might be, might not be, but as you surely know: gigahertz isn't a good indicator for performance and considering the fact that we've been hanging around the 3GHz the last few years, I'm pretty sure that the reason is engineering too. (Mainly caused by heat...)

But, yes, your point stands: end-user requirements for computers have pretty much plateaued.

This problem is already solved

[skeptictank]

There are dozens of modeling systems that will map algorithms across an arbitrary number of homogeneous processors. Most of these development tools don't target x86 instruction set based machines, so I guess thats why Intel doesn't seem to have a clue they exist. Or perhaps this is a bunch of hype to lay the ground work for a future marketing campaign.

National Instruments already does this

[CapitalC]

http://www.ni.com/multicore/ They have been doing it for a while.

PVM?

[GordonCopestake]

Surely the lessons learnt from PVM and other similar networked parallel machines can be used in multicore programming?

Re:Show me the money anyone!

[owndao]

Does anyone know of a benchmarking of the top OSs showing performance as core numbers increase for various activities? To me the question for the buyer is going to be: What can this computer/OS/App offer to me as the number of processors (and thus chip/machine prices) increase? I suspect that what we will find is that performance increases diminish as the number of processors increase due to fundamental multi-core architecture problems involving moving data intra as well as inter chip even before we get to issues involving how to best allocate the workload. Perhaps the new optical bus technology is needed now that we are potentially asking for 16x (or more with overhead) the current single processor communication load. The optical technology can perhaps eliminate these limitations now so we can get on to the tougher problem of how to intelligently distribute processing resources.

And there it is...

[p3d0]

...the obligatory "current computers are fast enough" comment that we get on every article about new technology.

Re:Show me the money anyone!

[everphilski]

Does anyone know of a benchmarking of the top OSs showing performance as core numbers increase for various activities?

It's easy in my case, since I write my own engineering code. Restrict the number of cores your program is allowed to access. Compare.

Now if you are using commercial software, it's pretty case dependant, but in some areas of work (video rendering is one) software is already utilizing 8 cores, no problem.

I suspect that what we will find is that performance increases diminish as the number of processors increase due to fundamental multi-core architecture problems involving moving data intra as well as inter chip even before we get to issues involving how to best allocate the workload.

I haven't seen this. My data set is pretty small: a quad core Opteron and a dual core Athlon x2. Scaling from 1-4 processors on the Opteron returns rather linear performance increases. Scaling on the x2 is just 2 data points. I will admit my work is very low I/O.

I'd love to build me a dual quad-core Xeon box at home and play with those numbers, but I just don't have the financial reserves at the moment... wife, kids, college keep sucking it away :)