Talk:List of AMD Ryzen processors

Termal solution (col) & Notelist (type)

1. About Thermal Solution: Is there a way to improve recently added Termal Solution column?
As of right now it takes good portion of space (e.g. Template:AMD Ryzen 1000 series).
How about:

• Wikilink header to AMD Wraith and remove "Wraith" from cells?
• Change "LED" to "RGB" and remove "NO LED", so it's either RGB or nothing?
• Maybe simplify entire column, by reducing it to "yes|no" check marks and moving col behind MSRP?
  

2. About Notelist (and NoteTag/NoteFoot): Can we universally use only one type? Maybe only lower-roman or lower-alpha footnotes?
IMO some tables are a bit disorganized, plus there is extra space between two note lists (e.g. Template:AMD Ryzen Mobile 5000 Zen 3 based series).
Also "note X" takes more space inside cells (e.g. Template:AMD Ryzen Mobile 3000 Zen+ based series). Rando717 (talk) 18:37, 23 April 2023 (UTC)

Hi Rando717!

Regarding the thermal solution info:

This issue was actually previously discussed by me at User:Artem S. Tashkinov's talk page after I noticed him moving the cooler info on the Ryzen 7k series template out of the table and into the common features list above the table.

I was going to do that to the other tables, but then I figured that it wasn't an optimal solution either, as it would end up with very long text on some of the templates, something like "model 1 comes with type 1 cooler, model 3 and 5 come with type 2 cooler, models 6 and 7 come with type 3 cooler".

The current idea that Artem S. Tashkinov has come up with, is to remove the cooler info from all the tables entirely, since the tables are about the CPUs and their specs, not what comes with the CPUs anyway, and instead have all the "what Ryzen CPU comes with what cooler?" information in a table at the AMD Wraith article instead.

Pinging @CGBR (who added the info to the tables), and @Artem S. Tashkinov to start the discussion.

--------------------------------------------

Onto the explanatory footnotes issue:

Personally, I don't really care what type of footnotes are used / how they are presented.

If anything, I prefer various different types of footnotes to be used for each category of item (i.e. roman numerals for technical details, NoteTag for additional models not listed). I would leave them as they are.

Although, one thing I would like to see being done regarding explanatory footnotes in the templates, is to remove the notelist templates from all the templates entirely, and instead have them in a "Notes" section on every article that has the template. The reason for this is that if you have the notelists in the templates instead, this interferes with any footnotes being used on the articles, outside of the templates. Instead of appearing in the "Notes" section of the article like they should, instead they will just appear in the nearest template below it only, which can be rather confusing and cumbersome to readers. A good example of this can be found here, look at that notes list, completely empty, even though there should be notes in it considering there are some of them on the article.

So let's not have notelists in templates. But that's my opinion though. — AP 499D25 (talk) 03:49, 24 April 2023 (UTC)

Removing termal solution col also works. Tables are about CPUs anyway.

About footnotes:

I mean, using roman numerals for header notes is fine, using lower-alpha for any extra notes withing cells is fine (yes, there is small spacing inside notelist, but whatever).

But than when it comes to notetags, they take too much space IMO. Great example would be Template:AMD Barceló, 3 sets of notes are used, look how much space NoteTags take (models col).

I would rather have Pro models back inside tables than using those Note 1, Note 2,...tags. Rando717 (talk) 14:42, 10 May 2023 (UTC)

Inclusion of prices in the tables

Looking at the edit history of Template:AMD Ryzen 1000 series, as well as the cleanup tags once placed on this list article, I see that there is an intent to remove the pricing / MSRP of CPUs from the tables.

WP:NOTCATALOG has been cited as the reason for the removal of the pricing information.

I understand that Wikipedia articles should not list every single known piece of information about a product out there, that they should contain just the information that's relevant to the average reader / "makes sense" in an encyclopedia.

However, I believe the prices should be included as they have encyclopedic relevance, and don't break the "What Wikipedia is not" criteria above. Here's why:

The pricing of computer hardware and their components can change a lot over time, due to things like inflation, change in costs of materials, cost of manufacturing, and competition.

Having the pricing there tells us a "story" of how the pricing of the products has changed (or not changed) over the many years of new generations. For example, when Ryzen 5000 series came out, it increased the prices across the board (3600X $249 --> 5600X $299, 3800X $399 --> 5800X $449, etc) as AMD was able to do so at that time due to its "dominant" position over Intel as their processors were quite superior in performance to the Intel counterparts.

Another great example is the Threadripper 3000 and Pro 5000 series. Intel has been very lacking in this HEDT / workstation space lately, with the last release from them being the 10xxx series of Cascade Lake-X processors released in 2019, which only go up to 18 cores. AMD was able to charge $3990 for its 64-core Threadripper 3990X, because they were simply able to do so, due to this highly dominant position. And then with Threadripper Pro 5995WX they were able to charge even more money at US $6500, due to lack of competition once again.

On Intel side you have i9-9980XE $1979 --> i9-10980XE $979, they dropped the prices of the 10000 series HEDT processors due to the competition from AMD. It is also likely it has gotten cheaper to manufacture over the years, being built on the many-years-old 14nm node as before.

So yeah, I think the prices have relevance in an encyclopedic article, as they indicate ("tell a story" of) how relatively cheap or expensive the product was for its time, how things were at the time in terms of economics and competition. I did not know the Core i7-920 retailed for only 284 USD! I thought it was at least twice as expensive as that, given how powerful and advanced that processor was at that time.

On top of that, plenty of other tech product articles like ones on game consoles, and flagship smartphones also mention pricing of the product somewhere in the article. This has been done for at least over a decade now.

---

Also a quick sidenote: the edit on the Ryzen 1000 template by Evelyn Marie also removed HTML break tags from the header cells of the article. I have no idea why these break tags were removed. They make the table wider and less space efficient, there becomes an awful lot of blank space in the table cells and the eye has to scan the rows a much more distance / "arc" when reading the table row-by-row. For these reasons, I strongly believe they should be kept and not removed. — AP 499D25 (talk) 13:24, 13 June 2023 (UTC)

You make some good points here, and I think this is why I've been reluctant to remove the price column from processor lists myself, even if it felt a bit hypocritical while I was removing prices from car articles. They should be seen as less of a shopping guide and more of an insight to how AMD marketed the chips (in a clearer way than the model numbers themselves), and how they competed with Intel. Overall, I don't strongly feel one way or another about their inclusion in these lists. --Vossanova ^o< 15:32, 13 June 2023 (UTC)

