engadget.com — Now that the Megahertz race has faded into the distance (we hear it was a myth), Intel is well and truly kicking off the start of a multi-core war with the demonstration of an 80-core research processor in San Francisco last week.
Feb 12, 2007 View in Crawl 4
philodoxFeb 12, 2007
So Intel has replaced the megahertz myth with the multicore myth? Sounds like Intel just doesn't get what making processors is all about.
grumpyrainFeb 12, 2007
"Multi-threaded programming for an 80-core system wouldn't be difficult? Who are you kidding?"The tricky part of SMP is not the number of cores you use but how easy the problem can be parallelised. If you can separate a problem out into independent tasks, then 80 core is not more complex than 2 core. There is however an overhead in thread creation, synchronisation and destruction so you do not want to just create threads for the sake of doing so. In the case of a browser, there is not really the need to create 80 threads. But you know what? That's ok. I have 36 other processes running at the moment, so even if each just makes use of a couple of cores, they would nearly get exclusive use of a core.
himselfFeb 12, 2007
for $100, Alex, what are 78 cores?(someone has to step up and DUMP backwards compatibility and design a fresh architecture)
blackadderiiiFeb 12, 2007
"All these cores will only be useful when software actually make efficient use of it. Without that it's a meaningless rat race between the processor companies."Don't worry - systems of this size are pretty much geared toward making use of multiple cores, and so are the operating systems and programs run on them.@etnuI really mean no offense, but you seem a bit confused about the nature of the problems at hand.Confused in a way that makes it hard to believe you're a programmer who understands WTH they're talking about. Not to insult you for that, nobody knows everything(I don't, that's for sure), but consider doing some research before trying to dispel myths you see floating around. :-)
ngsayjoeFeb 12, 2007
@chungthomas>>>VHDL is strictly speaking not a programming language, it is a Hardware Description LanguageYes, that's what I'm talking about, I never said it was a software language. I said we said borrow the concept of the idea and implement it for software programming. Hardware are parallel in nature, whereas software has been sequential since the beginning. But we can totally change that mindset, and think in terms of parellism.So how does hardware synchronize when there could be so many parallel components running at the same time? Well, the answer is CLOCK. So implementing a new programming language similar to that of Verilog could solve multi-threading problems. But the problem here is languages such as C/C++, Java, can easily be implemented is because they map directly to the processor instructions. On the other hand, there's no way you can do the same with Verilog as many necessary instructions required to do parallelism are missing. So, you basically need to create a virtual machine to get around that. So, here's what I'm talking about. Create a parallel language, and create a virtual machine, and BANG you have a software programming language for multi-cores without worrying about thread synchronization and stuff. I feel if multi-cores is the future, then a new programming language is imminent! Just a matter of time.
littlebylittleFeb 12, 2007
Can we just get on to "Infini-Core" and be done with it already. I'd like true Light Speed guts with that too (Motherboard, Bus, etc.). Thanks.
phluxFeb 12, 2007
@the Sauce - actually its the reverse... these are specifically floating point cores.
dharmaturtleFeb 13, 2007
"Octogenitalia...that would be very interesting"You'd fall over.
etnuFeb 13, 2007
I'm a professional engineer. I write multi process and multi threaded apps for a living -- mostly server-side these days, but I used to do desktop programming. I never claimed that multi threading (or multi processing, as the case may be) was trivial, I just pointed out that it's not the insurmountable force that people make it out to be. Not every problem can be processed in a parallel manner easily, but many, many tasks can be, and the ones that can't be are usually insignificant enough to not really matter. Common things that can be made into parallel systems (workload distribution, not task distribution) with relative ease:- Video rendering- File parsing- some compression algorithms- serialization- many (though not all) file format transcoding- audio playback (where practical, like game sound effects)- file transfer(these are things I've worked on personally, I'm sure other people have more examples).In addition, there are many task-based ways to do parallel processing that yield huge performance benefits. A video game that goes from a single-threaded app to an app with one thread each for video, audio, input, and physics will almost certainly yield greater performance on a multi core system. If you're going to complain that multi threaded programming is "hard", then you may as well complain that programming, in general, is "hard". If a task can be distributed, it can be distributed using techniques that have been around for decades. There is nothing new under the sun.
theduke333Aug 13, 2009
Is this something new from Intel? Looks like a tech glove of some sort called SOMA. check it.<a class="user" href="http://www.intel.com/business/enterprise/emea/eng/project/orick.htm" rel="nofollow">http://www.intel.com/business/enterprise/emea/eng/ ...</a>