Hyperthreading is Intel's copyrighted term for Symmetric Multi Threading (there's something you can Google for and get good information). Symmetric multithreading is different than symmetric multiprocessing (multiple processors) for several reasons:
1. It's one processor that can process multiple threads at once, not actually two processors.
2. Since it's one processor, the two (or more) threads running share certain registers, L1 and L2 cache availability, etc.
3. Because they must share, there can be contention between the two parallel threads and so they must be scheduled (by the OS and by the processor prefetch logic) in an efficient manner.
Intel's hyperthreading has nothing to do with LONG pipelines, it instead has everything to do with multiple execution units in the processor itself. The P4 chips have seperate FPU, Integer, SSE, and SSE2 execution engines inside the core. Before Intel started using HT, only one of those execution engines could run at a time.
Thus, if an FPU instruction came through the pipes, the integer, SSE and SSE2 units were all inactive and just sat there waiting. With Intel's Hyperthreading, they now can allow two of those execution engines to run simultaneously. That doesn't DOUBLE your output, but it does increase it by a noticeable amount
if you have unlike instructions that can be run parallel.
So for example, if you have multiple FPU instructions all streamed together, HT isn't going to help at all. If you have a mix of FPU, Integer and SSE that all needs to compute
and the instructions are not dependant on eachother, they can be processed in parallel and can rip through them faster.
The absolute best case scenario is something like a 65% increase in processing ability because of cache coherency and branch prediction issues (so it never can actually double). Many multithreaded apps can see a 15-30% increase, basically all others see an average of zero
There are several older applications that will slow down when hyperthreading is enabled, mostly old multithreaded apps that were never actually meant to run in an SMT environment. These apps break off worker threads that are all interdependant of eachother, and often that scenario can make a Hyperthreaded processor stall out even worse than a normal processor would.
These apps are few and far between, and an SMT-aware operating system (Windows XP) can be forced to limit those threads to a single virtual processor in order to keep them from misbehaving and slowing down.
Both AMD and IBM are reportedly looking at SMT options as well, because most modern microprocessors have multiple execution engines that are (quite often) idling. Again, it has nothing to do with total pipeline length, it has only to do with the total number of seperate execution engines on the CPU core.
