Talk:Epyc

Both are used in the article. Perhaps it should be decided which is correct. 49.145.129.243 (talk) 16:23, 10 August 2017 (UTC)

Followed convention and made all uses be Epyc, and mention EPYC stylisation in the lede. —ajf (talk) 17:32, 10 August 2017 (UTC)

Ajfweb, what convention was used? AMD uses EPYC.^[1] Within the secondary sources it appears mixed, but the majority appear to also use EPYC.^[2][3][4][5] Therefore, I would suggest EPYC is more probably more correct. Dbsseven (talk) 19:59, 10 August 2017 (UTC)

…honestly, “Epyc” was what Wikipedia was already using more often, so I just went with that. You may be right that EPYC is better. —ajf (talk) 02:54, 11 August 2017 (UTC)

@Ajfweb and Dbsseven: I would prefer "Epyc" and I think it's also correct according to MOS:TM. -- intgr [talk] 07:46, 11 August 2017 (UTC)

@Ajfweb and Intgr: Normally I would agree, but it is worth noting the MOS:TM states to use Epyc "as long as this is a style already in widespread use". I am not sure that Epyc is in widespread use (relative to EPYC) and think this exact point is what we should discuss. Dbsseven (talk) 18:34, 11 August 2017 (UTC)

I guess this is worth revisiting to avoid edit warring with Curly Turkey. Recent edit notes have stated that the stylization of EPYC in the lead is a waste of time. I would disagree. And as I understand the discussion here, at no point was it suggested to remove the stylization entirely. Directly on this topic MOS:TM/STYLE states explicitly it is convention to note the stylized version of a trademark in the lead. Even Curly Turkey's note of MOS:TMCAPS uses as an example eBay, which includes a "stylized" in the lead. Dbsseven (talk) 22:55, 10 October 2017 (UTC)

"Epyc" is not an acronym for anything, and ALL-CAPS in names and titles is entirely trivial. eBay is an example where the stylization is trademarked and used by third parties. "Epyc" fails both tests. This both is misleading and clutters up the lead. If there's any legitimacy at all to the ALL-CAPS, then the article name itself should be moved. Curly "JFC" Turkey 🍁 ¡gobble! 00:04, 11 October 2017 (UTC)

The recent edits I am discussing are in the lead and address the stylized version of the trademark. Acronyms are not an issue here. (Acronyms are capitalized throughout the article. Not the case with this edit.) To address your points: EPYC is used in third party sources, as discussed above.^[3][4][5] And it is trademarked.^[6] Including the stylized keeps with the MOS (MOS:TM/STYLE) and adds clarity to how the product is presented/marketed. (As examples see Dell and nvidia, neither are acronyms.) As for the idea of moving the article, I believe that is directly topical to the discussion above. Dbsseven (talk) 00:40, 11 October 2017 (UTC)

"EPYC is used in third party sources"—not systematically, and not any more than you would expect third-party sources to randomly ALL-CAPS a trademarked name. The ALL-CAPS in the logo are utterly unremarkable and sticking it up first thing in the lead serves no reader in any way shape or form. It's not even trivia. It's noise. Curly "JFC" Turkey 🍁 ¡gobble! 03:11, 11 October 2017 (UTC)

MOS:TMRULES states "widespread use", not absolute/perfect use. And EPYC's use cannot be random if it is used consistently by multiple third-party sources. In fact, this cannot be the standard as some articles have multiple "stylized as" versions, i.e. nvidia and Asus.

I appreciate your effort to remove "noise" or "trivia", but these are personal opinions. I disagree and I am not even the editor who added this (Ajfweb). Again, I believe the stylized clarifies the marketing/presentation of the article's subject. Therefore, as this appears to be an editorial disagreement about article structure WP:structure, I propose we follow the policy to achieve a WP:NPOV, which is to follow the MOS. If the issue is that the MOS should exclude this sort of material in general, that talk page would probably be more appropriate for the discussion. Dbsseven (talk) 12:22, 11 October 2017 (UTC)

