Slashdot Log In
Inside Intel's $20M Multicore Research Program
Posted by
Zonk
on Thu Apr 03, 2008 02:32 PM
from the that-is-a-lot-of-cores dept.
from the that-is-a-lot-of-cores dept.
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.'"
Related Stories
Submission: Inside Intel's $20M multicore research program by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
It's easy (Score:5, Funny)
Most PCs are fast enough (Score:3, Insightful)
Re:Most PCs are fast enough (Score:5, Funny)
So, uh, you haven't Vista yet, I see...
Parent
Re: (Score:3, Insightful)
Re:Most PCs are fast enough (Score:4, Insightful)
Parent
Re: (Score:2)
Re: (Score:3, Informative)
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 process
Re:Most PCs are fast enough (Score:4, Insightful)
And 640k ought to be enough for anyone.
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.
You do not understand how the scheduler works.
Parent
Re:Most PCs are fast enough (Score:4, Insightful)
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.
Parent
Re: (Score:2)
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
Re:Most PCs are fast enough (Score:4, Insightful)
Parent
Re: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:3, Insightful)
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: (Score:2)
Re:Most PCs are fast enough (Score:4, Insightful)
Terrible, terrible idea. Definitely not thought out.
Parent
Re: (Score:3, Informative)
Re: (Score:2, Insightful)
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
UFC's next fight (Score:2)
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.
Will more cores help me decipher this run-on? (Score:5, Funny)
Multicore Programs (Score:4, Insightful)
Re: (Score:2)
CPU is not bottleneck on desktop (Score:3, Interesting)
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
I hope they do better then GPU manufacturers. (Score:2)
Multi-threaded qsort() anyone? (Score:2)
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? (Score:4, Informative)
One of several parallelised standard algorithms [209.85.135.104].
Parent
Sun? (Score:4, Funny)
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: (Score:3, Informative)
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,
Show me the money Intel. (Score:5, Insightful)
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: (Score:2)
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 w
Re:Show me the money Intel. (Score:5, Insightful)
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.
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.
Parent
Re: (Score:3, Interesting)
Hardware description to parallel programming lang? (Score:3, Interesting)
Although VHDL is a hardware description language, couldn't similar concepts be used to make a parallel centric computer programming language?
Re: (Score:2, Interesting)
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 resea
Re:Hardware description to parallel programming la (Score:2)
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, large
We do it already (Score:2)
We have already seen this one, it ended badly (Score:2)
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 ev
Re: (Score:2)
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 t
Moving the bottleneck... (Score:5, Interesting)
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 [markturansky.com]. It's been a very interesting project.
why so much disk I/O? (Score:3, Informative)
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 algori
Virtualization (Score:2)
Re: (Score:2)
Re: (Score:2)
Why not sponsor Scala? (Score:2)
Mats
Intel already has some good threading tools (Score:2)
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.
Seriously Folks (Score:2)
Faster CPU's are not the problem (Score:3, Insightful)
Re: (Score:2)
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 muc
Re: (Score:2)
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
Re:stupid much? (Score:5, Informative)
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:
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 [boostcon.com]).
Parent