EduardoS (no.delete@this.spam.com) on May 8, 2013 8:27 am wrote:
> Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on May 8, 2013 5:27 am wrote:
>> Oracle demonstrated with the SPARC T4 that SMT can be beneficial for narrow architectures
>> too though in their case SMT leverages a memory subsystem which has significantly
>> higher latency and allows for many more concurrent accesses.
>
> Oracle were targeting databases, a completly different workload from Atom or A15, no comparison is possible.

The earlier T series implementations (by Sun) were, IIRC, targeted at various server uses with task-level parallelism, particularly web serving. This would fit with the use of Atom in microservers.

SPARC T4 also has eight threads per core. With support for only two threads per core, a SMT- (or even SoEMT-)capable Atom would not be as special-purpose.

However, a SMT-capable Atom might be less suitable to the primary workloads targeted, even with SMT turned off (and even ignoring added fixed costs and risks associated with design and validation and even if the design was not biased to favor good SMT execution). The choice of copy-on-commit might also be less appropriate for a SMT design (such might make reusing registers when SMT is disabled more difficult; on the other hand, such might allow removing power from the unused block of registers) and might perhaps be a hint that SMT is not intended to be added in the near future.

(As I noted, fast context switching--which MT support could facilitate--could be useful in some embedded uses, so it is not exclusively server workloads that might benefit from MT. Similarly, mechanisms used to provide additional contexts might be useful in helping to support transactional memory, support for which might be useful in unifying the software environment.)