perhaps @Intgr: and @Ajfweb: would like to discuss as-well? Dbsseven (talk) 12:25, 11 October 2017 (UTC)

Dbsseven: "but these are personal opinions"—you've got to be joking. And why are you linking to MOS:TMRULES to support this noise? If MOS:TMRULES applied, we'd need a page move. Worse, have you actually read MOS:TMRULES—particularly what it says about Time, Asus, etc? Curly "JFC" Turkey 🍁 ¡gobble! 10:36, 12 October 2017 (UTC)

Not joking at all. And I have in-fact read the whole MOS:TMRULES, which states to use standard English in the article. (Which is done in this article.) However, the same page of the MOS also states it is convention to indicate the “stylized as” in the lead, as was done here before the edit. (And the examples in the same MOS:TMRULES referenced often do exactly this: Asus, The Players Championship, Kiss.) So should we follow the MOS, and the whole MOS, or not? Dbsseven (talk) 13:35, 12 October 2017 (UTC)

And how does cluttering the lead with this noise serve the reader in any way? Can the reader not recognize an ALL-CAPped name without Wikipedia holding their hand? I hope we're not resorting to Wikilawyering to cram everything we can get into the lead. Curly "JFC" Turkey 🍁 ¡gobble! 21:01, 12 October 2017 (UTC)

I believe it clarifies that the product is not marketed as Epyc, but rather as EPYC. That products will be branded and advertised by the manufacturer in this particular way.^[7] (Just as AsusTek Computer Inc. markets is products under the name Asus, nvidia, etc.) I'm not saying this is a huge addition, which is why it only takes 18 characters to include. How is this clutter and noise, exactly? (And I don't believe it is wikilayering to discuss and find common consensus, including using the MOS, so articles are formatted and improve in a consistent manner.) Dbsseven (talk) 18:24, 13 October 2017 (UTC)

• (notified at the MOS page); speaking for the video game project, we routinely do not include the all-caps stylization if it is not an initialism, unless there are other stylization effects involved (eg Adrift (video game) is mentioned its stylization as "ADR1FT".) Too many products frequently use non-initialism all-caps of an otherwise normal word to make pointing that out unnecessary, particularly if we have imagery that shows the branding. --MASEM (t) 15:04, 12 October 2017 (UTC)

  Very good points Masem. However I am not clear if there is a similar convention for hardware as their is for game software (as noted with the nvidia and Asus examples). Also, there is no imagery here to otherwise indicate the stylization. Dbsseven (talk) 15:32, 12 October 2017 (UTC)

  Imagery-wise, you can opt to include the Eypc logo (it is a 100% valid use of non-free logo), or alternatively, based on Google images, a free image of a Epyc CPU case, that has the name emblazened on it, is possible. --MASEM (t) 16:19, 12 October 2017 (UTC)

  It's not "hardware vs software"—it's "what's the point of something so trivial"? How does it serve the reader? Curly "JFC" Turkey 🍁 ¡gobble! 21:03, 12 October 2017 (UTC)

  Masem noted there was a community consensus within the video game project on how to deal with stylization. This is a good example where the community came to a general consensus to use box-art rather than prose. However, I was simply noting there does not appear to be a similar consensus in the computer hardware field (again examples of nvidia and Asus). In the absence of additional information somewhere in the article, I believe it serves the reader (and is non-trivial) to know how the product is marketed/branded. But this is exactly what is being discussed here. Dbsseven (talk) 17:47, 13 October 2017 (UTC)

• Yeah, use "Epyc" in the text; it is not an acronym, so we would not capitalize it to mimic the logo, per MOS:TM. It's not required to have something like "(stylized as EPYC)" in the lead, though such a note is common, if the trademark is uniformly stylized that way. For simple capitalization it's probably superfluous (e.g., we have no such note at Sony), but such notes are helpful for less routine stylizations, e.g. at Client (band).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  20:48, 12 October 2017 (UTC)
• I restored the “stylised as EPYC” bit and cited AMD's website. AMD use “EPYC” consistently, and some (but not all) third-party sources do, so it seems remiss not to mention that. OTOH if we were to include the logo, maybe that bit could be removed again. —ajf (talk) 12:57, 13 October 2017 (UTC)

  ajf: Don't ever pull something like this again. You were told there was a discussion underway—your choices are to join it or stay away—and the "sourcing" is absurdly unacceptable. Whatever the outcome of the discussion, it will not be acceptable to use such a source in such a way. Curly "JFC" Turkey 🍁 ¡gobble! 14:26, 13 October 2017 (UTC)

  Curly Turkey can we please keep this civil? Yelling at and criticizing other editors here and in edit summaries does not appear in keeping with civility, even if the discussion isn't complete here.

  And how citing the copyright owner is "absurdly unacceptable" as a cite for the stylization? (Though I would have cited AMD's copyright page or Epyc branding guidelines^[7] to be more on point.) Dbsseven (talk) 17:08, 13 October 2017 (UTC)

  The source ajf provided was primary and doesn't discuss capitalization. The editor does not comment on the source—the editor reports on what's in the source, and the source says nothing about the comment "often stylized blah blah blah". Sources can never be used in this way.
  The source you provide is again primary; it might be an argument for a page move, not for trivial lead clutter. Are you promoting a page move? Curly "JFC" Turkey 🍁 ¡gobble! 20:58, 13 October 2017 (UTC)

  I am simply arguing for the inclusion of a notation of the "EPYC" branding within the article. While stylized appeared to be general convention based on the MOS:TM/STYLE, this appears to merit discussion here. What did you think of the infobox alternative below? Dbsseven (talk) 21:19, 13 October 2017 (UTC)

  I don't see what purpose that would serve to the reader. Why not just do what others have recommended—putting an image of the logo in the infobox? Curly "JFC" Turkey 🍁 ¡gobble! 04:18, 14 October 2017 (UTC)

  An image is a viable possibility. But as multiple proposals have been put forth/supported by multiple users, I was simply suggest the infobox option that I think satisfies most/all objections. I generally prefer prose over adding media, as media is not always available (ie. on mobile or otherwise limited connectivity). (And I believe all proposals, except complete removal, serve the same purpose: to inform the user of the branding.)Dbsseven (talk) 12:53, 14 October 2017 (UTC)

  I don't see the point, but at least it doesn't intrude on the reading experience. I won't say I support it (because I don't), but I won't oppose. Curly "JFC" Turkey 🍁 ¡gobble! 02:07, 15 October 2017 (UTC)

As an additional possibility (in addition to the previous "stylized as", or adding a graphic), the CPU infobox has an optional "brand1" line where we could list "EPYC" to make clear the product branding (the result being "Brand name(s) EPYC"). While away from the MOS for indicating stylization, this would get it out of the lead and make clear it is the branding of the product. I believe this could satisfy most current viewpoints. Thoughts? Dbsseven (talk) 20:13, 13 October 2017 (UTC)

