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

M1 Macs: Truth and Truthiness

daringfireball.net

Post reply on HN
Print view View original

761–770 of 882 posts

Re: M1 Macs: Truth and Truthiness

#761

Post by thu2111 »

valuearb wrote: post #493
thu2111 wrote: post #198

Earlier quoted context omitted.

How does that matter though? His machine isn't sitting on his lap or running on a battery. Electricity isn't that expensive.

It matters because its not just adding electricity, its adding heat. Pretty clearly Apple can add a whole bunch of Firestorm cores to future M1 derivatives and still fit in smaller power/heat budgets that current generation Ryzen and Threadrippers operate in.

Maybe. I don't know enough about CPU design to argue with that. There are others elsewhere in this thread saying that a lot of the energy and heat goes on the communications systems and other resources you need more of when you ramp up the core count.

I suspect we'll never know. Apple have shown little interest in anything other than prosumer workloads for a long time. I doubt they'll be making an M1 server platform anytime soon.

Re: M1 Macs: Truth and Truthiness

#762

Post by tolien »

detaro wrote: post #656
blunte wrote: post #626

Earlier quoted context omitted.

Is Intel really so blind that they didn't see this coming or even have detailed inside info about it? I would wager that they knew, but execs chose to protect their personal short term interests overt those of the company and its long term shareholders. This is typical modern US publicly traded company behavior.

What would have been the choice they should have made that was not protecting their short term interests and better for the company?

There's been comments here and elsewhere for a while saying that Intel's remuneration policy (i.e. salaries and benefits) have been uncompetitive and between that and the culture some of the best people have left (a number of them to Apple) so the answer's pretty obvious.

Throw money at it - find the best and brightest people and stuff their mouths with gold to have them solve whatever problems Intel's still having with 10nm and beyond as quickly as possible and with honest timelines to when that'll happen (not "oh it'll totally work this quarter").

Intel blowing the lead they had on semiconductor process technology is an existential threat, especially if it's blocking them getting out improvements in IPC (i.e. see what AMD are doing) also, so it's impossible to overstate how important this should be to Intel's senior leadership (by which I mean if it's not solved real soon, the shareholders ought to be removing them from post).

Re: M1 Macs: Truth and Truthiness

#763

Post by saagarjha »

alwillis wrote: post #745
saagarjha wrote: post #366

Earlier quoted context omitted.

> Apple’s Rosetta 2 doesn't do emulation; it translates the x86 code into ARM code on the fly and runs it That’s…emulation.

Nope. First line from Wikipedia[1]: Rosetta is a dynamic binary translator developed by Apple Inc. for macOS… Follow the link for Dynamic Binary Translator[2]: Dynamic binary translation (DBT) looks at a short sequence of code—typically on the order of a single basic block—then translates it and caches the resulting sequence. Code is only translated as it is discovered and when possible, and branch instructions are m…

Believe me, I know how Rosetta works. You don't need to quote Wikipedia at me ;)

