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

691–700 of 1001 posts

Re: Apple Silicon M1: Black Magic Fuckery

#691

Post by niea_11 »

detaro wrote: post #670
niea_11 wrote: post #656

Earlier quoted context omitted.

I don't use apple products but I think the high price of a workstation is not something specific to Apple. From a discussion I had with a friend recently, I found that Precision workstations from Dell or Z workstations from HP have similar prices for similar performances (sometime prices can reach 40k or 70k dollars). When comparing Mac Pro to an enthusiast pc build, yes the mac pro is "overpriced", but the mac pro i…

It's not just "enthusiast PC builds". You can buy plenty of PCs in that middle category of high-but-not-extreme performance without the certifications, Quadros and vendor markup that a full-on "workstation" model has. And they're perfectly fine choices for many professional use cases. For that market , the Mac Pro is overpriced (the high-end Dell/HP workstations are too), and Apple doesn't make anything more suited f…

My bad, I misunderstood the context of the comment. Thanks for the clarification.

For me personally, outside of laptops and phones, I don't see the appeal of using Apple hardware (unless you want to use MacOS X).

Re: Apple Silicon M1: Black Magic Fuckery

#692

Post by masklinn »

pjmlp wrote: post #606
masklinn wrote: post #566

Earlier quoted context omitted.

Apple’s runtimes have always used rc, this is not a change between Intel and arm.

Nope, they also tried a tracing GC for Objective-C on the desktop, but it was a failure due to interoperability across libraries compiled in different modes alongside C semantics. Then they pivoted into automating retain/release patterns from Cocoa and sold it, Apple style, as a victory of RC over tracing GC, while moving the GC related docs and C related workarounds into the documentation archive.

> Nope, they also tried a tracing GC for Objective-C on the desktop

Operative word: tried. GC was an optional desktop-only component deprecated in Mountain Lion, which IIRC has not been accepted on MAS since 2015 was removed entirely from Sierra.

Without going into irrelevant weeds, "apple has always used refcounting everywhere" is a much closer approximation.

Re: Apple Silicon M1: Black Magic Fuckery

#693

Post by roguelynn »

kenneth wrote: post #689

I do take slight issue with the section about RAM performance. The idea in the article is that M1 Mac runs software that uses reference-counting instead of garbage collection as its memory model (i.e. Objective-C and Swift software). Two issues… 1/ Sure, but that's also the case with with x86 Intel Macs. Still running reference-counting Obj-C and Swift software for the most part. So how is this a M1 differentiator? 2…

Minor correction: Spotify isn’t Electron, it’s Chromium Embedded Framework.

Re: Apple Silicon M1: Black Magic Fuckery

#694

Post by emsy »

tolien wrote: post #626
read_if_gay_ wrote: post #603

Earlier quoted context omitted.

Then buy the new Mac Pro? I don't understand why that's not an option for GP.

Because as the sibling comments point out, the price of a Mac Pro isn't just an "Apple Tax^WPremium" over a desktop machine but is an order of magnitude more expensive (assuming you don't care about workstation-class components, i.e. Xeon Ws, Radeon Pro GPUs and ECC RAM). There's an enormous price gap between a Mac Mini and the Mac Pro (especially when the Mini now has higher single-threaded performance than the base…

Exactly this. The closest to this would be an i7 iMac but not everyone wants an Aio PC. It’s kind of a bummer. We finally have an iPhone for everyone, even a high end small form factor option. Whoever is responsible for that decision please take a look at the Mac lineup next.

Re: Apple Silicon M1: Black Magic Fuckery

#695

Post by zarkov99 »

ngai_aku wrote: post #425
zarkov99 wrote: post #198

I am thinking about getting thing mostly to ssh into a linux server. I would like to run emacs on the server and have its display bounced back via X to the Mac. Is this practical? I tried Quartz on my wife's Mac but the fonts looked like crap.

Why run emacs on the server instead of running emacs on your local machine and accessing the server via tramp?

I have a highly customized emacs setup that works best on the server.

Re: Apple Silicon M1: Black Magic Fuckery

#696

Post by socialdemocrat »

chongli wrote: post #408
xoa wrote: post #57

Not to speak for anyone else, but one thing I gently disagree with: > Given that Hackintoshers are a particular bunch who don’t take kindly to the Apple-tax[...] I have zero issues with an Apple premium or paying a lot for hardware. I think a major generator of interest in hackintoshes has been that there are significant segments of computing that Apple has simply completely (or nearly completely) given up on, includ…

Apple does not want to offer to the hackintosh/enthusiast market because they are the most price conscious segment. Targeting that segment means putting out extremely performant, low-margin commodity machines. Doing so then cannibalizes the market for their ultra-high-end stuff. Not only that, though. Enthusiasts are also extremely fickle and quick to jump ship to a cheaper hardware offering. If you look at all of Ap…