Prices are very much subject to change and hence, require a lot of maintenance. Moreover, none of the claimed prices, as far as I can ascertain, are actually sourced and it is unclear if these are retail prices (which will likely differ from one supplier to the next) or OEM prices.

Worst of all, the prices were listed in Template:AMD Ryzen 1000 series, transcluded into a number of articles, which makes it worse. It also renders this talk page a non-obvious venue for discussion, but I'll let that slide.

So, no. I don't think prices should be listed in templates. Or indeed, elsewhere. Kleuske (talk) 07:28, 14 June 2023 (UTC)

Couple of things:

1. the prices listed in all the tables are specifically the original manufacturer suggested retail price (MSRP) of the CPUs. That is, when the company launches the product, they specify a suggested end consumer pricing for the retailers (these are not OEM prices). They can mark the price up or down however they want, but the MSRP remains the MSRP (though, that said, the majority of US retailers do usually adhere to the MSRP). This is actually quite common information, as AMD will put out a presentation or press release listing all the original MSRPs and then secondary sources will copy and repeat them in their articles, meaning it can be found quite easily. Hence why citations aren't often provided about it. Here are some examples of articles containing MSRP info for the Ryzen 1000 series:
2. yes, the actual prices of the parts do often change over time, especially after it's been over half a year since the products launched (they usually get cheaper). The prices shown in the tables are meant to be the original launch price of the parts, and never updated. Once again, it tells how things were at the launch of the product, in terms of economics and competition.
3. For the "templates" part: well, there's no better way to put them than have them be part of the product listing tables. A separate table or section on the article about the pricing would make significantly less sense.
4. Templates continued: So the way AMD Ryzen, AMD Radeon and Intel Arc articles are set up, are that all the tables listing the individual SKUs and their details are put into templates, which are then transcluded on the various articles that would want to have the same table. The major advantage of doing this is it "deduplicates" the same table between multiple articles that may have the same table. So for example, if I want to add a new Ryzen 7000 SKU to Wikipedia, instead of having to add it two or three times across the various articles that contain a Ryzen 7000 SKU list, I only need to add it to the template once, and then it will go "live" on the two or three articles that have the template, simultaneously. Another advantage of using templates is it helps keep a consistent style and layout between those various articles.
5. Further reading into the use of templates on CPU / GPU articles: this has actually been recently discussed on the Intel Arc talk page, where someone previously tried to remove templates from the Intel Arc article and replace them with regular substituted tables, likely due to not knowing how to edit the template. They voiced their opposition on the talk page, but the use of templates has been supported by numerous editors, citing synchronicity and style consistency as the core reasons once again. One product family / lineup which doesn't use templates on Wikipedia yet is the Nvidia GeForce GPUs, which I have actually started a proposal on the talk page about moving all the tables on GeForce articles to templates. (As of yet, nobody has opposed the idea of moving them to templates.)
6. Templates continued 2: yes, one disadvantage of having the product lists in templates is that it does make it seem not obvious where to discuss the product lists. To counter this, the documentation of the templates explain and provide a link to the centralised discussion place where the tables should be discussed, which is how I came here. If you look at the template documentation of the Ryzen 1000 series template, you'll notice that it says Common place to discuss layout and style of the Zen CPU tables at: Talk:List of AMD Ryzen processors. in it.

Hope that makes things clearer about why templates are used and why the prices are listed in them. — AP 499D25 (talk) 09:20, 14 June 2023 (UTC)

@Kleuske Is there anything you want to add to the above?

I'm considering starting a requests for comment on this, as there are at least hundreds of Wikipedia product list tables out there that contain pricing (not just AMD CPUs, but also GPUs, Intel CPUs, who knows what else), so I feel like gathering a wider consensus on whether pricing should really be included in these list tables or not. After all, some of these list tables have had pricing in them for over an entire decade now, undisputedly. — AP 499D25 (talk) 13:16, 16 June 2023 (UTC)

In favor of including launch MSRP in tables. Can someone with better editing skills than me add a price column and prices back to the Ryzen 1000 series table so it at least matches the tables for all the other desktop Ryzen parts?

And the for the love of God, please don't remove the launch MSRP data from all the other tables. If you do, you may as well do it on all the articles for different generations of Intel Core i3/i5/i7/i9 processors and the lists of those processors too, and the launch prices of Nvidia GeForce and AMD Radeon GPUs on those list pages and generational articles... wait. Please, oh please, for the love of God, don't make any of those changes either. Jtenorj (talk) 01:08, 1 August 2023 (UTC)

Sorry for late response, but I did restore the pricing information on Template:AMD Ryzen 1000 series once (diff), but then another editor came in and also removed the pricing information / disagreed with me (diff). Hence why I came here and created this thread, to discuss whether prices should really be included or not.

My plan is to do what has been suggested at User talk:WhatamIdoing/Archive 22 § RfC help needed, which is to incorporate original retail prices into sentences on the Ryzen article, talking about how they competed with similarly priced or positioned products from the competitor cited with reliable sources, rather than having them listed for each product in every desktop processors list table. Otherwise, I may consider starting a RfC on this. — AP 499D25 (talk) 04:56, 23 January 2024 (UTC)

I removed the tags because there's no reason to make the table compact for the sake of making it compact. We aren't on 80 column screens. The <br /> tags are also just downright ugly and make the table harder to maintain. - Evelyn Marie (leave a message · contributions) 03:53, 15 June 2023 (UTC)

The <br /> tags are also just downright ugly and make the table harder to maintain. → The same thing could be said about non-breakable spaces, convert templates, and vice versa. "It looks ugly in the source code" isn't a valid reason to remove it in my book. Forced breaks have been used in numerous AMD CPU and GPU, Intel product tables for at least over a decade now, without any complaints about them. I've seen plenty of other "ugly" looking source code in articles and templates I've edited in the past too, I've almost never seen anyone remove or 'tidy' them. At the end of the day what really matters is what's visible to the readers, not what's behind the scenes.

Also, who wouldn't like a table that has less empty space and requires less distance scanning across the rows when reading them?

