Slashdot Mirror
Intel Expands Core Concept for Chips
Aziabel writes "As most of you have probably heard, Intel plans to come out with chips containing two processing cores next year, but that's just the start. The Santa Clara, Calif.-based chip giant intends to exploit the concept of using multiple processor cores; chips with four cores and eight cores will eventually join dual-core chips, which will begin to appear from Intel next year. The company's research department is also looking at the feasibility of creating chips with hundreds of cores to assist servers and supercomputers with large numbers of relatively repetitive calculations, said Steve Smith, vice president of the desktop platforms group at Intel. The focus on multiple cores arises from Moore's Law, which dictates that the number of transistors on a chip doubles every two years. I say, the more the better. Keep 'em coming, chip-makers!"
...a beowulf cluster on a chip!
How am I supposed to fit a pithy, relevant quote into 120 characters?
It's nothing more than a catch-up move to Sony/Toshiba/IBM Cell, just like EMT64 to catch up AMD. Those late and awkward moves are of bad omen for Intel, IMO.
I am beginning to suspect that Intel does things like this simply to make x86's instruction set harder and harder to emulate well.
Kind of like to what I suspect Microsoft has been trying to do against Lindows for a while now, namely complicate their API more and more. And with IE and HTML.
Of course they're well within their rights to try. We'll just build a better idiot savant. Or let Steve Jobs keep making Apples that no one can really imitate in the first place.
vicious, untreated political sewage...niche entertainment for the spiritually unattractive...worshipless pap
This does not bode well for problems that mathmatically cannot be executed in parallel.
Now I can do away with my furnace.
The problem is with what they (both intel and amd) plan to do is saying a dual core 1.5 centrino (for example) cpu is actually a 3Ghz machine (from the pr they have allready put out about these chips).
Read overclockers.com for some good speculation on what the good/bad/ugly features are likely to be.
...
The focus on multiple cores arises from Moore's Law, which dictates that the number of transistors on a chip doubles every two years.
I don't think non-compliance with Moore's Law is a felony. It's an observation, not a statute. Moore's Law arises from the fact that transistor counts keep doubling, not the other way around.
Also, doubling the number of transistors in any way possible doesn't necessarily translate into double the power for any given application. In this case, multiple cores are good news for multi-threaded or forking server apps, but rather less interesting for a lot of desktop apps. Intel obviously has a vested interest in pushing ever larger die sizes, because it does large dies better than anyone else. Whether this will always be in the interests of the rest of the industry, let alone the end user, is less obvious.
Virtually serving coffee
Personally, I produce more drool thinking about dual dual-core Opterons. Not that that's really necessary. It's just that 4 > 2, and quad processor boards don't make very good workstations, especially in light of two-socket boards from companies like Iwill and Tyan that will also be SLI-capable. Really, all of that power is not necessary, but imagining it makes me feel good. Or is that weird feeling from having stayed up all night?
if a kernel is written to take advantage of multiple cores, would this mean applications written ontop of it would start using the multiple cores?
if not, how feasable is a multicore > single core emulation in linux.
>will begin to appear from Intel next year.
Very likely this is marketing sp33k for "will be paper-launched at the last day of next year"
Belief is the currency of delusion.
IBM have been doing this for years - and its biggest technological success story, the POWER5 chip shows that Intel are blatantly only playing catch-up with this announcement.
5 _moores_law/ shows this perfectly.
http://www.theregister.co.uk/2004/11/26/ibm_power
It reminds me of the way that Intel pretended that they invented integrated wireless technology with its Centrino chip only after Apple had been shipping laptops for nearly two years with internal wireless cards.
Normally, asking if they had no shame would be appropriate but it is unfortunately clear (without the need to ask) that they don't.
Most of the reports that I have read have said that AMD will be releasing theirs next year and Intel the following year. Intel, though didn't start talking of dual cores until AMD started talking about theirs. From research that I have done, each manufactorer has some mighty issues to overcome with the single core before dual cores can be implemented nicely.
AMD has said that dual cores will be clocked anywhere from 600Mhz to 1Ghz slower than the single core counterpart, namely because of heat issues. There are many more issues that arise with dual cores here are a few
Cache correnance
Bus contention
software implementation
plus more
It will be interesting none the less on how each manufactorer overcomes the issues with multi-core chips and the benefits to the user of of multi-core.
A few years ago I thought of a different kind of twist on computer architecture that I labelled OOH.
The basic idea is that a computer could comprise many, many tiny CPUs, each with its own tiny local memory.
A given (CPU+RAM) could be designated to operate as RAM for another CPU, so the MMU/OS could balance the number of processes needing memory with those needing processors.
A (CPU+RAM) could also be labeled as a slave to others, so a multithreaded application could have the number of processors it needed.
I haven't thought about it in a while, and it's been some time since I studied architecture, so probably these ideas are hopelessly naive.
Raise your children as if you were teaching them to raise your grandchildren, because you are.
Sun's new Ultrasparc IV shipped in the SunFire 490's and larger servers already do this. The plans right now are to scale this up to 32 cores per cpu. The only issue that I see is that the memory controller is onboard the cpu, so while you may have 2/4/8/16/32 cores, you still only have a single memory controller, which limits the ammount of ram you can have. I'm sure they have a solution for this, but I don't know what it is.
This signature is a waste of 42 characters
Yeah, it is called Niagara, and it is working silicon now, but far from done. expect an unveiling in February.
If you want to know a bit more about it, I wrote it up a few weeks ago here:
http://www.theinquirer.net/?article=19423
-Charlie
Intel just canned their 8-way chip and replaced it with a variant of Montecito, or more likely a Montvale derivative. Here is a bit on it:t tp://www.theinquirer.net/?article=20286
:)
http://www.theinquirer.net/?article=20270
h
Needless to say, their long term strategies are a tad up in the air right now.
As for their desktop (IE P4 based) dual core plans, there are 2 generations planned. The first is a simple pairing of 2 current cores with a minimum of tweaks, basically a scared response to AMD. The second one is really the first one they planned, and it is a lot more sophisticated.
AMD was there from long before Day One, and have the most coherent philosophy on dual cores for the desktop/server.
Rather than re-write all my own articles here, here is a link where I break down all of Intel's dual core plans as well as some of AMDs.
http://www.theinquirer.net/?article=17906
Sorry for all the self links, but I don't really want to keep re-writing that stuff, links are the reason behind the web, right?
-Charlie
Although for some, non-memory intensive, highly threaded applications multiple cores can be a boon, for many applications this won't be a boost in performance at all.
Remember that each of these processing cores will have to share their memory bandwidth and possibly level 2 cache as well. As it is Intel's EM64T Xeon processors really feel the bandwidth bottleneck in their memory interface and can easily saturate it.
I can see a dual core Xeon being able to saturate its memory bus on its own. Similarly, the dual core Opteron, unlike a dual processor Opteron, will have to share a single memory bus and hence be slower than a dual processor machine.
Adding extra cores merely moves the computing bottleneck elsewhere, it's not a panacea.
Agrajag: "Oh no, not again!"
"Laws" like Moore's, Newton's, Ohm's and others, don't "dictate" anything. They "describe" observations. Intel doesn't meet integration targets based on some hoary old directive from Gordon Moore from the late 1960s. They meet production deadlines projected as close to their maximum productivity. Moore observed the logarithmic rate of transistor integration increase way back then, and described it as invariable as gravity.
Engineers especially must understand that "laws" of nature, including human innovation, are governed by an "invisible hand". Not some imaginary deity, or some government, or some mythic genius. Rather, there is a deeper order to events, like the way every triangle has 180 degrees, the Sun "comes up" every morning, controversial Slashdot posts will get mod'ded "Troll", without any false statements or duplicity. We're engineers: our job is to engage the deeper order, understand it, model it, and exploit it, without further mystifying it.
--
make install -not war
Intel is, no make that was, rumored to be, [no, definitely are] in the process of buying the design group that develops Itanium from HP.
The vnunet page has a little speculation as to why the move is being made. But if you put that together with HP's general strategy of streamlining its fragmented high performance server offerings: Then the picture that emerges is in agreement with parent comment: Intel is in catch-up mode. They have, as other stories and commenters have pointed out in
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
This is much less of a problem than you might thin, not because it isn't a real problem, but because it is so obvious. Everyone already has a workaround, most of which involve FB-DIMMs.
Niagara (see my post above) is bandwidth rich, the AMD solutions are also. The only ones with a looming problem are Intel until CSI comes on in a few years, but that is manageable.
Moral, Sun OK, AMD OK, Intel solid plan.
-Charlie
What you're saying is, for applications with poor cache performance, multi-core processors will be no better than single-core. Personally, I can live with that. Most of the processor developments of the last 10 years have favored applications with good cache performance.
What worries me is what happens when the OS schedules a process with good cache performance on one core, and a process with poor cache performance on the other core. Unless the cache does something special to prevent it, the "bad" process will completely deplete the cache, causing the "good" process to slow way down.
I recently worked on a real-time program for the Pentium IV, and we found that our worst-case performance was actually 4-5 times worse when hyperthreading was enabled, because our process would occasionally have to share its cache with something that was heavily memory-bound.
Excuse me but IIRC Tera is more a multi-threaded processor, not a multi-core. It was intended to run 128 threads simultaneously, and solve the memory latency problem by running each thread in succession. The idea was that if a thread was stalled by a need to access main memory, by the time it got back around to that thread again the data would have arrived. Overall throughput was supposed to put it into the supercompuer class.
You're right that the processor didn't succeed, probably because in practice it didn't preform as well as the theory sounded. What I never understood was that given all the problems in the first Tera machine, why the UCSD-SCC then went back to them and spent to much additional money on a second one?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
It seems to me like you could parallelize most desktop apps.
An MP3 player: I would think you should be able to decode one second with one processor, and the next second with the other processor.
Word processor: I would think that parts of the boot process that do not require the other parts would be able to run independently. Two processors could check alternating lines until the whole document was checked.
Spreadsheets: I would think that the first half of a giant list could be handled by one processor, the second half of the giant list handled by the second processor.
3D graphics, non-accelerated: I would think that the screen could be cut in four, and one processor rendering each part.
Games: I would think the simulation could be divided into parts, and the different parts simulated by different processors.
Compiling, Parsing: If you have 40 files to parse, each processor can handle 10 files, so you would go roughly 4x as fast. Parsers aren't just for C++, parsers are found in just about every program that reads data from a disk or the Internet.
So it seems to me that we could make major performance gains, using multiple processors.
I read that some functional programming languages can automatically multithread a program so that the task is split up over multiple processors. The programmer would just program as for a single CPU and change nothing or very little.
/. thread:
Functional programmming languages examples are Lisp and OCaml.
Oh, correction, from a previous
OTOH, it is theoretically possible to automatically multithread purely functional programs, especially if they're lazy like Haskell. So it could end up being a very important language on multi-processor and distributed systems.
The only way I see multi-core processors or cluster-like processors (Cell) succeed is if programmers switch to languages like that. Any other way would introduce too many bugs in programs. Computers should make life easier, not harder. Even for programmers.
Eventually, multi-core/processor is the only way forward, long before single-processors have to heat up to supernova temperatures to increase speed.
We're just at the beginning of computing. Looking back, programmers of the future will pity us poor folk who had to make do with only 1 CPU. However, we need the right tools to move forward. Anyone know if there's an automatically multithreading (functional) programming language in existance or being invented?
- -- Truth addict for life.