Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"The Computer made me do it."


devel / comp.arch / Ryzen 7000 Described, but not detailed

SubjectAuthor
* Ryzen 7000 Described, but not detailedQuadibloc
+* Re: Ryzen 7000 Described, but not detailedAnton Ertl
|`* Re: Ryzen 7000 Described, but not detailedQuadibloc
| +- Re: Ryzen 7000 Described, but not detailedMichael S
| `* Re: Ryzen 7000 Described, but not detailedAnton Ertl
|  `* Re: Ryzen 7000 Described, but not detailedMichael S
|   `- Re: Ryzen 7000 Described, but not detailedAnton Ertl
`* Re: Ryzen 7000 Described, but not detailedTorbjorn Lindgren
 +* Re: Ryzen 7000 Described, but not detailedQuadibloc
 |+- Re: Ryzen 7000 Described, but not detailedMitchAlsup
 |`- Re: Ryzen 7000 Described, but not detailedTorbjorn Lindgren
 `* Re: Ryzen 7000 Described, but not detailedAnton Ertl
  `* Re: Ryzen 7000 Described, but not detailedTorbjorn Lindgren
   +* Re: Ryzen 7000 Described, but not detailedAnton Ertl
   |`- Re: Ryzen 7000 Described, but not detailedTorbjorn Lindgren
   +* Re: Ryzen 7000 Described, but not detailedEricP
   |+- Re: Ryzen 7000 Described, but not detailedMitchAlsup
   |+- Re: Ryzen 7000 Described, but not detailedAnton Ertl
   |`* Re: Ryzen 7000 Described, but not detailedMichael S
   | `* Re: Ryzen 7000 Described, but not detailedEricP
   |  `* Re: Ryzen 7000 Described, but not detailedAnton Ertl
   |   `* Re: Ryzen 7000 Described, but not detailedEricP
   |    `* Re: Ryzen 7000 Described, but not detailedAnton Ertl
   |     +- Re: Ryzen 7000 Described, but not detailedMitchAlsup
   |     `* Re: Ryzen 7000 Described, but not detailedMichael S
   |      `* Re: Ryzen 7000 Described, but not detailedAnton Ertl
   |       `* Re: Ryzen 7000 Described, but not detailedMichael S
   |        `* Re: Ryzen 7000 Described, but not detailedAnton Ertl
   |         `* Re: Ryzen 7000 Described, but not detailedMichael S
   |          +* Re: Ryzen 7000 Described, but not detailedStephen Fuld
   |          |`* Re: Ryzen 7000 Described, but not detailedMitchAlsup
   |          | `* Re: Ryzen 7000 Described, but not detailedStephen Fuld
   |          |  +* Re: Ryzen 7000 Described, but not detailedMitchAlsup
   |          |  |`* Re: Ryzen 7000 Described, but not detailedStephen Fuld
   |          |  | `* Re: Ryzen 7000 Described, but not detailedMichael S
   |          |  |  `- Re: Ryzen 7000 Described, but not detailedStephen Fuld
   |          |  `* Re: Ryzen 7000 Described, but not detailedMichael S
   |          |   `- Re: Ryzen 7000 Described, but not detailedMitchAlsup
   |          `* Re: Ryzen 7000 Described, but not detailedAnton Ertl
   |           +- Re: Ryzen 7000 Described, but not detailedMitchAlsup
   |           `* Re: Ryzen 7000 Described, but not detailedMichael S
   |            +* Re: Ryzen 7000 Described, but not detailedMitchAlsup
   |            |`* Re: Ryzen 7000 Described, but not detailedMarcus
   |            | `- Re: Ryzen 7000 Described, but not detailedTerje Mathisen
   |            `* Re: Ryzen 7000 Described, but not detailedAnton Ertl
   |             +* Re: Ryzen 7000 Described, but not detailedMichael S
   |             |`* Re: Ryzen 7000 Described, but not detailedAnton Ertl
   |             | `* Re: Ryzen 7000 Described, but not detailedMichael S
   |             |  `* Re: Ryzen 7000 Described, but not detailedAnton Ertl
   |             |   `* Re: Ryzen 7000 Described, but not detailedBrett
   |             |    +- Re: Ryzen 7000 Described, but not detailedMitchAlsup
   |             |    `* Re: Ryzen 7000 Described, but not detailedAnton Ertl
   |             |     `* Re: Ryzen 7000 Described, but not detailedMichael S
   |             |      `- Re: Ryzen 7000 Described, but not detailedAnton Ertl
   |             `* Re: Ryzen 7000 Described, but not detailedBrett
   |              `* Re: Ryzen 7000 Described, but not detailedAnton Ertl
   |               `- Re: Ryzen 7000 Described, but not detailedMitchAlsup
   `* Re: Ryzen 7000 Described, but not detailedTorbjorn Lindgren
    `* Re: Ryzen 7000 Described, but not detailedQuadibloc
     `- Re: Ryzen 7000 Described, but not detailedTorbjorn Lindgren

Pages:123
Ryzen 7000 Described, but not detailed

<aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25451&group=comp.arch#25451

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ad4:5bc1:0:b0:42c:3700:a6df with SMTP id t1-20020ad45bc1000000b0042c3700a6dfmr16107052qvt.94.1653294200404;
Mon, 23 May 2022 01:23:20 -0700 (PDT)
X-Received: by 2002:a05:6870:8a26:b0:f1:8c07:299e with SMTP id
p38-20020a0568708a2600b000f18c07299emr11895251oaq.214.1653294200213; Mon, 23
May 2022 01:23:20 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!2.eu.feeder.erje.net!feeder.erje.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 23 May 2022 01:23:20 -0700 (PDT)
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:54df:770b:e9bb:3440;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:54df:770b:e9bb:3440
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
Subject: Ryzen 7000 Described, but not detailed
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Mon, 23 May 2022 08:23:20 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Quadibloc - Mon, 23 May 2022 08:23 UTC

Lisa Su's Computex keynote noted some facts about the Ryzen 7000
series in general, but she didn't give the details on each SKU in the
forthcoming lineup.

The 16-core version has, apparently, a turbo speed of around 5.5 GHz,
as shown in a game demo.

15% single-thread performance uplift was noted. The L2 cache was
doubled, however, and this was enough to give 15% extra performance
in the previous-generation X3D. One would have expected that the
higher frequency, and some IPC improvements in the architecture, would
lead to a bigger uplift for these chips - 15% from just the bigger cache,
plus a few percent more, at least, from all these other things.

John Savard

Re: Ryzen 7000 Described, but not detailed

<2022May23.112121@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25452&group=comp.arch#25452

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Mon, 23 May 2022 09:21:21 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 37
Message-ID: <2022May23.112121@mips.complang.tuwien.ac.at>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="91a43f25bdbd950c7ec1ec8001f40ef0";
logging-data="26469"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19rJSQIYp1LdmlW6B3zkCNK"
Cancel-Lock: sha1:8ebM98PLPI0XRVuvpDQa389l3As=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Mon, 23 May 2022 09:21 UTC

Quadibloc <jsavard@ecn.ab.ca> writes:
>Lisa Su's Computex keynote noted some facts about the Ryzen 7000
>series in general, but she didn't give the details on each SKU in the
>forthcoming lineup.
>
>The 16-core version has, apparently, a turbo speed of around 5.5 GHz,
>as shown in a game demo.
>
>15% single-thread performance uplift was noted. The L2 cache was
>doubled, however, and this was enough to give 15% extra performance
>in the previous-generation X3D.

L3 cache was tripled to 96MB in the 5800X3D. But yes, between the
clock rate increase and the IPC increase from the larger L2, I expect
little other IPC increases.

But increasing the clock to 5.5GHz is quite a feat. I wonder how they
did that? Is the new process so good, or have they managed to reduce
the gate delays per pipeline stage without reducing IPC?

