Earlier quoted context omitted.
Good point. I'm really surprised they don't translate during installation (ahead of time).
I believe they do.
In certain cases, such as when they come from the App Store. I believe other apps do not get this.
How M1 Macs feel faster than Intel models: it’s about QoS
401–410 of 427 posts
Re: How M1 Macs feel faster than Intel models: it’s about QoS
#402It does not just feel faster, in many cases it is faster. E.g. compiling Rust code is so much faster that it is not even funny. cargo install -f ripgrep takes 22 seconds on a Mac Book Air with M1, same on a hexacore 2020 Dell XPS 17 with 64GB RAM takes 34 seconds.
Are you compiling for ARM in both cases (or x86 in both cases)? Otherwise you are building 2 completely different programs, one is ripgrep for ARM and the other is ripgrep for Intel.
The programs would be pretty much identical until they are lowered, which is generally not a bottleneck for Rust compiles…
Re: How M1 Macs feel faster than Intel models: it’s about QoS
#403Earlier quoted context omitted.
As of recently, macOS does support priority inheritance for a bunch of synchronization primitives [1], ranging from pthread mutexes to Mach IPC. But it's not perfect. For instance, read-write locks currently don't support priority inheritance, though they could. More problematically, when userland processes use any kind of custom synchronization scheme based on condition variables or similar, there's no way for the k…
You should look into libdispatch, in my understanding, essentially everyone is expected to use libdispatch, and it may have something special to somehow help with priority inheritance.
Where available, libdispatch uses the kernel primitives that support priority inheritance. However, there is nothing that can help you if you are blocked on a task that macOS cannot discern where it might wake up from (this is why waiting on a semaphore is usually not advised).
Re: How M1 Macs feel faster than Intel models: it’s about QoS
#404Earlier quoted context omitted.
"I never hear the fan. Even playing Magic Arena AND a Parallels VM runs silent." That is because there is no fan.
The regular M1 MacBook does have a fan. The M1 Air doesn't, but throttles the CPU to avoid overheating
While we're being technical, there is no M1 MacBook; there is a M1 MacBook Pro and an M1 MacBook Air, as we as an M1 Mac Mini.
Re: How M1 Macs feel faster than Intel models: it’s about QoS
#405Re: How M1 Macs feel faster than Intel models: it’s about QoS
#406Earlier quoted context omitted.
Note that's a 16 core CPU with 105W TDP compared to a quad core < 10W M1
5850U is an 8 core CPU with a TDP that is adjustable between 10-25w. If you want to keep it to 4 cores just so it is a fair fight, there's the 5400U/5450U. AMD does pretty well...
Yeah I'd say the M1 and latest AMD CPUs are virtually tied for fastest single threaded performance, edging out the best by Intel.
But for something like compilation which is multithreaded obviously the higher core count will win.
Re: How M1 Macs feel faster than Intel models: it’s about QoS
#407Earlier quoted context omitted.
> I believe most of the benchmarks where Metal based in the Anand article But that doesn't tell you anything. Being Metal-based doesn't mean they were designed nor benefit from UMA. Especially since, again, Apple's own recommendation on big data (read: textures) is to copy it. > Any back and forth between CPU and GPU will be faster with unified memory especially with a coherent on die cache. Yes, but games & gfxbench…
First API's don't support it, can't pin memory (which is what a PBO does). Then oh well they are not taking advantage of it. Move the goal post much? TBDR came to prominence in UMA mobile architectures, it's a big part of what allows it to perform so well with limited memory bandwidth. The M1 is just an evolution of Apples mobile designs and PowerVR before that. Mali GPU's are UMA and alway have been AFAIK https://co…
> First API's don't support it, can't pin memory (which is what a PBO does). Then oh well they are not taking advantage of it. Move the goal post much?
No, they don't, so no, I didn't move the goal posts at all. PBOs are a transfer object. You cannot sample from them on the GPU. The only thing you can do with PBOs is copy them to something you can use on the GPU.
As such, PBOs do not let you take advantage of UMA. In fact, their primary benefit is for non-UMA in the first place. UMA systems have no issues blocking glTexImage2D until the copy to GPU memory is done, but non-UMA ones do. And non-UMA ones are what gave us PBOs.
> TBDR came to prominence in UMA mobile architectures, it's a big part of what allows it to perform so well with limited memory bandwidth.
Support that with a theory or evidence of literally any kind. There's nothing at all in TBDR's sequence of events that has any apparent benefit from UMA.
Here: https://developer.arm.com/solutions/graphics-and-gaming/deve...
Look at that the sequence of steps. ARM doesn't even bother including a CPU in there, so which step would UMA be helping with?
What UMA can do here is improve the power efficiency by reducing the cost of sending the command buffers to the GPU, but that's not going to get you a performance improvement as those command buffers are not very big. If sending data from the CPU to GPU was such a severe bottleneck then you'd see the impact of things like reducing the PCI-E bandwidth on discreet GPUs, but you don't.
Re: How M1 Macs feel faster than Intel models: it’s about QoS
#408Earlier quoted context omitted.
>What I can't stand are all the people saying the M1 is capable of replacing high end x86 computers. Whether or not this is possible completely depends on their unique workload. The M1 could probaly obviate any x86 chip for the average programmers. But that wouldn't be the case for gamer workloads, for example.
Is it really about workload though? A high end gaming PC will compile typescript, play games with high quality graphics, and run your 100 browser tabs. Let's be honest, an Intel Core 2 Duo would obviate most programmer workloads just fine. By your logic the Apple M1 is comparable to a high-end x86 chips, but you go on in the same breath with the disclaimer that it is "only certain workloads." That is my point. A high…
Is this an honest assessment though?
I'm usually running 5+ electron programs (IDE, Slack, Discord, etc), multiple browser tabs, test runners (Jest, Detox), IDE plugins (eslint, auto import, gitlens), an emulated terminal (iTerm2), multiple VMs (android, simulator), xCode, Android Studio, and that's just my base setup. From there add more casual programs like calendar, memos, omnifocus, spotify and so on. An intel core 2 duo would thrash at just 10% of that workload.
Re: How M1 Macs feel faster than Intel models: it’s about QoS
#409Earlier quoted context omitted.
And yet it is extremely unlikely that it's linear or anywhere near it.
What is "linear" in this context? If the Y-axis is performance, what is the X-axis? That statement doesn't seem to make much sense without any additional explanation. If I run a benchmark for a program on the M1, that's a single data point. It's hard to call a single data point "linear", "quadratic", or anything else... and you can't really put multiple benchmarks on the X-axis, because they're measuring different th…
> I have no reason to believe that the M1's performance starts tanking if you run it for longer than a few seconds
This statement speaks volumes about your bias. You're immediately on the defensive and assuming we're attacking the M1 rather than the assumptions made in a test and it's methodology.
No one was implying that the M1's performance would tank. I specifically conjectured that perhaps x86, not M1, might have a penalty.
The original assertion made was that all x86 compiles were ~30% slower than the M1, but the benchmark was a ~20 compile. What happens if the compile is hours?
If the penalty is ~30% linear then a 60 minute compile on M1 is 80 minutes on x86. But if there's just a 10 second warmup penalty on x86 the compile time might only be 60 minutes + 10 seconds.
The truth is probably somewhere in between.
Re: How M1 Macs feel faster than Intel models: it’s about QoS
#410Earlier quoted context omitted.
What is "linear" in this context? If the Y-axis is performance, what is the X-axis? That statement doesn't seem to make much sense without any additional explanation. If I run a benchmark for a program on the M1, that's a single data point. It's hard to call a single data point "linear", "quadratic", or anything else... and you can't really put multiple benchmarks on the X-axis, because they're measuring different th…
> I have no reason to believe that the M1's performance starts tanking if you run it for longer than a few seconds This statement speaks volumes about your bias. You're immediately on the defensive and assuming we're attacking the M1 rather than the assumptions made in a test and it's methodology. No one was implying that the M1's performance would tank. I specifically conjectured that perhaps x86, not M1, might have…
> But if there's just a 10 second warmup penalty on x86 the compile time might only be 60 minutes + 10 seconds.
But that doesn't make any sense, as I previously asserted. That's just not how any of this works. x86 is not suffering a "penalty". It doesn't need time to "warmup". I already discussed my views (based on actual real world experience) on all of this, but you conveniently bypassed those statements.
> This statement speaks volumes about your bias. You're immediately on the defensive and assuming we're attacking the M1 rather than the assumptions made in a test and it's methodology.
It really doesn't speak volumes. The default position I've seen is for people to assume that new technology is just a gimmick, and that results are only being cherry picked. And that's exactly what you just said you were assuming ("the truth is probably somewhere in between"), so I was right to reach that conclusion. No one here (that I've seen) is claiming the M1 is the unequivocal performance champion in all things, but it does really well in some use cases that impress me as a developer.
If it's really just about test methodology, you would just look up other tests, or run your own. Putting out completely unfounded statements like "what if there's a fixed 10 second ding on x86?" doesn't move the conversation forward when the hardware and results are so readily available. It's just a way of attempting to cast doubt on results. There's little need for speculation at this point, but you continue to speculate in defense of your previous comment without apparently having any hands on experience with M1.