Hacker News Reader

Comment by moonchrome | Hacker News Reader

I was thinking about throwing some last gen parts into an old tower/PSU I have to build a desktop for inlaws since they are stuck on a 10year old hand down laptop. This is a good package at that price (599$) - power consumption is likely nothing, MacOS included in price, small and quiet - will comfortably browse the internet, play videos, etc. for the next 5+ years. I won't be able to repair it out of warranty so that's a bummer- but at such low price and their usage pattern I guess I can live with the risk.

View on HN

Shame I can't buy an M2 Max on an ATX mobo.

I imagine a lot of the performance of the M1 and thereafter is a direct result of moving the memory closer to the die. The power efficiency, sure, that's all engineering, but super close and fast memory right next to the CPU is only one step away from AMD's 3D v-cache that has (had) the 5800X3D beating out newer 7000 series AMD chips.

I think the bigger factor is that the 3D v-cache is SRAM, which is why it needs a whole stacked die for just 64mb.

> I imagine a lot of the performance of the M1 and thereafter is a direct result of moving the memory closer to the die

I'm not sure why this Apple marketing point gets repeated so often. The M2 has the same memory support as current Intel chips: 128-bit LPDDR5 6400. Mounting the memory on the same package as the CPU might have some engineering advantages compared to socketed RAM, but it doesnt make the (industry standard) memory any faster.

IMHO the biggest advantage is the RAM->GPU VRAM pipeline, or at least, that was my experience before - whatever you want to send to the VRAM, it has to be in RAM first, and you have to wait until it gets copied, before you can use that RAM again. With unified memory it should not be necessary anymore (you just mark that part as input for GPU). Same should sort-of apply for iGPUs but I'm not 100% sure.

And given that the whole MacOS is built around various GPU-accelerated frameworks, it kind-of matters a lot.

ATX is just a formfactor, there's nothing preventing apple from releasing an ATX board with soldered-on memory - this is actually not even that unusual in the µATX formfactor.

It would be cool to get the SoC on a socket like the Pentium II was, and then have some NVMe slots, PCIe slots, and more I/O ports. This would also be better for the planet if it was a standard feature of each Macintosh and just the SoC got replaced. Unfortunately, Apple's Macintosh line doesn't work that way. The first Macs were all-in-one designs, the 90s saw some heterogeneity, and then the Macintosh line came back to an all-in-one design (except for the MacPro line and the G4 Cube). Today, the G4 Cube is like something out of an alternate universe. Not only was it upgradable, it was also incredibly easy to "open up".

Is this thing actually faster than a cheap Ryzen build for browsing? Like a 5600g that are super cheap now

Yes: https://browser.geekbench.com/processors/amd-ryzen-5-5600g https://browser.geekbench.com/macs/macbook-air-2022 (same chip as in the cheaper Mini; the Mini has a fan so it should run a _little_ faster there)

Though for web browsing both presumably fall solidly under "good enough".

If I was signing up for Tech Support for Relatives, though, I'd _definitely_ go with the Mac; you don't want to be getting phonecalls about Windows 12 or whatever in 2027.

Apples M chips are stupid fast at browsing the web because they have some native CPU instructions for JavaScript that x86_64 chips don’t.

They’re fast but that’s not usually why. ARM added some functions which could help with math-limited code:

https://community.arm.com/arm-community-blogs/b/architecture...

Most JavaScript isn’t dependent on that specific a feature for performance, however. In most cases what matters more is that they have great memory performance and handle branch-heavy code well.

Assuming you use Safari. For older relatives, probably not a bad assumption, but an important distinction to make nonetheless.

Mozilla also implemented it. I believe Chrome/v8 have as well, but I know there was some work there to avoid accidentally enabling it on older ARM chips which don't have support for it.

Actually, it's the reverse. The JS spec accidentally baked in the x86 description of int/float conversion.

This is done a LOT in JS because the JITs are actually using integers instead of floats all over the place for improved performance.

The ARM "JS" instruction just encodes the x86 semantics into hardware making the conversion several times faster than doing it in software.

M1 was faster than a 5600g, I think, but you can get a 5-series micro PC for cheaper than even the cheapest Mac Mini. For 'browsing' operations, I suspect it wouldn't matter much. There may be some advantage to using macOS vs. Windows, if this is aiding a family member... since I assume the IT support burden would be lower.

185W is nothing? My Haswell desktop with dedicated GPU, ssd and two spinning hard drives maxes at 140W

Where are you getting that number ? Just going on M2 MB Air battery lifetime I'd say you're an order of magnitude off.

https://support.apple.com/en-us/HT201897

Mac mini (M1, 2020) Apple M1 chip, 16GB unified memory, 2TB SSD Power Consumption Idle Max 6.8 W 39 W

This is 16GB/2TB model, entry level spec should be even lower.

https://www.apple.com/mac-mini/specs/

That's sounds like the PSU spec. They could have clocked it significantly higher than laptop for perf but I expect it to be in the M1 Mac mini range power consumption wise.

Reply on news.ycombinator.com