What she apparently did not mention is Spectre fixes:-(. In a few
days it will be five years since Intel and AMD learned about Spectre.
It seems that they don't want to fix it. However, if Zen4 reuses most of
Zen3's microarchitecture, they still have an excuse.

She apparently also did not mention AVX512, which many expected for
Zen4.

Competetively, Intel is expected to increase L2 with their next
generation (Raptor Lake IIRC), and leave the microarchitecture
otherwise mostly unchanged. And you can always expect a clock
increase from Intel.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Ryzen 7000 Described, but not detailed

<t6gkmj$92i$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25453&group=comp.arch#25453

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: tl...@none.invalid (Torbjorn Lindgren)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Mon, 23 May 2022 18:44:35 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <t6gkmj$92i$1@dont-email.me>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
Injection-Date: Mon, 23 May 2022 18:44:35 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="40c2bcf74bfe374656fb62badec8118b";
logging-data="9298"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19+st5rZXS4ECB6tyWQjojnTXkpS1qXaJk="
Cancel-Lock: sha1:1HUVFStwF8uqj/6BiMNwcytxTso=
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
 by: Torbjorn Lindgren - Mon, 23 May 2022 18:44 UTC

Quadibloc <jsavard@ecn.ab.ca> wrote:
>Lisa Su's Computex keynote noted some facts about the Ryzen 7000
>series in general, but she didn't give the details on each SKU in the
>forthcoming lineup.
>
>The 16-core version has, apparently, a turbo speed of around 5.5 GHz,
>as shown in a game demo.

No, what they showed that it's POSSIBLE to take ONE Zen4 cpu up to at
least 5.5GHz. The slides only says at least one SKU will hit "5GHz+"
single-core boost speed, usually one would expect this to also be the
high-core variant but that's not guaranteed either.

I don't think ANY details on what they were showing was given, if
that's true it could be the best chip they've produced so far
(ultimate golden sample) running on liquid helium (because not even
LN2 was enough). Or it could be a random high-bin sample running on
big air-tower or largeish AIO. I do hope it's closer to the later.

The 5950X already has a boost clock of up to 4.9GHz so the stated 5+
GHz means there MAY only be very little frequency increase compared to
Zen 3.

Basically we just don't know yet. "This fall" suggest AMD probably
know by now but...

The apparently hard DDR5 requirement could end up being a big
gift-wrapped package to Intel in the build-your-own segment since
IIRFC Intel will AFAIK support DDR4 up to at least 13th gen (Raptor
Lake).

This depends on how memory prices develop over the next few months,
I'm told the price-difference isn't bad for big OEM's (Dell, HP, ...)
but it's still 50%++ premium on various online stores for various
sizes and worse yet the common 2x8GB DDR4 config (or 1x8) is a bad
idea on DDR5 due to only 16Gbps DDR5 chips being available - "good"
8GB sticks need 8Gbps memory chips which exists for DDR4 but not for
DDR5!

>15% single-thread performance uplift was noted. The L2 cache was
>doubled, however, and this was enough to give 15% extra performance
>in the previous-generation X3D. One would have expected that the
>higher frequency, and some IPC improvements in the architecture, would
>lead to a bigger uplift for these chips - 15% from just the bigger cache,
>plus a few percent more, at least, from all these other things.

The 5800X3D trippled the size of the shared *L3* cache for 15% IPC
improvement, Zen 4 doubles the per-core *L2* cache. So, different
increase and at very different points in the cache structure.

So 5950X have 8MB L2 (16x512) and 64MB L3 and an hypotetical "7950X"
would have 16MB L2 (16x1024) and ?? L3, but probably 64MB L3 since
they don't mention an increase nor 3D. They did later assure some
reporters that 3D cache hasn't been dropped.

As mentioned we don't even know what frequencies it'll hit, just the
5GHz+. 5.0GHz would be 2% increase, 5.5GHz would be 12% increase.

Given that AMD seems to impy a total improvement of 15% despite
doubling the per-core L2 cache and presumably core improvements I'm
going to guess that it won't increase speed much over the 5950X's
4.9GHz.

AMD has earlier promised that Zen4 would be "overclocking friendly" -
perhaps the combination implies that PBO3? and increased power target
will allow higher frequencies ("single-click overclock") and the 15%
improvement is without overclocking and that the "stock" boost is
somewhere in the 5.0-5.2GHz range.

Re: Ryzen 7000 Described, but not detailed

<7cb8beb2-ad09-4199-8949-fbfe4c384245n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25454&group=comp.arch#25454

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:23c9:b0:461:c9e7:9cd6 with SMTP id hr9-20020a05621423c900b00461c9e79cd6mr18012567qvb.116.1653334377052;
Mon, 23 May 2022 12:32:57 -0700 (PDT)
X-Received: by 2002:a05:6808:3198:b0:32b:a54:1238 with SMTP id
cd24-20020a056808319800b0032b0a541238mr364087oib.16.1653334376784; Mon, 23
May 2022 12:32:56 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder1.cambriumusenet.nl!feed.tweak.nl!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 23 May 2022 12:32:56 -0700 (PDT)
In-Reply-To: <t6gkmj$92i$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:ec27:570b:23fc:9a14;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:ec27:570b:23fc:9a14
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <t6gkmj$92i$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7cb8beb2-ad09-4199-8949-fbfe4c384245n@googlegroups.com>
Subject: Re: Ryzen 7000 Described, but not detailed
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Mon, 23 May 2022 19:32:57 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Quadibloc - Mon, 23 May 2022 19:32 UTC

On Monday, May 23, 2022 at 12:44:38 PM UTC-6, Torbjorn Lindgren wrote:

> The apparently hard DDR5 requirement could end up being a big
> gift-wrapped package to Intel in the build-your-own segment since
> IIRFC Intel will AFAIK support DDR4 up to at least 13th gen (Raptor
> Lake).

True, but previous news reports said that Intel was telling motherboard
makers to "emphasize" DDR5 over DDR4 quite strongly, so it seems like
it doesn't want to accept the gift.

John Savard

Re: Ryzen 7000 Described, but not detailed

<9036a43c-be2c-4516-a394-f74e5ce22893n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25455&group=comp.arch#25455

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:1346:b0:2f9:17ce:2f1d with SMTP id w6-20020a05622a134600b002f917ce2f1dmr14468632qtk.657.1653336780088;
Mon, 23 May 2022 13:13:00 -0700 (PDT)
X-Received: by 2002:a05:620a:4310:b0:67e:8460:5a10 with SMTP id
u16-20020a05620a431000b0067e84605a10mr14595902qko.636.1653336779887; Mon, 23
May 2022 13:12:59 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 23 May 2022 13:12:59 -0700 (PDT)
In-Reply-To: <7cb8beb2-ad09-4199-8949-fbfe4c384245n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:6924:db9b:e195:3505;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:6924:db9b:e195:3505
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
<t6gkmj$92i$1@dont-email.me> <7cb8beb2-ad09-4199-8949-fbfe4c384245n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9036a43c-be2c-4516-a394-f74e5ce22893n@googlegroups.com>
Subject: Re: Ryzen 7000 Described, but not detailed
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 23 May 2022 20:13:00 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1889
 by: MitchAlsup - Mon, 23 May 2022 20:12 UTC

On Monday, May 23, 2022 at 2:32:58 PM UTC-5, Quadibloc wrote:
> On Monday, May 23, 2022 at 12:44:38 PM UTC-6, Torbjorn Lindgren wrote:
>
> > The apparently hard DDR5 requirement could end up being a big
> > gift-wrapped package to Intel in the build-your-own segment since
> > IIRFC Intel will AFAIK support DDR4 up to at least 13th gen (Raptor
> > Lake).
> True, but previous news reports said that Intel was telling motherboard
> makers to "emphasize" DDR5 over DDR4 quite strongly, so it seems like
> it doesn't want to accept the gift.
<
Perhaps driven by DRAM manufactures ?
>
> John Savard

Re: Ryzen 7000 Described, but not detailed

<t6gtpb$hpe$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25456&group=comp.arch#25456

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: tl...@none.invalid (Torbjorn Lindgren)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Mon, 23 May 2022 21:19:39 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <t6gtpb$hpe$1@dont-email.me>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <t6gkmj$92i$1@dont-email.me> <7cb8beb2-ad09-4199-8949-fbfe4c384245n@googlegroups.com>
Injection-Date: Mon, 23 May 2022 21:19:39 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="40c2bcf74bfe374656fb62badec8118b";
logging-data="18222"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ChNew/JBIhqCYEzqUxqj7NJKUAid7bNQ="
Cancel-Lock: sha1:65AQR6UECPUdxfOIOWXz57v/ZM0=
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
 by: Torbjorn Lindgren - Mon, 23 May 2022 21:19 UTC

Quadibloc <jsavard@ecn.ab.ca> wrote:
>On Monday, May 23, 2022 at 12:44:38 PM UTC-6, Torbjorn Lindgren wrote:
>> The apparently hard DDR5 requirement could end up being a big
>> gift-wrapped package to Intel in the build-your-own segment since
>> IIRFC Intel will AFAIK support DDR4 up to at least 13th gen (Raptor
>> Lake).
>
>True, but previous news reports said that Intel was telling motherboard
>makers to "emphasize" DDR5 over DDR4 quite strongly, so it seems like
>it doesn't want to accept the gift.

I suspect that's an old statement that made sense THEN, long before
the motherboards and CPUs came out - at that point everyone expected
DDR5 to only have a small premium. And at that point the unmatchable
bandwidth that DDR5 do give you was considered an Intels *advantage*
that AMD wouldn't be able to match for ~1 year! So they were trying to
lean into it.

It takes time to change course so I don't consider it surprising that
the initial set of motherboard only contains low and (lower) mid-range
DDR4 motherboards with the high-end reserved for DDR5.

And to be honest, to some extent it still largely makes sense, the
ultra-expensve $1000+ motherboards are really mostly for extreme
overclocking (XO) and both money and sense were discarded long before
the question of memory cost came up. It does still hurt Intel somewhat
in those segments, it would have been useful for XO users to have
access to a low-latency memory platform too which at this point is
still highly tuned DDR4.

But the number of motherboards sold to XO users are fairly small and
the remainder honestly seems to end up with people working on the
"more expensive=better" and "higher number=better" rules.

Where it has the potential to hurt the demand is with smallish (but
still way, WAY larger than XO) "workstation" class of products in the
upper mid-range which generally wants things like integrated TB4 and
10Gbps network which also ends up with DDR5 only (for now).

But most of that market is goes via SA's or big OEMs and as I
mentioned all reports are that for *those* the price-delta isn't very
large!

Also, workstation class machines often lives by the amount of memory
that can be stuffed into them and the DDR4/4-slot/Unregistered is
as it looks right now never going to exceed 128GB, but there's a good
chance the DDR5 variants will later be able to upgrade to 256GB! So
while there's a bummer it also has POSSIBLE future upsides.

So, it's a problem but mainly for a subset of a subset, or subset of
subset of subset.

Until I considered the amount of memory angle I was a bit surprised we
haven't seen any DDR4 Z690/10G/TB4 motherboard (yet) but I can easily
seeing them deciding it's too small market and/or deciding it'll hold
until the 13th gen motherboards comes out.

AFAIK those are likely coming out about the same time as AM4/Ryzen
7xxx/DDR5-only platform, until then they may well be fine continuing
to sell X570/10G/TB4 motherboard (for 5950X), no skin off their nose
that it's AMD instead of Intel.

It also depends on where they think DDR4 prices are going to go by
6-12 months time, there's a lot of lead-time in creating new
motherboards.

Re: Ryzen 7000 Described, but not detailed

<2022May24.082305@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25461&group=comp.arch#25461

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Tue, 24 May 2022 06:23:05 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 64
Message-ID: <2022May24.082305@mips.complang.tuwien.ac.at>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <t6gkmj$92i$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="3fde5b9ed4bdced33a548f1df7235f7b";
logging-data="25886"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/BSD7Vhg36VBqGhGkuj5gY"
Cancel-Lock: sha1:63DpuoZigS1shnkoA2sXjHWOLrE=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Tue, 24 May 2022 06:23 UTC

Torbjorn Lindgren <tl@none.invalid> writes:
>I don't think ANY details on what they were showing was given, if
>that's true it could be the best chip they've produced so far
>(ultimate golden sample) running on liquid helium (because not even
>LN2 was enough).

A quick search showed 6362MHz all-core for a 5950X with LN2
overclocking, so it's unlikely that they have to go to these lengths
for 5500Mhz on the next generation.

>Basically we just don't know yet. "This fall" suggest AMD probably
>know by now but...

In particular the announcements of multiple mainboards suggest that
the whole ecosystem is pretty far along.

>The apparently hard DDR5 requirement could end up being a big
>gift-wrapped package to Intel in the build-your-own segment since
>IIRFC Intel will AFAIK support DDR4 up to at least 13th gen (Raptor
>Lake).
>
>This depends on how memory prices develop over the next few months,
>I'm told the price-difference isn't bad for big OEM's (Dell, HP, ...)
>but it's still 50%++ premium on various online stores for various
>sizes

Currently more like a factor of 2 here: The cheapest available DDR4 is
2x16GB DDR4-2666 at EUR 96.90, the cheapest avaiolable DDR5 is 16GB
DDR5-4800 at EUR 80.90, but that's only at one dealer; otherwise it
starts at EUR 190.59 for 2x16GB DDR5-4800.

>and worse yet the common 2x8GB DDR4 config (or 1x8) is a bad
>idea on DDR5 due to only 16Gbps DDR5 chips being available - "good"
>8GB sticks need 8Gbps memory chips which exists for DDR4 but not for
>DDR5!

So buy 1x16GB instead of 2x8GB. Same capacity, similar bandwidth,
same number of channels.

But I see that 8GB DIMMs for DDR5 exist, e.g., Crucial CT8G48C40U5
(EUR 59.23).

Anyway, it looks like AM5 will be a high-end platform as long as DDR5
prices stay high, but you can still buy AM4 stuff; AMD may have to
reduce the price over time, though.

>As mentioned we don't even know what frequencies it'll hit, just the
>5GHz+. 5.0GHz would be 2% increase, 5.5GHz would be 12% increase.
>
>Given that AMD seems to impy a total improvement of 15% despite
>doubling the per-core L2 cache and presumably core improvements I'm
>going to guess that it won't increase speed much over the 5950X's
>4.9GHz.

Either that, or the core improvements are mainly for clock speed
improvements (plus L2 increase), and they had their hands full with
porting to the new process (AMD's tick-tock approach) and all the
stuff they had to do on the I/O die (DDR5, PCIe5, faster USB,
graphics, display port).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Ryzen 7000 Described, but not detailed

<29295d1c-c135-4fb9-8e52-91b1a58e0181n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25463&group=comp.arch#25463

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:27cc:b0:462:557b:cc38 with SMTP id ge12-20020a05621427cc00b00462557bcc38mr887712qvb.4.1653381774185;
Tue, 24 May 2022 01:42:54 -0700 (PDT)
X-Received: by 2002:a05:6214:238b:b0:456:30d0:140e with SMTP id
fw11-20020a056214238b00b0045630d0140emr19940357qvb.84.1653381774071; Tue, 24
May 2022 01:42:54 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 24 May 2022 01:42:53 -0700 (PDT)
In-Reply-To: <2022May23.112121@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:ec27:570b:23fc:9a14;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:ec27:570b:23fc:9a14
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <2022May23.112121@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <29295d1c-c135-4fb9-8e52-91b1a58e0181n@googlegroups.com>
Subject: Re: Ryzen 7000 Described, but not detailed
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Tue, 24 May 2022 08:42:54 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2058
 by: Quadibloc - Tue, 24 May 2022 08:42 UTC

On Monday, May 23, 2022 at 3:38:04 AM UTC-6, Anton Ertl wrote:

> She apparently also did not mention AVX512, which many expected for
> Zen4.

That's disappointing, but then Intel isn't offering AVX-512 in their
consumer chips either.

However, I _did_ see *one* thing that was exciting in what she said about
Ryzen 7000.

It will have 24 PCIe 5 channels. That isn't exciting by itself, since a graphics
card takes 16 of them, so that's not enough for two.

However, the chips will also have *on-chip graphics* even in the 8, 12, and 16
core SKUs, not just in the ones for budget builds. So, if one _isn't_ heavily into
gaming, and can be content with the (fairly good!) on-chip graphics...

finally one does not need to run out and buy a Threadripper if one wants to
put an *accelerator card* in one's CPU!

John Savard

Re: Ryzen 7000 Described, but not detailed

<d1bbcc06-b0dd-411d-af68-e81fb0e1c656n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25464&group=comp.arch#25464

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:a385:0:b0:6a3:2baf:7e98 with SMTP id m127-20020a37a385000000b006a32baf7e98mr16905497qke.109.1653386484085;
Tue, 24 May 2022 03:01:24 -0700 (PDT)
X-Received: by 2002:ac8:7fc5:0:b0:2f9:4414:c3b4 with SMTP id
b5-20020ac87fc5000000b002f94414c3b4mr799631qtk.22.1653386483936; Tue, 24 May
2022 03:01:23 -0700 (PDT)
Path: i2pn2.org!rocksolid2!i2pn.org!aioe.org!news.mixmin.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 24 May 2022 03:01:23 -0700 (PDT)
In-Reply-To: <29295d1c-c135-4fb9-8e52-91b1a58e0181n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.203.251.52; posting-account=ow8VOgoAAAAfiGNvoH__Y4ADRwQF1hZW
NNTP-Posting-Host: 199.203.251.52
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
<2022May23.112121@mips.complang.tuwien.ac.at> <29295d1c-c135-4fb9-8e52-91b1a58e0181n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d1bbcc06-b0dd-411d-af68-e81fb0e1c656n@googlegroups.com>
Subject: Re: Ryzen 7000 Described, but not detailed
From: already5...@yahoo.com (Michael S)
Injection-Date: Tue, 24 May 2022 10:01:24 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Michael S - Tue, 24 May 2022 10:01 UTC

On Tuesday, May 24, 2022 at 11:42:55 AM UTC+3, Quadibloc wrote:
> On Monday, May 23, 2022 at 3:38:04 AM UTC-6, Anton Ertl wrote:
>
> > She apparently also did not mention AVX512, which many expected for
> > Zen4.
> That's disappointing, but then Intel isn't offering AVX-512 in their
> consumer chips either.
>

Intel does not offer AVX-512 in their *new* consumer chips.
Previous generation, what they call Gen11, mainly Rocket Lake desktop
CPUs and Tiger Lake notebook chips, offers AVX-512 just fine.

I took a look at the web site of our biggest network of computer shops.
In the list of "Recommended desktop PCs with Intel CPU" 18 out of 38
models have AVX-512.
For notebooks, they have no "recommended" list, so I looked at all models.
There are many, so my numbers are less precise, but from quick glance it
looks like at the moment models with AVX-512 constitute overwhelming majority
of Intel-based notebooks. Only 20 or 25 models out of ~120 were either too old
(gen10), too cheap (Pentium Gold) or too new (gen12). The rest, i.e. ~75%
are based on i3/i5/i7/i9 Gen11 and support AVX-512.

Re: Ryzen 7000 Described, but not detailed

<2022May24.122829@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25465&group=comp.arch#25465

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Tue, 24 May 2022 10:28:29 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 27
Message-ID: <2022May24.122829@mips.complang.tuwien.ac.at>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <2022May23.112121@mips.complang.tuwien.ac.at> <29295d1c-c135-4fb9-8e52-91b1a58e0181n@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="3fde5b9ed4bdced33a548f1df7235f7b";
logging-data="19612"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18bFMs6YBNjufTN1A2kmSUX"
Cancel-Lock: sha1:a/HsWc0ZN8YGo+7Sqn+NjvQvWMo=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Tue, 24 May 2022 10:28 UTC

Quadibloc <jsavard@ecn.ab.ca> writes:
>On Monday, May 23, 2022 at 3:38:04 AM UTC-6, Anton Ertl wrote:
>
>> She apparently also did not mention AVX512, which many expected for
>> Zen4.
>
>That's disappointing, but then Intel isn't offering AVX-512 in their
>consumer chips either.

In Ice Lake, Tiger Lake (mobile), and Rocket Lake (desktop), they
offer AVX-512.

>However, the chips will also have *on-chip graphics* even in the 8, 12, and 16
>core SKUs, not just in the ones for budget builds. So, if one _isn't_ heavily into
>gaming, and can be content with the (fairly good!) on-chip graphics...

The graphics capability is expected to be weak. If you want fairly
good graphics, get, e.g., a Ryzen 5700G (AM4) or an unannounced AM5
6700G (the corresponding mobile APUs already exist).

But the graphics saves both the cost and the power consumption for the
low-end graphics card we have had to put in our Ryzen-based servers.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Ryzen 7000 Described, but not detailed

<10bcf006-e3c1-4626-84ab-64deffc2ecafn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25466&group=comp.arch#25466

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:6ed0:0:b0:2f9:4564:97b5 with SMTP id f16-20020ac86ed0000000b002f9456497b5mr887409qtv.669.1653391104265;
Tue, 24 May 2022 04:18:24 -0700 (PDT)
X-Received: by 2002:a05:6214:2604:b0:461:e027:d50e with SMTP id
gu4-20020a056214260400b00461e027d50emr20668269qvb.46.1653391104106; Tue, 24
May 2022 04:18:24 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 24 May 2022 04:18:23 -0700 (PDT)
In-Reply-To: <2022May24.122829@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=199.203.251.52; posting-account=ow8VOgoAAAAfiGNvoH__Y4ADRwQF1hZW
NNTP-Posting-Host: 199.203.251.52
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
<2022May23.112121@mips.complang.tuwien.ac.at> <29295d1c-c135-4fb9-8e52-91b1a58e0181n@googlegroups.com>
<2022May24.122829@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <10bcf006-e3c1-4626-84ab-64deffc2ecafn@googlegroups.com>
Subject: Re: Ryzen 7000 Described, but not detailed
From: already5...@yahoo.com (Michael S)
Injection-Date: Tue, 24 May 2022 11:18:24 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2080
 by: Michael S - Tue, 24 May 2022 11:18 UTC

On Tuesday, May 24, 2022 at 1:41:25 PM UTC+3, Anton Ertl wrote:
>
> But the graphics saves both the cost and the power consumption for the
> low-end graphics card we have had to put in our Ryzen-based servers.

It's not given that server OEMs would want to use built-in GPU.
Back when we were shopping for small Xeon-E3 v3 based server I
was surprised that Dell 1U servers do not support CPUs with
built-in graphics, like 1275v3. Instead, we ended up buying
E3 1271v3 + Matrox G200er.
I never understood Dell's reasons, but surely they had reasons.

However, few years later, similar DELL gear based E-21xx did use built-in GPU.

> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Re: Ryzen 7000 Described, but not detailed

<t6ikci$cf2$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25467&group=comp.arch#25467

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: tl...@none.invalid (Torbjorn Lindgren)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Tue, 24 May 2022 12:51:31 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 123
Message-ID: <t6ikci$cf2$1@dont-email.me>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <t6gkmj$92i$1@dont-email.me> <2022May24.082305@mips.complang.tuwien.ac.at>
Injection-Date: Tue, 24 May 2022 12:51:31 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="145e1dc29f4ae14aa033ccfeddae9d84";
logging-data="12770"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+X88zxfq4FY4CpKl8ORXbwv9SuXA/hDTA="
Cancel-Lock: sha1:Z4NlChDu8eipsx+0+kWCVdVG2ro=
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
 by: Torbjorn Lindgren - Tue, 24 May 2022 12:51 UTC

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Torbjorn Lindgren <tl@none.invalid> writes:
>>I don't think ANY details on what they were showing was given, if
>>that's true it could be the best chip they've produced so far
>>(ultimate golden sample) running on liquid helium (because not even
>>LN2 was enough).
>
>A quick search showed 6362MHz all-core for a 5950X with LN2
>overclocking, so it's unlikely that they have to go to these lengths
>for 5500Mhz on the next generation.

Yeah but it's the first processors of a new design, in a new node and
not launched yet, so it's possible they had to push hard.

No, I don't consider it likely that they had to resort to LN2 cooling,
never mind helium, it was obviously a deliberate "maximum possible"
example to compare with the other extreme (fairly standard cooling for
current high-end PCs) to illustrate how little we actually KNOW.

We should also remember that it was hitting 5.5GHz single-core peaks
running a game, not something that would have pushed the heat
generation much harder like Prime95 Small.

>>and worse yet the common 2x8GB DDR4 config (or 1x8) is a bad
>>idea on DDR5 due to only 16Gbps DDR5 chips being available - "good"
>>8GB sticks need 8Gbps memory chips which exists for DDR4 but not for
>>DDR5!
>
>So buy 1x16GB instead of 2x8GB. Same capacity, similar bandwidth,
>same number of channels.

I wrote Gbps (speed), I obviously meant Gb (size) for the memory
chips. So I'll try to make sure I write "stick" for the actual memory
sticks.

So, an 1x16GB stick configuration is half the channels and (a bit more
than) half the bandwidth of 2x16 stick configuration at the same speed
(and speed is independent).

Yes, it's true that I said that a DDR5 2x8GB stick configuration is
"not optimal" but it'll still beat the **** out of a DDR5 1x16GB stick
configuration. (aka "pre-built computer special", they really LOVE
their single memory sticks to save $5 or so).

OTOH "not quite as bad" isn't the best possible epitaph for a solution
that still cost a lot more than DDR4.

>But I see that 8GB DIMMs for DDR5 exist, e.g., Crucial CT8G48C40U5
>(EUR 59.23).

Yes, I at least implicitly acknowledged this when I said how they were
constructed and why they were inferior.

To elaborate a bit more:

Due to there not being any 8Gb DDR5 memory chips any 8GB DDR5 memory
stick will be built using four 16Gb x16 chips (4*16Gb=8GB, 4x16 gives
64 data bits) and when the memory chips are set up for x16 they have
significantly less concurrancy than when set up as x8 chips (less
groups and planes).

Don't ask me why that is, I just read data-sheets and read/watch
benchmark results :-)

Various new features in DDR5 likely lessen the impact of less
concurrency compared to DDR4 but it's still very noticeable in testing
I've seen.

A 16GB DDR5 stick OTOH is (so far) built using eight 16Gb x8 chips
(8*16Gb=16GB, 8x8 gives 64 databts) and as mentioned x8 (and x4) chips
doesn't have this issue.

The reason this usually isn't a problem for DDR4 is that there's still
4Gb and 8Gb chips in active production so it's trivial to build
smaller memory sticks using eight x8 chips (down to 4GB).

We still see a few of these four x16 chip configurations on very cheap
DDR4 SO-DIMMs now and then and the result tends to be BAD, the impact
is actually much worse on DDR4.

Now, it wouldn't be hard for the manufacturers to build 8Gb DDR5 chips
but I expect they don't think there's enough demand for it. The
various memory manufacturers all have larger DDR5 chips in their
roadmap (24Gb!, 32Gb, 48Gb! and 64Gb) but I don't think anyone has 8Gb
DDR5 listed in their public roadmaps.

>Anyway, it looks like AM5 will be a high-end platform as long as DDR5
>prices stay high, but you can still buy AM4 stuff; AMD may have to
>reduce the price over time, though.

Yeah, if they have fab allocation it certainly makes sense to continue
to produce AM4 especially in light of the current (high) demand and
uncertainty of a new process node.

Whether they do have enough 7nm fab space allocated at TSMC to do that
is of course the question since TSMC is *full* for the foreseable
future but it's not a question anyone outside AMD and TSMC is likely
to know, it's all planned 12-24 months in advance!

They also need the old 12/14nm GF IO die for any of the older chips
they build, again we don't know how how supplies of that looks (IIRC
they're been cutting down on GF deliveries).

On the positive side the Zen4 core dies and IO die both use different
fab processes (TSCM 5nm and 6nm respectively) so they're not in direct
competition in the fab! at least but I expect most processing after
that uses the same factories.

>Either that, or the core improvements are mainly for clock speed
>improvements (plus L2 increase), and they had their hands full with
>porting to the new process (AMD's tick-tock approach) and all the
>stuff they had to do on the I/O die (DDR5, PCIe5, faster USB,
>graphics, display port).

The new IO die certainly got a massive upgrade here OTOH they could
have had people working on that for a long time given how long they've
been using the current IO die.

Re: Ryzen 7000 Described, but not detailed

<2022May24.161734@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25469&group=comp.arch#25469

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Tue, 24 May 2022 14:17:34 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 63
Message-ID: <2022May24.161734@mips.complang.tuwien.ac.at>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <t6gkmj$92i$1@dont-email.me> <2022May24.082305@mips.complang.tuwien.ac.at> <t6ikci$cf2$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="3fde5b9ed4bdced33a548f1df7235f7b";
logging-data="2640"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/vUrAu3l6Zmep9x3p7mqR+"
Cancel-Lock: sha1:09LMSdT94OQJcT3x8KOjOonqdrI=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Tue, 24 May 2022 14:17 UTC

Torbjorn Lindgren <tl@none.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Torbjorn Lindgren <tl@none.invalid> writes:
....
>No, I don't consider it likely that they had to resort to LN2 cooling,
>never mind helium

From what I know, most modern CPUs stop working below -120C or so, so
already LN2 cooling is a balancing act, and LHe would not make sense
(less enthalpy of vaporization and much higher cost).

>>>and worse yet the common 2x8GB DDR4 config (or 1x8) is a bad
>>>idea on DDR5 due to only 16Gbps DDR5 chips being available - "good"
>>>8GB sticks need 8Gbps memory chips which exists for DDR4 but not for
>>>DDR5!
>>
>>So buy 1x16GB instead of 2x8GB. Same capacity, similar bandwidth,
>>same number of channels.
>
>I wrote Gbps (speed), I obviously meant Gb (size) for the memory
>chips. So I'll try to make sure I write "stick" for the actual memory
>sticks.
>
>So, an 1x16GB stick configuration is half the channels and (a bit more
>than) half the bandwidth of 2x16 stick configuration at the same speed
>(and speed is independent).

You compared 2x8GB DDR4 with DDR5. Even if it was true that there is
no 8GB DDR5 sticks, 1x16GB DDR5 is similar in performace to 2x8GB
DDR4.

>Due to there not being any 8Gb DDR5 memory chips any 8GB DDR5 memory
>stick will be built using four 16Gb x16 chips (4*16Gb=8GB, 4x16 gives
>64 data bits) and when the memory chips are set up for x16 they have
>significantly less concurrancy than when set up as x8 chips (less
>groups and planes).
>
>Don't ask me why that is, I just read data-sheets and read/watch
>benchmark results :-)

And what do the benchmark results say?

I remember that on one benchmark (on IIRC the Alder Lake review on
anandtech) DDR5 beat DDR4 by a lot due to having double the number of
channels with the same number of sticks, but for most applications the
CPU performance difference of different RAM configurations is
relatively minor.

>On the positive side the Zen4 core dies and IO die both use different
>fab processes (TSCM 5nm and 6nm respectively) so they're not in direct
>competition in the fab! at least but I expect most processing after
>that uses the same factories.

Is that really positive? They have to estimate the demand for their
various products far in advance. The might have estimated that AM5
demand will be much higher than it turns out to be thanks to DDR5
prices, and then they have capacity that they don't need (well maybe
do an Xbox SoC shrink early or something).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Ryzen 7000 Described, but not detailed

