Live data from Hacker News

Benchmarking the Apple M1 Max

tlkh.dev

211–217 of 217 posts

Re: Benchmarking the Apple M1 Max

#211
post #206

Earlier quoted context omitted.

No, you misunderstand. The 5700G is an APU. Memory is shared between it's GPU and CPU. Hence the "G".

It's unlike 5700G would push 200-400GB/s for GPU tasks, assuming one gets pytorch/tensorflow to use the shared memory and BIOS allows setting such a large shared window, all of them unlikely unfortunately.

Now that's a completely different argument, and still mostly incorrect. The 5700G will access as much memory throughput from its GPU as you can feed it. The limitation is not the GPU, it's how fast you can clock your RAM.

The BIOS doesn't set the shared memory. The BIOS sets the dedicated memory. The shared memory is set by the OS and driver as you need, and the only limit is how much memory you have and how much is used by other processes.

You can force any program to use shared memory by making dedicated memory low. As I said, these programs don't really choose to use it, it's a driver/OS responsibility.

The 5700Gs memory controller indeed can't go above 100GB/s. However 200-400GB/s is not what the M1 Max GPU can do, it's combined performance. You'd have to substract CPU performance. The M1 Max GPU would still be faster of course. But the premise is that GPU performance doesn't really matter.

Re: Benchmarking the Apple M1 Max

#212
post #189

Earlier quoted context omitted.

Not sure why you were downvoted for this. Considering that some of the magic in these things is the shared, local memory with a very wide bus it would seem obvious that trying to go multi chip would indeed be a massive headache in this regard

Check out this[0] link to see why the thought is Apple is doing exactly that. [0]: https://architosh.com/2021/10/apples-new-m1-pro-is-chop-vers...

That isn't what that article is saying.

Re: Benchmarking the Apple M1 Max

#213

Earlier quoted context omitted.

> If you don't like SPEC then look at workload benchmarks like video rendering or code compilation. The M series chips acquit themselves quite well. Then you get results that are equivalent rather than superior. > Not when they're actually doing anything. Yes, when they're actually doing anything. The M1 Macbooks get around 16 hours. Under the same kind of load a similarly performing PC laptop might get around 10 hou…

> It has very little to do with being in a single SoC. The part where the efficiency is radically better than competing parts has everything to do with it being an integrated SoC. > Then you get results that are equivalent rather than superior. Equivalent to what? Your desktop at 5+ times the wattage? A Windows laptop with half the battery life and twice the weight? > Yes, when they're actually doing anything. The M1…

> The part where the efficiency is radically better than competing parts has everything to do with it being an integrated SoC.

What makes you think that? The CPU is about the same speed as other CPUs, the GPU is about the same speed as other GPUs, and it uses less power in no small part because it's the first thing to use TSMC 5nm.

Being an SoC allows you to save a certain amount of overlap, e.g. you don't need separate memory controllers for the CPU and GPU, but none of that stuff uses a significant amount of power.

> If you don't care about performance or battery life or weight there are plenty of Windows options available.

It's not matter of not caring. You can get PC laptops with similar performance and similar weight and 10 hours of battery life instead of 16. Ten hours is not exactly oppressive. If you really, really need sixteen, you can trade it against weight or performance at your option -- it's not necessary to do both.

Or you could wait a few months for PC laptops on TSMC 5nm which will have better power efficiency.

Re: Benchmarking the Apple M1 Max

#214

Earlier quoted context omitted.

> It has very little to do with being in a single SoC. The part where the efficiency is radically better than competing parts has everything to do with it being an integrated SoC. > Then you get results that are equivalent rather than superior. Equivalent to what? Your desktop at 5+ times the wattage? A Windows laptop with half the battery life and twice the weight? > Yes, when they're actually doing anything. The M1…

> The part where the efficiency is radically better than competing parts has everything to do with it being an integrated SoC. What makes you think that? The CPU is about the same speed as other CPUs, the GPU is about the same speed as other GPUs, and it uses less power in no small part because it's the first thing to use TSMC 5nm. Being an SoC allows you to save a certain amount of overlap, e.g. you don't need separ…