• One should never be afraid to play around with caps, as long as there is a logical explanation for doing so, as per MOS:TMRULES. Punctuation, spacing, etc is a different matter, but caps may be dropped/gained as you please, pretty much. –Sb2001 ^{talk page} 13:22, 18 October 2017 (UTC)

  To the contrary, it obviously results in screaming disputes like this one. We have a Manual of Style for good reasons, and it should be followed. If you want to experiment with style, do it in your own sandbox, not in live article text.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  04:09, 21 November 2017 (UTC)

  @SMcCandlish: I agree with you about following the MoS, both to maintain civility and consistency in style across WP. But as was noted in this discussion, this can come across as "Wikilawyering". Dbsseven (talk) 17:08, 21 November 2017 (UTC)

  The actual wikilawyering is when people bend over backwards to try to find "loopholes" and "exceptions" to permit an over-stylization to mimic a trademark. A central principle at WP:CONSENSUS, WP:POLICY, and various other pages is that WP's rules (the policies and guidelines) are to be interpreted in the spirit in which they are intended, not with an eye toward system-gaming any weaknesses found in their wording. The absolutely clear intent at WP:MOS generally and MOS:TM and MOS:CAPS in particular, is that WP does not apply a stylization, including capitalization, to the name of any subject unless the vast majority of independent, secondary, reliable sources do so consistently with regard to that particular subject. That's clearly not the case with Epyc, who are capitalizing their logo in exactly the same manner as Sony's "SONY" logo. It simply is not an acronym, and nothing is going to change that fact. We all know that people get unreasonably hot around the collar about style matters (because, at the psychological level, everyone fluent in a language has an innate sense of "mastery" of it, and this leads to feelings that anyone who writes differently is "wrong" in a WP:TRUTH and WP:GREATWRONGS sense), so toying around with style in "live" articles in a willy-nilly manner is demonstrably disruptive. We spend more time at RM testily rehashing the same style matters – that are in fact already settled by the rules we have – than we do about virtually anything else, and this really needs to stop.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:40, 21 November 2017 (UTC)

  @SMcCandlish: You are right about consensus about language being difficult, but we did find something like that here without edit warring. Noteworthy, given the lively discussion. (Thought at no point did I consider it a "screaming", personally.) But I believe you've missed the issue with regards to the MOS. The question was no longer if a capitalized version should be used throughout (already settled in August), but centered around if "stylized as" should be used at all. (My fault for not creating a new section in October.) This goes to the clarity and relative weighting of the MOS. Even your example of Sony is confusing to me, it does not exactly jive with the Asus example on MOS:TM with regards to the stylized issue. If there is a consensus about if a "stylized as" should be used consistently, or some other standard, a note accordingly there would be helpful. I am not active on the MOS page, hence why I do not know the "clear intent" and asked for input. I have no desire/intent to wikilawyer, and am happy to reach any consensus/resolution. (as done here) But I suppose that consensus should fit the greater consensus on styles for the topic, and for WP in general (through the MOS). Dbsseven (talk) 20:09, 21 November 2017 (UTC)

  When people start commenting with things like "Don't ever pull something like this again", that's what I call screaming in this context. There is no consensus that a "stylized as" is required. It seems reasonable to include one, especially in absence of a logo, so people are certain they're on the right page (we can't assume that every reader is already certain whether the "EPYC" they encountered is an acronym or not or what it refers to). If we do illustrate the logo with its EPYC style, then a "stylized as" note is rather superfluous, and is likely why it was removed from the Sony article. I'm glad to see recognition that we no longer entertaining the idea of moving this to EPYC or writing "EPYC" throughout the article text. PS: Please keep replies attached to the posts they're replies to; and all this bulletizing is unnecessary (this isn't a vote, and bulletizing replies to the non-bulleted makes reply markup unnecessarily complicated).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  21:20, 21 November 2017 (UTC)

• MOSTMSTYLE clearly states that "it is conventional" (emphasis added) to include a stylization note in the lead, and explicitly includes "capitalization changes" within its purview. Looking through the discussion, I see no good reason to not include the note. If there is an objection to the guideline, it should be taken up at the MOS talk page. James (^talk/_contribs) 18:44, 21 November 2017 (UTC)

  I'd almost bet money that "capitalization changes" refers to situations such "iPod", and not to trivial ALLCAPSing. But again, this all sounds like wikilawyering, rather than focusing on what best serves the reader. The reader wants the text to get to the point, and does not want to traverse line noise such as predictable ALLCAPS variations of a trade name. Can someone give a cogent argument for interfering with the reading experience without resorting to "but if we stand on our heads, the MoS looks like it says ..." ...? Curly "JFC" Turkey 🍁 ¡gobble! 21:44, 21 November 2017 (UTC)

  I'd take that bet. It absolutely refers to what you call "trivial ALLCAPSing". Situations such as iPod are explicitly dealt with in a separate section of MOS:TM. What best serves the reader is a subjective ideal: I believe the reader is well-served by identifying variations on the topic's name. Nobody is standing on their heads, the guideline is perfectly clear – if you object to it, feel free to attempt to establish a global consensus for changing it. James (^talk/_contribs) 23:21, 21 November 2017 (UTC)

