rwessel (robertwessel.delete@this.yahoo.com) on May 31, 2013 9:02 pm wrote:
> It depends on the expected workloads, and the rest of the CPU's design.
>
> All of Intel's x86 SMT implementations have been two thread, and I think all of the IPF ones have
> been two thread as well, although I could be misremembering Poulson's specs. OTOH, both Sun/Oracle
> (UltrasSPARC T1 with four, T2 with eight) and IBM (POWER7 - four) have implement larger numbers.
>
> Supporting higher numbers is not free, each active context must (approximately) duplicate the entire
> architected state of the processor. And as already discussed, more active threads contend for (the now
> shared resources). Not least are the OOO resources (like the rename registers). But if you have a simple
> in-order processor, that's going to be running a lot of branchy code and thus spending a ton of time
> waiting for the memory subsystem, more threads will increase the number of parallel memory access possible.
> So that route (UltraSPARC T1/T2, Intel Silverthorne Atom) is an easy way to increase *throughput*, but
> leave you with individually slow processors (so such a CPU will run a web server well, but probably not
> a compiler). IBM's POWER7 is certainly neither simple or in-order, but does spend a lot of time executing
> very branchy commercial code, and is usually equipped with a very hefty memory subsystem (include relatively
> massive caches), so SMT makes sense there as well (and POWER7 cores can be configured to run one, two
> or four-way multithreading, depending on the expected workload).
>
> There is no doubt Intel could produce an x86 core with four-way SMT, but I expect that there would
> be relative few workloads where it would have a positive impact. To make it generally useful,
> they'd probably need to add a POWER7 scale cache and memory subsystem to the device, and that's
> not going to be within Intel's usual power and cost goals for chips. IBM, OTOH, can put four 300W+
> CPU dies with 1K+ I/Os on an MCM, largely because they're building the whole system.
>

Oh wow, quite a bit of diversity going on with multithreading amongst other processing types; including non-x86 instruction CPUs. Very interesting indeed. I suppose there seems to not only be a bit of both a balancing act involved, but also trying to see what would best suit the application.

Thank you very much, you've been very good at explaining the concepts to me, I appreciate it!

Also, as a sidenote; incase David reads this: Sorry for the double post previously. For some reason, Chrome decided to make a double post even though I didnt double click or anything that usually causes that in other forums. I apologize for that.