<2022May24.165104@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25470&group=comp.arch#25470

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Tue, 24 May 2022 14:51:04 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 31
Message-ID: <2022May24.165104@mips.complang.tuwien.ac.at>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <2022May23.112121@mips.complang.tuwien.ac.at> <29295d1c-c135-4fb9-8e52-91b1a58e0181n@googlegroups.com> <2022May24.122829@mips.complang.tuwien.ac.at> <10bcf006-e3c1-4626-84ab-64deffc2ecafn@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="3fde5b9ed4bdced33a548f1df7235f7b";
logging-data="13734"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Q9ssX/fgdXKa9G2U99Grc"
Cancel-Lock: sha1:tNtsDgjvaKDJGmHXjncrdH5JxT8=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Tue, 24 May 2022 14:51 UTC

Michael S <already5chosen@yahoo.com> writes:
>On Tuesday, May 24, 2022 at 1:41:25 PM UTC+3, Anton Ertl wrote:
>>
>> But the graphics saves both the cost and the power consumption for the
>> low-end graphics card we have had to put in our Ryzen-based servers.
>
>It's not given that server OEMs would want to use built-in GPU.

Yes, and many server customers want the graphics or whatever through
an extra Ethernet port that is served from an mainboard
graphics/control chip called a BMC. Funnily, whenever we bought a
board that advertized a BMC, it turned out that it's an optional
add-on that costs extra in addition to the already-high cost of the
server board.

