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

Rendering on the Apple M1 Max Chip

blog.yiningkarlli.com

Post reply on HN
Print view View original

21–30 of 328 posts

Re: Rendering on the Apple M1 Max Chip

#21

Post by mhh__ »

throwawaylinux wrote: post #4
dnautics wrote: post #2

> There’s really no way to understate what a colossal achievement Apple’s M1 processor is; compared with almost every modern x86-64 processor in its class On the other hand I'm sure there's more than a few chipheads out there who are saying "it's about time", there was a longstanding prediction that the arm architecture would overtake x86.

I thought the observation was always that instruction set was not such a big difference in high performance CPUs next to manufacturing technology which was by far the first order effect. It would be expected for a high performance ARM CPU to reach roughly the same performance in that case (AMD is 1 generation behind here, I think Intel is 2). Is there really "chipheads" who are predicting ARM ISA to buck this trend a…

Two thoughts:

1. The instruction set isn't so much a performance thing as much as a thing that bites you with power usage (you need to have a big fat decoder on all the time in the worst case). The widest X86's can only dispatch 75% of the instruction per cycle but X86 instructions can do more, so you'd have to check a specific benchmark.

2. I want X86 to die more because it's fucking ugly than performance as per se. ARM is not a simple ISA, so although you won't be writing a disassembler in 10 minutes like RISC-V, aarch64 is still much less insane than X86 with all the extensions.

Re: Rendering on the Apple M1 Max Chip

#22

Post by nyanpasu64 »

pier25 wrote: post #7

Some of these images look incredibly real. Even knowing those are renders my brain refuses to believe these are not actual photographs. Also, these Xeons are really put to shame here.

When I viewed Figure 5 [link] at full resolution, the pine tree bark felt to me like a poorly-done bump-mapping tech demo. I think it lacks sharp contrast between the raised and recessed regions (instead having a gradient), and I think the outline/silhouette of the branches are perfectly smooth and unaffected by the bark, and too uniform and slender to look like real trees.

[link]: https://blog.yiningkarlli.com/content/images/2021/Oct/takua-...

Re: Rendering on the Apple M1 Max Chip

#23

Post by DeRock »

soylentnewsorg wrote: post #17
MangoCoffee wrote: post #9

>in order to give the M1 Max some real competition, one has to skip laptop chips entirely and reach for not just high end desktop chips, but for server-class workstation hardware to really beat the M1 Max this is really interesting

and quite false. there are many laptop xeon CPUs. while costing more than the M1 Max, they beat the pants off it.

Can you share a laptop with one of them for comparison?

Re: Rendering on the Apple M1 Max Chip

#24

Post by defaultname »

soylentnewsorg wrote: post #17
MangoCoffee wrote: post #9

>in order to give the M1 Max some real competition, one has to skip laptop chips entirely and reach for not just high end desktop chips, but for server-class workstation hardware to really beat the M1 Max this is really interesting

and quite false. there are many laptop xeon CPUs. while costing more than the M1 Max, they beat the pants off it.

Can you name those laptop Xeon CPUs that beat the pants off the M1 Max?