Also by the way, the reason there is "(total)" in the L3 cache columns of the table templates is that the L3 cache layout of these processors are not straightforward – for example, in the case of Ryzen 7 1700X, instead of being a single pool of 16MB cache it's actually two separate 8MB caches, due to the "two CCX" layout of the chip where each CCD contains 4 cores and 8MB shared L3. The "total" makes it clear this is the total amount of L3 cache in the processors, rather than it being unknown if this is total number of the separate caches together, or if it's all shared. — AP 499D25 (talk) 04:53, 15 June 2023 (UTC)

References

Abbreviated dates

In response to that this Template:AMD Ryzen 1000 Series edit:

As far as I'm aware, it is within the MOS:DATE guidelines. It states Only in limited situations where brevity is helpful, but it also states in the explanatory footnote next to it, For use in tables, infoboxes, references, etc. Tables are meant to be a compact, concise presentation of data aren't they? — AP 499D25 (talk) 02:08, 20 June 2023 (UTC)

No, not always. It depends on how much information they include. As that table does not include that much information, it does not make sense to unnecessarily abbreviate dates, and as far as I am aware, most tables I'm aware of don't abbreviate dates regardless, same with how references don't have abbreviated dates either. Edit: Plus, to be honest, abbreviated dates kinda just look wrong when you're shortening month names like March, July, June, etc when they are already pretty short in name. - Evelyn Marie (leave a message · contributions) 02:14, 20 June 2023 (UTC)

Alright.

There's also the consistency argument: one table might have short dates like May June July, while the other table has long dates like September November. In that case it makes sense to either use short dates or long dates on all the tables, rather than have some be short and some be long depending on length of the month names.

Unfortunately, Template:AMD Ryzen 1000 Series isn't the only product list table that has abbreviated dates, there are at least 50 odd other table templates out there that also have abbr'd dates. As far as I'm aware, if you're in a dilemma where 20 tables use style 1 but 2 tables use style 2, and there is no guideline or policy that strongly recommends one over the other, the general precedent is to use the style that is the most widely used across all the articles, rather than changing them all the other way around to use the less widely used style, unless there is consensus from editors to do so. — AP 499D25 (talk) 02:39, 20 June 2023 (UTC)

~50 templates using abbreviated dates vs hundreds of thousands of templates using non-abbreviated dates means that those ~50 templates should be updated to follow the near-universal date style, in this case being non-abbreviated dates. - Evelyn Marie (leave a message · contributions) 02:43, 20 June 2023 (UTC)

Okay then, that makes sense. I've moved this to article talk so other editors can easily view the reasoning for un-abbreviating the dates, as well as participate in the discussion if they wish. — AP 499D25 (talk) 04:28, 23 June 2023 (UTC)

Add a table of contents?

It's hard to track the logical separations without a TOC 96.234.183.171 (talk) 01:30, 24 August 2023 (UTC)

There's no such chip as the "Ryzen 7845U"

one of the notes in the Barcelona-R section makes mention of a chip that doesn't exist. Apologies I'm not sophisticated enough to figure out how to edit that section :/ Evil genius fin (talk) 05:06, 14 December 2023 (UTC)

Note is from another section and I removed it because I agree that it's confusing and doesn't provide additional information. RM12 (talk) 12:41, 14 December 2023 (UTC)

AMD confirms Ryzen 8000G family doesn't support ECC RAM

AMD confirms Ryzen 8000G family doesn't support ECC RAM, but future Ryzen Pro 8000G family suppose to support ECC RAM, per article. • Sbmeirow • Talk • 04:45, 7 February 2024 (UTC)

AMD Ryzen (Pro) 8000G („Phoenix“)

Here is a list of all upcoming Ryzen 8000G (with GE) incl. Link to the original source. 147.161.136.180 (talk) 14:42, 15 February 2024 (UTC)

References

Usage of 'start date and age' templates

@RM12

While it's true that the usage of start date and age templates don't take up much additional space in the tables, there is one big problem with them, which is that it breaks the sortability aspect of the table:

Take a look at Special:PermaLink/1215822199. If you click the release date column to change its sorting order, it sorts by the number of the day first, rather than sorting properly by time. The dts template previously used correctly does this, and that's the reason why it's used on nearly all the other list tables here. — AP 499D25 (talk) 12:47, 29 March 2024 (UTC)

I switched it back to dts. I personally like the extra info but hey I don't care enough to argue about it.

Someone changed the other Ryzen 7000 & 8000 templates to plain text. Don't know if that also messes with sorting but that's not on me. RM12 (talk) 18:46, 29 March 2024 (UTC)

I've changed those back to the DTS template as well. Mind you the dates have been un-abbreviated because of a dispute above, but you are more than welcome to change them back and participate in that discussion. — AP 499D25 (talk) 23:34, 29 March 2024 (UTC)

Table design minor updates

Just an FYI, @Rando717 and @Artem S. Tashkinov, I'm going to be making the following small changes to all the Zen-based CPU list tables:

• Disable sortability for core count, clock speed, cache size, core config, chiplets, iGPU model, clock, config, processing power, thermal solution and price. I don't think it makes sense to have the sortability option on all the columns, and so by enabling sortability for only the model, TDP (base) and release date columns, we can reduce the width of the tables quite a bit (here's an example: before and after).
• Add nowrap to tables class to prevent text flow breaking when viewing on narrow width window. Right now, if you view the tables on a narrow window (e.g. small browser window, or a mobile phone), some text in the table such as the cooler info, TDP ranges and "Ryzen 3/5/7" will automatically break up, causing the table to grow taller while making it harder to read as it breaks the otherwise smooth text flow from left to right.
• Reorder common features list. They are in a bit of a random order (i.e. it goes bus-cache-bus), so I'm going to put them in a socket-buses (RAM-PCIe-system bus)-iGPU common info-cache-fab node-additional notes order.
• Add some secondary source references (or refs to non-AMD databases). The reason for this is I have seen some editors complain in the past about some of these list articles apparently relying too much on primary sources, additionally if you read the inclusion of pricing dispute above, editors have suggested that there must especially be secondary source references if we were to have the launch price info in the table. As a matter of fact, the AMD CPU databases don't actually seem to state the launch prices, and Intel removes MSRP info from their databases when CPUs are discontinued. So I think this may be a very good idea if we were to keep the launch price data in the tables.

