You said let's be clear but you're not even clear about what defines as "better".
ARM loses out in raw speed in server but wins in perf/watt, perf/$, and control. These are way more important in DC than just raw speed.
Last edited:
ARM loses out in raw speed in server but wins in perf/watt, perf/$, and control. These are way more important in DC than just raw speed.
- Mar 8, 2022
- 3,961
- 5,280
- 106
This is most likely the benchmark itself?
Someone more knowledgeable might have a definitive answer
Where is the perf/watt measurement?
can't find that tbh cause there is no way to test this thing unless you are amazon
I thought phoronix would have the data cause they usually have the data but as it turns out it was vCPU so my bad.
Do I need a public letter like Lip Bu Tan for you to forgive me 🤣
It's hard because getting independent testing of Arm server hardware is difficult now due to a mix of AMD's competitiveness and hypervisors rolling their own versions of ARM processors. This is the best comparison I know of:
So, not that far off in a general sense, but Zen5c would be a significant improvement over everything shown here. With Ampere being bought-out by Softbank, it will be interesting to see if they can get more traction for 3rd party ARM solutions and improved release cycles.
Does not show Ampere CPUs in this chart but you can compare with previous Zen 4 Epyc results to see roughly how it would stack up:
So let's assume the benchmark is coded to do both P and E cores - to what extent is AS designed to run all cores at full tilt, and does that break the thermal budget and start throttling? After all, the expectation is that one process isn't driving them all at once - you might be running all the P cores full chap, but the E cores would be reserved for system tasks, etc. that are decoupled from the P core process and likely are less common because the user is doing something substantial to use all P cores. Again, these are consumer machines that effectively always have someone sitting at the keyboard and the P core use is directly a response to what that user is doing, not servers grinding away at a problem in a closet somewhere. Note the QoS is typically done at the process level, not the thread level, and Apple's thinking is that you're advanced enough to QoS threads for E cores you're doing it either for power saving or for responsiveness say for your main control loop where you want to be responsive to user input, or I/O, etc., not to juice performance, because again, these are consumer products, not HPC.
So I wouldn't be surprised if the SoC in a 1 hour long test exceeded its thermal envelope after a few moments and just started to throttle. Run that test again in liquid nitrogen and I wonder if you get the same result. I would expect more than a 20% drop off in performance if it was accidentally running on E cores, but 20% seems pretty reasonable if it's dialing the P cores back and keeping the E cores running. After all, if you are throttling, you're not going to throttle the E cores - they're not the problem. I don't know how granular their power management is, but my x86 MBP would fall off a cliff the moment it started to throttle.
Note Amazon doesn't specifically care about perf/watt. They care about total cost. Last I read they can acquire a given level of compute for about ⅓ the cost of AMD. This is fixed, but a meaningful sum. They also have to pay for the electricity, the land so compute/rack is a factor, there's other factors in there in terms of their ability to control and monetize it, so one of their big applications for ARM is Lambda which is a very heterogeneous compute environment that isn't even well mapped to individual cores and has all kinds of additional transaction cost to isolate that process, etc.
So I wouldn't even expect Graviton to have particularly similar design constraints to AMD. The whole point of AWS was to rethink the cost model of traditional compute and that should apply not just to datacenter and racks but also the die itself. To them the superiority of ARM isn't to run a bigger Crysis, but to enable that different cost model of compute. Apple is doing something similar but rethinking how compute is delivered. Every x86 benchmark is on desktop, but you can switch most Apple Silicon benchmarks to a laptop with a fan and you'll get basically the same number. FFS, an iPad was atop the leaderboard for half the year. A big part of Apple's market is you can take your 9950X3D performance to an airplane seat, to the hotel room, to the conference. And if you can live with slightly less performance, you can put that in your pocket. So are they trying to win on desktop? Not really. They don't want to be behind, but that's not where their money comes from. Their money comes from continuing to eat away at the desktop PC market, which again peaked in 2012 right when the iPad launched and knowing they can easily win in portables and below.
So I wouldn't even expect Graviton to have particularly similar design constraints to AMD. The whole point of AWS was to rethink the cost model of traditional compute and that should apply not just to datacenter and racks but also the die itself. To them the superiority of ARM isn't to run a bigger Crysis, but to enable that different cost model of compute. Apple is doing something similar but rethinking how compute is delivered. Every x86 benchmark is on desktop, but you can switch most Apple Silicon benchmarks to a laptop with a fan and you'll get basically the same number. FFS, an iPad was atop the leaderboard for half the year. A big part of Apple's market is you can take your 9950X3D performance to an airplane seat, to the hotel room, to the conference. And if you can live with slightly less performance, you can put that in your pocket. So are they trying to win on desktop? Not really. They don't want to be behind, but that's not where their money comes from. Their money comes from continuing to eat away at the desktop PC market, which again peaked in 2012 right when the iPad launched and knowing they can easily win in portables and below.
The butt kicking Apple does in CPUs is not as amenable to GPUs. You can see simply in comparisons that GPUs once the architecture gets to the ballpark competitiveness, it's mostly dependent on Moore's Law, while CPUs are highly dependent on smarts of the engineering and ideas.
Also, while it may seem simple, making it work flawlessly in games across many different hardware and software configurations as in the PC is a different story. And Apple doesn't care about this, which is the more important part.
Uhh.... no.
The weakness of PC GPUs is that they are hanging off a PCIe spec that is about to be 2 versions ahead of what is actually shipping to customers. Shared memory is their opportunity, as is Metal being a better environment to develop in, and a much less schizophrenic hardware/software/driver space. It's a cost effective space to operate in if you can get gamers to buy in. But it's not so much a technological problem as a really nasty go-to-market problem and the best Apple really can do is keep erasing technical debt and being ready when an opportunity arises.
Jan Olšan
Senior member
- Jan 12, 2017
- 553
- 1,090
- 136
How? Metal is a NIH Apple product, making it an API that game devs have to support on top of the mainstream APIs that already cover most of the market. What about that makes targeting the API better environment to develop in?
What do you base this on? Do you think Apple has more mature tools and platform for game development than what AMD/Nvidia + Microsoft's DirectX SDKs provide? (And that Apple's GPU drivers are more mature stack for games to target?)
- Mar 8, 2022
- 3,961
- 5,280
- 106
Unless Apple makes a video game console and its popular, I don't ever see Metal nor Apple GPUs drivers being tuned for gaming like DirectX, Radeon and GeForce is.
Thunder 57
Diamond Member
- Aug 19, 2007
- 3,862
- 6,497
- 136
GPU's don't need PCIe 6 or 7. PCIe 6 won't be coming to desktop for years. It is expensive and not necessary for that market.
Really the only case I could see being made for it is if Apple tried to do a dGPU (which they would never do) because they'd want to preserve the same unified memory model and memory map the GPU's local memory over PCIe. They wouldn't need the speed of the new PCIe versions so much (though it wouldn't hurt) but the latency improvements made to support CXL most certainly would.
Because it's objectively easier to develop in Metal than say Vulkan. Nobody disputes this. And to the extent that most developers use an existing game engine, you really just need to get the engine ported to get most of the benefit. UE5 is ported to Metal. Unity, Red, Decima are all ported.
There has been a feature gap between Apple GPUs and Nvidia beyond just overall performance, and that gap is mostly getting closed down with Metal 4.
I think Apple has largely the same tools. That's not the issue so much. Apple's GPU drivers aren't more mature so much as they're more stable due to have an infinitely smaller hardware profile. I mean, have you ever read a gaming board?
The 2022 apple TV is competitive in single core performance and not too far behind in useable MT performance to the og PS5 and XBone. It has a out half the graphics performance, but much faster storage tech.
If the next Apple TV is based on any of their current generation chips, it will be as good or better than them in every way. They have a game console that's far better then the volume leader (switch) and on par with last Gen home models.
They just lack the will...
Jan Olšan
Senior member
- Jan 12, 2017
- 553
- 1,090
- 136
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 21K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter