Printable View
Where by "the benchmarks", you mean "an actual implementation". ;)Quote:
Originally Posted by richardginn
This sounds like something that would be very difficult to do in hardware. It would be, IMO, a much more interesting development than HyperThreading.
I believe where this really would do some good is in at least a dual core, dual CPU platform whereby the two cores on each chip are treated as one. That way you still have the benefit of having two MONSTER CPUs.
Who knows...this is most likely so far off that something even wilder will be out to market by then.
just my .02 ;)
That's great!:D That means I can give myself more time and see how this pans out.....;)
I really doubt it's a good idea. Gives more incentives to lazy programmers to stay on old, single thread technology instead of learning and using a new one. Yeah, MT is more complex and it has its limits but it's clearly more efficient (and complex to code) than ST. IMHO it's a push to keep marker share with minimal efforts.
BTW, for two cores the same limitations apply as for two threads. I.e. performance increase won't be 2x. And I'd think it will be much worse than two threads working on single task. In general those threads are coded by human programmer, and granted that he know what he was doing it'd be optimized to minimize lock contention and paralelize as much as possible. Now executing ST stream of machine code with two cores. I think it'll be much frequent case when one core has to wait for another core's result to get the job done.
Heh, yeah, it would seem that way, but check out the thread I just started on 4GHz Opterons coming soon. Tbird may yet have to recant and eat his words about AMD getting 'smashed' ;)Quote:
Originally Posted by bldegle2
I’ll believe it when I see it. If you could just wish instruction dependencies away you wouldn’t need multiple core CPU’s to begin with, you could just make a single ultra wide issue core.
It WAS thought of earlier. Parallellised multi-threaded or single multi-threaded CPUs are the wave of the future. Anti-hyperthreading my foot. Its not that easy, its not something you can expect to just turn up in the market one day.
All the big chip makers met a few years ago and had this all planned out. Thats right, AMD, IBM and Intel. Im surprised that everyone here is surprised. If you still have no idea what Im talking about, you should read up about the Cell. :) The Cell chip even gives the first of many ,perhaps, answers to Moridin's question.
With all due respect, the answer might actually shock him. Tbird especially if he even reads this. It cuts out one of his favourite items.
http://www.anandtech.com/cpuchipsets...spx?i=2379&p=1
Intel isn't in the wake either, they've had this on their roadmap for a long time. ;)
The only big news here is that it MIGHT come into succession much earlier than expected. Though I doubt AMD will just make it appear. Im betting its Intel or IBM.
Edit: I hope I don't sound rude or overstep my boundaries. But seriously, this idea has been around for a long time. Im just excited that people actually think that this might come out next fall, that is extremely unlikely. From something that is merely a rumour.
First of all, Cell tech is from consortium of IBM, Sony and Toshiba.
And second, most of us already knew about the Cell technology. After all, that's what would be used in PS3! But still Cell tech is multi-core parallel processing at its best. It's not the same...
Quote:
Originally Posted by Transfurzz
A microprocessor is an inherently sequential device, it does one thing and uses the result of doing that thing as an input into the next thing it does. It’s this feed forward behavior that allows it to do the things is does. While not every instruction is dependant on a previous one, sooner or later you get to an instruction which has an input that comes from a previous output. If this wasn’t the case there are other better ways to accomplish the task then using a microprocessor.
Consider the following example, let’s say you have two sets of numbers you want to add and then you want to multiply the result together:
E=A+B
F=C+D
G=E*F
It’s immediately apparent that the third operation CANNOT be performed before the first two are complete. It also makes no sense whatsoever to perform it on another processor someplace else because there would be a long delay while you moved the first two results over to a second processor.
It is possible to perform the first two in different places or different orders but this is something processors have already been doing for a very long time. Processors that could complete the first two instructions simultaneously have been the norm for 25 years and processors that recognize the order in which these two instructions are performed is irrelevant have been the norm for nearly 15 years.
Such data dependencies are a very well studied and well understood field, and modern processors already do a great job finding work that can be performed simultaneously. There is no advantage to trying to spread that work over multiple processors because it’s already being done in a very efficient way, and adding a second processor into the mix slows things down because you have to move data vast distances.
To go beyond this you need to do one of three things.
A) You can have a programmer manually identify specific tasks that can performed simultaneously so they can be assigned to separate processors. This makes the program itself multiprocessor aware so “reverse hyperthreading” is irrelevant. Your program already knows about multiple processors and can use them effectively, you don’t need to make those multiple processors look like a single processor.
B) You can have a compiler examine your raw code for tasks that can be performed simultaneously. In this case, while your source code isn’t specifically multiprocessor aware your final binary code is, and once again there is no need for any type of reverse hyperthreading, the program you are running is already specifically aware of multiple processors and can take advantage of them.
As a variation on this you can make processors that specifically support extraction of parallelism in the compiler. This is, a very large part of the premise behind processors like Itanium, and Cell, though both approach it in very different ways.
C) You can run the original single processor binary under either emulation or binary recompilation. This is an intriguing possibility but emulation is slow, in fact very slow, so there are few gains to be had there. Binary recompilation is kind of an extension of option B) the, processor treats the binary executable as source code and compiles it to a new executable that can be multiprocessor aware.
Once again, we already have technologies that do something like this. Java, for example, compiles to a hypothetical machine language called byte code which is recompiled to true machine language at run time. Transmettas’ Cursoe processor recompiles X86 instructions to a native instruction format for execution. Intel and HP both use binary recompilation to provide X86 support on Itanium processors.
Of these, binary recompilation is the most like “reverse hyperthreading”, and in the lab it does have performance benefits. In real code, however, it generally takes a fairly large performance hit.
There really is nothing new under the sun. If there is a way to split a task up and perform the work in separate locations there has been someone working on it for years, and some existing technology using it. Overall the best gains always come from writing your code from the ground up to support multiple processors which is really what happens when developing for “cell”.
There are, as I mentioned, other ways to kinda/sorta get the benefits of multiple processors for code that wasn’t specifically written to support them, but in general the performance benefits from them hasn’t justified their use. The real problem is that many tasks performed by a microprocessor are simply to sequential in nature to benefit from multiple processors. The only real solution is to rethink how those tasks are performed from the very beginning, which means radically changing the way most computer programmers work.
I realized my main point may have gotten lost a bit in the length of my previous post. The basic problem is that to execute code across multiple execution resources, be that separate cores, separate processors, or separate functional blocks within a processors you first need to find parallelism. Parallelism can take many forms but basically but they all boil down to tasks that don’t have a dependence on some other task being done first and can therefore can be performed at the same time.
Today’s processors already exploit nearly all of the single thread parallelism there is to be had, so there is are simply no gains to be had by “making 2 processors look like 1” so a single threaded program can use them both. Even if there were there would be tremendous overhead in doing so, it would be far more efficient to simply add additional execution resources to a single core.
Great read Moridin, clarified a few issues for me. Thanks
Understood. :) I do understand moridin's point. Its touched on in the linked article as well.
I also feel that the added programmer burden is quite a waste.
This post ignores the fact that there are limits to how parallel a task can be made. Not all code can be made multi-threaded. It's a much more complex issue than simply "lazy programmers".Quote:
Originally Posted by Zvi