Hacker News Reader

Comment by beatgammit | Hacker News Reader

This is a pretty bold change and really makes Intel chips less appealing. With the recent kernel changes for Intel's Spectre issues and this chip coming up, I think it's a distinct possibility that AMD will take back a ton of marketshare in the server space.

If these chips really do have a ~25% performance gain over Ryzen (not counting IPC gains), I might just upgrade, and I think a lot of other people are in the same boat.

This could be a fantastic win for AMD. I was worried that Zen 2 was going to be a moderate improvement, but this seems to be pretty significant. It's been a while since AMD has been first to market with a big winner...

View on HN

What's disappointing is that none of the major cloud vendors has made any real commitments to AMD, at least none that I've seen.

If speculative execution is a problem and you need to give each VM its own exclusive cores, great when you can source parts with 64+ cores on them!

AWS, Microsoft, Oracle, Packet... all have AMD shapes, in bare metal and VM to varying degrees. The list goes on and on.

Oracle: https://www.amd.com/en/press-releases/2018-10-23-amd-and-ora...

Azure: https://azure.microsoft.com/en-us/blog/announcing-the-lv2-se...

AWS: https://aws.amazon.com/about-aws/whats-new/2018/11/introduci...

Packet: https://www.packet.com/hardware/amd/

LV2 is invite only on Azure, eg. not generally available.

Off-topic but eg = for example, ie = in other words.

Both those are from Latin; I knew what e.g. is short for, but now I got around to looking up i.e. too:

ie => id est => that is

eg => exempli gratia => for example

Thanks, as a non native speaker this is very useful for me

FWIW nobody's been a native Latin speaker for a thousand-plus years. You're in the same boat as everybody else! ;-)

True, but the problem is that my language (Italian) only uses "es." for "e.g." and doesn't have an equivalent acronym for "i.e." (we usually use other complete words that roughly translate to "therefore"), so it's easy for me to mix them up since I can't easily map them.

Thanks, I always mix them up.

AWS began releasing a new AMD generation a few weeks ago.. https://aws.amazon.com/blogs/aws/new-lower-cost-amd-powered-...

Fantastic news. Thanks for the link!

How could they? AMD has been off the map for generations.

Providers will begin uptake of AMD again, it just takes time for contracts to roll over and the new hardware to reach production.

What's even more disappointing is that Zen 2 doesn't include support for new techs like the upcoming DDR5 & PCIe 5.0 which seems are going to be supported in Zen 4

https://www.anandtech.com/show/13578/naples-rome-milan-zen-4...

IC: AMD has already committed that Milan, the next generation after Rome, will have the same socket as Rome. Can you make the same commitment with Zen 4 that was shown on the roadmap slides?

MP: We’re certainly committed to that socket continuity through Milan, and we haven’t commented beyond that. Obviously at some point the industry transitions to PCIe 5.0 and DDR5 which will necessitate a socket change.

IC: So one might assume that an intercept might occur with Zen 4?

MP: No comment (!)

Hoping for DDR 5 or PCI-E 5 support in Zen 2 is equivalent to hoping that Zen 2 is at least a 2020 architecture rather than a 2019 one. This is because:

1) PCI-E 5 isn't even standardized yet

2) Mass production of DDR5 memory chips might begin ramping up in 2019, but it's unlikely that DDR 5 memory sticks will be readily available on the market until 2020.

3) It takes a really long time to engineer a cpu architecture and bring it to market (generally a year or more for even just a revision of an existing architecture).

4) Adding support for a new memory or PCI-E version requires a new socket and a new chipset, which creates even more work that by definition can't be "done" until things are fully standardized.

AMD are going to support DDR5 and PCI-E 5 eventually... But they want to release a new architecture revision on their current socket and chipset now before it's reasonably possible to do that.

Edit: All this is to say nothing of AMD's commitment to potential partners to keep the underlying socket and chipset the same for a reasonable period of time, which is critical to planning supply chains and upgrade paths for major partnerships.

> Adding support for a new memory or PCI-E version requires a new socket and a new chipset

Memory, sure, you don't want compatibility issues. Why PCIe, when the important lanes are all driven directly off the CPU?

Ah, fair. I guess I should say "can require".

PCIE 4.0 was just standardized last year, it's not surprising that Zen 2 won't support 5.0, which is expected to be introduced mid next year.