We have a setup that works with classical VGA KVMs, and this add-on
nonsense ensures that we stay there (well, we have to think about
something for our new Intel servers that don't support VGA).

With the Ryzens, we could use consumer boards, which are not just much
cheaper than server boards, but, as we found recently, are also
arguably better server boards than the sold-as-server boards: The
consumer ASUS TUF Gaming B550M-Plus supports a 2280 and a 22110 NVMe
SSD, the server ASUS P12R-M/10G-2T supports only one 2280 NVMe SSD,
but costs more than twice as much (ok, we saved EUR 100 on a 10GbE
card, but had to pay extra for PCIe->M.2 adapters).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Ryzen 7000 Described, but not detailed

<ky7jK.6426$vFlb.149@fx34.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25472&group=comp.arch#25472

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx34.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <t6gkmj$92i$1@dont-email.me> <2022May24.082305@mips.complang.tuwien.ac.at> <t6ikci$cf2$1@dont-email.me>
In-Reply-To: <t6ikci$cf2$1@dont-email.me>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 57
Message-ID: <ky7jK.6426$vFlb.149@fx34.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Tue, 24 May 2022 16:17:20 UTC
Date: Tue, 24 May 2022 12:17:02 -0400
X-Received-Bytes: 3241
X-Original-Bytes: 3190
 by: EricP - Tue, 24 May 2022 16:17 UTC

Torbjorn Lindgren wrote:
>
> To elaborate a bit more:
>
> Due to there not being any 8Gb DDR5 memory chips any 8GB DDR5 memory
> stick will be built using four 16Gb x16 chips (4*16Gb=8GB, 4x16 gives
> 64 data bits) and when the memory chips are set up for x16 they have
> significantly less concurrancy than when set up as x8 chips (less
> groups and planes).
>
> Don't ask me why that is, I just read data-sheets and read/watch
> benchmark results :-)
>
> Various new features in DDR5 likely lessen the impact of less
> concurrency compared to DDR4 but it's still very noticeable in testing
> I've seen.
>
> A 16GB DDR5 stick OTOH is (so far) built using eight 16Gb x8 chips
> (8*16Gb=16GB, 8x8 gives 64 databts) and as mentioned x8 (and x4) chips
> doesn't have this issue.
>
>
> The reason this usually isn't a problem for DDR4 is that there's still
> 4Gb and 8Gb chips in active production so it's trivial to build
> smaller memory sticks using eight x8 chips (down to 4GB).
>
> We still see a few of these four x16 chip configurations on very cheap
> DDR4 SO-DIMMs now and then and the result tends to be BAD, the impact
> is actually much worse on DDR4.

