Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Loose bits sink chips.


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
Re: Ryzen 7000 Described, but not detailed

<aaf937e0-a4a7-469d-8446-65f3ad8de7b4n@googlegroups.com>

  copy mid

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

  copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:c26:b0:464:3fdd:a3e6 with SMTP id a6-20020a0562140c2600b004643fdda3e6mr10585554qvd.113.1653953678834;
Mon, 30 May 2022 16:34:38 -0700 (PDT)
X-Received: by 2002:a0c:ec87:0:b0:464:5b0f:f77a with SMTP id
u7-20020a0cec87000000b004645b0ff77amr3006657qvo.63.1653953678648; Mon, 30 May
2022 16:34:38 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.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, 30 May 2022 16:34:38 -0700 (PDT)
In-Reply-To: <a445527c-0d0b-461b-b35d-355346114505n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:75a4:df09:3829:736a;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:75a4:df09:3829:736a
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
<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>
<2022May26.190052@mips.complang.tuwien.ac.at> <9ad73d53-e73b-45d3-8df0-b7c67f279c7dn@googlegroups.com>
<2022May27.082753@mips.complang.tuwien.ac.at> <f3958e4e-1418-4f20-b7f3-f21ef4c09563n@googlegroups.com>
<2022May27.135524@mips.complang.tuwien.ac.at> <01e9bd68-da4d-4c15-9854-868ad42bf4c8n@googlegroups.com>
<t6qvv3$usi$1@dont-email.me> <9d7a3c6f-7b51-4a68-948c-37143f34c23cn@googlegroups.com>
<t7310v$g3m$1@dont-email.me> <a445527c-0d0b-461b-b35d-355346114505n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <aaf937e0-a4a7-469d-8446-65f3ad8de7b4n@googlegroups.com>
Subject: Re: Ryzen 7000 Described, but not detailed
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 30 May 2022 23:34:38 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Mon, 30 May 2022 23:34 UTC

