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

Apple’s new M1 Pro and M1 Max processors

apple.com

Post reply on HN
Print view View original

921–930 of 1001 posts

Re: Apple’s new M1 Pro and M1 Max processors

#921

Post by DiabloD3 »

rpmisms wrote: post #346
DiabloD3 wrote: post #17

Since these won't ship in non-Apple products, I don't see really the point. They're only slightly ahead of AMD products when it comes to performance/watt, slightly behind performance/dollar (in an Apples to apples comparison on similarly configured laptops), and that's only because Apple is head of AMD at TSMC for new nodes, not because Apple has any inherent advantage. I have huge respect for the PA Semi team, but t…

This is a poorly considered take, no offense to you. I think you're failing to consider that Apple traditionally drives innovation in the computing market, and this will push a lot of other manufacturers to compete with them. AMD is already on the warpath, and Intel just got a massive kick in the pants. There's other arguments against Apple being as big as it, but this isn't a good one. Tesla being huge and powerful…

A lot of Apple fans keep saying Apple drives innovation, but I'd love to see where this has actually been true. Every example I've ever been given has a counter-example where someone else did it first and Apple did not do it in a way that conferred a market advantage; the only thing Apple has proven they're consistently better at is having a PR team that is also a cult.

Re: Apple’s new M1 Pro and M1 Max processors

#922

Post by Zenst »

yellowapple wrote: post #469

If Apple ever gets around to putting an M1 Max in a Mac Mini, that'd probably push me over the edge toward buying one.

Many will as that kinda processing power and more so memory interface speed - it will seriously blur a lot of lines.

More so, it has really got the processing leaps and jumps back into life again and not really seen much of that for well over a decade now.

Re: Apple’s new M1 Pro and M1 Max processors

#923

Post by lostmsu »

Napkin math based on Ethereum mining, which on original 8 GPU core M1 was about 2MH/s, puts M1 Max GPU performance (8MH/s with 32 cores) to be only 1/4 of mobile 3060, which does over 34MH/s.

So I am extremely skeptical about Apple claims on "comparable" GPU performance to RTX 30xx mobile series. And again, that RTX is still using 7nm.

Re: Apple’s new M1 Pro and M1 Max processors

#924

Post by DiabloD3 »

pjmlp wrote: post #79
DiabloD3 wrote: post #17

Since these won't ship in non-Apple products, I don't see really the point. They're only slightly ahead of AMD products when it comes to performance/watt, slightly behind performance/dollar (in an Apples to apples comparison on similarly configured laptops), and that's only because Apple is head of AMD at TSMC for new nodes, not because Apple has any inherent advantage. I have huge respect for the PA Semi team, but t…

Our local office only uses macOS and Windows for desktop computers, GNU/Linux nowadays only for servers in some Amazon and Azure cloud instances. Apple will have plenty of customers.

OSX is less than 1/7th of the desktop OS market, and iOS is slightly over 1/4th of the phone market; the major cloud companies are the largest consumers of desktop and server scale CPUs, and buy mostly AMD with some Intel only when cluster compatibility requirements apply; when it is non-x86, it is a mix of things that do not include any Apple ARM offerings but do include larger scale higher performance ARM CPUs and some POWER as well.

The most used architectures of any kind (including embedded, industrial, and automotive) are MIPS, then ARM, then POWER/PowerPC, then x86. Apple is a tiny player in the overall ARM market, and by hyper-focusing on desktop and phone alone, they are giving up important opportunities to diversify their business.

At no point does "Apple will have plenty of customers" make sense in a context where Apple is a $2.45T company: either they have a large majority of possible customers in multiple industries at multiple levels, or reality is going to come crashing in and drive them back down to sub-$T levels. You cannot convince a company that only has a net income of $22B a year is worth that much, no matter how much "goodwill" and "brand recognition" and other nonsense intangibles they have. Steve Jobs died exactly ten years ago on Oct 5th, and the RDF died with him.

Re: Apple’s new M1 Pro and M1 Max processors

#925

Post by derefr »

Vomzor wrote: post #601
derefr wrote: post #432

Earlier quoted context omitted.