How many rows can each of these chips have open at once?
The internal configuration of the DRAMs would seem to be important.
I looked at some DDR4 chip specs and I couldn't see an explicit statement.

A picture showed a, say, 4 Gb chip having 4 groups, each group has 8 banks,
each bank has its own set of row address latches, row decode, sense amps,
and each row has 4096 column data latches. And each bank has 32768 rows.

So it looked like this chip could have 32 rows (banks) open at once.

For a 4 GB DIMM, it can use *1 (1 bit wide), *4 or *8 bit chips.
The DIMM has 16 chips, 8 per side.
If it uses *1's then all 16 chips must have the same 32 rows open,
and each chip supplies 1 bit per clock edge from 4096 column addresses.
If it uses *4's then it looked like I can get 4*32=128 rows open at once,
but each row supplies 4 bits per edge, from 1024 column addresses.
For *8's it is 256 rows, 8 bits per edge, from 512 columns addresses

There was also how many beats or bunches-of-bits are read per column access.
It looked like that could scale from 2, 4 or 8 bits (1, 2 or 4 clocks).

So the memory controller has to scale from managing 32 to 256 open rows.
And control how many bits are read per beat per column address.

Does that all sound about right?

Re: Ryzen 7000 Described, but not detailed

<61bb472e-e0ba-46aa-b829-4a584caa3543n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25473&group=comp.arch#25473

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ad4:4208:0:b0:461:d262:7842 with SMTP id k8-20020ad44208000000b00461d2627842mr22048514qvp.113.1653410897742;
Tue, 24 May 2022 09:48:17 -0700 (PDT)
X-Received: by 2002:a05:620a:22a7:b0:6a5:823d:652d with SMTP id
p7-20020a05620a22a700b006a5823d652dmr1098554qkh.127.1653410897574; Tue, 24
May 2022 09:48:17 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 24 May 2022 09:48:17 -0700 (PDT)
In-Reply-To: <ky7jK.6426$vFlb.149@fx34.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:f189:f730:a180:c250;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:f189:f730:a180:c250
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
<t6gkmj$92i$1@dont-email.me> <2022May24.082305@mips.complang.tuwien.ac.at>
<t6ikci$cf2$1@dont-email.me> <ky7jK.6426$vFlb.149@fx34.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <61bb472e-e0ba-46aa-b829-4a584caa3543n@googlegroups.com>
Subject: Re: Ryzen 7000 Described, but not detailed
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Tue, 24 May 2022 16:48:17 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 4138
 by: MitchAlsup - Tue, 24 May 2022 16:48 UTC

On Tuesday, May 24, 2022 at 11:17:26 AM UTC-5, EricP wrote:
> Torbjorn Lindgren wrote:
> >
> > To elaborate a bit more:
> >
> > Due to there not being any 8Gb DDR5 memory chips any 8GB DDR5 memory
> > stick will be built using four 16Gb x16 chips (4*16Gb=8GB, 4x16 gives
> > 64 data bits) and when the memory chips are set up for x16 they have
> > significantly less concurrancy than when set up as x8 chips (less
> > groups and planes).
> >
> > Don't ask me why that is, I just read data-sheets and read/watch
> > benchmark results :-)
> >
> > Various new features in DDR5 likely lessen the impact of less
> > concurrency compared to DDR4 but it's still very noticeable in testing
> > I've seen.
> >
> > A 16GB DDR5 stick OTOH is (so far) built using eight 16Gb x8 chips
> > (8*16Gb=16GB, 8x8 gives 64 databts) and as mentioned x8 (and x4) chips
> > doesn't have this issue.
> >
> >
> > The reason this usually isn't a problem for DDR4 is that there's still
> > 4Gb and 8Gb chips in active production so it's trivial to build
> > smaller memory sticks using eight x8 chips (down to 4GB).
> >
> > We still see a few of these four x16 chip configurations on very cheap
> > DDR4 SO-DIMMs now and then and the result tends to be BAD, the impact
> > is actually much worse on DDR4.
> How many rows can each of these chips have open at once?
> The internal configuration of the DRAMs would seem to be important.
> I looked at some DDR4 chip specs and I couldn't see an explicit statement.
>
> A picture showed a, say, 4 Gb chip having 4 groups, each group has 8 banks,
> each bank has its own set of row address latches, row decode, sense amps,
> and each row has 4096 column data latches. And each bank has 32768 rows.
>
> So it looked like this chip could have 32 rows (banks) open at once.
>
> For a 4 GB DIMM, it can use *1 (1 bit wide), *4 or *8 bit chips.
> The DIMM has 16 chips, 8 per side.
> If it uses *1's then all 16 chips must have the same 32 rows open,
> and each chip supplies 1 bit per clock edge from 4096 column addresses.
> If it uses *4's then it looked like I can get 4*32=128 rows open at once,
> but each row supplies 4 bits per edge, from 1024 column addresses.
> For *8's it is 256 rows, 8 bits per edge, from 512 columns addresses
>
> There was also how many beats or bunches-of-bits are read per column access.
> It looked like that could scale from 2, 4 or 8 bits (1, 2 or 4 clocks).
>
> So the memory controller has to scale from managing 32 to 256 open rows.
<
Memory controller can restrict itself to 32 banks and if it needs more, close a bank.
That is:: it does not have to be able to use all the rows.
<
> And control how many bits are read per beat per column address.
>
> Does that all sound about right?

Re: Ryzen 7000 Described, but not detailed

<2022May24.192204@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25474&group=comp.arch#25474

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Tue, 24 May 2022 17:22:04 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 45
Message-ID: <2022May24.192204@mips.complang.tuwien.ac.at>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <t6gkmj$92i$1@dont-email.me> <2022May24.082305@mips.complang.tuwien.ac.at> <t6ikci$cf2$1@dont-email.me> <ky7jK.6426$vFlb.149@fx34.iad>
Injection-Info: reader02.eternal-september.org; posting-host="3fde5b9ed4bdced33a548f1df7235f7b";
logging-data="29644"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19IZlfb7g6U3nLSGj5pSoC4"
Cancel-Lock: sha1:d6nhlxmYTls4ChpKdaUz22AAcxw=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Tue, 24 May 2022 17:22 UTC

EricP <ThatWouldBeTelling@thevillage.com> writes:
>For a 4 GB DIMM, it can use *1 (1 bit wide), *4 or *8 bit chips.
>The DIMM has 16 chips, 8 per side.

The sides of a DIMM are selected independently (two ranks per DIMM, at
least for DDR4; I guess with DDR5 this doubles because the number of
channels doubles) on usual DIMMs. DIMMs have 64 data bit lines. So
if a DIMM has 8 chips per side, it has *8 bit chips. AFAIK for UDIMMs
(unbuffered) load limit mean that you have at most 8/9 chips per rank
(there (rarely) are double-capacity UDIMMs with twice as many chips
per side, but they also have double the number of ranks, and you can
use only two of those on a memory controller that supports 4
normal-capacity UDIMMs). DIMMs with four chips per side are
necessarily x16-bits per chip.

Narrower chips are probably for registered RDIMMs and load-reduced
LRDIMMs (for big servers).

>If it uses *1's then all 16 chips must have the same 32 rows open,

All chips of a channel selected by the same rank have the same rows
etc. open.

>There was also how many beats or bunches-of-bits are read per column access.
>It looked like that could scale from 2, 4 or 8 bits (1, 2 or 4 clocks).

For DDR3 and DDR4 a burst is at least 8 transfers long. For DDR5 at
least 16. In order to match 64-byte cache line width, the channel
width has been 64 bits with DDR3/4, and has been reduced to 32 bits in
DDR5 (with the 64 bits of a DIMM containing two channels).

>So the memory controller has to scale from managing 32 to 256 open rows.
>And control how many bits are read per beat per column address.

The latter is pretty much fixed; i.e., 64 bits for DDR4, 32-bits for
DDR5. In the early DDR days minimal bursts were so short that one
could do something called dual-channel mode where instead of getting 8
beats from one 64-bit channel, you would get 4 beats each from two
channels, giving better bandwidth, but requiring the channels to have
the same rows open.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Ryzen 7000 Described, but not detailed

<f7281b82-9f73-4dea-889e-5fb1394f7c23n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25477&group=comp.arch#25477

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:22c1:b0:6a3:9974:fd12 with SMTP id o1-20020a05620a22c100b006a39974fd12mr7301358qki.93.1653421665888;
Tue, 24 May 2022 12:47:45 -0700 (PDT)
X-Received: by 2002:a05:622a:14b:b0:2f9:34e4:acfe with SMTP id
v11-20020a05622a014b00b002f934e4acfemr9495780qtw.426.1653421665731; Tue, 24
May 2022 12:47:45 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 24 May 2022 12:47:45 -0700 (PDT)
In-Reply-To: <ky7jK.6426$vFlb.149@fx34.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=2a0d:6fc2:55b0:ca00:988:c957:46aa:985f;
posting-account=ow8VOgoAAAAfiGNvoH__Y4ADRwQF1hZW
NNTP-Posting-Host: 2a0d:6fc2:55b0:ca00:988:c957:46aa:985f
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
<t6gkmj$92i$1@dont-email.me> <2022May24.082305@mips.complang.tuwien.ac.at>
<t6ikci$cf2$1@dont-email.me> <ky7jK.6426$vFlb.149@fx34.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f7281b82-9f73-4dea-889e-5fb1394f7c23n@googlegroups.com>
Subject: Re: Ryzen 7000 Described, but not detailed
From: already5...@yahoo.com (Michael S)
Injection-Date: Tue, 24 May 2022 19:47:45 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 5107
 by: Michael S - Tue, 24 May 2022 19:47 UTC

