Earlier quoted context omitted.
Do all technical advances make you feel sad? Why hang out on Hacker News then?
It's actually a legitimate phenomenon: https://news.ycombinator.com/item?id=15643663
Also the famous Jevons paradox.
ARM MacBook vs. Intel MacBook
71–80 of 106 posts
Re: ARM MacBook vs. Intel MacBook
#72Anandtech's deep dive into Apple's Firestorm big cores is definitely worth reading if you are interested in how the chips that use their ARM implementation are different. >On the floating point and vector execution side of things, the new Firestorm cores are actually more impressive as they a 33% increase in capabilities, enabled by Apple’s addition of a fourth execution pipeline. The FP rename registers here seem to…
The article is phrased confusingly, at one point saying there are 4 pipelines, and then saying it can do 4 FADDs and 4 FMULs(for a total of 8) per cycle. So are there 4 or 8?? I believe what they meant to say was 4 FADDs OR 4 FMULs. Then they say it has quadruple the throughput of Intel and older AMD chips, but that doesn't follow unless this does 8 floating point operations per cycle not 4. The image of the pipeline…
Each is a multiply-accumulate instruction: https://developer.arm.com/documentation/dui0473/latest/neon-...
Re: ARM MacBook vs. Intel MacBook
#73Re: ARM MacBook vs. Intel MacBook
#74Anandtech's deep dive into Apple's Firestorm big cores is definitely worth reading if you are interested in how the chips that use their ARM implementation are different. >On the floating point and vector execution side of things, the new Firestorm cores are actually more impressive as they a 33% increase in capabilities, enabled by Apple’s addition of a fourth execution pipeline. The FP rename registers here seem to…
The article is phrased confusingly, at one point saying there are 4 pipelines, and then saying it can do 4 FADDs and 4 FMULs(for a total of 8) per cycle. So are there 4 or 8?? I believe what they meant to say was 4 FADDs OR 4 FMULs. Then they say it has quadruple the throughput of Intel and older AMD chips, but that doesn't follow unless this does 8 floating point operations per cycle not 4. The image of the pipeline…
[deleted]
Re: ARM MacBook vs. Intel MacBook
#75Earlier quoted context omitted.
These are my personal observations. You can reproduce, but you'll need to bootstrap the Go toolchain first. For example, in your GOROOT: go test -test.bench=Cond2 --test.run=ZZ --test.cpu=1,2,4 sync For me: goos: linux goarch: amd64 pkg: sync BenchmarkCond2 3575089 336 ns/op BenchmarkCond2-2 3236198 370 ns/op BenchmarkCond2-4 2831134 420 ns/op goos: darwin goarch: arm64 pkg: sync BenchmarkCond2 5903233 190.4 ns/op Be…
I would not use a work in progress port of Go to compare. This would be better in C to rule out Go runtime issues.
It probably is in the Go runtime but I tend to look at things at this level. For example if there's some bug in libc++ that's not something I can overlook when evaluating the M1.
There was another comment here that was deleted that accidentally showed the output of running x86-64 go on the M1. That's another weird risk at the user level, that you may unknowingly run the wrong binary through rosetta2 instead of running the native one.
Re: ARM MacBook vs. Intel MacBook
#76Earlier quoted context omitted.
To follow-up on my own point, once an x86 instruction has been decoded into a micro-op, it gets stored in a micro-op cache, where the vast majority of the frontend spends it's time fetching from. Additionally, "in flight" is a function of frontend width, Reorder buffer size, additional Out of order structures sizes and throughput depends on those plus the retire width. Additionally, IPC alone is a poor metric for per…
How does this square with their relatively low power consumption? (Honestly asking--I don't know about this stuff)
I suspect that's largely due to the smaller process size.
Re: ARM MacBook vs. Intel MacBook
#77"The Intel processor has nifty 256-bit SIMD instructions. The Apple chip has nothing of the sort as part of its main CPU. So I could easily come up with examples that make the M1 look bad." The M1 has 128-bit NEON SIMD, and given its decode pipeline and cache efficiency it seems more likely to actually benefit entirely from it. AVX on Intel devices is often of limited value because it's either memory starved or gets…
This is one of the things I missed about AltiVec from the PPC days. They really designed it nicely. It was a different set of registers that worked normally. The permute instructions were very useful! When trying to port AltiVec code to Intel SSE at the time, it would often come out worse because of all the constraints. You couldn't intermix floating point and SSE code because they used the same registers. There were…
Yeah I really wanted to dig into AlitVec a bit more, but by the time I took a look at it, we had moved on to Intel. So I just tried to use the OS X vector libraries where possible, and hope for the best.
There was a paper that really got my attention, from US Air Force research I think, that reported a micro benchmark on a Mac Mini G4 where the AltiVec scores blew away their best Silicon Graphics beast.
The M1 reports feel a lot like that. Or better, because of the reports coming in on huge performance gains in real world apps.
Re: ARM MacBook vs. Intel MacBook
#78Earlier quoted context omitted.
Great, now that we have this new fast hardware, time for developers to make everything 2x slower again.
Do all technical advances make you feel sad? Why hang out on Hacker News then?
Not all but software related in general and Javascript/Electron related in particular any advance make me sad. I hang out on HN to find comfort in fact that others also feel crappy software hosing all the hardware advances.
Re: ARM MacBook vs. Intel MacBook
#79Earlier quoted context omitted.
4 x86 decoders, all modern x86 CPUs have micro-op caches that are wider than 4 and the retire width of the machines are 6 or greater. Saying it can process twice as many instructions per clock cycle is an incredibly incorrect statement.
Saying it can process twice as many instructions per clock cycle is an incredibly incorrect statement. It's not as incredibly incorrect as you may think. An x86 instruction can be as big as 15 bytes and there's no easy way for the decoder to know where one instruction ends and the next one begins. All ARM instructions are one size, making instruction decoding more efficient and makes out of order processing faster as…
Parent's comment was about micro-op caches. Modern x86 processors in a relatively tight loop do not decode the instructions each iteration.
I suspect you haven't internalized this, because reiterating the complexity of decoding instructions just isn't a valid response. The entire point is avoiding that cost.
Re: ARM MacBook vs. Intel MacBook
#80Earlier quoted context omitted.
That’s interesting considering all the articles I’ve read on this thing indicate the exact opposite. Uncontended atomics are basically free and a huge reason why Swift and ObjC code gets such a huge boost (ARC cost is down significantly). Traditional POSIX mutexes in MacOS weren’t heavily optimized. When I worked at Apple ~5 years ago they still didn’t have a good futex implementation (not sure if that’s changed sinc…
These are my personal observations. You can reproduce, but you'll need to bootstrap the Go toolchain first. For example, in your GOROOT: go test -test.bench=Cond2 --test.run=ZZ --test.cpu=1,2,4 sync For me: goos: linux goarch: amd64 pkg: sync BenchmarkCond2 3575089 336 ns/op BenchmarkCond2-2 3236198 370 ns/op BenchmarkCond2-4 2831134 420 ns/op goos: darwin goarch: arm64 pkg: sync BenchmarkCond2 5903233 190.4 ns/op Be…
Go f1980efb92c011eab71aa61b68ccf58d845d1de7 on a Mini on 11.0.1
goos: darwin
goarch: arm64
pkg: sync
BenchmarkCond2 4849542 249.7 ns/op
BenchmarkCond2-2 2639139 531.1 ns/op
BenchmarkCond2-4 3112030 393.1 ns/op