These would bring the Ryzen tables up to the standard of List of Intel Core processors, where I have already implemented the first three changes throughout all the tables. Artem, I know I've discussed this with you already on your talk page, but I'm just letting you know I'm intending to make the same changes here as well. Rando717 and anyone else, if you have any thoughts, suggestions or objections to these changes, please feel free to leave a comment! — AP 499D25 (talk) 11:12, 13 May 2024 (UTC)

Proposed table layout changes June 2024

Moved from User talk:SHJX § CPU list tables

 – — AP 499D25 (talk) 06:15, 5 June 2024 (UTC)

Let me say a few things:

• I don't like the breaking up of "Ryzen 9", "XDNA 2" into two separate lines. This breaks the otherwise smooth, left-to-right reading flow. In my table layout I added 'nowrap' to the tables class to prevent content being broken up when it is viewed on a small display.
• I don't know why you insist on always making links piped to the precise target rather than just simply linking them to the redirect. This is an unnecessary change because piped links save virtually zero time for the reader (i.e. redirects add nothing to loading time), furthermore it makes the source code longer and cluttered up. Have a read through WP:NOPIPE, MOS:NOPIPE and WP:NOTBROKEN. Another great reason why not to do this, is if an article gets created at that redirect, like happened with RDNA 2 and 3, those piped links now all have to be manually and tediously updated to link to that new article. Had those links been left without the piping to other target part, those links would never have to have been updated in the first place. The only time I use a piped link is if it links to a different topic with the same name or a disambiguation page if I don't do so.
• Also on a related note, you may see me inserting citations with DMY or even ISO (YMD) date formats. The reason for that is because the citation add tool in the source editing toolbar does DMY dates by default; if you see me using ISO dates it means I used the VisualEditor which does that by default. I don't really see the point in spending extra time aligning those dates to the date format used in the articles because usually there's a "Use mdy dates" or "Use dmy dates" template at the top of those articles, which automatically take care of and convert these inconsistent date formats in the articles in read mode.
• I also don't see the meaningful benefit in tidying up citation code and making source code 'neater'. At the end of the day, what really matters is what the reader sees when reading the page normally, not what editors see when editing the page. I've dealt with some horribly written source code in the past before, yet I still got along fine editing the page, and what was seen on the page in read mode was what you expected it to be. Sometimes I will tidy up hard-to-read source code but when I do so, it's often in combination with other edits, rather than just making that sole edit that does not change what readers see.
• Lastly, if you're going to massively revise template code like you did with those two new Ryzen CPU lists, maybe test them out on the pages they are on and make sure they are what you expect to see? On the Zen 5 page, the Granite Ridge table is missing a navbar and footnotes. The Strix Point table has blaring red error text where the footnotes should be. Also, the table layouts between just those two are inconsistent too. Desktop goes PCI-E lanes --> Memory support --> Socket, while mobile goes Memory support --> Socket --> PCI-E lanes.

P.S. I probably know who you are, but I am happy to let you edit freely so long as you don't keep making controversial page / table styling changes and edit warring over them!

Regards, — AP 499D25 (talk) 01:18, 4 June 2024 (UTC)

I don't like the breaking up of "Ryzen 9", "XDNA 2" into two separate lines

br tags were added for Ryzen 9, RDNA 3.5 and XDNA 2 to make the table narrower: SHJX (talk) 01:51, 4 June 2024 (UTC)

	SKU	Cores (threads)
Ryzen AI 9	365	10 (20)
	HX 370	12 (24)

vs.

Branding and Model		Cores (threads)
Ryzen AI 9	HX 370	12 (24)
	365	10 (20)

There are tradeoffs to make when designing the layout of the tables, and I am pretty sure my table layout balances those different design aspects pretty well. My table layout was in fact shorter and smaller than your layout, which apparently needs those undesirable tradeoffs to be done to not make the table too wide.

One thing I'll add here, is in response to highest-to-lowest sorting: the tables were made sortable for a reason. If anyone wants to view them in ascending order, they just click the "Branding and Model" header, and boom, it's in lowest-to-highest sorting. Highest-to-lowest sorting also makes sense when we compare CPU models - when I say "this CPU's performance is above that one!", indeed, with the descending sorting, it is logically placed above the lower-performing one. Whereas, with ascending order, the higher-performance part is placed below - "this CPU's performance is under that one!" - do you see what I'm talking about? — AP 499D25 (talk) 03:57, 4 June 2024 (UTC)

The ranking of "best" to "worst" is extremely subjective and varies between use scenarios. The 8-core 7800X3D is better than the 7950X3D in gaming due to lower latency with its single CCD even though the 7950X3D has a higher single-core boost clock. The 7950X is better than the 7950X3D in multi-threading due to higher all-core boost clocks as 3D V-Cache is sensitive to higher voltages. Ascending order by name is easier to understand and find specific SKUs because they are where you would expect them to be in the same way that a library is organized A-Z rather than by what people subjectively think are the "best" and "worst" books. The table shouldn't have to be sorted just to be more readable and logically ordered. The tables shouldn't reflect someone's opinion or corporate markteting, they should just be an organized and functional list of SKUs that are easy to understand. SHJX (talk) 17:20, 4 June 2024 (UTC)

Okay, fair point. I do know about the R7 7800X3D being faster in gaming than the R9 7950X3D and whatnot, as I have watched benchmark videos before.

This 'descending order by features' system has been used on Intel CPU tables (on the processor generation articles like Alder Lake and Skylake) for probably a decade without complaints now, and I haven't really seen any other complaints about the Ryzen CPU tables besides one in Jan 2023 (which was made by a blocked sockpuppet account, so their point is pretty much nullified), so I figured the vast majority of the community is fine with this sorting system. One of the ways to form consensus here is actually through editing, where if an editor makes a major change, and that change sticks around, then there you go, the consensus is pretty much in favour of that change.

By the way, the tables are actually in a mostly alphabetical order, except what has been done is that CPUs with less features will go below same-numbered models with more features. For example, i5-12400F placed below i5-12400 because it lacks iGPU. And then CPUs in lower TDP groups are placed below ones with higher TDP. For example, i5-13400T below i5-13400. This is the exact sorting system used on those intel CPU articles.

Did you know that back before the major style updates were done to Ryzen lists in late 2022, that they were still sort-of sorted by features and TDP group? Special:PermaLink/1129244858. The lower-TDP 'E' suffix parts are placed lower in the sorting than the standard TDP parts that don't have a suffix. So I didn't come up with this sorting system or introduce it really, I just continued the use of it as before, except flipped everything umop ap!sdn.

