I think the IPC gap will become an interesting battle in the near future, especially as gains that came from aggressive speculation have proven to introduce security holes (take your pick of Meltdown, Spectre variant n,...).

Are there any good post-Meltdown benchmarks conparing Intel and AMD?

Anandtech did a benchmark but that had a flaw in the way they measured the time. Many other benchmarks are with unpatched OS versions to keep comparability. It's not easy to judge when they don't explicitly investigate that effect.

Anandtech updated the benchmarks eventually: the massive performance drop that they attributed to meltdown/spectre patches vanished.

https://www.anandtech.com/show/12625/amd-second-generation-r...

Phoronix is my go to for those in depth benchmarks with security patches

True, they compared a lot - but exclusively under Linux.

Which is the main OS that will us CPUs when you count servers. Granted that isn't the consumer CPUs we care about but the work on servers actually trickles down. It isn't some minor group and AMD and Intel are very much concerned about how their CPUs run under Linux.

To be fair it's only recently that released the windows version of the openbanchmarking software, so this linux only side of things will change for sure. But yes

They have added various BSDs to their benchmarking.

Just use Geekbench. It's great for core performance comparisons, based on actual micro-workloads.

BTW We're looking at ~4200 for Ryzen, ~4800 Ryzen 2, and ~5800 for i7 Coffee Lake.

The IPC gap is directly related to their smaller cores. If you want to get more work done in a cycle you need to spend transistors to do it. You're asking them to have and eat cake, basically. That's not likely.

Case in point, Apple's ARM chips are huge (and hot) compared to the stock ARM chips and that is because they are throwing transistors at the problem.

Would you have a particular reference for this? I have read that the Apple ARM chips are more power efficient than comparable ARM chips powering Android devices.

SD835 was 72mm^2[1], A10 was 125[2]. A11 and SD845 are actually very similar in die area[3]. However Qualcomm integrates their modem on the SoC and Apple does not, and Apple's CPU cores are still significantly larger as can be seen from die shots.

Phone SoC makers don't really publish TDPs and there is a lack of good data about it, but Apple clearly has high peak power draw (and very good idle efficiency). Battery life and thermal throttling observed under a sustained heavy workload is probably the best proxy for measuring SoC power. For example, see GFXBench battery life/throttling results in Anandtech's review[4] of the iPhone 7/plus. Much higher power consumption (and performance, but this is resolution-dependent because it's a graphics benchmark) than the competition.

[1] http://www.techinsights.com/about-techinsights/overview/blog...

[2]https://www.extremetech.com/mobile/236091-new-apple-a10-tear...

[3] https://i.imgur.com/KBw8K8N.jpg

[4] https://www.anandtech.com/show/10685/the-iphone-7-and-iphone...

This is a great answer, thank you.

They idle really well. In particular the software layer around suspend is really first rate when compared with the Linux BSPs from vendors, which tend to be somewhere between glitchy and awful (c.f. all those times when your off-brand Android phone turned red hot in your pocket, or the fact that a RPi is running a "mobile" SoC that never manages to draw less than 3W).

The power under load is quiet high, apocryphally. No, I don't have numbers.

The Broadcom SoC used in the Raspberry Pi hasn't aged terribly well, there is a pretty good thread comparing the various boards out there on the Armbian Forum[1], in it they discuss how much power boards use with different parts enabled. Some Allwinner boards (like the PC2) can use just 1w at idle without disabling anything. Further savings is possible if you disable gigabit ethernet, GPU, etc. More info is in the 2nd link!

1 - https://forum.armbian.com/topic/1748-sbc-consumptionperforma... 2 - https://docs.armbian.com/Hardware_Allwinner-H3/

Oh sure. It was more a point about software polish. All these SoC's have hardware support for clock gating and separable power domains and deep idle states, etc...

But in general, making all junk work is a huge rats' nest of complexity. And in practice, except for a tiny handful of devices from top-tier manufacturers, it just doesn't. Maybe it works "most" of the time. Maybe there are tuning tricks you can use that get the power down but break two or three devices in crazy ways.

But Apple has the smarts and resources to ship a power-hungry part and guarantee that it sits at a clean idle reliably. And Qualcomm isn't far behind as long as they have an integrator like Google or Samsung breathing down their neck. But all the other junk? Yeah, junk.

All parties that run Linux on these devices should be forced to mainline their kernel patches. The patchwork of shitty BSPs that both Google and Samsung have created were shipped, resulting in hundreds of millions of insecure, poorly supported devices that are actively used.

Look at what Armbian has done with these bespoke chips in spite of limited resources, had Google and Samsung put in a minor amount of effort, akin to what Sony has done, the Android landscape would have many more users running fully patched, slightly less buggy software today.

light up the cpu, get the work done fast, then shut down. that is typically the energy efficient thing to do.

Apple uses a six wide decoder where as there is only a 4 wide decoder on the ARM stock chips.

But isn't it easier for AMD to close the gap due to their multiple dies on a package design instead of a large monolithic design like Intel? If they make the cores larger the cost for the entire CPU doesn't increase as much as Intels.

Even though Zen+ (cache optimization) is probably not as much of a improvement as Zen2 ("improves Zen in multiple dimensions") over Zen will be, the single threaded gap did shrink quite a bit:

https://i.imgur.com/dpfu5K3.png

But I guess some of these improvements come also from the faster memory that is supported. The benchmarks sadly were not made with the same memory.

To my knowledge the achievable IPC gains for a single thread are limited. Therefore it can be assumed that other players catch up in figures of IPC while the market leader kind of gets stuck with only a tiny advantage.

I keep wondering if there are some gains left by dropping the x86 legacy baggage e.g. using RISC-V or ARM64. It seems that there should be some loss due to x86 weirdness and past compromises

What i read was: The instruction decoder would become easier but the instruction decoder is only a small part. Most rare commands are implemented via microcode anyways, so silicon area is not hit too hard. x86 is somewhat efficient due to compact encoding compared to IA64 for example. There is surprisingly little to gain.

Maybe somebody who really knows the details can chime in :)