On Tuesday, May 24, 2022 at 7:17:26 PM UTC+3, EricP wrote:
> Torbjorn Lindgren wrote:
> >
> > To elaborate a bit more:
> >
> > Due to there not being any 8Gb DDR5 memory chips any 8GB DDR5 memory
> > stick will be built using four 16Gb x16 chips (4*16Gb=8GB, 4x16 gives
> > 64 data bits) and when the memory chips are set up for x16 they have
> > significantly less concurrancy than when set up as x8 chips (less
> > groups and planes).
> >
> > Don't ask me why that is, I just read data-sheets and read/watch
> > benchmark results :-)
> >
> > Various new features in DDR5 likely lessen the impact of less
> > concurrency compared to DDR4 but it's still very noticeable in testing
> > I've seen.
> >
> > A 16GB DDR5 stick OTOH is (so far) built using eight 16Gb x8 chips
> > (8*16Gb=16GB, 8x8 gives 64 databts) and as mentioned x8 (and x4) chips
> > doesn't have this issue.
> >
> >
> > The reason this usually isn't a problem for DDR4 is that there's still
> > 4Gb and 8Gb chips in active production so it's trivial to build
> > smaller memory sticks using eight x8 chips (down to 4GB).
> >
> > We still see a few of these four x16 chip configurations on very cheap
> > DDR4 SO-DIMMs now and then and the result tends to be BAD, the impact
> > is actually much worse on DDR4.
> How many rows can each of these chips have open at once?
> The internal configuration of the DRAMs would seem to be important.
> I looked at some DDR4 chip specs and I couldn't see an explicit statement.
>
> A picture showed a, say, 4 Gb chip having 4 groups, each group has 8 banks,
> each bank has its own set of row address latches, row decode, sense amps,
> and each row has 4096 column data latches. And each bank has 32768 rows.

4096 column are atypical. More typically, DDR4 devices have 1024 columns.
I am not even sure if 4096 columns allowed by JPEG standards.

32K rows per bank mostly appear in older and smaller chips. Bigger devices,
esp, those with 4-bit data bus can have up to 256K rows per bank.

>
> So it looked like this chip could have 32 rows (banks) open at once.

DDR4 devices with 32 banks are rare. Most typically, DDR4 device has 4 bank groups of 4 banks each
for 16 banks total.

>
> For a 4 GB DIMM, it can use *1 (1 bit wide), *4 or *8 bit chips.

JEDEC standard defines x4, x8 and x16 DDR4 chips. x1 does not exits.

x4 used almost exclusively for high-capacity server DIMMs, typically buffered/registered.
Unbuffered x4 would be problematic due to high capacitive load on address/control signals.

x16 is used in el-cheapo PC DIMMs and in embedded devices.

DIMMs used in good PCs are almost exclusively made out of x8 DDR devices.

> The DIMM has 16 chips, 8 per side.
> If it uses *1's then all 16 chips must have the same 32 rows open,
> and each chip supplies 1 bit per clock edge from 4096 column addresses.
> If it uses *4's then it looked like I can get 4*32=128 rows open at once,
> but each row supplies 4 bits per edge, from 1024 column addresses.
> For *8's it is 256 rows, 8 bits per edge, from 512 columns addresses
>
> There was also how many beats or bunches-of-bits are read per column access.
> It looked like that could scale from 2, 4 or 8 bits (1, 2 or 4 clocks).
>
> So the memory controller has to scale from managing 32 to 256 open rows.
> And control how many bits are read per beat per column address.
>
> Does that all sound about right?

Most typical PC DDR4 configuration has up to 64 simultaneously open banks per DIMM channel
(16 banks x 4 ranks) and 2 DIMM channels.
In server you have more channels, but also more controllers.
Sometimes in server you have more than 4 ranks, but AFAIK in DDR4 it costs you reduces data rate.

Re: Ryzen 7000 Described, but not detailed

<t6l7ne$20v$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25482&group=comp.arch#25482

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: tl...@none.invalid (Torbjorn Lindgren)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Wed, 25 May 2022 12:33:50 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <t6l7ne$20v$1@dont-email.me>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <t6gkmj$92i$1@dont-email.me> <2022May24.082305@mips.complang.tuwien.ac.at> <t6ikci$cf2$1@dont-email.me>
Injection-Date: Wed, 25 May 2022 12:33:50 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="b3e7518e9d0f63ef18d5689996dc520a";
logging-data="2079"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+/XTUZ590i0Hje5H7wDxdP1I8oVkwvSXE="
Cancel-Lock: sha1:bauY+ZYiP6Q5YbyGSoWo9KjtU0A=
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
 by: Torbjorn Lindgren - Wed, 25 May 2022 12:33 UTC

Torbjorn Lindgren <tl@none.invalid> wrote:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Torbjorn Lindgren <tl@none.invalid> writes:
>>>I don't think ANY details on what they were showing was given, if
>>>that's true it could be the best chip they've produced so far
>>>(ultimate golden sample) running on liquid helium (because not even
>>>LN2 was enough).
>>
>>A quick search showed 6362MHz all-core for a 5950X with LN2
>>overclocking, so it's unlikely that they have to go to these lengths
>>for 5500Mhz on the next generation.
>
>Yeah but it's the first processors of a new design, in a new node and
>not launched yet, so it's possible they had to push hard.
>
>No, I don't consider it likely that they had to resort to LN2 cooling,
>never mind helium, it was obviously a deliberate "maximum possible"
>example to compare with the other extreme (fairly standard cooling for
>current high-end PCs) to illustrate how little we actually KNOW.
>
>We should also remember that it was hitting 5.5GHz single-core peaks
>running a game, not something that would have pushed the heat
>generation much harder like Prime95 Small.

And we now know it was pretty close to the low-bar, AMD's Direct of
Technical Marketing Robert Hallock later disclosed in a PCWorld stream
that the 5.5GHz peak was done without overclocking using a reference
AM5 motherboard and a "consumer-based" Asetek 280mm - which build MOST
PC AIO's thanks to various patents on placing the pump on top of the
CPU (hence some model instead placing the pump in the radiator).

So more substantial cooling than I expect most people have on their
5950X (I'm guessing 240mm or big-air) but not chilled water (Intel 28
core 5GHz demo anyone) or anything crazy and it's a setup that should
be easy to match using consumer parts.

I was expecting it to be at least PBO boosting to hit 5.5GHz but even
that sounds like it's ruled out unless AMD has now decided PBO now
longer counts as overclocking.

Now, will it hit these frequencies on load that are far more strenous?
No idea, perhaps that may explain why they went with 5+GHz on the
poster. Or it was old information. Or...

Re: Ryzen 7000 Described, but not detailed

<t6lfdd$rld$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25483&group=comp.arch#25483

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: tl...@none.invalid (Torbjorn Lindgren)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Wed, 25 May 2022 14:45:01 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 126
Message-ID: <t6lfdd$rld$1@dont-email.me>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <2022May24.082305@mips.complang.tuwien.ac.at> <t6ikci$cf2$1@dont-email.me> <2022May24.161734@mips.complang.tuwien.ac.at>
Injection-Date: Wed, 25 May 2022 14:45:01 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="b3e7518e9d0f63ef18d5689996dc520a";
logging-data="28333"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Sz37jDEvRlOhXD9vCLQWHlh7JT+lxcJk="
Cancel-Lock: sha1:TvQGF2/7DvCi70AjVhjNCalBfuw=
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
 by: Torbjorn Lindgren - Wed, 25 May 2022 14:45 UTC

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Torbjorn Lindgren <tl@none.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>Torbjorn Lindgren <tl@none.invalid> writes:
>...
>>No, I don't consider it likely that they had to resort to LN2 cooling,
>>never mind helium
>
>From what I know, most modern CPUs stop working below -120C or so, so
>already LN2 cooling is a balancing act, and LHe would not make sense
>(less enthalpy of vaporization and much higher cost).

It's easy to find a number of XO (extreme overclocking) runs done
using LHe on both older and newer processors (like 9900K, 10900K,
i9-12900K, 3900X) so clearly it's used, even if it's rare compared to
LN2 XO.

From what XO'ers say, I think it's overstating it to say that most
CPUs stop working at -120C or so, some CPU types will run into
unsolvable problem at anywhere from -30 to -120C, while others are
fine even at "full pot" LN2 once you dial in all the required
voltages, IE they'll run even at effectively -195C (and full pot is
soooo much easier to do).

But if a CPU can handle "full LN2 pot" it's very likely it can go at
least a bit colder. I assume nothing will work at "full LHe pot"!, but
clearly it can get colder enough to be worthwhile in some cases.

It's certainly true that it's going to be a lot more expensive and
complicated than LN2 overclocking but... I hope no one is going to
argue AMD couldn't do it if they wanted and spent the required time!

So I used it as the hypotetical "extreme upper bound". As mentioned
elsewhere I didn't expect them to even use LN2 and in the end they
ended close to (but above) my "lower bound".

>I remember that on one benchmark (on IIRC the Alder Lake review on
>anandtech) DDR5 beat DDR4 by a lot due to having double the number of
>channels with the same number of sticks, but for most applications the
>CPU performance difference of different RAM configurations is
>relatively minor.

I'm not sure it's correct to say DDR5 doubles the channel count, the
briefs I've read all say that DDR5 has two independent subchannels.
Which is close but not quite the same. Example brief [1].

IE a DDR4 stick has a 64/72-bit channel and a full burst is 8 blocks
for a total of 64 byte. A DDR5 stick has two sub-channels of 32/40-bit
and a full transfer is 16 blocks so the full burst is actually kept
the same size, 64 byte.

Thanks to the higher transfer speed the longer burst doesn't hurt DDR5
that much, and this arrangement gain "concurrency" which is important
with todays higher core counts and advanced OoO cores.

There's a number of other concurrency improvements in DDR5 too, they
tend to have twice as many banks in total compared to a similar sized
DD4 chip which helps with this. Example
Micron 16Gb DDR4/5: bank groups/banks per bank group (total banks).
DDR4: x8: 4/4 (16) x16: 2/4 (8) [2]
DDR5: x8: 8/4 (32) x16: 4/4 (16) [3]

Interestingly the Micron DDR5 "core" data sheet actually list these
for 8/16/24/32/48/64 Gb chips despite AFAIK only the 16Gb being
available right now (from all manufacturer). That may mean they do
plan to launch 8Gb DDR5 chips at some point. Or not, it might just be
included in case.

But the bank increase does mean that DDR5 x16 based DIMMs should be
less dire than DDR4 x16 ones. There's very little testing of 2x8GB
DDR5, the best I've found was some bandwidth test by MSI [4].