Lastly, I'll say it one more time: the tables are sortable for a reason. If you want to view the list in ascending order, then click the header and there you go. — AP 499D25 (talk) 23:07, 4 June 2024 (UTC)

Also, why do we need to write the L1 and L2 cache amounts as total? They are not shared between the cores unlike L3 cache, they are per-core. A Ryzen CPU with more L1 and L2 total cache isn't inherently faster just because of that. — AP 499D25 (talk) 23:12, 4 June 2024 (UTC)

Wanting to rank CPUs "best" to "worst" doesn't make sense because they can be in absurd orders where it is difficult to easily find SKUs. A 12700T is ranked above a 12600K despite a 12600K being stronger. If you actually wanted to accurately rank CPUs from "best" to "worst", then some K SKUs would have to be above certain non-K SKUs and a Core i9 T SKU might outperform a non-K i5 SKU but not a non-K i7. It just gets too messy. Ordering by name in scending order is simpler and inuitive. A 12400F below a 12400 is correct because ascending order by name sorting puts items without a suffix first. A SKU without a suffix coming first makes sense because it is a base SKU upon which suffix modifiers are added like F, or K, or KF, or T for diffferent variants. It shouldn't be controversial to just plainly list SKUs in this order:

• 12400
• 12400F
• 12400K
• 12400KF
• 12400T

L3 cache is also not shared between every core. All 16 cores on the 7950X can't access the entire 64MB L3 cache. Each 8 core group can only access their CCD's local 32MB L3 cache. Intel's L3 cache is also per core with 3MB per P-core and 3MB per E-core cluster and each of these cache slices are connected via a ring bus rather than being one single unified block of cache. The 13700K has 30MB of L3 cache while the 13900K has 36MB of L3 cache due to more two E-core clusters being enabled. On the other hand a 6-core 7600X with two cores disabled still has the same shared 32MB L3 cache as an 8-core 7700X. If you oppose adding L1 and L2 caches because they are not global, then you should also oppose including L3 cache if you were being consistent. Only including one cache while vehemently excluding L1 and L2 looks silly. Just need at AMD's own product listings like the 9950X which list total L1 and L2 caches. Articles already acknowledge that L1 and L2 caches are per core so it doesn't need to be repeated with "8×1MB" in the table and totals make more sense. CPUs can have the same L1 and L2 caches but different L3 caches such as the 7700X and 7800X3D or they can have the same L3 cache but different L1 and L2 caches such as the 7900X and 7950X. Details actually matter and pretending that L3 cache is the only thing that exists or that matters is a very naive and simplistic way of thinking.

On December 31, 2022, user Pathogen-David wrote that "your new tables are much harder to read" and "Just because you didn't find value in some of the information presented in the tables doesn't mean others didn't". Other editors that have voiced concerns and were quickly haranged for doing so also included Trigenibinion who had problems with the massive removal of information. There is only one editor who actually supported it. SHJX (talk) 00:33, 5 June 2024 (UTC)

1. Total L1/L2 caches makes zero sense. L1/L2 caches are not shared.

2. L3 cache e.g. in the List_of_AMD_Ryzen_processors#Raphael_(7000_series,_Zen_4/RDNA2_based) is listed per CCD in a hint, so it's exactly correct. We may continue to do so.

3. "pretending that L3 cache is the only thing that exists" no one is pretending. The information is provided in the bullet list before the table. Artem S. Tashkinov (talk) 06:35, 5 June 2024 (UTC)

@SHJX: Alright, I've moved this discussion over to the article talk page, so other editors can join in and discuss these potential changes. The current table design as we know it has stuck around for 1.5 years without any complaints or major revisions from other editors since Jan 2023, so I'm pretty sure most people like or accept this current layout. This needs further discussion and acceptance from others before you can go ahead with applying this design.

By the way other editors, this revision of Template:AMD Ryzen 9000 Series and this revision of Template:AMD Ryzen AI Mobile 300 series are what the proposed new table layouts by User:SHJX look like. Currently, they have been reverted back to the current layout used on all the other tables.

Pinging @Artem S. Tashkinov, Rando717, and RM12:. — AP 499D25 (talk) 06:15, 5 June 2024 (UTC)

We do not need/have to list the same exact information for all CPUs. We've discussed this before, the consensus was reached. Someone who we probably intimately know and remember, again wants to make the tables 20 feet wide and absolutely unreadable because human beings just cannot follow such long lines. Artem S. Tashkinov (talk) 06:30, 5 June 2024 (UTC)

You seemed to be the only one who reached "consensus" in liking the giant wall of text in templates and a table design for simpletons with subjectively ranking CPUs "best" to "worst". Pathogen-David wrote that "your new tables are much harder to read" and "Just because you didn't find value in some of the information presented in the tables doesn't mean others didn't". Trigenibinion wrote that the "tables are now dumbed down to Intel's level" and objected to the mass removal of information. The current design includes things that are actually not relevant like thermal solution when more revelant information like PCIe lanes and memory support could be added instead. There are some CPU series like Phoenix that have different numbers of PCIe lanes depending on the SKU or Threadripper 7000 with different memory support that need to be specified rather than having to search through a giant wall of text to find. For consistency across tables, these columns need to be added for all tables even if the information is shared across all entries. The insincere concern trolling about the width of a table is made moot when things like "Ryzen 7" could be broken into 2 lines with a br tag to remove unneccessary width but are instead refused and some columns are made wider than they need to be.

Did you not read about how L3 cache is also not shared and that an exception is being made for its inclusion as total amounts compared to L1 and L2 caches? If you want to specify cache, you should specify all caches, not being obtuse and ignoring two thirds of the caches in a CPU because it makes your head hurt. SHJX (talk) 16:28, 5 June 2024 (UTC)

Last time the consensus was reached. Trying to extract just certain opinions supporting your PoV doesn't change it and that was to make/keep the tables readable, concise and not overloaded with duplicated info you're in favor of.

Other points:

* PCIe lanes do not differ between SKUs, you're welcome to add them to the bullet list.

* RAM support is actually listed for many line-ups, you're welcome to add the information where it's missing. Again, into the bullet list. There's no need for an extra column listing the same information for all SKUs.