> Being an SoC allows you to save a certain amount of overlap, e.g. you don't need separate memory controllers for the CPU and GPU, but none of that stuff uses a significant amount of power.

It absolutely uses more power to have things on separate dies. Why do you think monolithic designs like this are preferred for mobile first products? It's certainly not because it's cheaper or easier. SoCs like this typically have lower yields and higher costs--you do it because in return you can squeeze out better power and efficiency while also saving space on the board.

> It's not matter of not caring. You can get PC laptops with similar performance and similar weight and 10 hours of battery life instead of 16.

This is just so emphatically not true though. Like I'm going to need to see the workload you're referencing where a device with similar benchmarks across the board (CPU and GPU) gets 10 hours of real world battery life without weighing 5 lbs.

Like I have in my possession as a daily driver a 2020 MacBook Pro that uses an Intel IceLake chip--fairly recent tech! If I'm doing my actual work on it--a bit of Docker, Chrome, and an IDE--I'm lucky to make it much past lunch. A fairly recent Intel chip, that gets positively embarrassed performance-wise by an M1, and can barely turn in 6 hours of real usage.

I want to see this system you have that performs like an M1 and turns in 10 hours of real world battery usage.

> Or you could wait a few months for PC laptops on TSMC 5nm which will have better power efficiency.

You could have already had it for well over a year now with Apple. And by the time this mythical laptop you're speaking of arrives, Apple might have already moved on to the next node. But hey, it's your life not mine. Keep waiting if it pleases you.

Re: Benchmarking the Apple M1 Max

#215

Earlier quoted context omitted.

Yeah. I'm worried that they may have played their trump cards already, so to speak. I wonder if future perf gains will come, game console-style, from areas besides general purpose computation -- specialized instructions / cores for specialized tasks. Imagine an entire core optimized for Safari and its Javascript engine. Their next chip is called the "M1 Marathon Edition" and you get 36 hours of real-world battery lif…

The things that take up time and energy in browsers - i.e. things like garbage collection, JIT compilation, and so on - are already things that CPUs are hyper-specialized for. And the code that is ultimately intended to execute is also well-specialized for CPUs. It's already possible to target GPUs in-browser directly; and most older HTML primitives were recast in terms of GPU operations around the time of the origin…

This is a wonderful and informative reply. Thank you so much - i really appreciate the time you spent writing this.

Re: Benchmarking the Apple M1 Max

#216

Earlier quoted context omitted.

XPC sync is not in fact async underneath in recent macOS versions. It’s a severe performance pessimization to use async in many cases, because sync propagates thread priority and async often can’t. You don’t seem to have a full grip on the reasons for the intermittent hangs you’re experiencing. Can I suggest two things? 1 Grab a sysdiagnose during one of the hangs and file a feedback report with Apple 2 Use the `samp…

> XPC sync is not in fact async underneath That's interesting! I thought XPC was a wrapper around async mach messages. Do you have any pointers where I can learn more about this?

When you get to kernel land it is "something async plus a wait"; there's no other way for it to be when the remote task is on a different core.

But it's a special wait that the scheduler and other systems know how to benefit from using vouchers/turnstiles/etc. If you look at spindump output you should see it.

Re: Benchmarking the Apple M1 Max

#217

Earlier quoted context omitted.

> XPC is not asynchronous It's been some time since I dug into the internals of XPC, but my assumption was that the underlying protocol is asynchronous, and if you do sync calls the wrappers just do the waiting for you. The problem is that it has a tendency to get stuck in some rare cases, where services just don't reply for some reason. Then the sync calls are the worst -- the UI of the app is completely frozen and…

XPC sync is not in fact async underneath in recent macOS versions. It’s a severe performance pessimization to use async in many cases, because sync propagates thread priority and async often can’t. You don’t seem to have a full grip on the reasons for the intermittent hangs you’re experiencing. Can I suggest two things? 1 Grab a sysdiagnose during one of the hangs and file a feedback report with Apple 2 Use the `samp…

> 2 Use the `sample` command line tool to see what’s actually hanging a particular process for yourself

Don't use "sample" if the issue could be multi-process or in the kernel, use "spindump".

Post reply on HN