Rosetta absolutely is an emulator, which has traditionally referred to taking code from one CPU architecture and making it run on another (in contrast with taking a binary of the same architecture but running it in another environment, which is often called a "compatibility layer" or in Apple's terms a "simulator", or the hardware-assisted version of this which is virtualization). There are many ways to write the part of an emulator that mimics another CPU; the simplest is an interpreter loop, but there's ahead-of-time and just-in-time code generation techniques as well. Dynamic binary translation is quite simple, as your quote mentions; Rosetta 2 instead achieves its performance through a combination of static binary translation to a form amenable to its runtime. Things that it cannot translate go through a fairly advanced optimizing JIT that goes way beyond what a dynarec would typically do.

Re: M1 Macs: Truth and Truthiness

#764

Post by WhyNotHugo »

TBH, I think that most experts who didn't see this coming were simply in denial.

Disqualifying benchmarks because... it's mobile?

Disregarding performance and cooling differences with an iPad because... it's an iPad?

They all sound like excuses to disregard the obvious results. Synthetic benchmarks can lack fine grained precision. They might be bad at determining who's on top when there's a very small gap. But they provide valid results for determining if two products are in the same LEAGUE.

Sure, I an iPad could't run Linux, gcc or StarCraft,, but that's mostly an ecosystem issue, not a hardware performance one.

We've seen this coming for years now. Both the big obvious signs, and the little signs, like Apple continuously unifying code and APIs across platforms.

Re: M1 Macs: Truth and Truthiness

#765

Post by stefanv »

The only real (but small) downside (and just for some of us) is that you can't daisy chain two external monitors to the new M1 laptops. It's true that the mini can use two external monitors connected to separate ports or that you can jump through hoops and use more than two external monitors and that is why it's not such a big deal.

Re: M1 Macs: Truth and Truthiness

#766

Post by nix23 »

snazz wrote: post #275
romanoderoma wrote: post #242

Earlier quoted context omitted.

But honestly, does it matter? People buying a threadripper today don't care about it. What matters to them it's the performance, my gf is a 3d artist, she doesn't care if some cpu consumes more or less power than another (when I say she doesn't care I mean she doesn't even know that CPU have very different power requirements), she needs the fastest gear she can buy on her budget. Apple M1s are not it. There are many…

People using powerful laptops care about battery life, though. For someone moving from a "workstation"-class laptop, the M1's value is significant.

>For someone moving from a "workstation"-class laptop, the M1's value is significant.

Em NO, the M1's are not comparable with a workstation class laptops (not cpu wise nor ram...and especially not GPU wise)

Re: M1 Macs: Truth and Truthiness

#767

Post by Aissen »

ekianjo wrote: post #624
matheusmoreira wrote: post #332

Earlier quoted context omitted.

> messy device trees Can you please elaborate?

> * the x86 world resolves around standards such as ACPI, BIOSes and general-purpose dynamic buses. > * ACPI normalises every single piece of hardware from the perspective of most low-level peripherals. > * the BIOS also helps in that normalisation. DOS INT33 is the classic one i remember. > * the general-purpose dynamic buses include: - USB and its speed variants (self-describing peripherals) - PCI and its derivativ…

ARM UEFI systems exist. There are now the norm on servers along with ACPI. Even some embedded devices use UEFI. There are other standards to address those various points.

This post is so outdated, that ARM servers' companies had the time to have everything, then still die (most of them). And then revive with the AWS Graviton2 and other Neoverse chips.

Re: M1 Macs: Truth and Truthiness

#768

Post by account42 »

> We knew this to be true because that was the way things were. But now, with the M1 Macs, it’s not. M1 Macs run very fast and do so while remaining very cool and lasting mind-bogglingly long on battery. It was a fundamental trade-off inherent to PC computing, and now we don’t have to make it.

What a pile of horseshit. The tradeoff between heat and performance was always within a generation - "fast" is always relative. It's just the baseline that has moved, same as it has with every Intel/AMD generation, not a fundamental change.

Re: M1 Macs: Truth and Truthiness

#769

Post by jb1991 »

whywhywhywhy wrote: post #410
jb1991 wrote: post #244

Earlier quoted context omitted.

For the vast majority of users (who are not developers or doing production video work, etc), 16 GB is plenty. That's why.

"Pro" machine isn't for the "vast majority of users" it's for people who are developers and do video production work.

That's a surprising specific definition of the term you've come up with there.

Re: M1 Macs: Truth and Truthiness

#770

Post by dhruvdh »

alwillis wrote: post #758
dhruvdh wrote: post #666

Earlier quoted context omitted.

Another example - M1s can't do SMT, no one is denying that they are good chips but there's a lot of catching up for them to do. > And all of the M1 Macs have blazingly fast memory access. Remember, it's an SoC—the memory is on the same die as the CPUs, GPUs and they all have equal access to it. No bus to go across. What does this even mean? Memory works at a certain voltage, clock speed, and has a capped rate at whic…

Just read "Why Is Apple’s M1 Chip So Fast?" [1] to answer most of these questions. I’ll just hit the obviously erroneous issues here. A M1 chip has 16 billion transistors for 8 cores. AMD's EPYC Rome has 39.54 billion transistors for 64 cores. It doesn't make sense to compare the M1 with the EPYC Rome. They couldn't more different and were developed for dramatically different use cases. (I also don't think it's not a…

> It doesn't make sense to compare the M1 with the EPYC Rome. They couldn't more different and were developed for dramatically different use cases.

The author of your beloved article compared M1 to Zen 3, and all Zen 3 CPUs use the same 8-core chiplet. From the cheapest 6-core Ryzen 3 5600 to the 64 core EPYC. All of them are made of the the exact same chiplets, just then number of chiplets varies. If you have 2 chiplet you get 16 cores, etc.

> Yes, even the EPYC Rome only has 4 instruction decoders.

It doesn't have "4 decoders"; it's just one 4-way instruction decoder. It's not the same thing.

> Firestorm cores to essentially process twice as many instructions as AMD and Intel CPUs at the same clock frequency.

A decoder doesn't not process instructions, it only interprets them and splits it up into smaller instructions. It doesn't make sense to compare number of instructions across different ISAs anyway, ARM has smaller, simpler, and on account of that more numerous instructions. One x86-64 instruction more often than not maps to multiple ARM instructions. It just makes no sense to compare counts.

I sort of stopped reading your comment around here, sorry about that.

Post reply on HN