The contents of the L3 cache is shared between CPU cores within the same CCX. For CPUs with a single CCX it's just one big shared L3 cache, for CPUs with two CCX'es (or more) I guess it's totally OK to list this information via a hint.

Fan favourite AMD does not specify that actually: https://www.amd.com/en/product/12151 L3 cache: 64MB. No mention whatsoever that there are two separate CCX complexes. Maybe we could leave it that as well.

No one here has been trolling. There's also no need to try to look smarter, act haughty or insult others or even WP readers: "a table design for simpletons".

Please use the Sandbox and offer your new redesign. We'll discuss it. This is how it's been done here on multiple occasions while you were taking a break from WP. Artem S. Tashkinov (talk) 18:42, 5 June 2024 (UTC)

"PCIe lanes do not differ between SKUs, you're welcome to add them to the bullet list"

The Ryzen 7440U has 14 PCIe 4.0 lanes while the 7840U in the exact same series has 20 PCIe 4.0 lanes. The same 7840U SKU also has different memory support depending on the socket with DDR5 for FP7r2 and LPDDR5X for FP7 and FP8 sockets. Please look for yourself. SHJX (talk) 18:55, 5 June 2024 (UTC)

1. PCI-E lanes on Phoenix. You seriously want to add this completely useless info to the table? How many Phoenix laptops are there with PCI-E slots? 0? Because I've not seen any.

2. DDR support. Either your laptop comes with SO-DIMM slots, or it has soldered RAM onboard. The former? Always DDR5 5600MHz. The latter? It doesn't matter, because you have no control over that and the LPDDR5 speed will be chosen by your vendor, not by AMD specs.

Please enlighten me why you want to include arbitrary info into the table? We've already discussed it before and there are like 30 more data points for each AMD SKU. Should we add all of them because you feel so? I certainly feel so, let's do it! Let's actually make tables 20 feet long because we totally can, can't we?

For the vast majority of people what matters in the CPU is:

• Model name (obviously)
• Number of cores
• CPU boost speed (frequency)
• CPU base speed - mainly for geeks (most people never load all the cores so much as to hit TDP limits limiting CPU cores speeds)
• TDP
• L3 cache for geeks
• The iGPU beefiness for APUs

Everything else is almost completely irrelevant and should stay at the appropriate spec web pages.

So, where's your redesign? Artem S. Tashkinov (talk) 19:52, 5 June 2024 (UTC)

Over the course of the past two years, you (and your previously banned accounts) have been the only person willing to add a ton of repetitive and largely redundant info into the tables. There have been no concerns raised by anyone else, nor edits have been made in the same vein. Artem S. Tashkinov (talk) 19:56, 5 June 2024 (UTC)

BTW PCIe information is listed for 44 different CPU families. You made it look like it was totally missing. Please do not generalize and file complaints for individual CPU families, not for everything at once. Artem S. Tashkinov (talk) 20:02, 5 June 2024 (UTC)

You are being too irrational and deliberately obtuse to actually discuss this. You don't even understand the different between PCIe lanes and PCIe slots. Clearly you didn't actually read previous comments about how there were objections to the design from Pathogen-David and Trigenibinion but you bulldozed over them and treated them with contempt. The tables previously had full information rather than a couple of columns and wall of text "for geeks" with a subjective "best" to "worst" ranking for simpletons who don't actually under stand semiconductors. The current design was just added without any approval but reverting it back to something readable does since you apparently think you are god emperor of Wikipedia. Therefore, your mind will never be changed and trying to do so is unproductive. I don't know who you are but you have a disgusting controlling personality. There is not a grand conspiracy against you. SHJX (talk) 20:24, 5 June 2024 (UTC)

Take a look at Talk:Zen 4 § Extremely horrible design and data presentation for AMD CPUs templates where about four total editors criticised the old table layout and were requesting a rework of the tables. Nobody there objected to the plan or suggested stuff like "socket / memory support / PCI-E lanes MUST be in the table".

If you go to the original discussion in Archive 1, umm User:Visite fortuitement prolongée approved of the table rework there as well, it's not just Artem S. Tashkinov being the only one to give a thumbs up. Visite fortuitement prolongée wrote that they favour ascending order, but also that L1/L2 cache amounts should not be stated as total values (rather than per-core).

Trigenibinion's complaint was mainly about the removal of iGPU config and processing power info from the table, if you read carefully. I acknowledged his concerns along with another editor who also made strong points about wanting those data points back, so I added them back accordingly (example diff).

There have not been any renewed objections or major design changes since those complaints in Dec 2022 and Jan 2023 that you cited. Editors are allowed to defend their edits when someone opposes them, in fact you are trying to do that here right now, are you trying to say that's not allowed? They have not responded since those times, which suggests that they have gotten over it and got used to the current layout, or they see the big point in the layout changes after counterarguments have been made. — AP 499D25 (talk) 00:38, 6 June 2024 (UTC)

The PCIe slots matter because without them the number of PCIe lanes becomes irrelevant because there's nothing to expand and nothing to use them. But there are other users as well: e.g. an external GPU (via ThunderBolt/USB4) and M.2 expansion slots. Still, most laptops lack those or/and have enough CPU PCIe lanes not to have any troubles sharing them. I've not seen a single laptop customer researching the number of PCIe lanes for their mobile CPU. Nor there are any threads on the Internet about it. It's a desktop/workstation/server thing. Artem S. Tashkinov (talk) 06:41, 6 June 2024 (UTC)

Phoenix is also used in Ryzen 8000G desktop APUs where a 8500G doesn't have enough PCIe lanes for a full x16 GPU while the 8700G has 20 PCIe lanes. Your obfuscations about laptops having physical PCIe slots with personal anecdotes looks uninformed and childish. AAnyone who is taking the time to look up a list of SKUs on Wikipedia is not an uninformed "average consumer" and assuming so is insulting their intelligence. I don't think you actually care about the information behind CPU SKUs and instead care more about making things look incredibly uncomplicated and shallow with lots of bullet points. What is actually the point of even having a table if most of the information is in an essay while the 4 column wide table takes up extra space? SHJX (talk) 15:55, 6 June 2024 (UTC)

You've not addressed my previous concern: "there are like 30 more data points for each AMD SKU. Should we add all of them because you feel so? I certainly feel so, let's do it! Let's actually make tables 20 feet long because we totally can, can't we?"

