Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple Silicon M1: Black Magic Fuckery

singhkays.com

Post reply on HN
Print view View original

891–900 of 1001 posts

Re: Apple Silicon M1: Black Magic Fuckery

#891

Post by joshstrange »

corytheboyd wrote: post #866

Call me dumb, but I didn’t realize they had done so much memory optimization to make the physical 8GB of RAM so effective. I saw a very much lower number than I expected and just assumed it wouldn’t handle memory intensive workloads well. As someone who develops web tech my entire life revolves around crushing RAM, now I think the M1 may actually result in big gains for my workload hrmm

Same here, I guess after years of the iPhone specs being lower than Androids when it came to things like RAM but still crushing Android phones should have clued me in. I figured that with 16GB max that the new computers would be a non-starter for me but from what I've seen I was wrong about that. Unfortunately the monitor limit IS a non-starter but I'll be first in line for the M2/M1S/M1Z (whatever they call it) in next year's new 16" MBP (assuming I can continue to drive all my monitors).

Re: Apple Silicon M1: Black Magic Fuckery

#893

Post by thoughtsimple »

tachyonbeam wrote: post #475
boromi wrote: post #449

How far away (in years) are chips comparable from AMD and say ARM ( Microsoft SQ2 ) for Windows machines?

I think the biggest reason this has such a huge performance advantage is that the 8/16GB RAM is built into the chip. Modern CPUs are mostly limited by memory bandwidth rather than compute performance, and this has way more memory bandwidth than competing CPUs because of the tight integration. This RAM might also be clocked much higher than what we're used to, because there is no long bus to the CPU anymore. The downs…

This has been misreported. The RAM is on the same chip carrier as the SoC but not built into the same silicon die. The memory bandwidth is reportedly ~68 GB/s which is good but not exceptional.

Re: Apple Silicon M1: Black Magic Fuckery

#894

Post by lern_too_spel »

thu2111 wrote: post #850
lern_too_spel wrote: post #346

Earlier quoted context omitted.

For a very long time, budget Android devices that were one or even two generations older were faster than just released iPhones at launching new apps to interactivity (see: hundreds of Youtube "speed comparison" videos). This was purely due to better software, as the iPhone had significantly faster processors and I/O. RAM doesn't play a big factor at launch. One very minor contributor would be that the GC doesn't nee…

