Better get to the bottom of the mystery surrounding Apple's ECC patents on LPDDR ECC or you will have to make a leap of faith that your database on their chips won't wind up cruddy in a Bad Way. All we have now are assumptions and educated guesses about what they may be doing. It's also going to be an issue with AMD 395+ and nVidia+MediaTek GB10 (but I would assume NO ECC on those SoCs, based on their history).

It may only be a few mm to the LPDDR5 arrays inside the SoC, but there are all sorts of environmental/thermal/power and RFi considerations, especially on tiny (3-5nm) nodes! Switch on the numerical control machine on the other side of the wall from your office and hope your data doesn't change.

There are already big servers designed for huge single databases, for example the 8-socket Xeon types. Tbh I don't understand exactly why RAM is such a concern, but these machines have TBs of it.

Woah, 8x Xeon CPUs on a single motherboard. That is a new record for me.

I found one here from Supermicro: https://www.supermicro.com/en/products/motherboard/X13OEI-CP...

Has anyone see one of these in action? What was the primary use case? Monolithic database server?

I think a bigger business case is virtual machine hosting, say one of these is maxed out (8 Xeons with 56 cores ie 448 cores and 32tb of memory), say it's divided into a 1000 machines you can run each VM with 40% cpu utilization and 3gb of memory, considering many VM offerings have less RAM (and add a bit of overselling on top of it with regards to CPU) it could probably house over 2000 VM's.

You can do that more cheaply with separate machines. The use case for this mega one really is monolothic DB or server.

The question is about embedded DRAM, not trying to put a Mac in the data center. I am unaware of an apples to apples comparison here, but on the same Intel and AMD platform there can be a performance increase associated with embedded high speed LPDDR5 vs something on an SODIMM, which is why CAMM is being developed for that space.

I would be interested as well in what an on chip memory bank would do for an EPYC or similar system since exotic high performance systems are fun even if all I’ll ever touch at this point is commodity stuff on AWS and GCP.

He edited his comment. The previous version did reference the 512 GB being so big that it'd be a game changer for servers.

Yeah, 512GB was a game changer for servers... with DDR3...

And that wasn’t even where it topped out, there were servers supporting 6TB of DDR3 in a single machine. DDR4 had at least 12TB in a single (quad-CPU) machine that I know of (not sure if there were any 96*256GB DDR4 configs). These days, if money’s no object, there exist boards supporting 24TB of DDR5. I think even some quad-CPU DDR2-era SKUs could do 1.5TB. 512GB is nothing.

(Not directly in response to you, just adding context.)

While I did make a couple of cosmetic edits within a few minutes of posting (before there were any replies), even the original was referring to the speed of the memory ("on-chip"), not its size.

You misunderstood my post, and I don't appreciate the tone of your reply.

I didn't appreciate you removing everything I responded to either, replacing it with something making my comment look entirely out of context.

While I believe you that you meant to write about the different performance profile of on chip memory, that's not what you did at the time I wrote my reply. What you actually did write was how 512 GB of RAM might revolutionize i.e. database servers. Which I addressed.

And if you hadn't written that, I wouldn't have written my comment either, because I'm not a database developer that could speculate on performance side-grades of such kind (less memory, but closer to the CPU)

This is ridiculous, I changed like 3 words. While I did originally mention 512GB, the context (“on-chip”) made it clear I was referring to the speed, not the size.