Slashdot Mirror
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.'"
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?
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.
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.
Though with current technology speeds that high are very fuel inefficient and the air resistance increases as the cube of the velocity.
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.
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.
Slashdot Patriotism: We Support our Dupes!