Hacker News Reader

Comment by adfghopmnoi | Hacker News Reader

>Instead of discrete, fully independent cores, AMD grouped processing units into "Modules" where each module contained two integer execution units, but they had to share critical resources like one FPU, the instruction fetch/decode pipeline, and the L2 cache so when both "cores" inside a module were heavily taxed especially with math or physics-heavy calculations (like in videogames), they choked fighting over shared hardware.

They did just fine in parallel workloads, so I think this is not accurate. The design scaled just fine. The problem was that each core was weak.

View on HN

>They did just fine in parallel workloads, so I think this is not accurate

Depends how you define "doing just fine in parallel workloads". The contemporary competition from Intel that was 4-core + SMT was beating AMD's 8-core FX CPUs in most real-world tasks and benchmarks at the time. The 8-core AMD broke even and rarely won only in >4-thread strictly integer benchmarks and some >4-thread media encoding tasks/benchmarks. So if you wanted a prosumer media encoding workstation a budget then yeah, the AMD was better, but for most real world task, it really wasn't.

>The design scaled just fine. The problem was that each core was weak.

Can you elaborate and be more exact? What you wrote is technically vague and doesn't mean anything in technical dissection/terms.

When we say a design "scales", that means that increasing the size of the workload does not incur a lot of overhead. If contention between shared resources meant that the design was not able to achieve an ~8x speedup when run with eight parallel threads, that would mean the design was not scalable. But we did in fact see a roughly 8x speedup with eight threads, so the design scaled just fine. The problem with the design was that each core was individually crummy, so even eight cores running in parallel had lackluster performance.

The myth that each two-core module functioned more like one core with hyperthreading would suggest that these CPUs would have much higher per-core performance when lightly loaded than when fully loaded. That is not what happened. Each core was crummy even when lightly loaded, but under full load you would have eight crummy cores, which would beat four Intel cores on a lot of workloads.

The only time contention was a serious problem was with workloads that were dominated by floating point, which were relatively rare.

> If contention between shared resources meant that the design was not able to achieve an ~8x speedup when run with eight parallel threads, that would mean the design was not scalable.

By that definition it definitely was not scalable.

>But we did in fact see a roughly 8x speedup with eight threads,

Care to share a source? Because AFAIR there definitely was no 8x linear speedup with 8 threads even in benchmarks, let alone in real world use cases. The only benchmarks where those 8 threads would scale best and beat Intel were archival compression/decompression and media encoding. At everything else Intel wiped the floor with it.

>The only time contention was a serious problem was with workloads that were dominated by floating point, which were relatively rare.

Many real-world compute workloads, especially gaming related, are floating point.

Reply on news.ycombinator.com