Patrick Chase (patrickjchase.delete@this.gmail.com) on February 2, 2013 9:27 am wrote:
> mpx (mpx.delete@this.nomail.pl) on February 2, 2013 4:31 am wrote:
>> Doesn't BIG.Little architecture also represent a huge RISC advantage? Not only is the
>> little part well-within the RISC-advantage group but also is it possible to do x86 that
>> has a small and a large processor similar to each other bug-wise, so that programs are
>> debuggable even though switching between cores of different architectures?
>
> For *microservers*, which are the topic of this thread? I think not. Can you give
> an example of a realistic server workload for which BIG.little makes sense?

There has been an academic suggestion of using a high performance core for critical sections while simpler cores handle most of the processing. (Of course, this is not the same as the energy-efficiency orientation of big.LITTLE.)

Likewise, if it is known that a particular workload requires more single-thread performance to meet acceptable response times, then such could be allocated to a high performance core while ordinary workloads use the more efficient low performance cores. If migration overhead is sufficiently small, it could even be reasonable to migrate when a response time looks likely to be unacceptable.

While the traditional orientation of microservers might not have a sufficiently diverse workload behavior to justify including high-performance cores, the form seems to be expanding to include examples that use Xeon; so there might be a place for including a moderately brawny core with somewhat wimpy cores. This might also give a little peace of mind in that the system can be a little more general purpose.

(The improved single-thread performance in the SPARC T series might be viewed as a recognition that wimpy-only has limited attractiveness but wimpy with a decent potential for brawn is more broadly useful.)