Zen 2 will be the first CPUs supporting 4.0.

Power9 was the first to support it over a year ago. But you're right, 5 is not finalized, so it's not possible for amd to support it.

Release date for PCIe 5.0 is Q1 2019

Furthermore...

On June 5th, 2018, the PCI SIG released version 0.7 of the PCIe 5.0 specification to its members.

PLDA announced the availability of their XpressRICH5 PCIe 5.0 Controller IP based on draft 0.7 of the PCIe 5.0 specification on the same day

https://www.plda.com/products/xpressrich5

and...

Historically, the earliest adopters of a new PCIe specification generally begin designing with the Draft 0.5 as they can confidently build up their application logic around the new bandwidth definition and often even start developing for any new protocol features. At the Draft 0.5 stage, however, there is still a strong likelihood of changes in the actual PCIe protocol layer implementation, so designers responsible for developing these blocks internally may be more hesitant to begin work than those using interface IP from external sources.

From here: https://en.wikipedia.org/wiki/PCI_Express

AMD had plenty of time to include PCIe 5.0 even in the Draft 0.7 stage which is pretty much the same as final draft/release, but decided not to.

Yes. AMD could have simply switched the chip over to non-finalized standards between June 5th and now. Clearly

No possible way that could backfire or be impossible

> AMD had plenty of time to include PCIe 5.0 even in the Draft 0.7 stage which is pretty much the same as final draft/release, but decided not to.

... Just how long do you think it takes to make that kind of design changes? This requires a major change in silicon. It would have had to been done more than a year ago.

Not to mention there are no PCIe switches with it. You'd have to wait for Avago/PLX/Broadcom/whatever it's called now to update them.

Do the new 8th gen Intel chips finally deal with Spectre/Meltdown issues in hardware or do they still depend on OS level fixes?

Yes. I expect both vendors to reach parity with respect to mitigations of known speculative execution vulnerabilities. Whether their architectures have been fundamentally redesigned to make these issues more difficult to exploit is anyone's guess.

Variant 1: Both AMD and Intel will continue to rely on OS patches.

Variant 2: Both AMD and Intel will fix in silicon. Intel's fix comes in Cascade Lake.

Variant 3 (aka Meltdown): AMD was not affected, Intel will fix it in silicon in Coffee Lake Refresh and Cascade Lake.

Variant 4: Both AMD and Intel will rely on OS and Microcode patches

L1TF: AMD was not affected, Intel will fix in silicon in Coffee Lake Refresh and Cascade Lake.

I'll note that for the AMD products, this is my best guess from Lisa Su's comments. I do wish they put out a table like Intel did.

[1]: https://www.anandtech.com/show/13450/intels-new-core-and-xeo...

[2]: https://wccftech.com/amd-zen-2-cpus-fix-spectre-exploit/

EDIT: Replaced the Intel source with a better link

Don't forget the recent seven additions to meltdown/spectre. It'll be interesting to see if the latest round of hardware protections help there.

8th gen (Coffee Lake) have the same uarch as Skylake and have no hardware fixes for Meltdown or Spectre.

Yes, but 9th gen has fixes: https://www.anandtech.com/show/13400/intel-9th-gen-core-i9-9...

And no pcie4 either, unfortunately.

Sure they take care of it real well... in the OS.. can’t wait till this comes to windows by default.

https://www.phoronix.com/scan.php?page=article&item=linux-42...

Most of what I do is floating point operations, so I'll see >100% performance gains with the avx boost. I will upgrade.

Any chance your workload would see a benefit from porting the code to a GPU?

I work on tech to automate that. The generic answer is yes as long as you overcome the PCIe bottleneck (or can hide the latency).

I assume that should be "and can hide latency"?

While GPU offloading is extremely powerful in terms of compute, you have to deal with both bandwidth limitations (de facto ~12 GB/s for x16 PCIe 3.0) and the latency of launching compute kernels and waiting for them to complete.

That depends on the problem space. For some problems latency does not need to be an issue, if the problem can be pipe-lined then you can keep all your cores running at a high percentage of their theoretical maximum load even if latency is high.

For real time applications this is usually not an option, there latency > some threshold will kill your proposed solution.

In those cases where the latency is not a problem, it tends to be precisely because you can hide it e.g. via pipelining :)

