“ Users will notice that the 16-core processor is more expensive ($3521) than the 24 core processor ($2900) here. This was the same in the previous generation, however in that case the 16-core had the higher TDP. For this launch, both the 16-core F and 24-core F have the same TDP, so the only reason I can think of for AMD to have a higher price on the 16-core processor is that it only has 2 cores per chiplet active, rather than three? Perhaps it is easier to bin a processor with an even number of cores active”
I really don't think the article's speculation there is helpful... it's really reaching.
As I said below the article in the comments:
> If I were to speculate, I would strongly guess that the actual reason is licensing. AMD knows that more people are going to want the 16 core CPUs in order to fit into certain brackets of software licensing, so AMD charges more for those to maximize profit and availability of the 16 core parts. For those customers, moving to a 24 core processor would probably mean paying significantly more for whatever software they're licensing.
This is the more compelling reason to me, and it matches with server processors that Intel and AMD have charged more for in the past.
"Even vs odd" affecting the difficulty of the binning process just sounds extremely arbitrary... definitely not likely to affect customer prices, given how many other products are in AMD's stack that don't show this same inverse pricing discrepancy.
That paragraph struck me as poorly thought out/written as well. I think finding chiplets that will run two cores at the higher 3.5ghz clock is the tricky part, not that it's harder to pick the 2 fastest cores than pick 3.
Still seems like a typo, it doesn't make any sense that the 24 / 48 would be priced between the 8 / 16 and the 16 / 32. Either the prices of the 73 and 74 were swapped or the tag is just plain wrong. "2900" is also very suspiciously round compared to every other price on the press release.
It makes perfect sense if you're an enterprise customer and your software dependencies charge you extremely different priced tiers for different maximum numbers of cores. AMD is selling a license-optimized part at a higher price because there will be plenty of demand for it.
People who don't save a boatload by getting the license-optimized CPU will invariably choose to buy the 24-core one, which helps AMD by making it easier for them to keep up with the demand for the 16-core variant, and the 16-core variant gets an unusually nice profit margin. Win win.
This is not the first time AMD or Intel have offered a weird inverse-pricing jump like this... I highly doubt it is a typo.
Yep - in the past I've done "special orders" for not-publicly-advertised CPU configs from our hardware vendor to get low core count, high-clock servers for products like Oracle DB.
It doesn't seem to be a typo. AMD offers many variations of each core configurations, with different base frequencies. It's just that there are simply pricing overlaps between some low-core high-freq version and some higher-core lower-freq versions. For example the 7513 (32 cores) is also cheaper than the 73F3 (16 cores).
256MB L3 (or really, 8 x 32MBs L3) and 24-cores suggests the bottom-of-the-barrel 3 cores active per 8-core CCX.
8x CCX with 3-cores. The yields on those chips must be outstanding: its like 62.5% of the cores could have critical errors and they can still sell it at that price.
EDIT: My numbers were wrong at first. Fixed. Zen3 is double-sized CCX (32MBs / CCX instead of 16MBs/CCX)
---------
In contrast, the 28-core 7453 is $1,570. I personally would probably go with the 28-core (with only 2x32MB L3 cache, or 64MBs) rather than the 24-core with 256MBs L3 cache.
For my applications, I bet that having 7-cores share an L3 cache (and therefore able to communicate quickly) is better than having 1 or 2 cores having 32MBs of L3 to themselves.
There are also significant price savings, as well as significant power / wattage savings with the 28-core / 64MBs model.
Which is cheaper than the 24c 7443 and 7413 but not the 16c 7343 and 7313.
And it only has half the L3 compared to its siblings (1/4th compared to the 7543 top end), a lower turbo than every other processor in the range (whether lower or higher core counts), well as an unimpressive base frequency, and a fairly high TDP by comparison (as high as the 7543).
The 74F3 has no such discrepancy, it has the same L3 as every other F-series and slots neatly into the range frequency-wise: same turbo as its siblings (with the 72 being 100MHz higher), 300MHz base lower han the 73, and 250 higher than the 75.
> Which is cheaper than the 24c 7443 and 7413 but not the 16c 7343 and 7313.
28-cores for $1570 seems to be the "cheapest per core" in the entire lineup.
It all comes down to whether you want those cores actually communicating over L3 cache, or not. Do you want 7-cores per L3 cache, or do you prefer 4-cores per L3 cache?
4-cores per L3 cache benefits from having more overall cache per core. But more-cores per L3 cache means that more of your threads can tightly-communicate cheaply, and effectively.
---------
More L3 cache probably benefits from cloud-deployments, Virtual Desktops, and similar (since those cores aren't communicating as much).
More cores per L3 cache benefits from more tightly integrated multicore applications.
EDIT: Also note that "more cores" means more L1 and L2 cache, which is arguably more important in compute-heavy situations. L3 cache size is great of course, but many applications are L1 / L2 constrained and will prefer more cores instead. 24c 7443 with 2x32MB L3 is probably a better chess-engine than 16c 7343 4x32MB L3.
I am building a single socket server right now, I can't really justify more than twice the price of a 7443P for a marginally higher base clock and twice the cache. Does the cache makes that much of a difference? I thought these are already very large caches vs lots of Intel CPUs.
Hmm, with AMD Threadripper, you're already looking at TLB issues at these L3 sizes. So if you actually want to take advantage of lots of L3, you need either many cores, or hugepages.
Case in point: AMD Zen2 has 2048 TLB entries (L2), under a default (in Linux and Windows) of 4kB per TLB entry. That's 8MBs of TLB before your processor starts to page-walk.
Emphasis: Your application will pagewalk when the data still fits in L3 cache.
------------
I'm looking at some of this lineup with 3-cores per CCX (32MBs L3 cache), which means under default 4kB pages, those cores will always require a pagewalk to just read/write its 32MBs L3 cache effectively.
With that being said: 2048 TLB entries for Zen2 processors. Maybe AMD has increased the TLB entries for Zen3. Either way, you probably should start looking at hugepage configuration settings...
These L3 cache sizes are absurd, to the point where its kind of unwieldy. I mean, with enough configuration / programming, you can really make these things fly. But its not exactly plug-and-play.
The 64k page size available on Arm (and Power) makes a lot more sense with these kind of cache sizes. With 2MB amd64 hugepages its only 16 different pages in that L3 cache, which for a cluster of up to 8 CPUs is not much at all when using huge pages.
TLB-misses always slows down your code, even out-of-cache.
So having 2MB (or even 1GB) hugepages is a big advantage in memory-heavy applications, like databases. No, 1GB pages won't fit in L3 cache, but it still means you won't have to page-walk when looking for memory.
1GB pages might be too big for today's computers, but 2MB pages might be good enough for default now. Historically, 4kB was needed for swap purposes (going to 2MB with Swap would incur too much latency if data paged out), but with 32GBs RAM + SSDs on today's computers... fewer and fewer people seem to need swap.
There might be some kind of fragmentation-benefit for using the smaller pages, but it really is a hassle for your CPU's TLB to try to keep track of all that virtual memory and put it back in order.
---------
While there is performance hits associated with page-walks, the page-walk process is fortunately pretty fast. So most applications probably won't notice a major speedup... still though, the idea of tons of unnecessary page-walks slowing down untold amounts of code bothers me a bit for some reason.
Note: ARM also supports hugepages. So going up to 2MBs (or bigger) on ARM is also possible.
