User talk:Incassum

AMD CPU Naming
Sorry for the back and forth edits on the Black Edition stuff. Can you refer to where AMD states to use the BE abbreviation with no space, or find an list on their site? Generally I've really been hating AMDs naming rules, since they seem to switch up frequently (i.e. X6 vs 6-core, Black Edition vs Black), and seem to lack consistency even across their own pages. Kolano (talk) 03:20, 13 January 2014 (CET) Hmm, the more I look, the more it seems I was wrong. Using "BE" without a space in-between seems to merely be a convention when talking about those CPUs on the net/forums (and, as with most things on the net, even that is not 100% consistent), and as far as AMD themselves go, they actually do not use "BE" at all. When they refer to their own CPUs internally (on their site), it seems that they consistently write out the entire "Black Edition" bit (as e.g. here). However, looking for the actual model names brings up something interesting: This link and this official model number list, which lists official AMD desktop CPUs along with names/model numbers. Guess what? The actual model names do not use the letters at all. Technically, there is no such thing as neither a "975 BE" or a "975BE"; there is, however, a "975", officially called (but not bearing the actual model name of) "975 Black Edition" since it is "available as a Black Edition PIB" (coincidentally, there are no non-black edition variants of the 96x, 97x and 98x series in existence (at least not of the tray/boxed versions (part numbers ending in "BOX" as opposed to "DGM" which are OEM pieces)). With this in mind, it seems that the only option left to us if sticking with giving official/manufacturer-given names is to skip the "BE" altogether and either use "9xx" or "9xx Black Edition", as those are the only officially valid/correct names. If, however, we are prepared to let go of being manufacturer-loyal in our writing/naming-conventions, it's up to us to choose whether we'd like to use "BE" with or without a space, in which case I suggest without a space as that seems to be the consistently most used across the web, especially amongst hardware-geeks. One notable exception to this is Anandtech, which uses a space. incassum (talk) 22:32, 13 January 2014 (CET)

Thanks for the further investigation Incassum. You did confirm something I suspected, but hadn't looked into in that typically BE CPUs don't exist as non-BE, so it isn't a distinguishing factor. We had brought in the central manufacturer naming rule to help avoid the plethora of names that can arise for chipsets between general shortenings and sub-manufacture's naming. I believe you are right that AMD seems to never use the "BE" acronym, but you can see them vacillate between "Black Edition" and "Black", likely where they need to trim things up a bit. Given that the inconsistency there bothers me a bit, I may lean toward just purging the various BE texts generally, since it doesn't provide a distinguishing characteristic of things. We can already see higher overclocks those chips might allow in the "@ XXXGHz" postfixes. My main goal here is for there to be some consistency in the testing results to make them more generally applicable (and hopefully parsable for future metrics/compatibility list enhancements). Kolano (talk) 22:56, 13 January 2014 (CET) No need to thank me, we are all working for free here. Hmm, I can see the point of that in GPU naming conventions, however, as far as CPUs go, there isn't really a problem of people using radically different names for them, is there? And we don't even request name-dropping the chipset (which in the case of AM3/AM3+ CPUs would be e.g. 7xxxx, 8xxxx and 9xxxx)in the case of CPUs, so I don't think that there is a problem there, short of what we are discussing now (i.e. the "BE"-issue). Futher, nowhere have I found a place where AMD themselves refer to any CPU as only "Black", as far as I've been able to find they consistently use "Black Edition", so if you found them using only "Black" from a reliable source, then it is a practice which seems to be deprecated/changed and retroactively removed, so at least we don't have to worry about that. In the interest of sticking with something that is already prevalent, I, as stated above, would prefer to not use a space; further, for the sake of future parsing and the like, any and all *nix-users should know that using spaces where they are not absolutely needed is evil, haha. incassum (talk) 17:39, 14 January 2014 (CET)