What Apple could have done is to continue supplying something like the G4 towers. Those where stunningly beautiful machines and practical.

Re: Apple Silicon M1: Black Magic Fuckery

#697

Post by mpweiher »

brundolf wrote: post #25

This is fascinating: > Retain and release are tiny actions that almost all software, on all Apple platforms, does all the time. ….. The Apple Silicon system architecture is designed to make these operations as fast as possible. It’s not so much that Intel’s x86 architecture is a bad fit for Apple’s software frameworks, as that Apple Silicon is designed to be a bespoke fit for it …. retaining and releasing NSObjects i…

> "M1 and memory efficiency"

Hi folks!

It looks like my blog post[1] was the primary source for this (it's referenced both by this post and by the Gruber post), and to be clear, I did not claim that this helps ARM Macs use less RAM than Intel Macs. I think John misunderstood that part and now it has blown up a bit...

I did claim that this helps Macs and iPhones use less RAM than most non-Apple systems, as part of Apple's general obsessiveness about memory consumption (really, really obsessive!). This part of the puzzle is how to get greater convenience for heap allocation.

Most of the industry has settled on tracing GCs, and they do really well in microbenchmarks. However, they need a lot of extra RAM to be competitive on a system level (see references in the blog post). OTOH, RC trends to be more frugal and predictable, but its Achilles heel, in addition to cyclic references, has always been the high cost of, well, managing all those counts all the time, particularly in a multithreaded environment where you have to do this atomically. Turns out, Apple has made uncontented atomic access about as fast as a non-atomic memory access on M1.

This doesn't use less RAM, it decreases the performance cost of using the more frugal RC. As far as I can tell, the "magic" of the whole package comes down to a lot of these little interconnecting pieces, your classic engineering tradeoffs, which have non-obvious consequences over there and then let you do this other thing over here, that compensates for the problem you caused in this other place, but got a lot out etc. Overall, I'd say a focus on memory and power.

So they didn't add special hardware for NSObject, but they did add special hardware that also tremendously helps NSObjet reference counting. And apparently they also added a special branch predictor for objc_msgSend(). 8-). Hey, 16 billion transistors, what's a branch predictor or two among friends.. ¯\_(ツ)_/¯

[1] https://blog.metaobject.com/2020/11/m1-memory-and-performanc...

Re: Apple Silicon M1: Black Magic Fuckery

#698

Post by Twisell »

Maxion wrote: post #684
Twisell wrote: post #646

Earlier quoted context omitted.

However real case usage of such massive amount of data are limited for typical desktop user. Massive database load usually happen on specialized servers in which 256Go RAM and more are pretty mundane. So on customer PC ram is maybe more used as caching mechanisms or eaten away by poorly designed memory leak/garbage collection. And if your GPU is able do to real time rendering on data heavy load maybe you need less ca…

Plenty of use cases for more than 8gb of ram. When you're doing data analysis on even smaller datasets you may need several times more available memory than the size of the dataset as you're processing it.

1.Again typical use case for entry level PC is not data analysis on bigdata.

2.My current production server is a PostgreSQL database on a 16GB RAM VM running on Debian (my boss is stingy). This doesn't prevent me from managing a 300GB+ data cluster with pretty decent performances and perform actual data analysis.

3.If Chrome sometimes use +8GB for a godsake webrowser the only explanation is poor design, there is no excuse.

Re: Apple Silicon M1: Black Magic Fuckery

#699

Post by dfox »

lilyball wrote: post #453
dfox wrote: post #297

Earlier quoted context omitted.

I suspect that Apple didn't anything special to improve performance of reference counting apart from not using x86. Simply put x86 ISA and memory model is built on assumption that atomic operations are mostly used as part of some kind of higher-level synchronization primitive and not for their direct result.

M1 is faster at retain/release under Rosetta2 than x86, and yet Rosetta2 still has the same strong memory model that x86 does.

One thing is that M1 has incredible memory BW and is implemented on single piece of silicon (which certainly helps with low-overhead cache consistency). Another thing is that rosetta certainly does not have to preserve exact behavior of x86 (and in fact it cannot because doing so will negate any benefits of dynamic translation) it only has to care about what can be observed by the user code running under it.

Re: Apple Silicon M1: Black Magic Fuckery

#700

Post by foldr »

amelius wrote: post #674
fomine3 wrote: post #396

Earlier quoted context omitted.

Bottleneck for swap in/out must be SSD, not memory. Also its SSD isn't fast compared to other NVMe SSDs in both throughput and IOPS. Possibly latency is great thanks to integrated SSD controller onto M1 but I don't think it changes the game.

Is a SSD suitable for swap, given its limited number of write cycles?

When I looked into this, the information I found suggested that modern consumer SSDs generally have more than enough write cycles to spare for any plausible use case. Possibly this was more of an issue five to ten years ago.
Post reply on HN