Is it possible for a hardware layer to

[thermalpaste]

Imagine if we were to have an added hardware layer to the newer breed of dual core processors.....the basic function would be to split the instructions to be processed to both the cores. This way we don't need to re-write software for multi-threading and the older programs would exploit the advantage of having a DC CPU......can this be possible?

 

[Matthias99]

Sort of... but you wouldn't be able to do it very efficiently in a lot of cases. Since you have no way of knowing what instructions are going to come next, you'll hit pipeline stalls and branch mispredictions between CPUs all the time, hosing your performance. A lot of instructions would also need to communicate back and forth between the CPUs (which is slow). I can't see it being worth the effort.

You *might* have better luck with something at a software level -- basically run your programs through an interpreter (similar to what virtual machine software like VMWare does) that tries to split instructions among multiple CPUs. You're still going to have lots of synchronization problems, though, and I don't see any easy way around them. But maybe someone will come along and prove me wrong!

 

[Shalmanese]

I would imagine it would be far more efficient to write smarter compilers to do the job for you.

 

[NewBlackDak]

Originally posted by: Shalmanese
I would imagine it would be far more efficient to write smarter compilers to do the job for you.

Exactlt what I was going to say. Better educated programmers, and smarter compilers.

 

[borealiss]

There's only so much instruction level parallelism you can add to an exisiting architecture or instruction set. What you're describing has been done to a certain extent, in that x86 is essentially a wrapper and micro ops get executed by a microcode engine in modern x86 cpus. out of order execution helps this to some degree, but the level of parallelism you're describing at this point in time can only be done by the programmer writing the code because a compiler is never going to be smart enough to compile the benefit of multithreaded execution without running some type of intense profiling software on the target build. otherwise the compiler has no idea what resources will be needed at certain points in the execution. only the programmer is going to have this knowledge before runtime, and profiling software isn't always successful at what it aims to do. some compilers can optimize for this, but usually it is for a very specific task, i.e. databases or graphics processing on the cpu side.

 

[VirtualLarry]

I think that it is possible. I don't know much about the 'Cell' architecture, but it seems to be of a similar design - parallel groups of execution resource units operating in parallel. As for compilier support and reliance on a "smart" compilier - don't hold your breath. Intel has been going that approach with IA-64, and it hasn't really gotten them that far. There's only so much information that can be known statically at compile time. HP proved that with their 'Dynamo' project research, which can dynamically optimize running code through dynamic binary translation, based on what it "learns" about the code during runtime. Similarly, hardware decoders and caches/predictors, can obtain more information about the behavior of the code than can any particular compilier. Plus, you end up with the "brittleness" problem, which I feel is going to be an issue with IA-64, much moreso than IA-32. If the code in question is effectively "statically scheduled", and very tightly coupled to one specific CPU implementation of the IA-64 architecture, then those binaries will likely either not run at all, or run very in-efficiently on other upcoming members of the family. The answer of course is to re-compile the code, but lack of straight binary-compatibility between different members of the same CPU architecture family tends to dissuade customers from upgrading their software. That is one of the major reasons why IA-64 will never see widespread commercial adoption, IMHO. The only places that will use it are places doing scientific research, etc., who have the don't purchase commercial applications, but rather write their own, and have the source code to re-compile them if necessary.

 

[cirthix]

multithreading is useless, go look at hyperthreading performance reviews

 

[thermalpaste]

Originally posted by: cirthix
multithreading is useless, go look at hyperthreading performance reviews

I beg to differ......firstly MT doesn't work for many apps, but they can be redesigned for MT support, just like HT

 

[Sunner]

Originally posted by: cirthix
multithreading is useless, go look at hyperthreading performance reviews

You are aware that Intel isn't the only one doing SMT, right?
Look at IBM's POWER5, that thing does 2way SMT, and it does it very well.
OTOH POWER5's aren't exactly cheap, while the P4 is a consumer grade CPU, and the Xeon is a slightly more(or very much more if you go MP) expensive derivative thereof.