Also it's weird you first wrote about "The Ryzen 7440U has 14 PCIe 4.0 lanes while the 7840U in the exact same series has 20 PCIe 4.0 lanes." now you've suddenly jumped straight at "Ryzen 8000G desktop APUs where a 8500G doesn't have enough PCIe lanes for a full x16 GPU".

You've also completely neglected this comment I've made previously: "BTW PCIe information is listed for 44 different CPU families".

Anyways, I don't have enough stamina to argue with a person who

• insults WP readers and editors
• ignores what others say and makes it look like you are being ignored/not heard (which is patently false)
• ignores the information already present
• changes their mind all the time
• wants to add duplicated info into the tables because "a bullet list is for "simpletons"". I've not observed this trend on any other WP pages and I don't support it here.

This is simply exhausting and as a chronically fatigued/clinically depressed person I simply cannot take it any more. If there's going to be a vote here, I'll check it and see if I can opine. Otherwise I don't want to discuss anything with you ever again. Artem S. Tashkinov (talk) 17:36, 6 June 2024 (UTC)

This discussion has run its course, we've all made our points pretty clear, and as of now, there is no firm consensus in favour of changing the layout of the tables to what User:SHJX has proposed.

I too am pretty much done and out of here. User:SHJX, the current table layouts are here to stay until you get wide/strong agreement in favour of your changes. You could wait and hope someone else joins in here and offers their opinion, and/or invite other recent/regular contributors to these lists that you know, but until then, this redesign proposal won't be going ahead. — AP 499D25 (talk) 00:50, 7 June 2024 (UTC)

I need a tl;dr if you want a different answer but I'm going by what I've understood by having a quick look:

People said the tables were to wide and the consensus was to list shared specs above the table in a list and only keep the differentiating factors inside the table. For me that's a non-issue I care more about the information provided and not so much about how it's presented so you have to settle this between yourselves. ✌

Important note: @SHJX if you want to change the general layout though you have to keep it consistent across all tables meaning changing everything from Zen 1 to Zen 5 and not just having one weirdo table that's different from the rest. From that perspective I'm siding with @AP 499D25 in keeping it consistent.

P.S.: I'm thinking about adding "GPU config" to the Ryzen 7000 series and later as the previous tables all list this spec. I don't think processing power (GFLOPS) is needed as that doesn't say anything about real-world performance but if I remember correctly consensus was to restore it after the tables got shortened?! Would be nice if you could confirm or reject it before I start. RM12 (talk) 10:51, 5 June 2024 (UTC)

The RDNA2 chips in desktop CPUs are all the same and they are quite feeble, so I'm not sure if this information is really sought after/needed by anyone. It could be added to the common features' bullet list for all I know if so you wish. Artem S. Tashkinov (talk) 11:24, 5 June 2024 (UTC)

Correct; the iGPU info is already mentioned in the common features list of the Ryzen 7000 and 9000 tables (RDNA2; 2CU; 0.4/2.2GHz).

I'll give a rundown on what User:SHJX wants to accomplish (for User:RM12):