[Spoiler because I don't think I'll get a response -- there are none. Even when you get into the "luggable" category of workstation that is ostensibly portable but really needs to be plugged in, there is no competition right now. The upcoming Alder Lake should significantly improve Intel's entrant in this category, and hopefully brings some real competition]

Re: Rendering on the Apple M1 Max Chip

#25

Post by mhh__ »

AnthonyMouse wrote: post #5
dnautics wrote: post #2

> There’s really no way to understate what a colossal achievement Apple’s M1 processor is; compared with almost every modern x86-64 processor in its class On the other hand I'm sure there's more than a few chipheads out there who are saying "it's about time", there was a longstanding prediction that the arm architecture would overtake x86.

> there was a longstanding prediction that the arm architecture would overtake x86. So now the wheel turns and someone will have to predict how long it takes before RISC-V overtakes ARM.

I'm not totally convinced that'll happen in the desktop space. Embedded, I completely buy it, but I have read fairly convincing arguments that ARM might be a better ISA for really high-performance architectures. RISC-V also seems to value compressed instructions far too much, so we could see a high-performance fork of RISC-V?

Re: Rendering on the Apple M1 Max Chip

#26

Post by mhh__ »

throwawaylinux wrote: post #16
entee wrote: post #12

Earlier quoted context omitted.

Not a chiphead, but saw this in the article that might be a reason ARM is better for this kind of thing: "The theory goes that arm64’s fixed instruction length and relatively simple instructions make implementing extremely wide decoding and execution far more practical for Apple, compared with what Intel and AMD have to do in order to decode x86-64’s variable length, often complex compound instructions." Not sure it'…

The fixed width decoders have always been a commonly cited advantage of fixed width, and to some degree it must be true. But this is not a recent thing, the "common wisdom" about instruction format not mattering too much still very much applies here. Pre-decode lengths or stop-bits and more recently micro-op caches have been techniques that x86 has used to mitigate this and improve front end widths, for example. Peop…

> X86 tax might be 5%

A consistent 5% win is pretty huge for certain industries.

Re: Rendering on the Apple M1 Max Chip

#27

Post by paulmd »

soylentnewsorg wrote: post #17
MangoCoffee wrote: post #9

>in order to give the M1 Max some real competition, one has to skip laptop chips entirely and reach for not just high end desktop chips, but for server-class workstation hardware to really beat the M1 Max this is really interesting

and quite false. there are many laptop xeon CPUs. while costing more than the M1 Max, they beat the pants off it.

xeon branded workstation laptops aren't using Icelake-SP or similar server chips, they are using Tiger Lake-S or Ice Lake-S or Skylake-S client chips.

They are what would previously have been branded as "Xeon E3" series chips - on the desktop platform they used to share a socket and be drop-in upgrades with consumer desktop chips, because they're basically the same chips with "enterprise" features like ECC turned on.

An example would be Xeon E3-1285 v3 - which is basically the same thing as an i7 4770.

These products are nowhere, nowhere near the M1 Max. They are consumer laptop chips with ECC and vPro turned on.

Re: Rendering on the Apple M1 Max Chip

#28

Post by invalidname »

Thaxll wrote: post #19

I mean apple have it "easy", they control the hardware and the software, they don't need to to something that work with pci, old ram, thousands of different configs, different disk etc ... They can do whatever they want with 0 compatibility or backward compatibility. Why is the test not testing against some AMD CPU, CPU that cost $400, 5800x or 5900x for example.

Building from scratch isn't "easy". They still buy a lot of their components off the shelf so they do need to interact with vendors so they can benefit from the economies of scale on the PC side of things.

Yes, they can optimize a lot of pipelines but this goes both ways. E.g. they had lightning connector which was good. USB-C beat the pants out of it and now has a much better eco-system. Apple is stuck with their sub-par connector for phones and an unclear strategy (USB-C on macs/iPads but not on phones and low end iPads).

Re: Rendering on the Apple M1 Max Chip

#29

Post by parhamn »

I was randomly curious how long it would take to render a full movie at the quality of that forest image, which absolutely blew my mind.

At 24fps, a 2h movie has 172800 frames. 21,970,310 M1 seconds or 8.5 M1 months. Which is less than I was expecting. The rendering seems to scale linearly per core too.

Presumably bad math or a lot more rendering complexity for the pixar super computer deploys?

Re: Rendering on the Apple M1 Max Chip

#30

Post by paulmd »

throwawaylinux wrote: post #4
dnautics wrote: post #2

> There’s really no way to understate what a colossal achievement Apple’s M1 processor is; compared with almost every modern x86-64 processor in its class On the other hand I'm sure there's more than a few chipheads out there who are saying "it's about time", there was a longstanding prediction that the arm architecture would overtake x86.

I thought the observation was always that instruction set was not such a big difference in high performance CPUs next to manufacturing technology which was by far the first order effect. It would be expected for a high performance ARM CPU to reach roughly the same performance in that case (AMD is 1 generation behind here, I think Intel is 2). Is there really "chipheads" who are predicting ARM ISA to buck this trend a…

We'll get a live test of this very soon - Zen4 is going to be going head-to-head against Apple A16 (Apple's next core architecture) on TSMC N5P next year.

Does anyone expect x86 to close a factor-of-6 perf/watt difference? (from Anandtech's M1 Max preview) A factor-of-2-to-3 IPC difference? And that's just A15, not against the next-gen A16.

Node makes a big difference, it doesn't close up a factor-of-3 IPC gap in a single node though, that's facially ridiculous. Name a full-node shrink+architectural step that has tripled IPC in the last 10 years. Now name one that has done it while cutting power in 1/6th.

At that point we will see the goalposts shift again and it will be "well, x86 could do it if they wanted but Apple is just more willing to spend more transistors..."

Fact of the matter is the x86 makes it very difficult to spend those transistors efficiently - otherwise it already would have been done. If it was such an obvious gain to just spend those extra transistors, then surely AMD would have done it, if nobody else.

Everyone acknowledges x86 has some problems, but the other thing is that they've already mostly played their hand trying to fix those problems, the known solutions like instruction cache have mostly been exhausted at this point. The idea that AMD and Apple can just triple IPC at a whim but they've chosen not to do so for some reason, is facially ridiculous.

I know what Jim Keller said but the math just doesn't add up on it for me. OK, full node shrink, great, even if that doubles your transistor count at iso-power, or even doubles it at a little less power, that doesn't double your IPC let alone triple it, and it doesn't close a factor-of-6 perf/watt gap.

Post reply on HN