Ridiculous that you're downvoted. There are a lot of people posting here who haven't worked on memory management subsystems. GC vs RC is not a trivial comparison to make, but overall there are good reasons new systems hardly use RC (Objective-C dating back to the 90s isn't new). Where RC can help is where you have a massive performance cliff on page access, i.e. if you're swapped to disk. Then GC is terrible because…

Indeed, one of the articles cited by the article that this discussion is about (https://blog.metaobject.com/2020/11/m1-memory-and-performanc...) links to a paper saying that GC needs 4x the memory to match manual memory management and then makes a huge wacky leap to say that ARC could achieve that with less. It can't. ARC will always be slower than manual memory management because it behaves the same way as naive manual memory management with some overhead on top.

On the other hand, that same paper shows that for every single one of their tested workloads, the generational GC outperforms manual memory management. Now obviously, you could do better with manual memory management if you took the time to understand the memory usage of your application to reduce fragmentation and to free entire arenas at a time, but for applications that don't have the developer resources to apply to that (the vast majority), the GC will win.

I'm not saying that better memory management is the reason Android wins these launch to interactivity benchmarks because the difference is so stark relative to the hardware performance that memory management isn't nearly enough to explain it, but it does contribute to it. (My own guess is that most of the performance difference comes from smarter process initialization from usage data. Apple is notoriously bad at using data for optimization.)

Re: Apple Silicon M1: Black Magic Fuckery

#895

Post by tachyonbeam »

thoughtsimple wrote: post #893
tachyonbeam wrote: post #475

Earlier quoted context omitted.

I think the biggest reason this has such a huge performance advantage is that the 8/16GB RAM is built into the chip. Modern CPUs are mostly limited by memory bandwidth rather than compute performance, and this has way more memory bandwidth than competing CPUs because of the tight integration. This RAM might also be clocked much higher than what we're used to, because there is no long bus to the CPU anymore. The downs…

This has been misreported. The RAM is on the same chip carrier as the SoC but not built into the same silicon die. The memory bandwidth is reportedly ~68 GB/s which is good but not exceptional.

How does that compare to the top Ryzen mobile chips?

Re: Apple Silicon M1: Black Magic Fuckery

#896

Post by thoughtsimple »

_2d30 wrote: post #60
neilpanchal wrote: post #4

I just got one. I’m blown away by the speed as well. Chrome runs insanely fast! Alas, it’s not developer ready yet. Brew is a mess. Docker doesn’t work. PyCharm is WIP although can use x86 version. I was skeptical of the hype but this little laptop has made me realize how slow everything else is. Unfortunately, while the hardware has accelerated far beyond expectations, the software - specifically MacOS BigSur is a m…

Brew is only slightly a mess, in my experience. I've installed brew both in the historical /usr/local location as well as the future home of /opt/homebrew. I then created these two aliases: alias armbrew="/opt/homebrew/bin/brew" alias intbrew="arch -x86_64 /usr/local/bin/brew" My PATH selects for programs installed in the /opt/homebrew location first and then /usr/local. I try to install with the ARM version first wi…

I've been using MacPorts instead of Homebrew. It seems further ahead on the Darwin AArch64 transition. About 80% of things that I've tried have worked without trouble. Unfortunately, ffmpeg wasn't one of them. I got that working yesterday with libx264 and libx265 integration. Oddly, libx265 installs fine under MacPorts but libx264 doesn't. But I was able to download the latest from git and build it and copy it manually to /opt/local.

Re: Apple Silicon M1: Black Magic Fuckery

#897

Post by pjmlp »

mikepurvis wrote: post #831
pjmlp wrote: post #827

Earlier quoted context omitted.

None of those use cases seem relevant for iOS or macOS development.

Surely you'd want CI builds for your app? I suppose you can always go the sassy option and just offload this problem onto Travis or CircleCI, but then they're the ones stuck figuring out how to rack thousands of Mac Minis, dealing with thermals in a machine that isn't set up for hot/cold aisles, a computer that doesn't have a serial port or dedicated management interface, etc. If you're a big enough org or the app is…

Nope, just build straight from XCode.

Re: Apple Silicon M1: Black Magic Fuckery

#898

Post by pjmlp »

damnyou wrote: post #855
pjmlp wrote: post #827

Earlier quoted context omitted.

None of those use cases seem relevant for iOS or macOS development.

If you ever get a chance to meet employees at CircleCI or some other CI provider at a conference after Covid is over, consider asking them about how they rack Mac Minis.

Good for them, I just use XCode.

Re: Apple Silicon M1: Black Magic Fuckery

#899

Post by mumblemumble »

maccard wrote: post #821
mumblemumble wrote: post #789

Earlier quoted context omitted.

> offering no machine suitable for developers and power users This perception strikes me as having warped in from a different decade. Nowadays, at least in my neck of the woods, developers almost universally use laptops, and Apple's still plenty competitive in the (high end) laptop department. For the most part, the only developers I know who still use desktops are machine learning folks who don't like the cloud and…

I work in games where we write c++ in a multi-million LOC base. Every developer in my company has a minimum of 12 cores, and 96GB RAM. All of the offices are backed by build farms on top of this. There are entire industries that rely on very high end hardware. (Of course we also rely on lots of windows-only software too, but that's only an issue once the hardware is solved)

Fair, and we could spend ages listing all the different kinds of people who have really specific job descriptions that require them to have traditional, stationary workstations. And then we could follow that up with lists of all the reasons why they need to be running Windows or Linux on said workstations, and couldn't choose comparable Apple hardware even if it were available.

But I don't think that we need to beat a dead horse like that. The more interesting one would be to figure out some interesting and non-trivially-sized cross-section of people who both need a workstation-class computer, and have the option of even considering using OS X for the purpose.

Re: Apple Silicon M1: Black Magic Fuckery

#900

Post by sharatvir »

Aperocky wrote: post #788
oblio wrote: post #578

Earlier quoted context omitted.

Regrets rarely appear 1 week after buying a product :-)

I thought they often happen instantly? Or in the 5 hours after you received the product? I don't ever recall regretting something I've purchased, say, more than 1 month ago. The act of purchase is foregone past by that point.

In the last couple years Ive been regretting only opting for 8gb ram in my 2015 13" MBP.
Post reply on HN