James: in other words, you prefer to stick to lawyering ("capitalization changes" == ALCAPS is quite the acrobatics). Why not at least go through the motions of providing that "cogent argument for interfering with the reading experience" I asked for? Because you don't actually have one? You simply love yourself them ALLCAPS? Curly "JFC" Turkey 🍁 ¡gobble! 00:06, 22 November 2017 (UTC)

That would probably be a better discussion on the MOS talk pages. But as I understand it, the reason for a MOS is that no single editor knows "what best serves the reader". This is why consensus building occurs for style, not just content. If a particular case/field is exceptional, then a local consensus can be found. (Curly Turkey, if you'd like the MOS simplified to "Consult Curly Turkey, they know what the reader wants", I wish you the best of luck.) Dbsseven (talk) 23:49, 21 November 2017 (UTC)

Dbsseven: That's all you got out of this discussion? No wonder we're going around in circles. Curly "JFC" Turkey 🍁 ¡gobble! 00:06, 22 November 2017 (UTC)

Certainly not all, Curly Turkey. Just summarizing. :) Dbsseven (talk) 00:15, 22 November 2017 (UTC)

It would be nice if editors could approach articles with the readers in mind, rather than interfere with editors who do. Curly "JFC" Turkey 🍁 ¡gobble! 00:18, 22 November 2017 (UTC)

I assume all editors do. Dbsseven (talk) 00:22, 22 November 2017 (UTC)

"they know what the reader wants" is hardly a shining example of AGF, and I don't see arguments being made that ALLCAPS benefits the reader—rather that it can be "gotten away with" if we read the MoS in a particular way. There's no end to the amount of sourcedd information that could be crammed haphazardly into an article that the MoS doesn't (and shouldn't) disallow, and we have mountains of nigh-unreadable messes throughout Wikipedia as a result. Some of us are trying to remedy that.

(If only I had the understanding to do that at Glycated_hemoglobin—I got a medical exam back yesterday and wanted to know what "Haemoglobin A1c" was. Wikipedia was the wrong place to try to find out ... I'm sure it all makes sense to the people who wrote it.) Curly "JFC" Turkey 🍁 ¡gobble! 00:58, 22 November 2017 (UTC)

How was quoting you ("The reader wants...") within "they know what the reader wants" not AGF? I wished you good luck even. Dbsseven (talk) 01:03, 22 November 2017 (UTC)

In seriousness, I do know some biochemistry and might be able to answer your A1c question(s) (Olive branch).Dbsseven (talk) 01:08, 22 November 2017 (UTC)

Thanks! My question is: what is it, and why should I care (apparently my numbers were fine, I just had no idea what the numbers were referring to). Curly "JFC" Turkey 🍁 ¡gobble! 01:50, 22 November 2017 (UTC)

(Over)Simplified, A1c is checking for diabetes by measuring you average blood sugar over the last few months. This is better in many respects than your current blood sugar. If you just drank a Pepsi and had high blood sugar, that might be okay. But if you were fasting and had high blood sugar, not okay. Measuring A1c takes the timing out of the test. As for what it does: it measures the amount of the hemoglobin (the red, oxygen carrying protein in your blood) which has reacted with the sugar in your blood. This reaction happens naturally, but if you've got more sugar in your blood it happens more often. As your red blood cells have a fixed lifetime, ~3-months, this gives an average of your blood sugar over that time. (Plus in the medical world, I imagine they like things they can measure from blood. It's a lot easier than a biopsy.) Dbsseven (talk) 02:18, 22 November 2017 (UTC)