My reading of the 12900K 2x8GB DDR4 vs 2x8GB DDR5 graph is that
they're surprisingly close. And then the 2x8GB DDR5 to 2x16GB DDR5
graphs confirms this with significant uplifts for the 2x16GB kit, even
laterncy goes down, despite both having only 1 Rank.

So yeah, I think this suggest 2x8GB DDR5 with 16Gb x16 memory leaves
quite a bit of performance on the table. And while mostly matching
DDR4 might have been fine when there's near price parity, it's harder
to argue when DDR5 cost a lot more.

And as I expected DDR4 comes away with the latency crown, even though
Intel 12th gen's DDR4 controller tends to have higher latency than
10/11th gen (which we do see in an earlier graph doing that
comparison).

I expect all of this to change over time, the same happened with DDR3
and DDR2, it tends to take a little while for the full potential of a
new standard to be unlocked.

I also do agree that the performance difference for many tasks aren't
that big. There's some tasks that absolutely benefit from the
bandwidth provided by a 2x16 or 2x32GB DDR5, and then it may be
important to know that 2x8GB "16Gb x16" DDR5 configuration *may*
behave more like DDR4 benchmarks than DDR5 benchmarks for those tasks.

>>On the positive side the Zen4 core dies and IO die both use different
>>fab processes (TSCM 5nm and 6nm respectively) so they're not in direct
>>competition in the fab! at least but I expect most processing after
>>that uses the same factories.
>
>Is that really positive? They have to estimate the demand for their
>various products far in advance. The might have estimated that AM5
>demand will be much higher than it turns out to be thanks to DDR5
>prices, and then they have capacity that they don't need (well maybe
>do an Xbox SoC shrink early or something).

I should have said *possibly* positive or negative.

As I mentioned I've seen multiple claim that DDR5 pricing to OEMs
(Dell/HP) and SA's aren't that different from DDR4, it's mainly in the
retail space there's massive differences (this is US based reports).
And OEM+SA is AFAIK a much larger market than retail so if that stays
the case it might help AMD's demand. But DDR5 prices could also go up,
or down.

So, yeah, could definitely go either way.

1. https://media-www.micron.com/-/media/client/global/documents/products/technical-marketing-brief/ddr5_key_module_features_tech_brief.pdf
2. https://www.micron.com/-/media/client/global/documents/products/data-sheet/dram/ddr4/16gb_ddr4_sdram.pdf
3. https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/dram/ddr5/ddr5_sdram_core.pdf
4. https://www.msi.com/blog/a-closer-look-at-ddr5-benchmarks-with-intels-Alder-lake-cpus

Re: Ryzen 7000 Described, but not detailed

<JlrjK.56338$5fVf.20964@fx09.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25484&group=comp.arch#25484

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx09.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <t6gkmj$92i$1@dont-email.me> <2022May24.082305@mips.complang.tuwien.ac.at> <t6ikci$cf2$1@dont-email.me> <ky7jK.6426$vFlb.149@fx34.iad> <f7281b82-9f73-4dea-889e-5fb1394f7c23n@googlegroups.com>
In-Reply-To: <f7281b82-9f73-4dea-889e-5fb1394f7c23n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 120
Message-ID: <JlrjK.56338$5fVf.20964@fx09.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Wed, 25 May 2022 14:49:13 UTC
Date: Wed, 25 May 2022 10:48:40 -0400
X-Received-Bytes: 6622
 by: EricP - Wed, 25 May 2022 14:48 UTC

Michael S wrote:
> On Tuesday, May 24, 2022 at 7:17:26 PM UTC+3, EricP wrote:
>> Torbjorn Lindgren wrote:
>>> To elaborate a bit more:
>>>
>>> Due to there not being any 8Gb DDR5 memory chips any 8GB DDR5 memory
>>> stick will be built using four 16Gb x16 chips (4*16Gb=8GB, 4x16 gives
>>> 64 data bits) and when the memory chips are set up for x16 they have
>>> significantly less concurrancy than when set up as x8 chips (less
>>> groups and planes).
>>>
>>> Don't ask me why that is, I just read data-sheets and read/watch
>>> benchmark results :-)
>>>
>>> Various new features in DDR5 likely lessen the impact of less
>>> concurrency compared to DDR4 but it's still very noticeable in testing
>>> I've seen.
>>>
>>> A 16GB DDR5 stick OTOH is (so far) built using eight 16Gb x8 chips
>>> (8*16Gb=16GB, 8x8 gives 64 databts) and as mentioned x8 (and x4) chips
>>> doesn't have this issue.
>>>
>>>
>>> The reason this usually isn't a problem for DDR4 is that there's still
>>> 4Gb and 8Gb chips in active production so it's trivial to build
>>> smaller memory sticks using eight x8 chips (down to 4GB).
>>>
>>> We still see a few of these four x16 chip configurations on very cheap
>>> DDR4 SO-DIMMs now and then and the result tends to be BAD, the impact
>>> is actually much worse on DDR4.
>> How many rows can each of these chips have open at once?
>> The internal configuration of the DRAMs would seem to be important.
>> I looked at some DDR4 chip specs and I couldn't see an explicit statement.
>>
>> A picture showed a, say, 4 Gb chip having 4 groups, each group has 8 banks,
>> each bank has its own set of row address latches, row decode, sense amps,
>> and each row has 4096 column data latches. And each bank has 32768 rows.
>
> 4096 column are atypical. More typically, DDR4 devices have 1024 columns.
> I am not even sure if 4096 columns allowed by JPEG standards.

All such discrepancies with reality are entirely due
to me misreading or misremembering the DRAM specs.

I was mostly trying to get an approximate idea of what kinds of
things a DRAM memory controller has to deal with, in an arm-wavy way.

> 32K rows per bank mostly appear in older and smaller chips. Bigger devices,
> esp, those with 4-bit data bus can have up to 256K rows per bank.
>
>> So it looked like this chip could have 32 rows (banks) open at once.
>
> DDR4 devices with 32 banks are rare. Most typically, DDR4 device has 4 bank groups of 4 banks each
> for 16 banks total.
>
>> For a 4 GB DIMM, it can use *1 (1 bit wide), *4 or *8 bit chips.
>
> JEDEC standard defines x4, x8 and x16 DDR4 chips. x1 does not exits.

Yeah... my bad. The spec says 1 Gig x 16 but I remembered it as 1 x 16 Gb.

> x4 used almost exclusively for high-capacity server DIMMs, typically buffered/registered.
> Unbuffered x4 would be problematic due to high capacitive load on address/control signals.
>
> x16 is used in el-cheapo PC DIMMs and in embedded devices.
>
> DIMMs used in good PCs are almost exclusively made out of x8 DDR devices.
>
>> The DIMM has 16 chips, 8 per side.
>> If it uses *1's then all 16 chips must have the same 32 rows open,
>> and each chip supplies 1 bit per clock edge from 4096 column addresses.
>> If it uses *4's then it looked like I can get 4*32=128 rows open at once,
>> but each row supplies 4 bits per edge, from 1024 column addresses.
>> For *8's it is 256 rows, 8 bits per edge, from 512 columns addresses
>>
>> There was also how many beats or bunches-of-bits are read per column access.
>> It looked like that could scale from 2, 4 or 8 bits (1, 2 or 4 clocks).
>>
>> So the memory controller has to scale from managing 32 to 256 open rows.
>> And control how many bits are read per beat per column address.
>>
>> Does that all sound about right?
>
> Most typical PC DDR4 configuration has up to 64 simultaneously open banks per DIMM channel
> (16 banks x 4 ranks) and 2 DIMM channels.
> In server you have more channels, but also more controllers.
> Sometimes in server you have more than 4 ranks, but AFAIK in DDR4 it costs you reduces data rate.

One of the reasons I was looking at this has to do with ECC memory,
and specifically on how the main memory error scavenger works.
Currently the error scavenger resides in the memory controller and does a
sequential sweep over all of memory looking for errors and reporting them,
and repairing single bits errors before they become double bit.

Errors are reported to the cpu which logs them every so often.
OS's may use such logs to take bad pages off-line.

That configuration worked ok when main memory was relatively small
by todays standards, but because the scavenger scan is sequential
it has not scaled well as memory size has grown. It can now take
days to do each sweep and that is only going to get worse.

I was wondering if there was a way to allow each DRAM chip or DIMM
to scavenge itself in parallel. The scavenger scan and SECDED
logic could either be incorporated into the DRAM chip itself,
kind of like self-refresh, or else into an on-DIMM controller.

The ideal location for scavenging is on the DRAM chip itself,
and changing the widths to *9 or *18. But DRAM processes don't
like logic so this might not fly.

Next best would be an on-DIMM controller so at least each DIMM
can scavenge in parallel. But that looked like it might require
moving some of the memory controller logic, such as open row tracking,
into an on-DIMM controller.

And of course all of this implies interface changes
to the chips and/or DIMMs.

Re: Ryzen 7000 Described, but not detailed

<2022May25.195605@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25485&group=comp.arch#25485

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Wed, 25 May 2022 17:56:05 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 51
Message-ID: <2022May25.195605@mips.complang.tuwien.ac.at>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <t6gkmj$92i$1@dont-email.me> <2022May24.082305@mips.complang.tuwien.ac.at> <t6ikci$cf2$1@dont-email.me> <ky7jK.6426$vFlb.149@fx34.iad> <f7281b82-9f73-4dea-889e-5fb1394f7c23n@googlegroups.com> <JlrjK.56338$5fVf.20964@fx09.iad>
Injection-Info: reader02.eternal-september.org; posting-host="f80a06ed755d02b2287695ac37136878";
logging-data="6352"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/uVYQyEDCSjfqAisXjIrBa"
Cancel-Lock: sha1:RYkiw7gH6gtpQe5M6BcgopZI8hw=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Wed, 25 May 2022 17:56 UTC

EricP <ThatWouldBeTelling@thevillage.com> writes:
>One of the reasons I was looking at this has to do with ECC memory,
>and specifically on how the main memory error scavenger works.

Do you mean scrubbing?

>Currently the error scavenger resides in the memory controller and does a
>sequential sweep over all of memory looking for errors and reporting them,
>and repairing single bits errors before they become double bit.
>
>Errors are reported to the cpu which logs them every so often.
>OS's may use such logs to take bad pages off-line.
>
>That configuration worked ok when main memory was relatively small
>by todays standards, but because the scavenger scan is sequential
>it has not scaled well as memory size has grown. It can now take
>days to do each sweep and that is only going to get worse.

DDR5-4800 has ~38GB/s bandwidth per 64-bit superchannel. If you have
4096GB of memory to scrub with 8 superchannels, and you invest 1% of
the bandwidth (0.38GB/s per superchannel), it takes
4096GB/8/0.38(GB/s)=1347s, i.e. less than half an hour. If it takes
longer, it's because somebody decided to spend less bandwidth on it.

