8 ms·
AMD’s 7950X3D: Zen 4 Gets VCache
- metadat 4y agoI wish they'd also test xz andaune also RAR compression for vanilla vs vCores. It'd be interesting to learn if / how the results differ depending on compression implementation.
- shmerl 4y agoSomewhat moot benefit if scheduler doesn't decide what core to use depending on what the thread is doing.
- 7e 4y agoThe scheduler might be able to do it, but apps like games can always pin their threads by hand.
- syntheticcdo 4y agoNo need - the chipset drivers automatically park the non-VCache CCD cores when a game is running (effectively turning the 7950X3D into a 7800X3D).
- shmerl 4y agoHow would they know it's a game or not a game? I'm playing my games on Linux anyway. Haven't heard of schedulers using such logic. I'd expect some kind of predictive AI that analyzes thread behavior to be able to help. But not sure if anyone tried making a scheduler like that.
- wmf 4y agoUnder Windows the driver has a whitelist of process names that it recognizes and pins to V-cache. Of course you don't have these problems if you buy the 7800X3D...
- fredoralive 4y agoAIUI they currently use a rather basic system on Windows that asks "is the Xbox game bar active?", and using that to switch off the low cache cores. I suspect if these sorts of chips become common we might get something a bit more nuanced.
- sharpneli 4y agoIt’s the same mechanism that triggers the game mode in Windows. You can tag a program in the Xbox game bar as a game if it hasn’t recognized it by default.
- sudosysgen 4y agoWindows already has a system for detecting what is and isn't a game for purposes of switchable graphics laptops, so I imagine they reuse that. You can get pretty good heuristics by looking at graphics API usage. On Linux you could just put the appropriate taskset or numactl command in your game shortcut, it's pretty easy.
- ece 4y agoAnd this works pretty well, there's flickering on screen, but it is switching graphics. Maybe there's also some mouse stuttering or something as threads are moved to the active chiplet. This basically seems like AMD's version of big.LITTLE, except there's only a cache and frequency difference between cores, not altogether different cores.
- ilyt 4y agoWell, the simplest one would be "prioritize whatever talks with input devices and video card" I guess the hard part would be distinguishing between "a video game getting inputs" and "discord app getting push to talk key", but at the moment you moved all of the noninteractive system stuff to slow cores and only "things using keyboard" on fast cores it's already pretty good approximation.
- shmerl 4y agoNot every game benefits from it as well (vs higher core clocks), so it's not really a comprehensive method.
- shmerl 4y agoPinning anything by hand defeats the purpose. You'd need to benchmark things first to figure out if it helps or not. Too manual.
- tpxl 4y agoSome games do run benchmarks to figure out recommended settings for your setup.
- secondcoming 4y agoDefeats the purpose of what? Core isolation and pinning is very common.
- loeg 4y agoThe smaller Vcache devices (8 cores and fewer) uniformly have access to the large L3 (though not the 16-core 7950 review unit in the article).
- shmerl 4y agoYeah, the point is about 16 core one.
- naiv 4y agoI have absolutely no idea regarding cpus but would this also speed up database caching?
- stingraycharles 4y agoGenerally memory has different access speeds. In order for a CPU to actually perform operations on the data, it needs to be loaded into the memory closest to / within the CPU. L1 cache is the fastest (and closest to the CPU), but there’s very few of it. There’s also L2, L3 and L4, each being slightly slower but larger than the previous one. VCache is a new kind of mechanism where the caching layer is placed vertically “on top” of the CPU. This unlocks new possibilities, and possibly more cache available at lower access times, but there are some technical challenges to make it work. It will enable your database to perform computations faster, as more data can be stored closer to the CPU.
- loeg 4y agoVCache is more or less just a big L3 cache, with some quirks due to the way it is implemented. It's slightly slower than on-die L3 (~10%); on the bigger chips, it can only be accessed from a single CCD, etc.
- justsomehnguy 4y agoNot if you modus operandi is to SELECT * FROM t1 WHERE (SELECT * FROM t1 WHERE (SELECT * FROM t1.... EDIT: for whose who downvoted: https://news.ycombinator.com/item?id=32720856 https://news.ycombinator.com/item?id=32720856
- trollied 4y ago... then stream the entire resultset to the server and do the filtering in software. Drives me mad!
- loeg 4y agoIf your working set is between 32 and 96 MB, it can make a big difference. This is probably not what most people mean when they talk about database caching, though.
- cronin101 4y agoSeems like an obvious question but is there conventional wisdom on whether compilation/transpilation heavy workloads are more suited to cache size or to higher clocks? Is this a “it depends” situation? Wondering what to pick for my next workhorse.
- mastax 4y agoI thought I remembered benchmarks from when the 5800X3D came out showing it was good at code compilation but that is, at the very least, not always true. https://www.phoronix.com/review/amd-ryzen9-7950x3d-linux/13 https://www.phoronix.com/review/amd-ryzen9-7950x3d-linux/13
- the8472 4y agoAssuming the power is reported correctly it looks like an efficiency win: > While the build times were similar between the 7950X and 7950X3D, with the latter the CPU power consumption was significantly lower.
- mastax 4y agoI'm assuming the vast majority of that benefit is just from the X3D chips having a lower stock TDP. You could achieve the same efficiency by just reducing the 7950X TDP to 120W in BIOS or Ryzen Master.
- andrewstuart 4y agoIt sounds like this would be great for single user contexts, but really unpredictable for servers running multiple duplicate tasks. Can someone who knows better than me please comment on the Linux server scheduling issues with a CPU like this. At this stage I’m assuming I’d be better with a CPU with all cores the same.
- mastax 4y agoIt's a pretty similar shape of problem to NUMA, which servers have managed for quite some time. (Perhaps more similar to big.LITTLE which is not so common in servers but Linux should have decent support for from ARM SoCs) Its a bit of an unnecessary hassle and annoyance, though. I'm pretty sure all the V-Cache EPYCs will have cache on all their dies so there won't be this issue.
- MichaelZuo 4y agoLinux multi-threading code isn't the most elegant or robust out there, but I doubt it would catastrophically fail, in the sense of performing worse on the newer AMD design, outside of a few exceptional cases.
- andrewstuart 4y ago>> Linux multi-threading code isn't the most elegant or robust out there Evidence?
- MichaelZuo 4y agoYou want evidence of my personal estimation of Linux?
- secondcoming 4y agoHow about Linux will move your process to another core for no good reason?
- ilyt 4y ago
- ChuckMcM 4y agoFrom the article -- "Unfortunately, there’s been a trend of uneven performance across cores as manufacturers try to make their chips best at everything, and use different core setups to cover more bases." I don't find this unfortunate. Engineering is compromise and being able to make things that do a particular thing well can get you more performance per $ and per watt than you might otherwise see. The whole GPU thing that kneecapped Intel[1] is an example I use of how a compute element optimized for one thing can boost overall system performance. I have worked on a number of bits of code for "big/little" ARM chips and while it does make scheduling more complex, overall we've been able to deliver more capability per $ and per watt. That is perhaps more important in portable systems but it works in data centers too. I had an interesting discussion inside Google about storage and whether or not using a full up motherboard for GFS nodes was ideal. The prevailing argument at the time was uniformity of "nodes" meant everything was software, nodes could be swapped at will and you could write software to do what ever you needed. But when it comes to efficiency, which is to say what percentage of available resource is used to deliver the services, you found a lost of wasted watts/cpu cycles. All depends on what part of the engineering design space you are trying to optimize. [1] The "kneecapped" situation is that since the PC/AT (80286) on, Intel generally made the most margin of all the chips that went into a complete system. Now that it is often NVIDIA.
- usrusr 4y agoUnfortunate in how it demonstrates that there don't seem to be any lower-hanging fruit left. Actually it doesn't so much feel like picking higher hanging fruit, it feels like stretching hard for the last withered leaves, long after the last fruit have disappeared.
- ChuckMcM 4y agoYeah pretty much. There was never any real expectation that Moore's observation would result in infinitely improving compute performance, and Intel famously demonstrated that reality was much closer to Jim Gray's "smoking hairy golf ball" future. [1] "Jim: Here it is. The concept is that the speed of light is finite and a nanosecond is a foot. So if you buy a gigahertz processor, it’s doing something every nanosecond. That’s the event horizon. But that’s in a vacuum, the processor is not a vacuum, and signals don’t go in a straight line and the processor is running at 3 gigahertz. So you don’t have a foot. You’ve got four inches. And the speed of light in a solid is less than that. So this is the event horizon. If something happens on one side of this thing, the clock is going to tick before to the signal gets to the other side. That’s why processors of the future have to be small and in fact golf ball– size. Why are they smoking? Well, because they have to run on a lot of electricity. The way you get things to go fast is you put a lot of power into them. So heat dissipation is a big problem. Now it’s astonishing to me that Intel has decided that this is a big problem only recently, because people knew that we were headed towards this heat cliff a long time ago. And why is it hairy? Because you’ve got to get signals in and out of it, so this thing is going to be wrapped in pins." -- https://amturing.acm.org/pdf/GrayTuringTranscript.pdf https://amturing.acm.org/pdf/GrayTuringTranscript.pdf
- deleted 4y ago[deleted]