Lies, damned lies and Intel benchmarks
-
Intel is back at their usual shenanigans by doing a totally fair comparison between their latest laptop CPUs and the M1 MacBook Pro. And for a company that doesn't like benchmarks, they sure do a lot of benchmarks to prove their point that benchmarks are useless and "real world performance" is all that counts.
Intel Fires Back at Apple's M1 Processors With Benchmarks
Intel wants to take a bite out of Apple and prove its processors to be more worthy
First of all, they are comparing the 10W M1 with a 28W i7. Except for when testing battery life, where they are switching to the i5 instead, also using a laptop with a larger battery than the MacBook. And for productivity workloads they swapped the 16 GB MacBook Pro used in the performance tests for an 8 GB MacBook Pro.
And while the graphics tests showed the M1 was on par with Intel Xe, Intel skewed the results by listing a bunch of games at 0 FPS when they had no macOS support. And for pricing, they ignored the cheaper MacBook Air completely.
So, all that Intel has managed to prove in their extensive tests aare stuff not related to performance and easily found out by just reading the damn specs. Limited display external support and lack of ports on the MacBook is no surprise to anyone who bothers to read Apple's product page, and the other drawback they list (lack of software support) is of no surprise as anyone buying an M1 now is an early adopter and porting software takes time.
-
@Atazhaia said in Lies, damned lies and Intel benchmarks:
porting software takes time
In this case, it doesn't take much time unless you're using assembly, as you're targeting a device with the same word size and endianness, running the same OS. Or if you're doing things at the level of device drivers I guess. There's a bit more complexity in the build itself (as you need to internally compile each file twice) but that's mostly hidden inside the object file format for fat binaries. It's nothing like as bad overall as when Apple switched from PowerPC to Intel; that was quite a bit of work! Overall, I guess the current transition is 99% about updating the build instructions to include the flag to fatten the binaries, usually a small part of the overall space of any app anyway?
Not everything is so easy, but most macOS native applications really aren't going to have a lot of trouble. Supporting a new version of the OS is usually way more trouble! (There are times when I think that Apple's GUI designers are ADHD squirrel watchers.)
-
Hardware company cherry picks benchmarks to make their hardware look better than the competition. Is there any news in this?
-
@dkf Apple marketing has said it's very easy, but I also drag any statement from them through the Dead Sea a couple times before looking at it. And even if porting one app is easy (depending on complexity), for the entire ecosystem to be ported over to native M1 will take time depending on dev
and hardware availability. Some devs will start the transition as soon as Apple gives the heads up, while some will wait until support has been dropped completely before porting even with a 2 year advance notice to get things working.
-
@dkf said in Lies, damned lies and Intel benchmarks:
@Atazhaia said in Lies, damned lies and Intel benchmarks:
porting software takes time
In this case, it doesn't take much time unless you're using assembly, as you're targeting a device with the same word size and endianness, running the same OS. Or if you're doing things at the level of device drivers I guess. There's a bit more complexity in the build itself (as you need to internally compile each file twice) but that's mostly hidden inside the object file format for fat binaries. It's nothing like as bad overall as when Apple switched from PowerPC to Intel; that was quite a bit of work! Overall, I guess the current transition is 99% about updating the build instructions to include the flag to fatten the binaries, usually a small part of the overall space of any app anyway?
Does that mean the whole OS and every app takes up twice as much space on the limited SSD just so it can include the x64 code that it will use exactly never? Other than not having to pick the correct architecture for manual downloads (where I already have to pick Mac instead of Linux or Windows) I don't see any reason why I'd want fat binaries.
-
@topspin said in Lies, damned lies and Intel benchmarks:
Does that mean the whole OS and every app takes up twice as much space on the limited SSD just so it can include the x64 code that it will use exactly never? Other than not having to pick the correct architecture for manual downloads (where I already have to pick Mac instead of Linux or Windows) I don't see any reason why I'd want fat binaries.
As far as I understand fat binaries (as I have some on my x86 Mac with macOS 11), the fat binary is just the executable itself which contains two exes, one for x86 and one for ARM. And an executable tends to be a rather small part of an application. Resource files can be shared as they are not dependant on the architecture, and most shared libraries are provided by the OS itself so just need one copy of those too.
-
@topspin said in Lies, damned lies and Intel benchmarks:
Does that mean the whole OS and every app takes up twice as much space on the limited SSD just so it can include the x64 code that it will use exactly never?
In theory, yes. In practice, no, because large chunks of most apps are non-code assets that don't need duplication.
-
@topspin said in Lies, damned lies and Intel benchmarks:
Does that mean the whole OS and every app takes up twice as much space on the limited SSD just so it can include the x64 code that it will use exactly never?
Apps in macOS (and iOS etc.) are directories that contain the app’s executable(s) and any other resources it needs. Only the executable is bigger than usual because it contains the code needed for all the different processors it supports, plus a bit of stuff at the front to let the OS use the right one.
Other than not having to pick the correct architecture for manual downloads (where I already have to pick Mac instead of Linux or Windows) I don't see any reason why I'd want fat binaries.
Because it takes the “having to pick the correct architecture for manual downloads” out of the user’s hands. I remember there were a fair amount of people having trouble with Microsoft’s way of handling this — namely, having to pick the right version for your processor — some years ago.
-
@topspin said in Lies, damned lies and Intel benchmarks:
@dkf said in Lies, damned lies and Intel benchmarks:
@Atazhaia said in Lies, damned lies and Intel benchmarks:
porting software takes time
In this case, it doesn't take much time unless you're using assembly, as you're targeting a device with the same word size and endianness, running the same OS. Or if you're doing things at the level of device drivers I guess. There's a bit more complexity in the build itself (as you need to internally compile each file twice) but that's mostly hidden inside the object file format for fat binaries. It's nothing like as bad overall as when Apple switched from PowerPC to Intel; that was quite a bit of work! Overall, I guess the current transition is 99% about updating the build instructions to include the flag to fatten the binaries, usually a small part of the overall space of any app anyway?
Does that mean the whole OS and every app takes up twice as much space on the limited SSD just so it can include the x64 code that it will use exactly never? Other than not having to pick the correct architecture for manual downloads (where I already have to pick Mac instead of Linux or Windows) I don't see any reason why I'd want fat binaries.
In the PPC to intel transition period there were tools you could get to strip out the bit you weren't going to use
-
@dkf said in Lies, damned lies and Intel benchmarks:
In this case, it doesn't take much time unless you're using assembly, as you're targeting a device with the same word size and endianness, running the same OS.
ARM's memory model is different from x86, where essentially x86 bends over backwards to make things look more coherent than they really are, which ends up hiding a certain set of errors. Basically, on x86 you can get away with playing more fast and lose when it comes to stuff like multithreading than on ARM; if you were doing that, then porting to ARM might uncover a set of bugs that you technically previously already had. (Compare implementations of atomic stores: x86 can use the standard
movinstruction in cases where ARM has to usestlrinstead ofstr.)
-
@cvi said in Lies, damned lies and Intel benchmarks:
ARM's memory model is different from x86
Yes, but the M1 is different again, being more like an x86 than most ARM-based platforms. Having the memory in the package makes quite a big difference for that sort of thing. (There are huge numbers of options for what you can stick on an ARM core, and almost every licensee chooses a different subset. Apple's just gone for an unusual subset. Putting the memory in the package is not unusual though — that's really common for embedded uses — but they've put orders of magnitude more than anyone else.)
Most application code doesn't need to care too much. It should be just stating that a particular piece of memory needs atomic access and the compiler will do the right thing. Yes, the compiler absolutely does need to know what the right thing to do is, but that's normal and expected and its freaking job…
-
@dkf said in Lies, damned lies and Intel benchmarks:
Most application code doesn't need to care too much. It should be just stating that a particular piece of memory needs atomic access and the compiler will do the right thing.
And maybe avoid implementing their own semaphores...
-
@acrow said in Lies, damned lies and Intel benchmarks:
And maybe avoid implementing their own semaphores...
Oh yes. Avoid doing that.
-
@dkf said in Lies, damned lies and Intel benchmarks:
It should be just stating that a particular piece of memory needs atomic access and the compiler will do the right thing.
Yes, although that relies that the programmer in question does the right thing and uses atomic operations when they have to. Programmers writing bugfree code? Heh.
Point is, on x86 you can get away with a certain set of errors that you can't on (traditional) ARM. Porting to ARM will expose those errors. They were errors already, just that they didn't trigger problems on x86.
I don't know how much Apple changed around for the M1. But I doubt that they actually majorly changed the memory model (which is unrelated how the memory is connected to the hardware).
-
Judging by the crazy amount of cherry picking and comparing Apple to differently-sized-oranges, Intel must be really scared of this. Why didn't they actually compare an M1 Macbook vs an Intel Macbook, one wonders...
Their FUD makes me look forward to the Arm Macs more than I would otherwise.
-
@topspin said in Lies, damned lies and Intel benchmarks:
Why didn't they actually compare an M1 Macbook vs an Intel Macbook, one wonders...
I think we know the reason why here.
It'll be interesting to see what comes of the Intel chips being manufactured by TSMC, and whether Intel try any of the memory-in-package tricks for their mobile processors, as that's a very good idea (and hard to see being patented out the wazoo as it was common practice in embedded for ages). But the lead time on such things is considerable.
-
@topspin said in Lies, damned lies and Intel benchmarks:
Judging by the crazy amount of cherry picking and comparing Apple to differently-sized-oranges, Intel must be really scared of this. Why didn't they actually compare an M1 Macbook vs an Intel Macbook, one wonders...
Their FUD makes me look forward to the Arm Macs more than I would otherwise.
Maybe in future, we could call it Intel-Streisand effect.
-
The whole exercise seems pointless.
With Intel out of the Macbook market irregardless of which chips are best, they should be carefully crafting benchmarks which conclusively prove they're better than AMD. It would at least be relevant bullshit.
-
@loopback0 said in Lies, damned lies and Intel benchmarks:
The whole exercise seems pointless.
They're trying to stop the likes of Dell, HP and Lenovo from going down the same route.
-
@Atazhaia I would just like to congratulate Intel for somehow managing to be a worse company than Apple. That is truly a feat.
-
@topspin said in Lies, damned lies and Intel benchmarks:
Judging by the crazy amount of cherry picking and comparing Apple to differently-sized-oranges, Intel must be really scared of this.
Perhaps rightly so.
ARM's been more power efficient than x86 for the most part. Depending on what you're doing, that's a pretty big concern already. But it's certainly starting to matter in more and more places. If nothing else, more power efficient means you can get more work out of the same amount of power.
Intel/x86 was perceived to be ahead in terms of raw performance. With M1, Apple is starting to change that. Previous attempts at ARM for laptops etc. were low powered devices. Now .. they're not.
And as much as Apple is a bit of a special case, they've (again) demonstrated that switching architectures (or doing multiple) is kinda possible.
-
@cvi said in Lies, damned lies and Intel benchmarks:
And as much as Apple is a bit of a special case, they've (again) demonstrated that switching architectures (or doing multiple) is kinda possible.
They've more experience with this than virtually anyone else in the industry.
-
@cvi said in Lies, damned lies and Intel benchmarks:
ARM's been more power efficient than x86 for the most part.
A question about this, if I may.
Is the ISA really that much more efficient? Or is a large part of the efficiency gains from housing the memory near the CPU, and similar physical implementation differences?
-
@acrow said in Lies, damned lies and Intel benchmarks:
Is the ISA really that much more efficient?
It seems to need quite a lot less complex instruction decoder, and produces fairly dense opcodes (as condition checks and fixed shifts often get merged into adjacent instructions).
-
@acrow This is a bit out of my expertise, but what I've understood from HW people is that fast/wide buses are power hungry regardless of whether they go to memory or other stuff (PCIe, ...). So housing memory near the CPU certainly helps, but I'd consider that more of a systems issue (the flip side is that you concentrate heat generation more closely too). Not sure what the situation regarding that is on x86.
Other than what @dkf mentioned, x86 does a lot of behind the scenes magic to give the stronger memory guarantees it does (cache coherency etc.). That involves extra communication between cores and so on, so it's not free either.
-
@cvi said in Lies, damned lies and Intel benchmarks:
@dkf said in Lies, damned lies and Intel benchmarks:
In this case, it doesn't take much time unless you're using assembly, as you're targeting a device with the same word size and endianness, running the same OS.
ARM's memory model is different from x86,
Nobody has mentioned the other thing that's different about memory access between x86 and ARM.
ARM enforces alignment restrictions on memory accesses, while x86 doesn't care (unless you set the AC bit in the control word, in which case 99.(as many nines as you want)% of software will crash and burn).
-
@Steve_The_Cynic Yes, indeed. Forgot about that.
-
@Steve_The_Cynic said in Lies, damned lies and Intel benchmarks:
@cvi said in Lies, damned lies and Intel benchmarks:
@dkf said in Lies, damned lies and Intel benchmarks:
In this case, it doesn't take much time unless you're using assembly, as you're targeting a device with the same word size and endianness, running the same OS.
ARM's memory model is different from x86,
Nobody has mentioned the other thing that's different about memory access between x86 and ARM.
ARM enforces alignment restrictions on memory accesses, while x86 doesn't care (unless you set the AC bit in the control word, in which case 99.(as many nines as you want)% of software will crash and burn).
But does any of this matter when most software is still going to be written and run like shit? Chrome will still use 4GB of RAM?
-
@CodeJunkie said in Lies, damned lies and Intel benchmarks:
Chrome will still use 4GB of RAM?
That's only true if your system only has 4GB.
: System has memory?
: Yes.
:new ...
-
@Steve_The_Cynic said in Lies, damned lies and Intel benchmarks:
ARM enforces alignment restrictions on memory accesses
I've just looked it up. ARM64 with the MMU optional component (which the M1 will definitely have, unlike most embedded systems) supports unaligned accesses for the majority of operations. The only ones where it doesn't are where you're doing stuff like specifying that you want exclusive access (for atomic update ops) and those are generally to addresses that you'd have aligned in the first place.
-
@topspin said in Lies, damned lies and Intel benchmarks:
Why didn't they actually compare an M1 Macbook vs an Intel Macbook, one wonders...
This probably has the answers you’re looking for:
-
@Gurth can't wait to get one. The camera thing does sound a bit lame, but really, who cares.
The one thing that does have me worried a bit is the extreme lack of ports. And I do love the MagSafe power chord more than the USB C stuff.
-
@topspin said in Lies, damned lies and Intel benchmarks:
MagSafe power chord
Question: What do you get when Apple does rock music?
-
@Benjamin-Hall said in Lies, damned lies and Intel benchmarks:
@topspin said in Lies, damned lies and Intel benchmarks:
MagSafe power chord
Question: What do you get when Apple does rock music?
A free U2 album you never listen to?
-
@topspin said in Lies, damned lies and Intel benchmarks:
The one thing that does have me worried a bit is the extreme lack of ports.
4 down to 2 on the Pro certainly narrows the gap between the Air and the Pro but only having USB-C isn't really a major issue. Especially now USB-C hubs and docks are cheap.
-
@dkf said in Lies, damned lies and Intel benchmarks:
@loopback0 said in Lies, damned lies and Intel benchmarks:
The whole exercise seems pointless.
They're trying to stop the likes of Dell, HP and Lenovo from going down the same route.
Of the three, only HP would be fooled by that bullshit. They're still selling the Itanic after all.
-
@Benjamin-Hall said in Lies, damned lies and Intel benchmarks:
@topspin said in Lies, damned lies and Intel benchmarks:
MagSafe power chord
Question: What do you get when Apple does rock music?
A power chord is just the tonic, fifth, and octave, meaning it's not technically a chord at all.
-
@Benjamin-Hall said in Lies, damned lies and Intel benchmarks:
@topspin said in Lies, damned lies and Intel benchmarks:
MagSafe power chord
Question: What do you get when Apple does rock music?
- Jailbreak
- Systems Down
- Whole Lotta Rosetta
- Thunderboltstruck
- Send for the M1
- Where's the Flippin Switch?
-
This post is deleted!
-
@loopback0 said in Lies, damned lies and Intel benchmarks:
only having USB-C isn't really a major issue. Especially now USB-C hubs and docks are cheap.
Unless you actually try to use the lap-top on top of your lap. Then the dock actually matters.
Also on trains, planes, etc..
-
@topspin said in Lies, damned lies and Intel benchmarks:
I do love the MagSafe power c
hord more than the USB C stuff.I know it saved my MacBook (back when I used to use one) from hard contact with the floor a couple of times. I think it’s a step back to get rid of it.
-
@Gurth said in Lies, damned lies and Intel benchmarks:
@topspin said in Lies, damned lies and Intel benchmarks:
I do love the MagSafe power c
hord more than the USB C stuff.I know it saved my MacBook (back when I used to use one) from hard contact with the floor a couple of times. I think it’s a step back to get rid of it.
Same here. Actually, I would say that it did save not only the MacBook, but my me personally from several injuries (ok, I am little clumsy). One of the reasons why I still have my 2014 model and have no intention to upgrade (when it dies, I will try to get older model again).
Unlike many other features, this is literal life-saver! I will never understand why did the get rid of it.
-
@Kamil-Podlesak I've tripped over the USB-C cable of a more recent Macbook on multiple occasions - the plug still comes out just as easily without Magsafe.
Where Magsafe does better is when the impact/force is vertically on the connector.
-
@loopback0 To connector, or to the orientation of the connector?
Because the latter is fixable with a 10cm extension to the cable. Because it adds a breaking point that is always in line with the direction of pull. And is something I'd like to see become a standard feature.
-
@acrow Down onto the connector, as per this High Quality™ graphic I didn't just knock up in Paint.
Magsafe is quite shallow so it just drops off, but USB-C is deeper so doesn't.
-
MagSafe has got a perfect balance of “doesn’t fall out by itself” and still “disconnects from any kind of force”. Just lightly tapping in perpendicularly:
-
@topspin said in Lies, damned lies and Intel benchmarks:
MagSafe has got a perfect balance of “doesn’t fall out by itself” and still “disconnects from any kind of force”.
It's one of those things in connectors when you think “can't wait for it to come out of patent so it can be adopted as widely as it deserves” and instead the world converts to USB-C…
-
@dkf I'm assuming the patents aren't about to expire very soon. But once they do, we can for sure get as the new USB7 gen15.3x4:rev3C type C' +Mag connector (not compatible with the USB7 gen15.3x4:rev3C type C' (not mag!) connector).
-
@topspin said in Lies, damned lies and Intel benchmarks:
MagSafe has got a perfect balance of “doesn’t fall out by itself” and still “disconnects from any kind of force”. Just lightly tapping in perpendicularly:
My Macbook is too
to have that version of Magsafe, but it does have the older version which works similarly
-
@dkf said in Lies, damned lies and Intel benchmarks:
@Steve_The_Cynic said in Lies, damned lies and Intel benchmarks:
ARM enforces alignment restrictions on memory accesses
I've just looked it up. ARM64 with the MMU optional component (which the M1 will definitely have, unlike most embedded systems) supports unaligned accesses for the majority of operations. The only ones where it doesn't are where you're doing stuff like specifying that you want exclusive access (for atomic update ops) and those are generally to addresses that you'd have aligned in the first place.
Huh. OK; useful. On the other hand, atomic-access operations on x86 (
LOCKprefix) don't work on unaligned data either.