On Monday, May 30, 2022 at 2:26:35 PM UTC-5, Michael S wrote:
> On Monday, May 30, 2022 at 9:05:22 PM UTC+3, Stephen Fuld wrote:
> > On 5/27/2022 1:54 PM, MitchAlsup wrote:
> > > On Friday, May 27, 2022 at 11:58:14 AM UTC-5, Stephen Fuld wrote:
> > >> On 5/27/2022 9:11 AM, Michael S wrote:
> > >>> On Friday, May 27, 2022 at 3:15:03 PM UTC+3, Anton Ertl wrote:
> > >>>> Michael S <already...@yahoo.com> writes:
> > >>>>> On Friday, May 27, 2022 at 10:53:05 AM UTC+3, Anton Ertl wrote:
> > >>>>>> In the long run, the (sub)channels are going to become narrower,=20
> > >>>>>
> > >>>>> You still assume that we are ahead of long run [of Moore law].
> > >>>>> I am less optimistic. I seems plausible that provisions for 64gb devices
> > >>>>> that is already in DDR5 will suffice for more than decade.
> > >>>>> May be, close to 2 decades.
> > >>>> Newer DDR standards are not primarily about chip capacity (currently
> > >>>> the largest DDR5 chips are not larger than supported by DDR4: 16Gb),
> > >>>> but about transfer rate. I.e., if the transfer rate becomes faster
> > >>>> than 16x the internal cycle time of DRAM, they have to increase the
> > >>>> minimum burst length (and decrease the (sub)channel width) to benefit
> > >>>> from that increase. And currently I see no sign that the transfer
> > >>>> rate increases are slowing down. DDR4 was released 7 years after
> > >>>> DDR3; DDR5 was released 6 years after DDR4. On the PCIe front, the
> > >>>> release cadence seems to be even higher.
> > >>>> - anton
> > >>>> --
> > >>>> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > >>>> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
> > >>>
> > >>> I can not formulate it with sufficient rigor, but my opinion is that need
> > >>> in new DDR standards is very much a function of non-stability (hopefully growth)
> > >>> of the market in term of average capacity.
> > > <
> > >> I disagree. If it were true, then newer generations of the standard
> > >> would be much simpler; just add an address bit or two. The fact that
> > >> each standard provides a substantial increase in data rate/bandwidth
> > >> over the previous one, which is harder than adding an address pin, says
> > >> that data rate/bandwidth is the driving factor, and capacity comes in
> > >> second. Unfortunately, latency has proven resistant to substantial
> > >> improvements :-(
> > > <
> > > DRAM chips have rather constant area. Passing over a linear amount of
> > > real-estate is a wire delay problem. So that transistors are getting faster
> > > and wire is getting slower has finally become manifest in DRAM. {actually
> > > DRAM bank access to pin drivers has stayed rather constant since DDR2.}
> > While all of that is true, I think it is only a part of the reason for
> > the long latency. Consider a hypothetical chip of the same physical
> > size as a current DRAM, but instead uses SRAM. Of course, it will have
> > smaller capacity and perhaps require more pins than the DRAM, but I
> > expect it will have lower latency. Is that correct?
> >
> > I think that the original DRAM designers made the (IMO correct) tradeoff
> > to gain lower cost (fewer pins), at the cost of higher latency. This
> > was reinforced by the introduction of CPU caches, which are essentially
> > average latency reducers, hiding much of the longer latency. These
> > allowed DRAMS to successfully dominate the market.
> >
> > However, cache is a diminishing returns game. Adding more improves
> > performance, but not as much as the last time you increased it. So it
> > may be true that reducing DRAM latency may become more important.
> >
> > So what could be done? A lower overhead (fewer transfers) protocol
> > coupled with a different internal design and more pins (i.e. higher
> > cost) might be achievable. It is way out of my area of expertise, but I
> > just want to stimulate thoughts on this.
> >
> > Of course, the marketability of such a design, even if achievable, is a
> > different question. :-(
> > --
> > - Stephen Fuld
> > (e-mail address disguised to prevent spam)
> What you described exists:
> https://www.micron.com/products/dram/rldram-memory
> It is very very very niche, but its existence proves that it is not absolutely non-marketable.
<
This data sheet reminds me a lot of the Psuedostatic DRAM from around 1991.
{Which I used as/for the DRAM timing parameters of Mc 88120 design simulation.}

Re: Ryzen 7000 Described, but not detailed

<t73ncg$9sm$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ggt...@yahoo.com (Brett)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Tue, 31 May 2022 00:26:57 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 117
Message-ID: <t73ncg$9sm$1@dont-email.me>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
<2022May27.135524@mips.complang.tuwien.ac.at>
<01e9bd68-da4d-4c15-9854-868ad42bf4c8n@googlegroups.com>
<2022May27.200114@mips.complang.tuwien.ac.at>
<67b0eb94-163c-4206-b39c-05d09e9552d6n@googlegroups.com>
<2022May29.111409@mips.complang.tuwien.ac.at>
<f90895a5-f4c2-4236-a114-d391075f72b4n@googlegroups.com>
<2022May29.173049@mips.complang.tuwien.ac.at>
<12bfecfc-d427-4612-bf11-1d80048ceaadn@googlegroups.com>
<2022May30.150007@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 31 May 2022 00:26:57 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="ac8ca10f5662ec6ef95ea68bfd3e995e";
logging-data="10134"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+AVLjQyiVG45O8E0ehIYlr"
User-Agent: NewsTap/5.5 (iPad)
Cancel-Lock: sha1:1sNMvCR86xBBZ6OepL1aUjl//fQ=
sha1:QHIYxC5kgwXTMk5SFwTSCCcoPuI=
 by: Brett - Tue, 31 May 2022 00:26 UTC

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> On Sunday, May 29, 2022 at 7:06:16 PM UTC+3, Anton Ertl wrote:
>>> Michael S <already...@yahoo.com> writes:
>>>> On Sunday, May 29, 2022 at 1:14:20 PM UTC+3, Anton Ertl wrote:
>>>>> Looking at the "RAM type" category in <https://geizhals.eu/?cat=nb>:
>>>>>
>>>>> models
>>>>> 5235 DDR4
>>>>> 1578 LPDDR4
>>>>> 154 DDR5
>>>>> 255 LPDDR5
>>>>>
>>>>> So there are certainly many more models with DDR4/5 than with LPDDR4,
>>>>> and this probably also means more sales.
>>>>>
>>>>
>>>> I'm not sure that it follows.
>>>> Simple models like Dell Latitude 3320 probably outsel more advanced
>>>> models by significant factor.
>>> Maybe. And maybe even cheaper models like, say, the ASUS Business P1
>>> P1511CEA-BQ749 (offered by 81 dealers vs. 57 for the most-offered Dell
>>> Latitude 3320 variant)
>>
>> Or. may be, even lower end ASUS VivoBook E12
>
> Unlikely at the moment, because none are offered. Looking at one
> model, I see that it was last offered in February 2019.
>
>> At very least, we know that according to Gartner estimates Dell PC division
>> as a whole outsells ASUS PC division as whole, 2.5 to 1. So, fewer dealers,
>> but more PCs sold by each dealer.
>> Also, I would think that [at retail] ASUS has many more models than Dell.
>
> ASUS Dell
> 662 468 <https://geizhals.eu/?cat=nb> (Laptops).
> 61 227 <https://geizhals.eu/?cat=sysdiv> (Systems)
>
>> By the way, I don't know how it works in your country, but here Latitude is not
>> seen in shops at all. Only Inspiron , Vostro and occasional Alienware.
>> But at work Latitude is everywhere.
>
> I don't know how it works in my country, and I don't go to shops
> looking what brands of laptops they have, but I don't see that many
> Dells overall when I see other people's laptops. For those that I
> see, I have no idea what models they are. There's a central
> laptop/tablet ordering system two times per year from the University
> of Vienna that my university participates in, and I guess that many
> people buy laptops through this system; the most recent one was
> <https://ubook.at/fileadmin/content/broschueren/ubook_sose2022.pdf>.
> The only Dell Latitude there cost EUR 2239, and I doubt that many
> people bought it.
>
> Anyway, if we assume that Dell sells particularly many laptops, and
> that we need to study them separately, there the RAM type statistics
> is:
>
> models
> 362 DDR4
> 57 LPDDR4
> 17 DDR5
> 4 LPDDR5
>
> So for Dell laptops the balance is even less in favour of LPDDR4. Do
> people all buy these 57 LPDDR4 models, and Dell offers the other
> models just for fun?
>
>>>>> [CXL]
>>>>>> But my point is that people that build this boxen don't need new memory standard
>>>>>> every 5-7 years. Esp. when capacity does not go up. Even with DDR4 they likely
>>>>>> have internal bandwidth that easily exceeds bandwidth of their external COMM
>>>>>> channels, because there is no other way to get required capacity.
>>>>>> So, if they need DDR5 then only because of promised extra capacity.
>>>>> A pure memory box with bandwidth that cannot even compete with DDR4 in
>>>>> bandwidth (and certainly not latency) does not look to me like something
>>>>> that many people would buy. I doubt that we will see such products.
>>>>
>>>> Who says it does not compete with DDR4 in bandwidth?
>>> You do: "Even with DDR4 they likely have internal bandwidth that
>>> easily exceeds bandwidth of their external COMM channels".
>>>
>>
>> Hopefully, now you paid attention to qualifiers "internal and "external".
>>
>>> As for the rest: A box with more memory than supported by LRDIMMs on,
>>> e.g., EPYC boards will probably find a market, but I doubt that it
>>> will replace LRDIMMs.
>>
>> It does not have to replace LR-DIMM in order to make DDR6 unnecessary or,
>> at least, to delay its introduction.
>
> Like DDR5, DDR6 will probably be about bandwidth, not capacity. The
> fact that the largest DDR5 UDIMMs and RDIMMs at the moment are not
> bigger than the largest DDR4 UDIMMs and RDIMMs, respectively, shows
> that DDR5 is not about capacity (no DDR5 LRDIMMs yet, probably for
> lack of corresponding servers).
>
> If they can improve signaling speed enough that DDR5 is insufficient,
> there will be DDR6, offering improved bandwidth. It will be there for
> those who use UDIMMs, those who use RDIMMs, and those who use LRDIMMs.
> And the box you have in mind will have to compete with that.

DRAM stopped scaling a decade ago, RAM will move onto the CPU by the time
DDR6 is out. On CPU RAM will give 10x the RAM bandwidth or more. Look at
the Apple M1 for the future.

>> I rather see it as an opposite - LR-DIMM are in the same boat with those future
>> external boxes. Both serve to extend the usefulness of given generation of
>> DDRn, helping to reduce the necessity of the next generation.
>
> LRDIMMs increase the capacity, but not the bandwidth. But bandwidth
> is the main reason for the next DDR generation.
>
> - anton

Re: Ryzen 7000 Described, but not detailed

<2f62c424-8ef1-4f70-8056-32f3b468748dn@googlegroups.com>

  copy mid

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

  copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:22c1:b0:6a3:9974:fd12 with SMTP id o1-20020a05620a22c100b006a39974fd12mr28415255qki.93.1653957559274;
Mon, 30 May 2022 17:39:19 -0700 (PDT)
X-Received: by 2002:a05:620a:31a2:b0:6a3:d592:e9a6 with SMTP id
bi34-20020a05620a31a200b006a3d592e9a6mr25980530qkb.236.1653957559076; Mon, 30
May 2022 17:39:19 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!peer02.ams4!peer.am4.highwinds-media.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, 30 May 2022 17:39:18 -0700 (PDT)
In-Reply-To: <t73ncg$9sm$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:75a4:df09:3829:736a;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:75a4:df09:3829:736a
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
<2022May27.135524@mips.complang.tuwien.ac.at> <01e9bd68-da4d-4c15-9854-868ad42bf4c8n@googlegroups.com>
<2022May27.200114@mips.complang.tuwien.ac.at> <67b0eb94-163c-4206-b39c-05d09e9552d6n@googlegroups.com>
<2022May29.111409@mips.complang.tuwien.ac.at> <f90895a5-f4c2-4236-a114-d391075f72b4n@googlegroups.com>
<2022May29.173049@mips.complang.tuwien.ac.at> <12bfecfc-d427-4612-bf11-1d80048ceaadn@googlegroups.com>
<2022May30.150007@mips.complang.tuwien.ac.at> <t73ncg$9sm$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2f62c424-8ef1-4f70-8056-32f3b468748dn@googlegroups.com>
Subject: Re: Ryzen 7000 Described, but not detailed
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Tue, 31 May 2022 00:39:19 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 7105
 by: MitchAlsup - Tue, 31 May 2022 00:39 UTC

On Monday, May 30, 2022 at 7:27:00 PM UTC-5, gg...@yahoo.com wrote:
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> > Michael S <already...@yahoo.com> writes:
> >> On Sunday, May 29, 2022 at 7:06:16 PM UTC+3, Anton Ertl wrote:
> >>> Michael S <already...@yahoo.com> writes:
> >>>> On Sunday, May 29, 2022 at 1:14:20 PM UTC+3, Anton Ertl wrote:
> >>>>> Looking at the "RAM type" category in <https://geizhals.eu/?cat=nb>:
> >>>>>
> >>>>> models
> >>>>> 5235 DDR4
> >>>>> 1578 LPDDR4
> >>>>> 154 DDR5
> >>>>> 255 LPDDR5
> >>>>>
> >>>>> So there are certainly many more models with DDR4/5 than with LPDDR4,
> >>>>> and this probably also means more sales.
> >>>>>
> >>>>
> >>>> I'm not sure that it follows.
> >>>> Simple models like Dell Latitude 3320 probably outsel more advanced
> >>>> models by significant factor.
> >>> Maybe. And maybe even cheaper models like, say, the ASUS Business P1
> >>> P1511CEA-BQ749 (offered by 81 dealers vs. 57 for the most-offered Dell
> >>> Latitude 3320 variant)
> >>
> >> Or. may be, even lower end ASUS VivoBook E12
> >
> > Unlikely at the moment, because none are offered. Looking at one
> > model, I see that it was last offered in February 2019.
> >
> >> At very least, we know that according to Gartner estimates Dell PC division
> >> as a whole outsells ASUS PC division as whole, 2.5 to 1. So, fewer dealers,
> >> but more PCs sold by each dealer.
> >> Also, I would think that [at retail] ASUS has many more models than Dell.
> >
> > ASUS Dell
> > 662 468 <https://geizhals.eu/?cat=nb> (Laptops).
> > 61 227 <https://geizhals.eu/?cat=sysdiv> (Systems)
> >
> >> By the way, I don't know how it works in your country, but here Latitude is not
> >> seen in shops at all. Only Inspiron , Vostro and occasional Alienware.
> >> But at work Latitude is everywhere.
> >
> > I don't know how it works in my country, and I don't go to shops
> > looking what brands of laptops they have, but I don't see that many
> > Dells overall when I see other people's laptops. For those that I
> > see, I have no idea what models they are. There's a central
> > laptop/tablet ordering system two times per year from the University
> > of Vienna that my university participates in, and I guess that many
> > people buy laptops through this system; the most recent one was
> > <https://ubook.at/fileadmin/content/broschueren/ubook_sose2022.pdf>.
> > The only Dell Latitude there cost EUR 2239, and I doubt that many
> > people bought it.
> >
> > Anyway, if we assume that Dell sells particularly many laptops, and
> > that we need to study them separately, there the RAM type statistics
> > is:
> >
> > models
> > 362 DDR4
> > 57 LPDDR4
> > 17 DDR5
> > 4 LPDDR5
> >
> > So for Dell laptops the balance is even less in favour of LPDDR4. Do
> > people all buy these 57 LPDDR4 models, and Dell offers the other
> > models just for fun?
> >
> >>>>> [CXL]
> >>>>>> But my point is that people that build this boxen don't need new memory standard
> >>>>>> every 5-7 years. Esp. when capacity does not go up. Even with DDR4 they likely
> >>>>>> have internal bandwidth that easily exceeds bandwidth of their external COMM
> >>>>>> channels, because there is no other way to get required capacity.
> >>>>>> So, if they need DDR5 then only because of promised extra capacity.
> >>>>> A pure memory box with bandwidth that cannot even compete with DDR4 in
> >>>>> bandwidth (and certainly not latency) does not look to me like something
> >>>>> that many people would buy. I doubt that we will see such products.
> >>>>
> >>>> Who says it does not compete with DDR4 in bandwidth?
> >>> You do: "Even with DDR4 they likely have internal bandwidth that
> >>> easily exceeds bandwidth of their external COMM channels".
> >>>
> >>
> >> Hopefully, now you paid attention to qualifiers "internal and "external".
> >>
> >>> As for the rest: A box with more memory than supported by LRDIMMs on,
> >>> e.g., EPYC boards will probably find a market, but I doubt that it
> >>> will replace LRDIMMs.
> >>
> >> It does not have to replace LR-DIMM in order to make DDR6 unnecessary or,
> >> at least, to delay its introduction.
> >
> > Like DDR5, DDR6 will probably be about bandwidth, not capacity. The
> > fact that the largest DDR5 UDIMMs and RDIMMs at the moment are not
> > bigger than the largest DDR4 UDIMMs and RDIMMs, respectively, shows
> > that DDR5 is not about capacity (no DDR5 LRDIMMs yet, probably for
> > lack of corresponding servers).
> >
> > If they can improve signaling speed enough that DDR5 is insufficient,
> > there will be DDR6, offering improved bandwidth. It will be there for
> > those who use UDIMMs, those who use RDIMMs, and those who use LRDIMMs.
> > And the box you have in mind will have to compete with that.
<
> DRAM stopped scaling a decade ago, RAM will move onto the CPU by the time
> DDR6 is out. On CPU RAM will give 10x the RAM bandwidth or more. Look at
> the Apple M1 for the future.
<
DRAM stopped latency scaling a decade ago (or a bit more) density scaling
continues.
<
For most design point, (low) latency is more important than (high) Bandwidth
Which is why DDR[k] is out pf phase with desire.

Re: Ryzen 7000 Described, but not detailed

<t74b1v$91i$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Mon, 30 May 2022 23:02:38 -0700
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <t74b1v$91i$1@dont-email.me>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
<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>
<2022May26.190052@mips.complang.tuwien.ac.at>
<9ad73d53-e73b-45d3-8df0-b7c67f279c7dn@googlegroups.com>
<2022May27.082753@mips.complang.tuwien.ac.at>
<f3958e4e-1418-4f20-b7f3-f21ef4c09563n@googlegroups.com>
<2022May27.135524@mips.complang.tuwien.ac.at>
<01e9bd68-da4d-4c15-9854-868ad42bf4c8n@googlegroups.com>
<t6qvv3$usi$1@dont-email.me>
<9d7a3c6f-7b51-4a68-948c-37143f34c23cn@googlegroups.com>
<t7310v$g3m$1@dont-email.me>
<a8bc283e-1547-413e-bf58-ff59bdc01f7fn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 31 May 2022 06:02:40 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="c2082b61c5d675aaeca2c16032dbc87a";
logging-data="9266"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+D5KuWzjKGT5RGWmac2fYgFJqv4Bl9lGQ="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Cancel-Lock: sha1:798o7KJkpuEYH/3JSdlJcB6HIjk=
In-Reply-To: <a8bc283e-1547-413e-bf58-ff59bdc01f7fn@googlegroups.com>
Content-Language: en-US
 by: Stephen Fuld - Tue, 31 May 2022 06:02 UTC

On 5/30/2022 12:02 PM, MitchAlsup wrote:
> On Monday, May 30, 2022 at 1:05:22 PM UTC-5, Stephen Fuld wrote:
>> On 5/27/2022 1:54 PM, MitchAlsup wrote:
>>> On Friday, May 27, 2022 at 11:58:14 AM UTC-5, Stephen Fuld wrote:
>>>> On 5/27/2022 9:11 AM, Michael S wrote:
>>>>> On Friday, May 27, 2022 at 3:15:03 PM UTC+3, Anton Ertl wrote:
>>>>>> Michael S <already...@yahoo.com> writes:
>>>>>>> On Friday, May 27, 2022 at 10:53:05 AM UTC+3, Anton Ertl wrote:
>>>>>>>> In the long run, the (sub)channels are going to become narrower,=20
>>>>>>>
>>>>>>> You still assume that we are ahead of long run [of Moore law].
>>>>>>> I am less optimistic. I seems plausible that provisions for 64gb devices
>>>>>>> that is already in DDR5 will suffice for more than decade.
>>>>>>> May be, close to 2 decades.
>>>>>> Newer DDR standards are not primarily about chip capacity (currently
>>>>>> the largest DDR5 chips are not larger than supported by DDR4: 16Gb),
>>>>>> but about transfer rate. I.e., if the transfer rate becomes faster
>>>>>> than 16x the internal cycle time of DRAM, they have to increase the
>>>>>> minimum burst length (and decrease the (sub)channel width) to benefit
>>>>>> from that increase. And currently I see no sign that the transfer
>>>>>> rate increases are slowing down. DDR4 was released 7 years after
>>>>>> DDR3; DDR5 was released 6 years after DDR4. On the PCIe front, the
>>>>>> release cadence seems to be even higher.
>>>>>> - anton
>>>>>> --
>>>>>> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
>>>>>> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
>>>>>
>>>>> I can not formulate it with sufficient rigor, but my opinion is that need
>>>>> in new DDR standards is very much a function of non-stability (hopefully growth)
>>>>> of the market in term of average capacity.
>>> <
>>>> I disagree. If it were true, then newer generations of the standard
>>>> would be much simpler; just add an address bit or two. The fact that
>>>> each standard provides a substantial increase in data rate/bandwidth
>>>> over the previous one, which is harder than adding an address pin, says
>>>> that data rate/bandwidth is the driving factor, and capacity comes in
>>>> second. Unfortunately, latency has proven resistant to substantial
>>>> improvements :-(
>>> <
>>> DRAM chips have rather constant area. Passing over a linear amount of
>>> real-estate is a wire delay problem. So that transistors are getting faster
>>> and wire is getting slower has finally become manifest in DRAM. {actually
>>> DRAM bank access to pin drivers has stayed rather constant since DDR2.}
> <
>> While all of that is true, I think it is only a part of the reason for
>> the long latency. Consider a hypothetical chip of the same physical
>> size as a current DRAM, but instead uses SRAM. Of course, it will have
>> smaller capacity and perhaps require more pins than the DRAM, but I
>> expect it will have lower latency. Is that correct?
> <
> Back in 1998, I designed a DRAM macro for a logic process. The DRAM
> macro had 4× the density of SRAM and only a few picoseconds longer
> access time (in the era of 250-500 MHz processors (4ns-2ns)). So, I take
> issue that DRAM is inherently slower than SRAM. DRAM implemented in
> a DRAM process (moderate P-channels slow N-channels) would not be
> as fast a DRAM implemented in a logic process.

For a while, IBM used embedded DRAM as an L3 cache in some of their
Power and Z series systems, but I think have abandoned it. It always
seemed like a good idea to me, but I wonder why they stopped using it.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Re: Ryzen 7000 Described, but not detailed

<2022May31.095516@mips.complang.tuwien.ac.at>

  copy mid

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

  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, 31 May 2022 07:55:16 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 23
Message-ID: <2022May31.095516@mips.complang.tuwien.ac.at>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <01e9bd68-da4d-4c15-9854-868ad42bf4c8n@googlegroups.com> <2022May27.200114@mips.complang.tuwien.ac.at> <67b0eb94-163c-4206-b39c-05d09e9552d6n@googlegroups.com> <2022May29.111409@mips.complang.tuwien.ac.at> <f90895a5-f4c2-4236-a114-d391075f72b4n@googlegroups.com> <2022May29.173049@mips.complang.tuwien.ac.at> <12bfecfc-d427-4612-bf11-1d80048ceaadn@googlegroups.com> <2022May30.150007@mips.complang.tuwien.ac.at> <t73ncg$9sm$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="4fa50d026dd10901f8371a367dfcc270";
logging-data="21928"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/LQQ3PWSffhhWjBWWwIg6I"
Cancel-Lock: sha1:25lg7RNY7yjr8B2vZQ+wBD2HLmY=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Tue, 31 May 2022 07:55 UTC

Brett <ggtgp@yahoo.com> writes:
>DRAM stopped scaling a decade ago,

In 2012 we had DDR3 RAM with up to 8GB/UDIMM (with 4Gb chips) and at
most 2133 MT/s. Today we are switching to DDR5 RAM with currently up
to 32GB/UDIMM (with 16Gb chips) and 4800MT/s or more. What do you
mean with "stop scaling"?

>RAM will move onto the CPU by the time
>DDR6 is out.

Unlikely, because logic processes are different from DRAM processes.

>On CPU RAM will give 10x the RAM bandwidth or more. Look at
>the Apple M1 for the future.

The Apple M1 uses regular LPDDR4X memory; M1 Pro, M1 Max, and M1 Ultra
use regular LPDDR5 memory.

- 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

<e4460120-1634-4cec-8541-31289e6e3962n@googlegroups.com>

  copy mid

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

  copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:d0c:b0:45b:3c7:fd68 with SMTP id 12-20020a0562140d0c00b0045b03c7fd68mr49116222qvh.77.1653986587921;
Tue, 31 May 2022 01:43:07 -0700 (PDT)
X-Received: by 2002:a05:620a:244b:b0:6a5:b92e:9b with SMTP id
h11-20020a05620a244b00b006a5b92e009bmr16649450qkn.610.1653986587783; Tue, 31
May 2022 01:43:07 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.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, 31 May 2022 01:43:07 -0700 (PDT)
In-Reply-To: <t74b1v$91i$1@dont-email.me>
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>
<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>
<2022May26.190052@mips.complang.tuwien.ac.at> <9ad73d53-e73b-45d3-8df0-b7c67f279c7dn@googlegroups.com>
<2022May27.082753@mips.complang.tuwien.ac.at> <f3958e4e-1418-4f20-b7f3-f21ef4c09563n@googlegroups.com>
<2022May27.135524@mips.complang.tuwien.ac.at> <01e9bd68-da4d-4c15-9854-868ad42bf4c8n@googlegroups.com>
<t6qvv3$usi$1@dont-email.me> <9d7a3c6f-7b51-4a68-948c-37143f34c23cn@googlegroups.com>
<t7310v$g3m$1@dont-email.me> <a8bc283e-1547-413e-bf58-ff59bdc01f7fn@googlegroups.com>
<t74b1v$91i$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e4460120-1634-4cec-8541-31289e6e3962n@googlegroups.com>
Subject: Re: Ryzen 7000 Described, but not detailed
From: already5...@yahoo.com (Michael S)
Injection-Date: Tue, 31 May 2022 08:43:07 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2553
 by: Michael S - Tue, 31 May 2022 08:43 UTC

On Tuesday, May 31, 2022 at 9:02:43 AM UTC+3, Stephen Fuld wrote:
>
> For a while, IBM used embedded DRAM as an L3 cache in some of their
> Power and Z series systems,

One z14 description (IBM z14 Model ZR1 Technical Guide) claims that even L1
cache is eDRAM. I am not sure if it is mistake or true.

> but I think have abandoned it. It always
> seemed like a good idea to me, but I wonder why they stopped using it.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

The answer to this question is simple: because they no longer make POWER and Z on their own fabs.
Without their specialty trench capacitors on-die eDRAM caches are less attractive.

Re: Ryzen 7000 Described, but not detailed

<8750dec2-bb02-4591-a0d6-e8659a1e0d74n@googlegroups.com>

  copy mid

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

  copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:27cd:b0:6a3:756f:8267 with SMTP id i13-20020a05620a27cd00b006a3756f8267mr30249277qkp.374.1653988589832;
Tue, 31 May 2022 02:16:29 -0700 (PDT)
X-Received: by 2002:a05:6214:2aaf:b0:45b:9f:8752 with SMTP id
js15-20020a0562142aaf00b0045b009f8752mr49332403qvb.9.1653988589662; Tue, 31
May 2022 02:16:29 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.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, 31 May 2022 02:16:29 -0700 (PDT)
In-Reply-To: <2022May31.095516@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>
<01e9bd68-da4d-4c15-9854-868ad42bf4c8n@googlegroups.com> <2022May27.200114@mips.complang.tuwien.ac.at>
<67b0eb94-163c-4206-b39c-05d09e9552d6n@googlegroups.com> <2022May29.111409@mips.complang.tuwien.ac.at>
<f90895a5-f4c2-4236-a114-d391075f72b4n@googlegroups.com> <2022May29.173049@mips.complang.tuwien.ac.at>
<12bfecfc-d427-4612-bf11-1d80048ceaadn@googlegroups.com> <2022May30.150007@mips.complang.tuwien.ac.at>
<t73ncg$9sm$1@dont-email.me> <2022May31.095516@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8750dec2-bb02-4591-a0d6-e8659a1e0d74n@googlegroups.com>
Subject: Re: Ryzen 7000 Described, but not detailed
From: already5...@yahoo.com (Michael S)
Injection-Date: Tue, 31 May 2022 09:16:29 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2525
 by: Michael S - Tue, 31 May 2022 09:16 UTC

On Tuesday, May 31, 2022 at 11:02:49 AM UTC+3, Anton Ertl wrote:
> Brett <gg...@yahoo.com> writes:
> >DRAM stopped scaling a decade ago,
> In 2012 we had DDR3 RAM with up to 8GB/UDIMM (with 4Gb chips) and at
> most 2133 MT/s. Today we are switching to DDR5 RAM with currently up
> to 32GB/UDIMM (with 16Gb chips) and 4800MT/s or more. What do you
> mean with "stop scaling"?

While I agree that DRAM scaling didn't stop in last decade (although
it did slowed down) your example does not prove it.
32GB DDR5 UDIMM of today is not an equivalent of 8GB DDR3 UDIMM of 10 years ago.
There is very big (5x ?) price difference between the two which leads to
targeting different segments of the market.
8GB DDR3 UDIMM of 2012 was not exactly a market leader (4 GB UDIMMs were more\
common), but it was sold and bought widely. Unlike 32 GB DDR5 UDIMM today which
is tiny part of the market.

Re: Ryzen 7000 Described, but not detailed

<t755jt$1f83$1@gioia.aioe.org>

  copy mid

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

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!EhtdJS5E9ITDZpJm3Uerlg.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Tue, 31 May 2022 15:36:04 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t755jt$1f83$1@gioia.aioe.org>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
<JlrjK.56338$5fVf.20964@fx09.iad>
<2022May25.195605@mips.complang.tuwien.ac.at>
<r2OjK.32433$3Gzd.17515@fx96.iad>
<2022May26.190052@mips.complang.tuwien.ac.at>
<9ad73d53-e73b-45d3-8df0-b7c67f279c7dn@googlegroups.com>
<2022May27.082753@mips.complang.tuwien.ac.at>
<f3958e4e-1418-4f20-b7f3-f21ef4c09563n@googlegroups.com>
<2022May27.135524@mips.complang.tuwien.ac.at>
<01e9bd68-da4d-4c15-9854-868ad42bf4c8n@googlegroups.com>
<2022May27.200114@mips.complang.tuwien.ac.at>
<67b0eb94-163c-4206-b39c-05d09e9552d6n@googlegroups.com>
<1dc01ff0-a50b-4547-9f61-83607477439dn@googlegroups.com>
<t71s8h$prv$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="48387"; posting-host="EhtdJS5E9ITDZpJm3Uerlg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.12
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Tue, 31 May 2022 13:36 UTC

Marcus wrote:
> A few things that I have learned about CPU cores and memory consumption:
>
> 1. With every extra core you want more RAM. Twice the number of cores
> roughly translates to twice the memory requirements. My typical use case
> is parallel compilation (e.g. building LLVM), where each CPU core gets
> its own compiler process, and each process consumes RAM independently of
> the other. For embarrassingly parallel tasks multi-core CPUs are king.
>
> 2. I regularly enough run virtual machines to care about having enough
> RAM to support both a fully working host environment and a working VM
> environment. Usually the VM uses 25-50% of the host RAM, so out of my
> 32 GB RAM I sometimes have to do with 16 GB available RAM when the VM
> is running.

100% agree.

I have had 32 GB RAM (+ 2TB disk, originally spinning rust, now SSD) as
my default laptop size for well over a decade now (4 or 5 different PCs,
from 4 different employers), and I'm only going to change that up, not down.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: Ryzen 7000 Described, but not detailed

<t75745$165$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.arch
Subject: Re: Ryzen 7000 Described, but not detailed
Date: Tue, 31 May 2022 07:01:41 -0700
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <t75745$165$1@dont-email.me>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com>
<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>
<2022May26.190052@mips.complang.tuwien.ac.at>
<9ad73d53-e73b-45d3-8df0-b7c67f279c7dn@googlegroups.com>
<2022May27.082753@mips.complang.tuwien.ac.at>
<f3958e4e-1418-4f20-b7f3-f21ef4c09563n@googlegroups.com>
<2022May27.135524@mips.complang.tuwien.ac.at>
<01e9bd68-da4d-4c15-9854-868ad42bf4c8n@googlegroups.com>
<t6qvv3$usi$1@dont-email.me>
<9d7a3c6f-7b51-4a68-948c-37143f34c23cn@googlegroups.com>
<t7310v$g3m$1@dont-email.me>
<a8bc283e-1547-413e-bf58-ff59bdc01f7fn@googlegroups.com>
<t74b1v$91i$1@dont-email.me>
<e4460120-1634-4cec-8541-31289e6e3962n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 31 May 2022 14:01:41 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="c2082b61c5d675aaeca2c16032dbc87a";
logging-data="1221"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+NdmIxL8tDz5gAFS2glBFC8sKicKwHoHk="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Cancel-Lock: sha1:GZhNVCDjU9PPaLVR3e3Cr775ElA=
In-Reply-To: <e4460120-1634-4cec-8541-31289e6e3962n@googlegroups.com>
Content-Language: en-US
 by: Stephen Fuld - Tue, 31 May 2022 14:01 UTC

On 5/31/2022 1:43 AM, Michael S wrote:
> On Tuesday, May 31, 2022 at 9:02:43 AM UTC+3, Stephen Fuld wrote:
>>
>> For a while, IBM used embedded DRAM as an L3 cache in some of their
>> Power and Z series systems,
>
> One z14 description (IBM z14 Model ZR1 Technical Guide) claims that even L1
> cache is eDRAM. I am not sure if it is mistake or true.
>
>> but I think have abandoned it. It always
>> seemed like a good idea to me, but I wonder why they stopped using it.
>> --
>> - Stephen Fuld
>> (e-mail address disguised to prevent spam)
>
> The answer to this question is simple: because they no longer make POWER and Z on their own fabs.
> Without their specialty trench capacitors on-die eDRAM caches are less attractive.

That makes sense. Thanks.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Re: Ryzen 7000 Described, but not detailed

<2022Jun1.130648@mips.complang.tuwien.ac.at>

  copy mid

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

  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: Wed, 01 Jun 2022 11:06:48 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 54
Message-ID: <2022Jun1.130648@mips.complang.tuwien.ac.at>
References: <aa564fec-f392-478a-b660-1b76f6000a6cn@googlegroups.com> <67b0eb94-163c-4206-b39c-05d09e9552d6n@googlegroups.com> <2022May29.111409@mips.complang.tuwien.ac.at> <f90895a5-f4c2-4236-a114-d391075f72b4n@googlegroups.com> <2022May29.173049@mips.complang.tuwien.ac.at> <12bfecfc-d427-4612-bf11-1d80048ceaadn@googlegroups.com> <2022May30.150007@mips.complang.tuwien.ac.at> <t73ncg$9sm$1@dont-email.me> <2022May31.095516@mips.complang.tuwien.ac.at> <8750dec2-bb02-4591-a0d6-e8659a1e0d74n@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="f9bf1a9d7e4d339bd3af31318f6bafbc";
logging-data="7684"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/D2lOIxEV40Mt8JsIBoH7z"
Cancel-Lock: sha1:2y9jhyozxVZ+vDgi8N4ihIrXmoU=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Wed, 1 Jun 2022 11:06 UTC

Michael S <already5chosen@yahoo.com> writes:
>On Tuesday, May 31, 2022 at 11:02:49 AM UTC+3, Anton Ertl wrote:
>> Brett <gg...@yahoo.com> writes:
>> >DRAM stopped scaling a decade ago,
>> In 2012 we had DDR3 RAM with up to 8GB/UDIMM (with 4Gb chips) and at
>> most 2133 MT/s. Today we are switching to DDR5 RAM with currently up
>> to 32GB/UDIMM (with 16Gb chips) and 4800MT/s or more. What do you
>> mean with "stop scaling"?
>
>While I agree that DRAM scaling didn't stop in last decade (although
>it did slowed down) your example does not prove it.
>32GB DDR5 UDIMM of today is not an equivalent of 8GB DDR3 UDIMM of 10 years ago.
>There is very big (5x ?) price difference between the two which leads to
>targeting different segments of the market.

I found an 8GB DDR-2133 DIMM that was on the market in 2012:

<https://geizhals.eu/?phist=659067&age=9999>

A 32GB DDR5-4800 DIMM is about 3 times more expensive.

I don't think they target different segments of the markets. If you
wanted a top DIMM in 2012, you bought something like that (no bigger
and faster UDIMMs were available), and if you want to buy a big and
fast UDIMM today, you buy a 32GB DIMM, and if you want it for an Alder
Lake system, you probably go for DDR5 instead of DDR4. If you are
really going for the top, DDR5-4800 may be too slow for you despite
its high price.

>8GB DDR3 UDIMM of 2012 was not exactly a market leader (4 GB UDIMMs were more\
>common), but it was sold and bought widely. Unlike 32 GB DDR5 UDIMM today which
>is tiny part of the market.

Given the price difference, sure. Supposedly the retail price of DDR5
DIMMs reflects the current scarcity of the power management chips on
these DIMMs, the price of 32GB DDR4 may better reflect the fundamental
costs; looking at

<https://geizhals.eu/?cat=ramddr3&xf=15903_DDR4&sort=r#productlist>

the second-cheapest (EUR/GB) DIMM is a 32GB DDR4-2666 DIMM, and the
cheapest DDR4-3200 DIMM is 32GB in size, so 16Gb chips/32GB DIMMs seem
to have the lowest cost/bit.

So in terms of Moore's law, the 16Gb DDR4 chips are the relevant chips
at this point in time. However, ten years ago it was more than 0.5Gb,
so the scaling was slower than the 2 years per doubling that has
occasionally been claimed to be Moore's law, and certainly slower than
the 18 months per doubling that Moore stated in his 1975 paper.

- 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.8
clearnet tor