News Massive LGA7529 Socket for Intel's 'Sierra Forest' Pictured

Page 2 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.

JayNor

Reputable
May 31, 2019
430
86
4,760
I believe EMR will update CXL.MEM, and expect to see more use of CXL memory pools. Nextplatform has also pointed to a slide for EMR that says "next gen HBM". HBM3 doubles channels per stack to 16. That's a nice boost for EMR.

Don't know if any of this applies to Sierra Forest, but it does come later ...
 
  • Like
Reactions: bit_user

bit_user

Polypheme
Ambassador
Anyway, it feels like you're grasping at straws, here. If you think encryption (which is an non-overloaded term you could use, in the future) is a significant workload component or one that justifies the amount of cores in Sierra Forest, the burden of proof is on you to demonstrate that.

I don't really care. I'm not saying your definitely wrong, just that you haven't made a compelling case.

You were dead wrong about AI, though, which implies these notions weren't well-sourced. If you want to improve the signal-to-noise ratio of these forums, I'd advise refraining from such reckless claims.
 
Last edited:

bit_user

Polypheme
Ambassador
I believe EMR will update CXL.MEM, and expect to see more use of CXL memory pools.
But, they won't be ugrading the PHY speed (i.e. still PCIe 5.0-equivalent). It takes about 9 PCIe 5.0 lanes to equal one channel of DDR5, on these CPUs. So, if you repurposed 80 lanes for CXL.mem, you'd only get the equivalent of 8-9 additional DDR5 channels worth of memory bandwidth. That's not nothing, but it's not even a doubling and it's also unlikely most customers will go that far.

My take on CXL.mem is that it's really about scaling capacity more than bandwidth. The big capacity gains come from CXL 2.x, which incorporates support for a switch fabric.

Nextplatform has also pointed to a slide for EMR that says "next gen HBM". HBM3 doubles channels per stack to 16. That's a nice boost for EMR.
"The number of memory channels was doubled from 8 channels of 128 bits with HBM2e to 16 channels of 64 bits with HBM3. Therefore, the total number of data pins of the interface is still 1024."

However, they also doubled the peak specified data rate. So, the fastest HBM3 memory should have the same channel bandwidth as the peak HBM2e spec, while having 2x the channels. That said, it'll probably be a while before we see shipping HBM3 reach that peak.

Don't know if any of this applies to Sierra Forest, but it does come later ...
Eh, the more cores or SMT threads you have, the more memory you typically need. Splitting however much HBM they can fit (80 GB? 120 GB?) across the majority of Sierra Forest's cores won't go very far. When provisioning a VM, my starting point is usually about 1 GB per thread, but it's obviously workload-dependent.

The next option would be to use memory tiering, which might indeed be viable by then.

Lastly, you could simply use it as a L4 cache, but we have yet to see how well that works, in practice.
 
Last edited:

InvalidError

Titan
Moderator
Anyway, it feels like you're grasping at straws, here. If you think encryption (which is an non-overloaded term you could use, in the future) is a significant workload component or one that justifies the amount of cores in Sierra Forest, the burden of proof is on you to demonstrate that.
Pervasive encryption is a thing and in a DB protected with pervasive encryption, every attempt at manipulating protected columns would require decryption of selected cells. Can't imagine that amount of overhead being cheap. Make it cheap enough though and it is likely more companies will deploy more of it to reduce their data breech liabilities.
 

bit_user

Polypheme
Ambassador
Pervasive encryption is a thing and in a DB protected with pervasive encryption, every attempt at manipulating protected columns would require decryption of selected cells. Can't imagine that amount of overhead being cheap. Make it cheap enough though and it is likely more companies will deploy more of it to reduce their data breech liabilities.
Sorry, I don't find your imagination a particularly useful data point.

So, we're just missing:
  • Examples of database that work or are deployed this way.
  • Performance data to quantify the impact of the added encryption.
  • Any sort of data on market or usage trends.