I'm not sure you are really clear about the distinction between serial and parallel workloads. It seems you are referring mostly to memory access patterns which

I'm not sure you are really clear about the distinction between serial and parallel workloads. It seems you are referring mostly to memory access patterns which cause cache misses and dominate actual processing. Of course larger cores can throw more resources at this program through resource sharing, hyperthreading,caching and parallelism not to mention they can issue memory requests faster as they don't spend as much time processing the data they get in. Most designs for smaller cores are designed around tasks that exhibit uniform data access patterns for precisely this reason. Either: 1) you throw more cache at the problem or increase memory speed 2) redesign your algorithm(almost always the best choice) If memory access latencies are causing problems you aren't going to stop the bleeding by band-aiding the problem for very minimal gain. For most workloads it isn't worth making this trade. The Sparc T1 was very effective at hiding memory latency but suffered from very slow performance at each task; and this was very heavily tuned workloads that exhibit high concurrency. It didn't matter if a task was blocked because another one was always ready. The big.LITTLE design simply wouldn't run this type of workloads.It isn't a case of concurrency is hard, I don't see the theoretical benefits here at all.