Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMD Discloses Initial Zen 2 Details

fuse.wikichip.org

Post reply on HN
Print view View original

181–190 of 207 posts

Re: AMD Discloses Initial Zen 2 Details

#181

Post by ptero »

majewsky wrote: post #82
ChuckMcM wrote: post #74

"Oh the places you'll go" :-) Assuming this chip doesn't trip all over itself moving things around, it will be an astonishing amount of computer power in a reasonably sized package. This is for me, the only reason to work at an internet giant; because they will build a tricked out motherboard with two sockets and up to 8TB of RAM and with say a petabyte of attached non-volatile storage available, field solvers, CFD a…

> exact numerical solutions Isn't that an oxymoron? Numerical solutions always involve some sort of rounding errors because of limited floating-point precision, so they cannot be exact.

One can always build a counter-example, for example when candidate solution space is discreet but continuous-space solvers are fast and convenient. Then as soon as you get within half of discretization step you get an exact solution.

Re: AMD Discloses Initial Zen 2 Details

#182

Post by cantankerous »

Kipters wrote: post #164
apexalpha wrote: post #155

Earlier quoted context omitted.

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

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! ;-)

Re: AMD Discloses Initial Zen 2 Details

#183

Post by Dylan16807 »

drewg123 wrote: post #174
Dylan16807 wrote: post #143

Earlier quoted context omitted.

The interconnect latencies give you something like an extra 50 nanoseconds[1]. That matters when accessing memory. Not so much for PCIe, where your base latency is most of a microsecond[2][3]. There seems to be plenty of bandwidth to handle it, too. [1] https://www.servethehome.com/amd-epyc-infinity-fabric-latenc... [2] https://forum.stanford.edu/events/posterslides/LowLatencyNet... [3] https://gianniantichi.github.i…

My comment was addressing the parent comment about bandwidth, not latency. Because you only have 1/2 the memory and I/O bandwidth on threadripper, if maxing out I/O is your concern, you would likely be better off with a low-end epyc that still had all the memory controllers and pcie lanes wired up.

> My comment was addressing the parent comment about bandwidth, not latency.

Oh, it is? It really seemed to be about direct vs. non-direct, and nothing else. And that pretty much only affects latency, because it only loads the infinity fabric by about 20-25% to route 16 PCIe lanes to each die.

Re: AMD Discloses Initial Zen 2 Details

#184

Post by phkahler »

mbell wrote: post #54

Anyone know why we aren't seeing Intel/AMD go the 'ultra-wide' route that we've seen in ARM processors? (Apple's in particular) e.g. we've seen Apple's A12 processor expand ALU's from 4->6 and what seems like a strong focus on cache latency and these changes seem to be rather beneficial in real code. Why aren't we seeing the same from Intel / AMD? As someone whom isn't particularly well informed on the topic my guess…

Instruction set and the number of registers visible to the programmer influence the practical limits to issue width. AMD64 (x86_64) only has 16 general purpose registers, so there are limits to how many instructions could possibly execute at one time. If I recall correctly the ARM ISA has 32 registers, so there is potential for a lot more data sitting there ready to do something on any given cycle. There are limits imposed by software as well - lots of real world program code simply doesn't have opportunities to do many things in parallel.

Having said all that, any extra execution units can be used more effectively with multi-threading. It sounds neat to have twice as many threads as cores, but on my workloads that's only about a 20 percent performance increase. Going wider would probably help the second thread quite a bit, but what would be sacrificed is deep in the details of a given design. I suspect they increase width so long as it doesn't impact single thread performance.

Re: AMD Discloses Initial Zen 2 Details

#185

Post by yboris »

beatgammit wrote: post #12

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 sam…

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.

Re: AMD Discloses Initial Zen 2 Details

#186

Post by Dylan16807 »

rasz wrote: post #180
ploek wrote: post #162

Earlier quoted context omitted.

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

its all analog at that level

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

Re: AMD Discloses Initial Zen 2 Details

#187

Post by mda »

tutanchamun wrote: post #157
zymhan wrote: post #96

Earlier quoted context omitted.

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…

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.

Re: AMD Discloses Initial Zen 2 Details

#188

Post by Dylan16807 »

m_mueller wrote: post #177
dragontamer wrote: post #176

Earlier quoted context omitted.

Dennard Scaling would have been 2x clock-rate from an improved node. 1.25x scaling from an improved node is way, way, way worse than Dennard Scaling of the past. Intel Pentium III Coppermine (1999) went from 733 MHz on the 180nm node to Pentium III Tualatin (2001) 1400 MHz on the 130nm node. THAT was Dennard scaling. Today, we "only" get double-digit gains from an improved process node. Dennard Scaling was triple-dig…

If you look at GP's question, (s)he was asking about 5Ghz in Zen2. Since Epyc 1 is ~3Ghz, a 1.6x increase in clock speed for a ~1.4x smaller process size (AFAIK "7nm" is overselling it compared to 14nm) to me smells like Dennard scaling and thus cannot be expected anymore (if you disregard tricks like turbo boost where a bunch of hardware gets disabled such that the rest can be boosted).

They're asking about a 1.25x increase on a 1.4x smaller process.

Even if you completely ignore boost clocks, the 1900X has a base clock of 3.8GHz, so interpret it as "4.75GHz base clock on a non-Epyc part" if you must.

But I don't think you should ignore boost clocks. They're not a trick to make the silicon seem more capable. The silicon really is that capable and boost clocks are a trick to cap power draw. It's entirely fair to look at the 4.2 boost clock on the 2990WX and conclude that the silicon is capable of 4GHz under non-exotic conditions.

Re: AMD Discloses Initial Zen 2 Details

#189

Post by slededit »

atq2119 wrote: post #156
slededit wrote: post #139

Earlier quoted context omitted.

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.

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

Re: AMD Discloses Initial Zen 2 Details

#190

Post by shaklee3 »

Tuna-Fish wrote: post #161
dopenmoredope wrote: post #90

Earlier quoted context omitted.

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…

> 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.
Post reply on HN