• re-sort the CPU models in an ascending alphabetical order (so this would mean in the case of an intel table, i7 13700, 13700F, 13700K, 13700KF, 13700T), rather than sorting by features / TDP group.
• remove the CPU common features bulletpoint list, instead putting all that info in the table as stated below:
• add L1 and L2 cache columns to the table, and state total amounts (so if it's an 8 core CPU with 1MB L2 per core, it would say 8MB L2)
• add memory support, PCI-E support and socket columns to the table
• add iGPU info columns to Ryzen 9000 table (which would also potentially apply to Ryzen 7000 table)
• Disable sortability
• Break up "Ryzen 5", "Ryzen 7", "RDNA 2" etc so they are on multiple lines

Apologies for not being clearer earlier, this whole discussion was started on the user's talk page as you can see, so I also talked about some other things not directly related to these recent template edits. — AP 499D25 (talk) 12:21, 5 June 2024 (UTC)

Nothing on this list makes any sense to me. I struggle to understand why that's all proposed (which feels more like "imposed"). Artem S. Tashkinov (talk) 13:18, 5 June 2024 (UTC)

Oh, and about iGPU config and performance (GFLOPS): two editors strongly suggested to put those two columns back after I had removed them in the initial late 2022 table redesign, they made some very good points, so I put them back. — AP 499D25 (talk) 13:42, 5 June 2024 (UTC)

I should have been more clear I'm only planning adding iGPU config for mobile Ryzen as for APUs the iGPU is significant. I have left the desktop tables to you guys as you do a good job maintaining them.

To the proposed changes:

• strictly alphabetical sorting makes it harder in general to find similar SKUs so sorting by features is better in my opinion because it results in a semi-aphabetical format anyway (using your example 13700K(F) -> 13700(F) -> 13700T) which isn't that much different.
• I first disliked the idea for the "common features list" but it has grown on me because it makes the tables easier to read on mobile devices. Other than that I see no reason to keep it that way so I'm open for change if you reach another consensus.
• I've already said that I support adding iGPU info to the table but only on mobile (APUs). Desktop is up to you guys I use those rarely.
• Disabling sortability sounds good to me but seeing how many fights break out about how a table should be sorted I think it's best leaving it on.
• Breaking up the rowspans is absolutely opposed by me! It makes reading the table a nightmare because information is duplicated unnecessarily. Just using the sort tool already does this for the people who want it.

@AP 499D25 no need to apologize. RM12 (talk) 05:49, 6 June 2024 (UTC)

Got it, anyways thanks for chiming in!

I too find it harder to look for and compare specific SKUs in a table sorted by alphabetical order, actually.

One thing I might add to my to-do list for the Zen-based CPU tables (and also Intel Core list tables) is to reword the common features list a bit, so for example it reads like "Memory support: DDR5-5600 dual-channel" instead of "All the CPUs support DDR5-5600 in dual-channel mode". That way, it's concise, quicker to read and doesn't sound like an 'essay', which is one of User:SHJX's gripes about that list it seems.

I too have had an intention to add iGPU config and processing power info to the mobile Ryzen 7000 series and later tables. Though, one roadblock I ran into is that AMD doesn't publish those pieces of info themselves, and while the Techpowerup GPU database does have the info of many of Ryzen APUs' integrated graphics, from what I've seen, there were quite a number of entries where some info was wrong (e.g. contradicting other sources like Notebookcheck), so I'm honestly not sure what's a good source/place of info to find and use here.

I'm not sure why User:SHJX wants to disable sortability on the tables, though anyways, I've been going through and disabling sortability on certain columns of the table where it isn't very useful (e.g. clock speed, cache, core count), which decreases the width of the table by a noticeable bit.

Also, what is meant by breaking up "Ryzen 9" / "RDNA 2" etc onto separate lines, is this: take a look at this revision of Ryzen AI 300 mobile table by SHJX. See the "RDNA 3.5", "XDNA 2", "Ryzen AI 9" cells? That's what I'm talking about. It hurts the reading flow of left-to-right in my view. — AP 499D25 (talk) 09:14, 6 June 2024 (UTC)

I've made a revision with sorting that is narrower and actually includes important information like PCIe lanes which can vary in the 8000G series or different memory support adn sockets which can vary in the Ryzen 7040U series. I didn't have a problem with a sortable table, it was the extra width of the arrows in a sortable table. You probably won't like it but I at least made an effort:

Old:

	SKU	Cores (threads)	Chiplets	Core config	Clock rate (GHz)		Graphics			Cache			PCIe lanes	Memory support	Socket	TDP	Release date	Price (USD)
					Base	Boost	Arch- itecture	Cores	Clock (GHz)	L1	L2	L3
Ryzen 5	9600X	6 (12)	1 × CCD 1 × I/OD	1 × 6		5.4	RDNA 2	2 CUs 128:8:4:2	2.2	480 KB	6 MB	32 MB	28 PCIe 5.0	DDR5-5600 dual-channel	AM5	65 W	Jul 31, 2024	$299
Ryzen 7	9700X	8 (16)		1 × 8		5.5			2.2	640 KB	8 MB					65 W		$399
Ryzen 9	9900X	12 (24)	2 × CCD 1 × I/OD	2 × 6		5.6			2.2	960 KB	12 MB	64 MB				120 W		$549
	9950X	16 (32)		2 × 8		5.7			2.2	1.25 MB	16 MB					170 W		$699

New:

	SKU	Cores (threads)	Chiplets	Core config	Clock rate (GHz)		Graphics			Cache		PCIe lanes	Memory support	Socket	TDP	Released	Price (USD)
					Base	Boost	Arch- itecture	Cores	Clock (GHz)	L2	L3
Ryzen 5	9600X	6 (12)	1 × CCD 1 × I/OD	1 × 6		5.4	RDNA 2	2 CUs 128:8:4:2	2.2	6 MB	32 MB	28 PCIe 5.0	DDR5-5600 dual-channel	AM5	65 W	Jul 31, 2024	$299
Ryzen 7	9700X	8 (16)		1 × 8		5.5			2.2	8 MB					65 W		$399
Ryzen 9	9900X	12 (24)	2 × CCD 1 × I/OD	2 × 6		5.6			2.2	12 MB	64 MB				120 W		$549
	9950X	16 (32)		2 × 8	4.3	5.7			2.2	16 MB					170 W		$699

— Preceding unsigned comment added by SHJX (talk • contribs) 16:45, 6 June 2024 (UTC)

There's exactly zero reason to include these items in the table:

1. Graphics uarch

2. Graphics cores

3. Graphics clocks

4. PCIe lanes

5. RAM support

6. Socket

This is the same info for all the CPUs in the table. In short, the existing presentation form is near perfect and needs no changes. On mobile, the new table is impossible to read or follow through. On desktop, normal human beings can barely follow more than ten items on a table row. Artem S. Tashkinov (talk) 17:41, 6 June 2024 (UTC)

Nope. Sorry mate, but I still disagree with these proposed changes 👎. Decreasing the font size makes it even worse since now people with eyesight issues will have an even harder time reading the table. Small font size should be used as more of a last resort solution such as for a gigantic table with 20+ columns (example: Template:AMD Radeon RX 7000). This is going to be my last comment here actually, as I've made all my points clear. Like I said in my previous reply above, until there is strong consensus in favour of this new table design, these changes will not be going ahead. — AP 499D25 (talk) 01:11, 7 June 2024 (UTC)

@AP 499D25 honestly this discussion is so one sided and pointless. I do have respect for you, but please in future don't ping me whenever this editor (sockpuppet) is involved.

Same discussion happened in January 2023 (with APD4711), similar discussion on list of AMD gpus (with CristoCalis), there was also similar story on Raptor Lake (edit warring with LeaveMeB).

Also, why doesn't SHJX mention any complains from APD4711, only Trigenibinion and Pathogen-Davi are mentioned? It's not that deep to figure it out.

I stopped editing wiki, but still check from time to time. And I can right away say 10 simularities with LeaveMeB, but I can't be bothered writing reports and wasting time going back and forth every 6 months. It gets tiresome.

In my opinion, at this point this requires LTA, same for all annon proxy/VPN edits (from Algeria) in Q1 2024. That's all I got to say on this subject. Anything else would be pointless. Rando717 (talk) 19:01, 6 June 2024 (UTC)

Not sure what you're trying to imply about me, but I'm certainly nobody's sockpuppet. I still don't like the changes that were made to this page, and I no longer reference it anymore as a result. I don't have the energy to engage on this subject further (and honestly I didn't back during my initial comment either–I just wanted to express my disapproval and frustration.) I would appreciate it if you all would stop tagging me. Pathogen-David (talk) 19:27, 6 June 2024 (UTC)

The sockpuppetry claims weren't targeted at you, they were directed towards a different individual here. I apologise on behalf of the others if it sounded like those claims were against you.

---------------------------------------

User:SHJX, this user (Pathogen-David) isn't interested in discussing here, so you will need to stop pinging them from now on. In general, you should only ping an editor once. — AP 499D25 (talk) 00:55, 7 June 2024 (UTC)

Rando717, yes I know this discussion has ended up to be a waste of our time. I just hoped to settle this matter for once.

"please in future don't ping me whenever this editor (sockpuppet) is involved." Acknowledged. From this point on, I will be less tolerant of this editor (User:SHJX)'s behaviour of edit-warring to apply controversial style changes and attacking other editors on talk pages. — AP 499D25 (talk) 01:00, 7 June 2024 (UTC)

Notes