> but the new MBP still has less total memory From the perspective of your GPU, that 64GB of main memory attached to your CPU is almost as slow to fetch from as if it were memory on a separate NUMA node, or even pages swapped to an NVMe disk. It may as well not be considered "memory" at all. It's effectively a secondary storage tier. Which means that you can't really do "GPU things" (e.g. working with hugely detailed…

That's not how M1's unified memory works. >The SoC has access to 16GB of unified memory. This uses 4266 MT/s LPDDR4X SDRAM (synchronous DRAM) and is mounted with the SoC using a system-in-package (SiP) design. A SoC is built from a single semiconductor die whereas a SiP connects two or more semiconductor dies. SDRAM operations are synchronised to the SoC processing clock speed. Apple describes the SDRAM as a single p…

I know; I was talking about the computer the person I was replying to already owns.

The GP said that they already essentially have 64GB+8GB of memory in their Intel MBP; but they don't, because it's not unified, and so the GPU can't access the 64GB. So they can only load 8GB-wide models.

Whereas with the M1 Pro/Max the GPU can access the 64GB, and so can load 64GB-wide models.

Re: Apple’s new M1 Pro and M1 Max processors

#926

Post by dcchambers »

JustFinishedBSG wrote: post #857
cbarrick wrote: post #745

Earlier quoted context omitted.

Last I heard, there were graphics driver issues left to iron out. Linux 5.13 was the first with M1 support. Dunno if that's enough for M1 Pro/Max.

> Last I heard, there were graphics driver issues left to iron out. Who cares in a server ?

I assume because so far the only devices released with M1 processors have been consumer devices with attached screens, the focus has been on bringing over the full graphical, desktop Linux experience to it, not just headless server linux.

Re: Apple’s new M1 Pro and M1 Max processors

#927

Post by willseth »

rgrs wrote: post #758
willseth wrote: post #669

Earlier quoted context omitted.

Video playback is accelerated by essentially custom ASIC processing built into the CPU, so it's one of the most efficient things you can do now. Most development workloads are far more compute intensive.

Might be less computationally expensive. But video playback constantly refreshes screen which uses up battery

This is true, but it's not worst case by far. Most video is 24 or 30 fps, so about half the typical 60 hz refresh rate. Still a nice optimization path for video. I'm not sure what effect typing in an editor will have on screen refresh, but if the Electron issue is any indication, it's probably complicated.

Re: Apple’s new M1 Pro and M1 Max processors

#928

Post by Grustaf »

ChuckNorris89 wrote: post #243
Grustaf wrote: post #176

Earlier quoted context omitted.

This only makes sense if you presume people throw away their laptops when they replace them after "a few years". Given the incredibly high second hand value of macbooks, I think most people sell them or hand them down.

You're talking about selling working devices but parent was also talking about repairing them. Seems like a huge waste to throw away a $2000+ machine when it's out of warranty because some $5 part on it dies and Apple not only doesn't provide a spare but actively fights anyone trying to repare them, while the options they realistically will give you out of warranty being having your motherboard replaced for some insa…

> actively fights anyone trying to repare them

What makes you say that? What did you expect would happen if you spill juice into your laptop?

What they are perhaps fighting is unauthorized repairs, in the sense that they want to be able to void the warranty if some random third party messes with the insides. That's not quite the same thing.

Apple has been very helpful when I brought in a 5 year old macbook pro with keyboard issues, replaced some keys for free on the spot. Also when the batteries of 8 and 9 year old MBAs started to go bad, they said they could replace them but advised me to order batteries from iFixit and do it myself, which I did.

Re: Apple’s new M1 Pro and M1 Max processors

#929

Post by thomastjeffery »

smoldesu wrote: post #612
modulusshift wrote: post #584

Earlier quoted context omitted.

Yeah, and they also deprecated OpenGL, which would have wiped out most of those games even if the 32-bit support didn't. I'm not expecting to see much backwards compatibility, I'm expecting forwards compatibility, and we're starting to see new titles come out with native Apple Silicon support, slowly, but surely.

I wouldn't hold your breath. Metal is still a second-class citizen in the GPU world, and there's not much Apple can do to change that. Having powerful hardware alone isn't enough to justify porting software, otherwise I'd be playing Star Citizen on a decommissioned POWER9 mainframe right now.

Metal is 4th class:

1. Vulkan 2. DirectX 3. OpenGL 4. Metal

IIRC, there are some efforts to translate Vulkan to Metal similar to how the WINE project translates DirectX into OpenGL/Vulkan, but that's still an imperfect workaround.

Re: Apple’s new M1 Pro and M1 Max processors

#930

Post by dragontamer »

rocqua wrote: post #829
dragontamer wrote: post #465

Earlier quoted context omitted.

How do you prefetch "node->next" where "node" is in a linked list? Answer: you literally can't. And that's why this kind of coding style will forever be latency bound. EDIT: Prefetching works when the address can be predicted ahead of time. For example, when your CPU-core is reading "array", then "array+8", then "array+16", you can be pretty damn sure the next thing it wants to read is "array+24", so you prefetch tha…

You prefetch by having node->next as close as possible to node. You do that by using an allocator that tries very hard to ensure this. Doesn't work that well for GC but for specific workloads it can work very nicely.

Yeah, that's a fine point.

I always like pointing out Knuth's dancing links algorithm for Exact-covering problems. All "links" in that algorithm are of the form "1 -> 2 -> 3 -> 4 -> 5" at algorithm start.

Then, as the algorithm "guesses" particular coverings, it turns into "1->3->4->5", or "1->4", that is, always monotonically increasing.

As such, no dynamic memory is needed ever. The linked-list is "statically" allocated at the start of the program, and always traversed in memory order.

Indeed, Knuth designed the scheme as "imagine doing malloc/free" to remove each link, but then later, "free/malloc" to undo the previous steps (because in Exact-covering backtracking, you'll try something, realize its a dead end, and need to backtrack). Instead of a malloc followed up by a later free, you "just" drop the node out of the linked list, and later reinsert it. So the malloc/free is completely redundant.

In particular: a given "guess" into an exact-covering problem can only "undo" its backtracking to the full problem scope. From there, each "guess" only removes possibilities. So you use the "maximum" amount of memory at program start, you "free" (but not really) nodes each time you try a guess, and then you "reinsert" those nodes to backtrack to the original scope of the problem.

Finally, when you realize that, you might as well put them all into order for not only simplicity, but also for speed on modern computers (prefetching and all that jazz).

Its a very specific situation but... it does happen sometimes.

Post reply on HN