>I was wondering if there was a way to allow each DRAM chip

A DRAM chip does not have the ECC information in DDR4, it's on a
separate chip. DDR5 has something called on-die ECC, but apparently
that is not real ECC (I have not seen any information that explains it
and that looked trustworthy).

>or DIMM
>to scavenge itself in parallel.

At the DIMM level it would be possible, but it would require an
additional memory controller that talks to all chips on the DIMM
(extra cost and extra load on the lines). And you save only a factor
of two (with one such scrubber per DIMM) or four (with one scrubber
per DIMM side).

>Next best would be an on-DIMM controller so at least each DIMM
>can scavenge in parallel. But that looked like it might require
>moving some of the memory controller logic, such as open row tracking,
>into an on-DIMM controller.

Yes, and it would have to coordinate with the CPU's DRAM controller.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Ryzen 7000 Described, but not detailed

<06719e14-fb32-4a85-9001-b3d57b4ac9dbn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25486&group=comp.arch#25486

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:258e:b0:680:f33c:dbcd with SMTP id x14-20020a05620a258e00b00680f33cdbcdmr24730972qko.542.1653553475141;
Thu, 26 May 2022 01:24:35 -0700 (PDT)
X-Received: by 2002:ad4:5d49:0:b0:461:f201:857a with SMTP id
jk9-20020ad45d49000000b00461f201857amr29363189qvb.36.1653553474963; Thu, 26
May 2022 01:24:34 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 26 May 2022 01:24:34 -0700 (PDT)
In-Reply-To: <t6l7ne$20v$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:d29:c821:85ef:6e45;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:d29:c821:85ef:6e45
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
<t6gkmj$92i$1@dont-email.me> <2022May24.082305@mips.complang.tuwien.ac.at>
<t6ikci$cf2$1@dont-email.me> <t6l7ne$20v$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <06719e14-fb32-4a85-9001-b3d57b4ac9dbn@googlegroups.com>
Subject: Re: Ryzen 7000 Described, but not detailed
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Thu, 26 May 2022 08:24:35 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2740
 by: Quadibloc - Thu, 26 May 2022 08:24 UTC

On Wednesday, May 25, 2022 at 6:33:53 AM UTC-6, Torbjorn Lindgren wrote:

> And we now know it was pretty close to the low-bar, AMD's Direct of
> Technical Marketing Robert Hallock later disclosed in a PCWorld stream
> that the 5.5GHz peak was done without overclocking using a reference
> AM5 motherboard and a "consumer-based" Asetek 280mm - which build MOST
> PC AIO's thanks to various patents on placing the pump on top of the
> CPU (hence some model instead placing the pump in the radiator).
>
> So more substantial cooling than I expect most people have on their
> 5950X (I'm guessing 240mm or big-air) but not chilled water (Intel 28
> core 5GHz demo anyone) or anything crazy and it's a setup that should
> be easy to match using consumer parts.

Given that people have achieved over 6 GHz with previous generations of
Ryzen parts, if the 5.5 GHz had been achieved with liquid nitrogen, I think
the Securities and Exchange Commission would be having a word with
Lisa Su.

Chilled water, like in an IBM mainframe, indeed counts as "something
crazy", but water cooling using a fan and radiator on the water outside
the case is what AMD _recommended_ for their 16-core chips, both the
5950 and its predecessor the 3950. (In fact, it was also recommended
for the 5900 and other members of that series.)

So one can't fault them for using the standard, recommended cooling
solution for their chip!

John Savard

Re: Ryzen 7000 Described, but not detailed

<r2OjK.32433$3Gzd.17515@fx96.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25487&group=comp.arch#25487

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder.usenetexpress.com!tr2.eu1.usenetexpress.com!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx96.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <t6gkmj$92i$1@dont-email.me> <2022May24.082305@mips.complang.tuwien.ac.at> <t6ikci$cf2$1@dont-email.me> <ky7jK.6426$vFlb.149@fx34.iad> <f7281b82-9f73-4dea-889e-5fb1394f7c23n@googlegroups.com> <JlrjK.56338$5fVf.20964@fx09.iad> <2022May25.195605@mips.complang.tuwien.ac.at>
In-Reply-To: <2022May25.195605@mips.complang.tuwien.ac.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 75
Message-ID: <r2OjK.32433$3Gzd.17515@fx96.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Thu, 26 May 2022 16:38:47 UTC
Date: Thu, 26 May 2022 12:38:21 -0400
X-Received-Bytes: 4264
 by: EricP - Thu, 26 May 2022 16:38 UTC

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> One of the reasons I was looking at this has to do with ECC memory,
>> and specifically on how the main memory error scavenger works.
>
> Do you mean scrubbing?

Yes

>> Currently the error scavenger resides in the memory controller and does a
>> sequential sweep over all of memory looking for errors and reporting them,
>> and repairing single bits errors before they become double bit.
>>
>> Errors are reported to the cpu which logs them every so often.
>> OS's may use such logs to take bad pages off-line.
>>
>> That configuration worked ok when main memory was relatively small
>> by todays standards, but because the scavenger scan is sequential
>> it has not scaled well as memory size has grown. It can now take
>> days to do each sweep and that is only going to get worse.
>
> DDR5-4800 has ~38GB/s bandwidth per 64-bit superchannel. If you have
> 4096GB of memory to scrub with 8 superchannels, and you invest 1% of
> the bandwidth (0.38GB/s per superchannel), it takes
> 4096GB/8/0.38(GB/s)=1347s, i.e. less than half an hour. If it takes
> longer, it's because somebody decided to spend less bandwidth on it.

The number I had from 2010 came from Intel's recommendation
for one of its memory controller hubs and was 1.5 hours/GB.
DRAMs haven't gotten faster since then, just bigger.

>> I was wondering if there was a way to allow each DRAM chip
>
> A DRAM chip does not have the ECC information in DDR4, it's on a
> separate chip. DDR5 has something called on-die ECC, but apparently
> that is not real ECC (I have not seen any information that explains it
> and that looked trustworthy).

I know. I'm exploring new, different configurations.

For example, if the DRAM internal row was a multiple of 72 then
an internal scrubber could read a row and chew away on it over
multiple cycles, ideally without interfering with normal operations.
A 72 bit value could be read/written over a *18 interface in
2 clocks (4 edges).

Reading a 64 byte cache line could then have 8 chips on one side
of the DIMM open to the same 32 rows, with reads staggered across
the chips so the whole cache line is read in a 16 clocks burst.

>> or DIMM
>> to scavenge itself in parallel.
>
> At the DIMM level it would be possible, but it would require an
> additional memory controller that talks to all chips on the DIMM
> (extra cost and extra load on the lines). And you save only a factor
> of two (with one such scrubber per DIMM) or four (with one scrubber
> per DIMM side).

With a scrubber per DIMM or per side it allows each scrub itself
in parallel with all other DIMMs. But it still has to transfer
all the data off each chip to the local controller for checking.

If each chip did its own scrubbing in the background that
transfer bottleneck is avoided.

>> Next best would be an on-DIMM controller so at least each DIMM
>> can scavenge in parallel. But that looked like it might require
>> moving some of the memory controller logic, such as open row tracking,
>> into an on-DIMM controller.
>
> Yes, and it would have to coordinate with the CPU's DRAM controller.
>
> - anton

Re: Ryzen 7000 Described, but not detailed

<2022May26.190052@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25490&group=comp.arch#25490

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Thu, 26 May 2022 17:00:52 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 54
Message-ID: <2022May26.190052@mips.complang.tuwien.ac.at>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <t6gkmj$92i$1@dont-email.me> <2022May24.082305@mips.complang.tuwien.ac.at> <t6ikci$cf2$1@dont-email.me> <ky7jK.6426$vFlb.149@fx34.iad> <f7281b82-9f73-4dea-889e-5fb1394f7c23n@googlegroups.com> <JlrjK.56338$5fVf.20964@fx09.iad> <2022May25.195605@mips.complang.tuwien.ac.at> <r2OjK.32433$3Gzd.17515@fx96.iad>
Injection-Info: reader02.eternal-september.org; posting-host="aa851ce9bdb8ec799e3855bf657f3d3d";
logging-data="12024"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+fI/1aQMqiXYKttJmDYqcI"
Cancel-Lock: sha1:ftMsCQJPWkmeQTRL1kOKLiZnUcY=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Thu, 26 May 2022 17:00 UTC

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Anton Ertl wrote:
>> DDR5-4800 has ~38GB/s bandwidth per 64-bit superchannel. If you have
>> 4096GB of memory to scrub with 8 superchannels, and you invest 1% of
>> the bandwidth (0.38GB/s per superchannel), it takes
>> 4096GB/8/0.38(GB/s)=1347s, i.e. less than half an hour. If it takes
>> longer, it's because somebody decided to spend less bandwidth on it.
>
>The number I had from 2010 came from Intel's recommendation
>for one of its memory controller hubs and was 1.5 hours/GB.
>DRAMs haven't gotten faster since then, just bigger.

DRAM bandwidth has gotten much bigger. 2010 would be DDR3 memory.
But even DDR3 memory supports mempory bandwidths that support much
higher scrubbing rates even if you use only 1% of the bandwidth. If
Intel scrubbed this slowly by default, it's because they felt that
there is no need for faster scrubbing.

>> A DRAM chip does not have the ECC information in DDR4, it's on a
>> separate chip. DDR5 has something called on-die ECC, but apparently
>> that is not real ECC (I have not seen any information that explains it
>> and that looked trustworthy).
>
>I know. I'm exploring new, different configurations.
>
>For example, if the DRAM internal row was a multiple of 72 then
>an internal scrubber could read a row and chew away on it over
>multiple cycles, ideally without interfering with normal operations.

From the things I have read about DDR5's on-die ECC, it really does
per-die ECC, and fixes errors on the die, but does not send any ECC
information outside.

My guess is that they correct a whole row (minimizing the additional
bits necessary, e.g., 14 extra bits for SECDED of an 8Kb row); it's
possible that it's too expensive to compute ECC for an 8K+14bit row,
and in that case they may choose to use more extra bits and a cheaper
ECC function.

My other guess is that they do the SECDED on every refresh. That
mechanism is already in place, the refreshes occur anyway, and given
that the reason for on-die ECC is flaky RAM cells, it makes little
sense to do a refresh without correcting errors. The stated benefit
of on-die ECC is that this counteracts the tendency of RAM to become
less reliable as processes shrink.

But DDR5 also has ECC DIMMs that have 40 bits per sub-channel, which
allows end-to-end ECC checking. And I guess you run a scrubber on
that, too.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor