291–300 of 565 posts
Earlier quoted context omitted.
SME is just the AMX coprocessor that’s been in Apple chips since 2019. SME made it easier to target the AMX. But it’s been in use and available to developers since 2019.
The point stands that virtually no apps used AMX (either directly or through a framework).
Earlier quoted context omitted.
Rust has been in the kernel for sometime now? With 6.18 to include significantly more including arguably the single most important component of Android, binder, entirely re-written in Rust.
Yes, it has. Marcan left Asahi and Linux after the DMA maintainer rejected their patch on non-technical grounds and labeled Rust as cancer for maintainers. So Linus supports Rust in the kernel, Rust patches come in, some maintainers reject them, there is no guidance on where or how Rust will or will not be accepted. Just do a bunch of free work and roll the gatekeeping dice. Very healthy and not abusive.
Guidance was provided...
> Maintainers who want to be involved in the Rust side can be involved in it, and by being involved with it, they will have some say in what the Rust bindings look like. They basically become the maintainers of the Rust interfaces too.
But maintainers who are taking the "I don't want to deal with Rust" option also then basically will obviously not have to bother with the Rust bindings - but as a result they also won't have any say on what goes on on the Rust side.
So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust.
But that "wall of protection" basically goes both ways. If you don't want to deal with the Rust code, you get no say on the Rust code.
Put another way: the "nobody is forced to deal with Rust" does not imply "everybody is allowed to veto any Rust code".
https://lore.kernel.org/lkml/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_...
I can’t wait to suffer M5 with macOS 26, such a disappointment. Edit: Let me double down, macOS 26 is the worst OS that Apple has shipped in the last two decades.
Earlier quoted context omitted.
Here’s the multi core Geekbench progression: M1: 8350 M2: 9700 M3: 11650 M4: 14600 M5: 16650 (estimated) This is assuming an 8% uplift as mentioned. Also nice.
I wish we could get something other than Geekbench for these things, since Geekbench seems to be trash. For example, it has the Ryzen 7 7700X with a higher multi-core score than the Epyc 9534 even though they're both Zen4 and the latter has 8 times as many cores and is significantly faster on threaded workloads in real life.
Earlier quoted context omitted.
Nice. Lots of people still claim that M1 is super duper fast but now we're at almost twice the performance!
What is that, 6 years for less than a doubling? Nothing against the Apple chips themselves, but gone are the days of Moore...
Earlier quoted context omitted.
Alyssa wasn't doing the GPU driver work. Marcan already provided the tools needed to capture the data being passed back and forth between MacOS and the GPU, so you can see exactly what the newer versions of the SOC are doing that is different.
I think you are confused. There are two drivers here. The kernel space driver mostly developed by lina. And the user space driver developed by Alyssa. Both are drivers. And of the two the user space driver is an order of magnitude more complex.
> We are pleased to announce that our graphics driver userspace API (uAPI) has been merged into the Linux kernel. This major milestone allows us to finally enable OpenGL, OpenCL and Vulkan support for Apple Silicon in upstream Mesa.
Earlier quoted context omitted.
I dunno, working with M1 daily I struggle with resource contention and slow py/js builds. I'd love something faster when work provides me with updated device.
Sounds like you need to spend some time optimising your build. Faster hardware just makes developers lazy. I'm still on an M1 and it's fine, although I do have 32GB.
Nice. The iPads generally measure around ~8% slower than the MacBooks, I guess for cooling reasons. So we should see approximately a 4400 single core Geekbench score for the MacBook series. This is nice. Single thread MacBook progression on Geekbench: M1: 2350 M2: 2600 M3: 3100 M4: 3850 M5: 4400 (estimated) https://browser.geekbench.com/mac-benchmarks
Keep in mind that a big part of the huge jump in recent chips was that GB6 added support for SME, and to my knowledge, no app uses SME as of yet. GB5 is a better benchmark for all these chips for this reason. The actual IPC increase and perf/clock of these chips excluding SME specific acceleration is MUCH smaller.
It feels like Intel and AMD are asleep at the wheel with their mobile lineup. I've been looking at non-apple equivalents that have similar performance/power as the M lineup and it seems they all lag about 20%+. For $800 the M4 Air just seems like one of the best tech deals around.
Not at all, you are stuck with a machine that has only 256GB of ssd(and not upgradeable) and 60hz LCD screen, also only 2 IO ports.
the M4 maybe the best mobile CPU, but that does not mean it will make every machine with it the best.