Live data from Hacker News

Apple Silicon M1: Black Magic Fuckery

Post reply on HN

Print view View original

841–850 of 1001 posts

Re: Apple Silicon M1: Black Magic Fuckery

#841

Post by ogre_codes » Wed, Nov 25, 2020, 4:27 PM UTC

izacus wrote: post #612

ogre_codes wrote: post #553

Earlier quoted context omitted.

> So, the "walled garden" is intended for the underlying hardware. I don't think that is what he was saying at all. Regardless. There is nothing preventing Linux (or Windows) from booting on Mac M1 hardware. People almost certainly will have Linux running on Mac hardware before too long. It's just a slog getting it working well. Not a walled garden in any traditional sense, just difficult to implement.

> There is nothing preventing Linux (or Windows) from booting on Mac M1 hardware. Except the iOS-like secure boot verification and complete lack of any kind of documentation or drivers for the hardware. Details!

> Except the iOS-like secure boot verification...

Which Apple has documented how to work around.

> ... or drivers for the hardware.

Which is why I said it was going to be difficult to implement.

> ... Details!

Were apparently ignored.

Re: Apple Silicon M1: Black Magic Fuckery

#842

Post by vetinari » Wed, Nov 25, 2020, 4:27 PM UTC

brutal_boi wrote: post #683

Shared404 wrote: post #444

Earlier quoted context omitted.

You do get obtrusive telemetry (Cortana is a good example), but you avoid Candy Crush et al. You can disable some of the telemetry during install as well.

Just run any of the reclaim series. Pure gold if you ask me. https://gist.github.com/alirobe/7f3b34ad89a159e6daa1

That looks like fork of https://github.com/Disassembler0/Win10-Initial-Setup-Script

Re: Apple Silicon M1: Black Magic Fuckery

#843

Post by derefr » Wed, Nov 25, 2020, 4:29 PM UTC

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…

> it won't help in areas that Apple just organizationally doesn't care about/doesn't have the bandwidth for because that's not a technology problem

I would posit that Apple is always going to keep macOS working on some workstation-class hardware, just because that kind of machine is what Apple's software engineers will be using internally, and they need to write macOS software using macOS.

Which means one of two things:

1. If they never release a workstation-class Apple Silicon chip, that'll likely mean that they're still using Intel/AMD chips internally, and so macOS will likely continue to be compiled for Intel indefinitely.

2. If they do design workstation-class Apple Silicon chips for internal use, they may as well also sell the resulting workstation-class machines to people at that point. (Or, to rearrange that statement: they wouldn't make the chips if they didn't intend to commercialize them. Designing and fabbing chips costs too much money!)

Which is to say, whether it be a Hackintosh or an Apple Mac Pro, there's always going to be something to cater to workstation-class users of Apple products — because Apple itself is full of workstation-class users of Apple products.

Re: Apple Silicon M1: Black Magic Fuckery

#844

Post by ericmay » Wed, Nov 25, 2020, 4:29 PM UTC

ehvatum wrote: post #814

ericmay wrote: post #750

Earlier quoted context omitted.

> Okay, but offering no machine suitable for developers You mean... software developers? The same people who almost universally use a Mac?

> The same people who almost universally use a Mac? This has become steadily less true since about 2012, in my experience. I don’t know any full time developers still using an Apple laptop. The keyboard situation caused a lot of attrition. I finally stopped support for all Apple hardware at my company months ago, simply to get it out my headspace. Will Fusion360 again be completely broken by an Apple OS update? Am I…

> I don’t know any full time developers still using an Apple laptop.

Fascinating. I can name a few startups in my town that use Apple. One just IPO'd (Root), another is about to (Upstart). There are others as well.

The big companies it's hit or miss. Depends on if they are working on big enterprise applications or mobile/web. Mobile and web teams are all on MacBook Pros, and the big app dev teams aren't.

When I was last in Mountain View they were on Mac as well but I know that depends on personal preference.

Re: Apple Silicon M1: Black Magic Fuckery

#845

Post by __float » Wed, Nov 25, 2020, 4:30 PM UTC

sudosysgen wrote: post #536

ogre_codes wrote: post #452

Earlier quoted context omitted.

> It's very easy to perform very well on a specific benchmark when there's dedicated hardware for this. I'd say the same about GPUs as well. It's great for people who game, but beyond a certain baseline, it's pretty pointless for most of us. > I'm not saying this isn't good, it's great for people editing, but this isn't a general indicator of performance Umm, it's also great for people who watch YouTube or Netflix. Z…

GPUs, unlike video decoders, are programmable and general in purpose. As for Zoom, YouTube, and Netflix, existing hardware is more than fine enough. No one is streaming 8K RAW for a conference call. Unless you're an editor, you won't see much of a benefit.

I think many folks' experience with Zoom would show the opposite. Perhaps it's not very efficient software, but battery life often tanks, computers get very warm, and fans start spinning.

Any improvement to that is a very welcome change, if you ask me.

Re: Apple Silicon M1: Black Magic Fuckery

#846

Post by thu2111 » Wed, Nov 25, 2020, 4:34 PM UTC

saagarjha wrote: post #282

torstenvl wrote: post #161

Earlier quoted context omitted.

I don't think that's quite right. Apple believes strongly in retain-and-release / ARC. It has designed its software that way; it has designed its M1 memory architecture that way. The harmony between those design considerations leads to efficiency: the software does things in the best way possible, given the memory architecture. I'm not an EE expert and I haven't torn apart an M1, but Occams's Razor would suggest it's…