Well, that was nice & clear! One more question: they only took one blood sample. How could they know my blood sugar level for the previous three months? Curly "JFC" Turkey 🍁 ¡gobble! 02:43, 22 November 2017 (UTC)

Because the blood cells only "survive" 3 months. The hemoglobin was modified sometime after it was made, so measuring your A1c from that sample gives an average over that time window. (But this is only an average, they don't know what is was 3 months ago or what it is today, from this test.) A poor analogy: Say you want to know where a tiger generally lives, it's range. You can check on that tiger every day... Or you can note where all the paw-prints are, and conclude it has lived in somewhere within the range defined by those the paw-prints since the last time it rained. (Sorry, not the best analogy but having trouble coming up with something better.) Dbsseven (talk) 03:07, 22 November 2017 (UTC)

Okay, I think you've answered my question well enough. thanks again! Curly "JFC" Turkey 🍁 ¡gobble! 04:59, 22 November 2017 (UTC)

Million-dollar question: Are they vulnerable to Meltdown and/or Spectre? –61.2.48.24 (talk) 09:19, 18 September 2018 (UTC)

Nope for Meltdown and very limited to Spectre (besides Spectre V1 which affects all modern processors to date). --Denniss (talk) 11:31, 18 September 2018 (UTC)

https://www.planet3dnow.de/cms/54858-fuenf-neue-amd-epyc-prozessormodelle-mit-teilweise-deutlich-hoeherem-basistakt-gelistet/ -- 92.117.191.78 (talk) 13:08, 11 February 2020 (UTC)

As far as I can tell, this diff on the 23rd shortly after some guy on Quora backronym'd it. A few news sources including NASDAQ on the 26th and Yahoo on the 27th (and only in sources appearing after the 23rd) then appear to have used the uncited edit as a source and should not be used to readd the acronym to the article (as this would create a false citation loop).Techhead7890 (talk) 09:54, 18 March 2021 (UTC)

The Milan section really needs updating from future tense to present tense, but I can't be arsed to rewrite it all. (I wish people would care more for the stuff they originally write here) --jae (talk) 06:08, 25 March 2022 (UTC)

Hey, I went and updated some of the Milan stuff and added Milan-X, let me know if I missed anything --Justanotherintrovert (talk) 22:24, 27 April 2022 (UTC)

All the models tables are in super inconsistent organization. Milan is sorted in descending order of core count, Naples is sorted in ascending order of price, and I'm not quite sure what Rome is doing. Snowy Owl also follows descending order of core count, and I think all the tables should be updated to reflect that, but wanted to get feedback here first, any other suggestions? Justanotherintrovert (talk) 22:28, 27 April 2022 (UTC)

Not only that, but also, Epyc 7001 series has release dates and prices combined into one column, 7002 series has them separately, and 7003 series omits the release date column. AP 499D25 (talk) 14:15, 24 November 2022 (UTC)

It makes the most sense for processors to be organized by their names in ascending alphabetical/numerical order. CristoCalis (talk) 15:33, 24 November 2022 (UTC)

Is there a reason this article omits all of the vendor-specific OEM releases? Specifically the parts for MS Azure, Google, and Amazon.They are starting to come up on the secondary market. It was very confusing not finding them here. The 7B12 OPN-100-000000020, 7V12 OPN-100-000000056, 7D12 OPN-100-000000044, 7R12 OPN-100-000000027, 7R32 OPN-100-000000091, 7K62 OPN-100-000000109, 7V13 OPN-100-000000320, and more, EPYC 7713, 7543, 7J13, 7T83. Evil genius fin (talk) 23:24, 2 March 2023 (UTC)

After a year without any reaction, it is time to propose a table listing all vendor-specific OEM processors. Data-centers sell their old hardware including these OEM processors. I have also been confused not finding them on Wikipedia :-/ Oliver H (talk) 11:49, 25 March 2024 (UTC)

I'm not a sophisticated enough editor to add the required code. But I'm certainly willing to deep dive all the info and update the charts. If someone else will add the section. LFG Evil genius fin (talk) 04:53, 22 January 2025 (UTC)

There is no mentions about embedded 7001, 7002 or 9004 series? ,

Should we treat this as new entries, like Embedded 3000 series is?

Or we just add note to existing 7001/7002/9004 sections (and tables), for example "also available as embedded X model" or something. Specs are more or less the same, what would be the point of identical tables. Rando717 (talk) 21:30, 1 April 2023 (UTC)

I would add them in a separate section on the Epyc article. Although, if the Epyc Embedded processors are radically different from the normal server ones enough that there would be significance in creating a separate article about them, then creating an article is the logical option. — AP 499D25 (talk) 12:52, 11 May 2023 (UTC)

Forgot to reply... I recently changed first gen table design and added "embedded option" column with links pointing to embedded counterparts. Any thoughts about it? Rando717 (talk) 19:20, 18 October 2023 (UTC)

Should the lineup for the Epyc 8004 Siena SKUs be in its current location in the 4th gen table alongside Genoa and Bergamo CPUs or should it be moved under the embedded section alongside Snowy owl? There's already an embedded specific CPU lineup for Genoa, but the parts are basically 1:1 from a spec perspective Justanotherintrovert (talk) 12:03, 18 October 2023 (UTC)

Epyc 8004 series SKUs are Zen4c based CPUs using SP6 LGA socket, unlike embedded BGA package. I don't think they belong inside embedded section next to Snowy owl series. Zen4 and Zen4c cores are identical (arhitectually), so in my opinion they should remain within 4th-gen section. But I don't think they should be inside same table with Genoa and Bergamo models, because of different sockets (SP5/SP6) and naming convention (8004/9004).

A while ago, I started working on unified design for all Epyc and embedded tables (including Ryzen), but didn't released anything until recently on first gen tables. [example]

I lost time (and will) to search for references about OEM models. If you want, you are welcome to take 8004 section and make "AMD Epyc 8004 series" template from it. Rando717 (talk) 19:01, 18 October 2023 (UTC)

I'm absolutely terrible at table formatting so maybe someone else can tackle it, but some new 3rd gen EPYCs were recently launched in September and aren't on the table. Stormscape 09:27, 15 November 2023 (UTC)

To those who regularly update this article: today AMD introduced the Epyc 4004 series, which are apparently processors that utilise the AM5 platform and go up to 16 cores, with some 3D V-Cache variants available as well: announcement.

I'm guessing they'll go under the "Epyc 4th gen 9004 series" table but tbh I think we should split up the template into separate templates for the Epyc 4004, 8004, 9004 and 9704 processors. — AP 499D25 (talk) 02:13, 22 May 2024 (UTC)

I am looking for AMD server CPUs with the largest possible cache size accessible per individual core, to exceed the single-thread performance of the 96 megabyte shared L3 of the consumer 7800X3D CPU.

It is very ambiguous in these specifications if the L3 cache is shared across all Epyc cores in the socket package, or if for example it is using a segmented / chiplet design whereby 144 cores may be claimed to have 768 megabytes of L3, but each group of 8 cores only has access to a maximum of 64 megabytes of L3.

This is regarding ridiculously huge Factorio mega-factories and heavily modded kitchen-sink Minecraft (ATM8 / ATM9), trying to achieve the maximum possible single-core performance (4 ghz / 1/60th second = a maximum of only 66 million clock cycles available per Factorio tick) via huge L1/L2/L3 static-RAM caches with no wait states, and a minimum of slow main-memory dynamic-RAM refresh wait states. -- DMahalko (talk) DMahalko (talk) 17:58, 24 May 2025 (UTC)