AMD Ryzen 7 5800X3D Continues Showing Much Potential For 3D V-Cache In Technical Computing

[bridgman]

Yep... going with a mid-sized package that was sufficiently smaller to make a big cost difference would also require a third (mid-sized) I/O die somewhere between the client (125mm^2 ?) and server (416mm^2 ?) I/O dies we have today.

The question marks are because I am going from memory.

[fuzz]

Something is off with the xmrig benchmarks. Neither of them are near where they should be, at least for the Monero variant, and other benchmarks have shown that the 5800X3D variant is roughly on-par with the 5800X if not a tad slower (not counting overclocking). This is because the RandomX algorithm already uses 2MB/thread which the 5800X can handle fine.

Basically, don't get the 5800X3D expecting faster monero mining performance. I've been able to personally confirm this .

https://xmrig.com/benchmark?cpu=AMD+...Core+Processor
https://xmrig.com/benchmark?cpu=AMD+...Core+Processor

EDIT: That said, it's possible with undervolting that the X3D can be more power efficient per hashrate. Depends on the motherboard etc and what they allow you to set.

[chocolate]

I would think its about the cache holding more code/data, so when the engine does something atypical, whatever its churning through is more likely to already be in the cache.

Have a look at this.

https://www.youtube.com/watch?v=t_rzYnXEQlE

Not sharing stuff that is already in memory somewhere else is an industry standard apparently since the inception of large 3D games. We can speculate that games that stutter because of I/O (yes, after removing shader compilation stutters), with nothing particularly fancy on screen to justify it (say, effectively hundreds or thousand of objects/units with a complex behavior attached, implying descriptors with various pointers and so on), have nasty code with tons of duplication, probably a broken object model, and generally rushed routines written months before shipping.

[fuzz]

If by "2MB/thread" you don't mean pagesize: With 5800X3D it could use 6MB/thread (6MB*16=96MB), no?

One of the xmrig developers has to get her/his hands on an 5800X3D before it can be concluded whether 5800X3D has a hashrate similar to 5800X.

It's a strict limitation of the RandomX algorithm, necessary because of the nature of distributed proof of work. I think anything else would be a new algorithm and not necessarily usable by Monero.

[fuzz]

Are you sure that executing 2 or 3 RandomX programs per 1 CPU thread (because 5800X3D has enough L3 cache to run multiple RandomX programs per core) will fail to achieve a significantly higher (such as: +25%) hashrate?

Indeed, that is one of the first things the xmrig developers suggested to me. It only reduced the hash rate (though not too much).