The hardware makes uncontended atomics very fast, and Objective-C is a heavy user of those. But it would really help any application that could use them, too.

But GCd languages don't need to hit atomic ops constantly in the way ref-counted Objective C does, so making them faster (though still not as fast as regular non-atomic ops) is only reducing the perf bleeding from the decision to use RC in the first place. Indeed GC is generally your best choice for anything where performance matters a lot and RAM isn't super tight, like on servers.

Kotlin/Native lets us do this comparison somewhat directly. The current and initial versions used reference counting for memory management. K/N binaries were far, far slower than the equivalent Kotlin programs running on the JVM and the developer had to deal with the hassle of RC (e.g. manually breaking cycles). They're now switching to GC.

The notion that GC is less memory efficient than RC is also a canard. In both schemes your objects have a mark word of overhead. What does happen though, is GC lets you delay the work to deallocate from memory until you really need it. A lot of people find this quite confusing. They run an app on a machine with plenty of free RAM, and observe that it uses way more memory than it "should" be using. So they assume the language or runtime is really inefficient, when in reality what's happened is that the runtime either didn't collect at all, or it collected but didn't bother giving the RAM back to the OS on the assumption it's going to need it again soon and hey, the OS doesn't seem to be under memory pressure.

These days on the JVM you can fix that by using the latest versions. The runtime will collect and release when the app is idle.

Re: Apple Silicon M1: Black Magic Fuckery

#847

Post by derefr » Wed, Nov 25, 2020, 4:35 PM UTC

iguy wrote: post #793

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…

Yes, I think they view the basic mid-range tower box as a nearly-extinct form. Like corded telephones & CRTs. They choose to make the mac pro as some kind of halo product, I guess. But really the slice of people who need more power than an iMac, and less than this "Linux tower full of GPUs" or a render farm, they judge to be very small indeed. This wasn't true in the 90s, when laptops (and super-slim desktops) came w…

I don't think they think it's a small market; I think they think it's a commoditized market with very thin margins. That form-factor has a literal thousand+ integrators building for it, and also in many segments (e.g. gaming) people build their own to save even more money. Those aren't the sort of people who are easily swayed to pay an extra $200+ of pure margin in exchange for "integration" and Genius Bar "serviceability" (the latter of which they could mostly do themselves given the form-factor.)

Re: Apple Silicon M1: Black Magic Fuckery

#848

Post by seabrookmx » Wed, Nov 25, 2020, 4:35 PM UTC

the_duke wrote: post #509

seabrookmx wrote: post #480

Earlier quoted context omitted.

> emulating virtualized x86 code I don't think this is an issue for Docker. They can run an ARM64 Linux VM instead of the current x86 one, and then use QEMU to run x86 Docker containers within it if they want. The bummer is that this won't be taking advantage of Rosetta 2 so it'll likely perform bad, but it might be good enough for debugging the odd image or even development depending on _how_ bad.

Qemu performance without hardware virtualization is painfully slow and is not really practical for eg running a Kubernetes cluster.

Yeah that's what I was getting at.

There is no hardware virtualization here because it's emulating a different architecture.

Rosetta 2 is able to do this entirely in software with very impressive performance but I doubt QEMU will be in the same league.

That said, if you can get most of your containers in native ARM (you can already run k8s on ARM, for instance), it might be a valid escape hatch for the odd image that hasn't updated yet.

Re: Apple Silicon M1: Black Magic Fuckery

#849

Post by lozaning » Wed, Nov 25, 2020, 4:37 PM UTC

philwelch wrote: post #839

mikepurvis wrote: post #803

Earlier quoted context omitted.

Sure, but there's a legit gap in the datacenter— not having a sanely, legally rackable OS X machine is a pretty big problem for a lot of organizations. Not everyone wants to do their Jenkins builds or generate homebrew bottles on a Mac Mini under someone's desk.

Apple tried selling Xserves for years.

And to this day they're still the most gorgeous servers ever made, especially the xserve raid.

Re: Apple Silicon M1: Black Magic Fuckery

#850

Post by thu2111 » Wed, Nov 25, 2020, 4:39 PM UTC

lern_too_spel wrote: post #346

nemothekid wrote: post #154

Earlier quoted context omitted.

I saw that point brought up on Twitter and I don't know how it it makes more efficient use of RAM. Specifically, as I understood it is that Apple software (written in objective C/Swift) uses a lot of retain/release (or Atomic Reference Counting) on top of manual memory, for memory management rather than other forms of garbage collection (such as those found in Java/C#), which gives Objective C programs a lower memory…

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 it'll try and page huge sections of the heap at once where as RC is way more minimal in what it touches.

But in most other scenarios GC will win a straight up fight with an RC based system, especially when multi-threading gets involved. RC programs just spend huge amounts of time atomically incrementing and decrementing things, and rummaging through the heap structures, whereas the GC app is flying along in the L1 cache and allocations are just incrementing a pointer in a register. The work of cleaning up is meanwhile punted to those spare cores you probably aren't using anyway (on desktop/mobile). It's tough to beat that by hand with RC, again, unless you start hitting swap.

If M1 is faster at memory ops than x86 it's because they massively increased memory bandwidth. In fact I'd go as far as saying the CPU design is probably not responsible for most of the performance increase users are seeing. Memory bandwidth is the bottleneck for a lot of desktop tasks. If M1 core is say 10% faster than x86 but you have more of them and memory bandwidth is really 3x-4x larger, and the core can keep far more memory ops in flight simultaneously, that'll explain the difference all by itself.

Post reply on HN