The peeps building Mill CPU are claiming they can do 10x performance over traditional (x86). IIRC in an early talk they explained this is mostly by bringing the IPC on a level with high IPC microcontroller arches. They do VLIW which can do a lot of things more efficiently if your compiler can handle it (Rust should be able to pull a lot of performance out of VLIW IIRC)

VLIW plus a "sufficiently smart compiler"? Isn't that IA-64 in a nutshell?

Basically, though Mill also is belt-based (think stack with size-limit) not registers and compilers nowadays are a bit better at VLIW than when IA-64 was introduced. They also have a shitload of security addons that would mitigate most modern exploits and other nice-to-haves.

Nah, the Mill is sufficiently different than a standard VLIW. I'm still on the fence about it, but it's noticeably different from the Itanic.

Intel usually says it's less than 3%.

I don't want AMD to overtake intel on single-core performance. There are only a handful of things that a chip manufacturer can be best at. If AMD is ahead on per-core and total number of cores, then they can and will demand the premium prices intel does today. I like AMD because they are the underdog who must keep prices low to keep my business.

AMD taking the lead could also make them complacent when it comes to the more annoying things like DRM and privacy. I want them to remain the lean company. I don't want them investing in all the chaotic side projects that intel chips participate in. AMD needs to stick to number crunching and not allow their CPUs to become gateways for other tasks. They need to stay as they are now.

Lastly, atm AMD and intel sell very different chips. They do different things well. Those who pick one or the other do so for clear reasons. If they get too close on per-core performance we risk endless brand debates. Two tribes will emerge. Wagons will circle and fanboys appear. Competition betters the breed, but with only two players on the field we all know what will happen.

Your post is strange in how heavily it reflects your values instead of what's best for AMD or consumers. There's nothing so great about the current status quo that we should actively discourage change or real competition. In the unlikely event AMD were ever to supplant Intel (in market share) it would just force Intel into AMD's position now. OH NO! Your business isn't so valuable that it's incentive for AMD to active try and stay in second place.

We want competition, competition pushes progress. Maintaining the status quo, not so much. And if your biggest argument against AMD upsetting the status quo is you'll have to put a little more effort into shopping, well that's not really a problem for most of us...

> Your post is strange in how heavily it reflects your values instead of what's best for AMD or consumers.

> OH NO! Your business isn't so valuable that it's incentive for AMD to active try and stay in second place.

Not every post is about what's strategically best for a company. They very clearly stated it's what they personally wanted, and why.

What's the point of ripping into someone because they've actually expressed desire for a specific scenario? If you think they won't actually get what they want from the scenario or action they've described, just point out how you don't think it will end up that way.

Econ 101: Competition is good. Econ 102: Unhealthy competition is bad. Econ 201: The wrong kind of healthy competition is also bad.

Where only two competitors sell too similar a product, two dogs chasing the same rabbit, market forces will only amplify this lack of diversity. I want a range of core/clock options at a variety of price points. If AMD and Intel become too similar on close speeds I fear the inevitable race will reduce my options to a binary of two very similar product lines. This is s recognized realworld phenomena.

https://en.wikipedia.org/wiki/Hotelling%27s_law