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

331–340 of 1001 posts

Re: Apple Silicon M1: Black Magic Fuckery

#331

Post by alwillis »

spurgu wrote: post #143
bawolff wrote: post #134

Earlier quoted context omitted.

That's not really on this topic. What linus wants to use personally has little bearing on what architectures linux will (eventually) support. Edit To clarify: i mean, linus is saying he wouldnt go to the trouble personally, not that he would reject a patch adding support. Those are two very different things.

How is "Apple may run Linux in their cloud, but their laptops don't ;(" not on topic? Edit: It's not like Apple has any (commercial) interest in working with the Linux kernel developers to ensure support/compatibility even if the M1 is ARM based. Edit 2: Don't get me wrong, if Apple announces they will support Linux I'll run out the door and buy one now, as a MacOS user. Edit 3: And this is a criticism against Apple…

Do you really think the M1 future is looking rosy for Linux?

I think fairly soon, we'll have Linux running nicely on Apple Silicon Macs, using the hypervisor built into macOS. And it will run faster than comparable Intel machines.

Apple gets the importance of Linux and Docker for developers; I'm pretty sure it'll get worked out.

Re: Apple Silicon M1: Black Magic Fuckery

#332

Post by kevindong »

hu3 wrote: post #302
kllrnohj wrote: post #249

Earlier quoted context omitted.

Not even close to true. Apple's ARM processors are unlike anyone else's, and everyone else's ARM processors are not particularly impressive. The power/performance isn't really there, and scaling performance up is not linear, either. You can't just "make it bigger" and retain the same power/performance ratio you had. The 1W power draw that the 'big' ARM cores target, like the Cortex-A78, isn't even that special. You c…

It's not far, really. Android phones with Qualcom Snapdragon 865 scores better than an Intel i7 7700HQ (4 cores, 8 threads) on Geekbench on multi-core and ties on single core while using a magnitude less energy. While this i7 model is not new, it's not the "U" low voltage processor version. I could see Qualcom getting fancy and trying to scale their processors at 5nm. https://browser.geekbench.com/android_devices/one…

The last time the i7-7700HQ was sold in a Mac was for the mid-2017, 15" MBP. The current gen (late-2019) base model 16" MBP uses a i7-9750H.

Single core performance is ~17.5% better and multi-core performance is ~51.2% better than the 865. The numbers are still surprisingly close given that the Snapdragon uses significantly less power.

https://browser.geekbench.com/processors/intel-core-i7-9750h

Re: Apple Silicon M1: Black Magic Fuckery

#333

Post by fomine3 »

socialdemocrat wrote: post #293
fomine3 wrote: post #230

Earlier quoted context omitted.

I can't understand why less RAM is enough specially in Apple Silicon rather than Intel. Is the argument proved? RAM capacity is just RAM capacity. Possibly Swift-made apps uses less RAM compared to other apps, but microarchitecture shouldn't be matter.

I don't quite see that either. But I suspect that it is just macOS itself which uses less memory than Windows in general. But the much faster SSD to RAM transfer for the M1 means that shuffling stuff in and out of RAM is much faster meaning RAM matters less.

I think OS' usage isn't main matter for RAM. Browser, Electron apps, professional apps like Photoshop, IntelliJ, and VM should be.

I expected SSD is way fast, but benchmark says its SSD is about below 3000MB/s RW, not very fast but usual Gen3 x4 speed.

Re: Apple Silicon M1: Black Magic Fuckery

#334

Post by crazygringo »

3np wrote: post #284
crazygringo wrote: post #129

Earlier quoted context omitted.

Seriously, I'm utterly baffled by all the people claiming that 8 GB isn't enough for the average user. The only situation I ever ran into where it was a problem was in trying to run multiple VM's at once. Otherwise it's just a non-issue. Programs often reserve a lot more memory than they actually use (zero hit in performance) so memory stats are misleading, and the OS is really good at swapping memory not touched in…

I pretty much daily have to do a closing round to not run out of my 24GiB. That’s all web browsers (Usually 100-200 tabs), vs code with some extensions and 2x4k display.

But what do you even mean "run out"? This is what I don't get.

If you have multiple browsers with hundreds of tabs, the majority of those tabs are probably swapped out to your SSD already.

With swapfiles and SSD's, physical memory is less and less relevant except when you're performing very specific computational tasks that actually require everything to be simultaneously in memory -- things like highly complex video effects rendering.

How do you measure "running out" of your 24 GiB? And what happens when you do "run out"?

Re: Apple Silicon M1: Black Magic Fuckery

#335

Post by saagarjha »

lilyball wrote: post #72
brundolf wrote: post #54

Earlier quoted context omitted.

I'm wondering if the "optimized for reference-counting" thing applies to other languages too. i.e. if I write a piece of software in Rust, and I make use of Rc , will Macs be extra tolerant of that overhead? In theory it seems like the answer should be yes

I sure hope so. In macOS 10.15, the fast path for a retain on a (non-tagged-pointer) Obj-C object does a C11 relaxed atomic load followed by a C11 relaxed compare-and-exchange. This seems pretty standard for retain-release and I'd expect Rust's Rc to be doing something similar. It's possible Apple added some other black magic to the runtime in 10.16 (and they haven't released the 10.16 objc sources yet) but it's hard…

I’d think the bigger win would have to be in the release part of the code, which actually cares about contention.

Re: Apple Silicon M1: Black Magic Fuckery

#338

Post by fartcannon »

bitwize wrote: post #330
gumby wrote: post #270

Earlier quoted context omitted.

I agree: this kind of thing is infuriating because it's such a slowdown to have to go touch the mouse and find the pointer on the screen. Really interrupts the workflow.

The stopwatch consistently proves it takes less time than using the keyboard. Apple's HCI research showed that people "lose" the time it takes to hunt and acquire the keyboard shortcuts.

So don't use it? Why prevent people from using their computer how they would like.

Re: Apple Silicon M1: Black Magic Fuckery

#339

Post by nezgar »

IggleSniggle wrote: post #285
tobyjsullivan wrote: post #243

Earlier quoted context omitted.

In Apple's defence, I've been exclusively a mac user (work and personal) for going-on eight years now and I had no idea about the Option-letter shortcut. I've always found keyboard nav within modal popups confusing. I consider myself lucky if hitting Space selects the primary button. Doesn't sound like the change is necessarily an improvement, though.

Wow, I didn’t know about that either. And yet Windows 95 had this solved: just show the shortcut letter underlined and/or bolder.

Even Windows 3.11, NT 3.51 did this... and my Atari ST... probably windows 1.0 even because a mouse was not always guaranteed to be attached and/or working on early PC's. In my case in the mid 90's I remember I sacrificed the serial port the mouse was attached to run another modem for dial-in access to our officer on NT 3.51 server... THAT tought me fast how to get around a windows desktop with the keyboard - and it impressed me you could access everything - switching windows, menus, etc without getting "stuck" . With a mac, your computer would be useless, or at best infuriating (ie using some plug in to slowly nudge the pointer around the screen with arrow keys....)

Re: Apple Silicon M1: Black Magic Fuckery

#340

Post by saagarjha »

gpderetta wrote: post #102
trevyn wrote: post #27

Earlier quoted context omitted.

They stuff the reference count in the unused bits of the 64-bit pointers.

How would that work? The refcount need to be on the pointee, not on the pointer.

It’s stored in the isa pointer inside the object.
Post reply on HN