You overcome the bottleneck by doing as much as possible on the GPU. Even things you don’t think are fully suited to it.

I humbly request in every conversation whenever someone uses "distinct possibility" that they quantify it with a number.

This phrase may be worse-than-useless: it creates the impression between people that they agree, but could mean a discrepancy between 0.0001% to 10%.

I know this isn't central to what you're saying, I just want a better conversational norm around probabilities during conversations in the world.

Intel has a chip shortage, so AMD might be able to sell their CPUs and motherboards while Intel cannot meet demand.

I always wanted to make an Amiga with an AMD chip and get AmigaOS into X86-X64 and away from PowerPC so it can sell cheaper and faster systems. Compete with Apple at least by merging AmigaOS with GNU/Linux work with Valve on SteamOS to run AmigaOS apps and get some classic Amiga games into SteamOS and GNU/Linux.

Amiga hardware is what made it special, an generic OS on a generic hardware is just yet another OS.

I was actually underwhelmed by the post, what exactly is the "pretty bold" change?

Seperating the analog logic (IO die) from the digital logic (CPU cores). Analog shrinks really bad with smaller nodes wheras digital logic shrinks really good.

New process nodes get more and more expensive - especially if the node is new (bad yields etc.) So you want to get the most out of it as possible, which AMD does with this strategy.

For example Zen 1 8 core chips are 213 mm2 on 14nm. On 7nm these chipse would be > 106 mm2 (because the analog elements don't scale). Zen 2 chiplets should be at most 75 mm2 (while also increasing cache, widen AVX etc.) which is mobile SoC territory which means they are cheaper to produce (better yields etc.). Since Intel uses monolithic dies AMD already had an cost advatage, with Zen 2 it's not even funny.

Especially if the guesses of many people are true and AMD designed the IO chip to be cut down, which means they can reuse it for their desktop CPUs (Ryzen on AM4). Anonther nice advantage of this would be that they can bin the chip even better for EPYC, Threadripper and Ryzen.

AdoredTV does a good job of aggregating all the infos/ideas that are floating around and presenting them:

https://www.youtube.com/watch?v=I6AG-woscDU

There's also the clever business reason where they're obligated to keep buying silicon from Global Foundaries but GF had bowed out of pursuing 7nm. So here they can use GF's 14nm for enough silicon to cover their obligations.

I/O module is not analog, but most of your points still stand, It is mostly for increasing yields and reducing costs. With this separation they are reducing chiplet size quite a bit, so that they will have superlinear cost reduction on 7nm process.

IO is 100% analog. Slew rates, crosstalk, reflections, routing, etc. It is literary called Black Magic in EE community.

Must read "High Speed Digital Design: A Handbook of Black Magic": https://books.google.pl/books/about/High_speed_Digital_Desig...

I am not sure our definition of analog are same. Are you claiming that gigantic chip shown in the zen 2 picture is an analog chip?

Whole CPU is analog, just hidden away under vendor(cadence/mentor/synopsys/etc) supplied RTL IP building blocks (GDS libraries) abstraction whose specification is highly customized to particular fab house. This lets you design logic part of the circuit without getting into analog hell.

The difference between logic part of CPU and IO is in the amount of work spend on RTL vs direct custom layout of geometric structures on the chip.

There is nothing analog about the IO die. It interfaces the memory, and the system's busses like PCIe. They are all digital.

Sorry, I've meant analog circuitry, which I've read again and again about on CPUs - see below as one example. And it was also mentioned in some articles about the IO die on Zen 2.

> Intel’s analog designers are responsible for creating circuits such as PLLs (for clocking) and PCIe (for I/O) that are critical for modern SoCs on a process that isn’t optimized for analog

https://www.realworldtech.com/intel-22ffl-process/

its all analog at that level

Yeah, anything measured in GHz going off-chip is well into analog signal processing territory.

the incorporation of the IO chiplet is a sea change for processor tech. It means many physically separate core-chipsets get the same path to RAM and overcomes the many issues with NUMA, while avoiding massive and expensive cpu dies.

The UMA benefit is a double-edged sword. Best-case RAM latency probably gets worse, all else being equal. But maybe they've made Infinity fabric faster enough in Zen2 to eliminate any additional latency compared against the local memory domain in Zen1.

Reply on news.ycombinator.com