201–210 of 303 posts
These sorts of core-density increases are how I win cloud debates in an org. * Identify the workloads that haven't scaled in a year. Your ERPs, your HRIS, your dev/stage/test environments, DBs, Microsoft estate, core infrastructure, etc. (EDIT, from zbentley: also identify any cross-system processing where data will transfer from the cloud back to your private estate to be excluded, so you don't get murdered with egr…
Earlier quoted context omitted.
RAM! (And NAND SSDs too now, probably...) When I was looking in October, I hadn't bought hardware for the better part of a decade, and I saw all these older posts on forums for DDR4 at $1/GB, but the lowest I could find was at least $2/GB used. These days? HAH! If I had a decent sales channel I might be speculating on DDR4/DDR5 RAM and holding it because I expect prices to climb even higher in the coming months.
I don't remember DDR4 ever hitting $1/GB. Was I not shopping in the right places? IIRC DDR3 settled in at $1/GB quite a long time ago and recycled datacenter DDR4 was maybe ballpark $2.50/GB at some point.
For my hacking purposes it would have been perfect. It's hard to justify the project at even $2/GB though.
With packages like this (lots of cores, multi-chip packaging, lots of memory channels), the architecture is increasingly a small cluster on a package rather than a monolithic CPU. I wonder whether the next bottleneck becomes software scheduling rather than silicon - OS/runtimes weren’t really designed with hundreds of cores and complex interconnect topologies in mind.
I don't think there are any fundamental bottlenecks here. There's more scheduling overhead when you have a hundred processes on a single core than if you have a hundred processes on one hundred cores. The bottlenecks are pretty much hardware-related - thermal, power, memory and other I/O. Because of this, you presumably never get true "288 core" performance out of this - as in, it's not going to mine Bitcoin 288 as f…
You memory only has so much bandwidth, but now it's shared by even more cores.
> From a cache hierarchy standpoint, the design groups cores into four-core blocks that share approximately 4 MB of L2 cache per block. As a result, the aggregate last-level cache across the full package surpasses 1 GB, roughly 1,152 MB in total.
If cores are grouped into four-core blocks, and each block has 4MB of cache… isn’t that just 1MB per core? So 288MB total?
HotHardware reports
https://hothardware.com/news/intel-clearwater-forest-xeon-6-...
> these processors pack in up to 288 of the little guys as well as 576MB of last-level cache, 96 PCIe 5.0 lanes, and 12-channel DDR5-8000.
> The Xeon 6+ processors each have up to 12 compute tiles fabbed on 18A, all of which have six quad-core modules for a total of 24 cores per tile. There are also three 'active' base tiles on Intel 3, so-called because the base tiles include 192MB of last-level cache, which is so-called because each compute tile has 48MB of L3 cache.
So maybe 1MB per core L2, then 192MB of basically-L4 per base tile, then 48MB of L3 per compute tile? 192*3+48*12 gets me to the 1152, maybe that’s it.
Anyway, apparently these things will have “AMX” matrix extensions. I wonder if they’ll be good number crunchers.
With packages like this (lots of cores, multi-chip packaging, lots of memory channels), the architecture is increasingly a small cluster on a package rather than a monolithic CPU. I wonder whether the next bottleneck becomes software scheduling rather than silicon - OS/runtimes weren’t really designed with hundreds of cores and complex interconnect topologies in mind.
Yes there are scheduling issues, Numa problems , etc caused by the cluster in a box form factor. We had a massive performance issue a few years ago that we fixed by mapping our processes to the numa zones topology . The default design of our software would otherwise effectively route all memory accesses to the same numa zone and performance went down the drain.
Earlier quoted context omitted.
Intel contributes to Linux, how is this a problem?
Wrong level of abstraction. NUMA is an additional layer. If the program (script, whatever) was written with a monolithic CPU in mind then the big picture logic won't account for the new details. The kernel can't magically add information it doesn't have (although it does try its best). Given current trends I think we're eventually going to be forced to adopt new programming paradigms. At some point it will probably m…
Earlier quoted context omitted.
E cores ruined P cores by forcing the removal of AVX-512 from consumer P cores Which is why I used AMD in my last desktop computer build
E cores didn't just ruin P cores, it ruined AVX-512 altogether. We were getting so close to near-universal AVX-512 support; enough to bother actually writing AVX-512 versions of things. Then, Intel killed it.
Earlier quoted context omitted.
I'm one of those people, and I don't agree. Before I drop 5 figures on a single server, I'd like to have some confidence in the performance numbers I'm likely to see. I'd expect folk who are experienced with on-prem have a good intuition about this - after a decade of cloud-only work, I don't. Also, cloud networking offers a bunch of really nice primitives which I'm not clear how I'd replicate on-prem. I've estimated…
> Also, cloud networking offers a bunch of really nice primitives which I'm not clear how I'd replicate on-prem. Like what?
In AWS, it's straightforward to say e.g. "permit traffic on port X from instances holding IAM role Y".
You can easily e.g. get the firewall rules for all your ec2 instances in a structured format.
I really would not look forward to building something even 1/10th as functional as that.
I’ve not kept up with Intel in a while, but one thing that stood out to me is these are all E cores— meaning no hyperthreading. Is something like this competitive, or preferred, in certain applications? Also does anyone know if there have been any benchmarks against AMDs 192 core Epyc CPU?
Also have seen it disabled in academic settings where they want consistent performance when benchmarking stuff.