Hacker News Reader

Comment by dev_tty01 | Hacker News Reader

Click bait. It is not a "design limitation," it is a different design choice. Of course highly performant code needs to be aware of the selected architecture. Nothing to see here.

View on HN

Ok, I've replaced that interpretation with the underlying factual description (32MB TLB) and left the OP's word 'bottleneck' in there.

Perhaps there's an interesting discussion to be had about it?

Thank you. Fair enough, there may be an interesting discussion lurking here somewhere about GPU architectures and rendering modes. However, Apple has been using this approach since the A11, so it is not new information. The OP assertion that Apple helped the WOW devs is probably also specious, since the app may have already been optimized (or close to it) for the architecture if they had been following Apple's GPU/Metal programming advice for the last few years. Caches always have limits and abusing those limits often has punitive results.

Those are synonymous terms with different spins. The bottleneck in getting software to run fast on GPUs is usually the performance engineering on the code and additional hoops and pitfalls of the platform substract from the real world performance users in practice will see. Yes, of course you can always say it's not "highly performant code" then... but it's more important to run apps well than benchmarks.

right, I'm sure that people who write low-level libs will be thrilled to optimize them for 0.1% of the iGPU market

If you’re writing a low-level library, don’t you want it to target specific architectures? Wouldn’t you want the abstraction happening higher up?

Curious, where does the 0.1% come from? Apple Mac US market share is over 14% and iPhone market share is over 50%. I get that you are just being a bit hyperbolic, but if a low-level lib ignores the Apple Silicon GPU hardware they are ignoring a sizable market segment.

https://www.statista.com/statistics/576473/united-states-qua...

https://www.counterpointresearch.com/us-market-smartphone-sh...

I know this is pretty common in hn, but you need to remember that the US is just one country, and not even the most populous country, in this world.

0.1% isn't close to the truth worldwide either, so it's inaccurate regardless.

It's probably pretty close to the overall percentage of M1 Ultra owners, all things considered.

The question is what is the percentage of potential market for a specific product. If you are optimizing GPU code, that is a very different market from “all computers” or “all phones”. If the market depends on high performance GPUs, then the Ultra has potential to be a noticeable percentage of that market.

Well up until the M1 Ultra, almost no one was doing GPU intensive stuff on mac, since they didn't have a line with a decent gpu. As such, Apple is creating an issue for developers that only manifests on the $6000 version of their machine that requires rewriting your whole algorithm to work around.

Exactly. On top of that, Apple is still in the minority and refuses to support the Vulkan API they helped design. So, from a development standpoint, rewriting your software to support ~15% of your potential market isn't a very lucrative idea. Especially when the vast majority of those users will be running relatively incapable hardware, at least on the GPU side of things.

Well, this is already an improvement, the way the parent stated it: from "no Mac line with a decent gpu" to "only the $6000 version".

Well, over next releases, lesser Mac models will upgrade to something like M1 Ultra specs, as it happens, so that 0.1% is not exactly static.

Yes, I agree. That's why I pointed out that it was specifically US market share. I just found those quickly. The percentages are lower in other regions, but the total numbers are still huge.

Sure but what if the US Engineering population represents a large portion of your paid-user demographics. For a lot of HN's startups this is very much the case.

That's not very relevant for the purpose of this discussion though. For example, a common stat floating around is how iPhone has 20% market share around the world but provides 80% of in-app revenue, which is what businesses care about.

Based on the twitter thread this bottleneck only seems to apply to the M1 Ultra that is currently only in the $2k+ Mac Studio and no other Macs or phones so 0.1% doesn't sound too far off.

Nope. The same issues can be observed across all Apple Silicon GPUs but are most noticeable in M1s. Apple is currently the 3rd largest global PC vendor, if you add iPads they’ve been the 1st for quite some time. With wallet-share/spending power the target market is even larger. The question is whether developers should adopt Apple’s Accelerate/Metal APIs & optimise code for TBDR. It’s an obvious ‘yes’.

That's just your opinion. This leaves a ton of performance on the table and saves Apple basically nothing in cost. Many of us would call that a design limitation, even a design flaw.

Where do you find that information? I couldn't find anything on apple.com where they detailed the various design tradeoffs they made working on their GPU

Reply on news.ycombinator.com