3 ms·
I didn't claim to disprove Amdahl's law - I argued with an assumption based on "Amdahl's law" that I put in quotes, exactly because there's a leap from real Amd
by _yosefk 14y ago
I didn't claim to disprove Amdahl's law - I argued with an assumption based on "Amdahl's law" that I put in quotes, exactly because there's a leap from real Amdahl's law to something that doesn't follow from it in that line of reasoning.
What you "salvaged" is not bad though :) And - ARM might be getting there if a licensee takes big.LITTLE to that direction as I pointed out.
- cpleppert 14y agoI'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.