Hacker News Reader

Comment by JohnBooty | Hacker News Reader

Yeah. I'm worried that they may have played their trump cards already, so to speak.

I wonder if future perf gains will come, game console-style, from areas besides general purpose computation -- specialized instructions / cores for specialized tasks.

Imagine an entire core optimized for Safari and its Javascript engine. Their next chip is called the "M1 Marathon Edition" and you get 36 hours of real-world battery life with Safari. And/or the iWork suite. And maybe they have a behind the scenes collab with Slack and select other app makers so that they can be a part of the "Marathon" program too.

I dunno, just spitballing. Not saying that's likely or even what I'm pining for, just one possible avenue once they've plucked all the low-hanging general purpose computing fruit.

View on HN

The things that take up time and energy in browsers - i.e. things like garbage collection, JIT compilation, and so on - are already things that CPUs are hyper-specialized for. And the code that is ultimately intended to execute is also well-specialized for CPUs.

It's already possible to target GPUs in-browser directly; and most older HTML primitives were recast in terms of GPU operations around the time of the original iPhone. The only thing I can think of that's still been left on the table is rendering vector geometry on-GPU; but most sites don't redraw so much as to make this a huge performance win.

Video decode has been offloaded to hardware for decades as well. The only reason to decode video on-CPU is if you're decoding crazy-old formats[0] that don't have hardware decoder blocks present for them.

The other huge problem is networking - which is also heavily hardware-optimized and has been for a while. Large assets mean keeping your Wi-Fi or LTE baseband on for longer. You could mitigate this with compression; which can be hardware optimized... though I'm not sure how much of a benefit that provides outside of game consoles[1].

[0] In my personal experience: I wrote a Sorenson H.263 decoder for Ruffle. Right now it not only executes on-CPU, but blocks the event loop main thread. However, the video files in question are so low-quality that this isn't a significant problem for most Flash movies and everything works fine (though I do want to try on-GPU video decoding at some point).

[1] Current-gen game consoles (PS5/XSeries) have hardware decompression blocks. However, the intent is to quickly decompress gigabytes worth of data quickly; most websites aren't nearly that bloated.

This is a wonderful and informative reply. Thank you so much - i really appreciate the time you spent writing this.

Sounds like a nightmare to me. Want to change browsers? Buy a new device with a different processor or suffer massive battery or performance penalties. Want to change media players? Buy a new device with a different processor or suffer massive battery or performance penalties.

By that logic, any time anybody optimizes for anything, they're somehow punishing everybody else with "penalties."

What if somebody on the Intel/AMD side of things includes some optimizations for SSE, AVX, etc? Are they punishing everybody else?

At any rate, my idea was less than half baked and again, not exactly something I'm pining for. Was just thinking about things Apple might conceivably be able to try with their unique vertical integration.

SSE/AVX/etc aren't optimizations for a single application, they're optimizations for specific kinds of math instructions. Any application using that processor can use them, and they're overall pretty general instructions.

Hyper-optimizing for a particular application means the way that particular application works gets accelerated, but not things in general. Sure, if a browser behaved identically to Safari, it too would potentially experience the speed up barring any weird microcode/firmware that only allows those extensions to be used by Apple-signed binaries which is a whole 'nother level of nightmare. Stepping outside of that highly optimized path is essentially a penalty though as it by definition wouldn't be so highly optimized. And once that optimized path has been etched into the silicon, there's no real updating it unless we move to CPUs being more like FPGAs which isn't likely to happen.

When they make optimizations for something, and then _artificially limit_ access to those optimizations (for applications that absolutely could utilize them) for purely commercial or marketing reasons, then yes, absolutely they're punishing.

Intel doesn't forbid compilers from generating code for SSE or AVX.

Apple _does_ forbid Chrome from using energy management and other APIs for no other reason than to keep it less efficient than Safari.

I didn't realize Safari made such heavy use of private APIs.

That is unfair and I would not support that behavior whether talking about private software APIs or private hardware instructions. What I was half-assedly imagining wouldn't be anything like that.

(Although, FWIW, Chrome has private APIs too: https://blog.chromium.org/2021/01/limiting-private-api-avail... Different use case, but still.)

That's already the case, though. The battery life difference using Safari versus Firefox/Chrome is staggering. Sure, you don't have an option to buy a FF/Chrome mac atm, but you've definitely bought one where safari is the only decently efficient browser.

Is that really due to the hardware or because of the overall behavior of the two browsers? Isn't Safari better battery-wise than Chrome even on Intel Macs? IIRC Edge has better efficiency in Windows than Chrome, so its not surprising me Chrome is less efficient. Its a bloated shadow of its original self.

macOS has a bunch of energy management and performance-related "private" APIs and libraries that Safari is allowed to call, but Chrome is not.

Can you point me to information about this? The Google results are a bit polluted with (hilariously enough) articles about Google's recent restriction of Chrome's private APIs.

I've been having trouble figuring out exactly which private bits and bobs Webkit might be taking advantage of on MacOS.

That's the second time you have made that assertion in this discussion. Can you be more specific please? I have not seen any evidence of that, but I am very interested.

I would also like to see some documentation on these private apis. Sounds fascinating I wonder what they’re doing differently? Are they exposing the same kind of abstractions but the public api is purposely slower? Why would they not want all apps to use less battery life?

Yeah, that's my question.

Other commenters are suggesting that Apple's intent is to keep Chrome and other third-party apps from matching Safari's energy efficiency.

But as you say, I'm not sure that makes strategic sense. If that is true, Apple is essentially crippling most Mac use cases just to benefit Safari. That really would not seem to be in Apple's best interests.

I am a developer, but not a iOS/MacOS developer. So I have followed this sort of thing only very loosely over the years.

But whenever I have heard about grumblings about private Apple-only APIs being used by blessed first-party Apple apps on iOS, it seems to me that the explanation was always that the private APIs either:

1. posed some sort of security issue

2. were simply not yet stable enough to expose to third-party apps

As every developer knows, publicly exposing any API represents a maintenance burden: you're committing to support that API and keep it stable for X number of years. In general you see this kind of pattern a lot: a platform developer dogfoods APIs internally for some period of time before they're stable enough to expose publicly.

Most of the time the hardware accelerators are available for everyone to use, if they program to it. Ex ffmpeg and other media encoding engines all have the ability to write coders / decoders against certain hardware accelerators. You can choose CPU coders, Nvidia specific ones, etc.

Except that they locked access to the hardware accelerators via their APIs. The Neural Accelerator is only available through CoreML and even some of the benchmarks show features that are not available to the public (int8)

Sure, that's been the case in the past and maybe that's what JohnBooty meant with his comment, but his comment specifically pointed out a particular browser so I took it to mean CPU extensions targeted for how Safari operates. Like, specific ways Safari handles Javascript or rendering with all of its specific quirks etched into silicon. Other browser manufacturers would have to pretty much behave like Safari or else run as a penalty on legacy instruction sets.

That already happens though given that different hardware has different support for hardware accelerated playback of video.

E.g even on the M1 Pro/Max, you're going to get much better performance and battery if you're using a video editor that supports prores decoding.

I get that, but that's a bit more general than saying Safari will run faster than Chrome because Apple made Safari-specific application instructions rather than H.264 will be more power efficient than Theora on a given CPU. Any browser could support any particular hardware's video decoders, but only Safari behaves exactly like Safari. The person I was replying to was writing specifically about CPU instructions to enhance the performance of Safari in particular, not of all browsers in general.

> Imagine an entire core optimized for Safari and its Javascript engine. Their next chip is called the "M1 Marathon Edition" and you get 36 hours of real-world battery life with Safari.

I don't think that would be worth it. What's the point of 36 hours of battery life? How often do you need more than 12 hours of life on battery? Increasing the maximum battery life only makes sense when it also increases battery life for the more power-hungry workload (which is where you're likely to reach the limit), why bother building dedicated hardware for a specific workload that's already beyond what you need?

Many parts of the world don't have stable electricity, reducing electricity usage reduces costs and overall emissions in to the planet, and as you approach much longer periods you massively increase convenience.

Those parts of the world aren't generally spending multiple thousands of American dollars on a laptop.

You'd be surprised. Additionally, that also includes parts of the US as well.

I don’t think regions susceptible to black/brown outs and power outages are the intended market of an M1 Mac, though that could change.

Aren’t many companies normally located in the Silicon Valley now migrating to Texas, where the electricity infrastructure is wonky at best.

Texas is pretty average when it comes to electricity reliability in the US even though it experiences some of the most diverse weather in the US. Not too many states experience both tornadoes and hurricanes on a regular basis. Its biggest challenge it currently faces is winterization measures due to climate change. Things just weren't designed to get as cold as it did in February, which was a exceptionally rare event historically. I've lived in Texas nearly my whole life, it has never been that cold for that long since I've been here.

There's a gap between no stable electricity and 20+ hours without electricity, so what fraction of Apple customers do you expect to live in this tiny niche, like 0.1%? In such situation you'd use an external battery anyway…

> reducing electricity usage reduces costs and overall emissions in to the planet

You're going to need a looooooooooooooooong time for the electricity usage reduction to compensate for the enormous energy cost of manufacturing a new laptop. If you care about the climate, don't buy a new laptop if your previous one is still running fine, there's just no way energy efficiency is going to be worth it.

> I'm worried that they may have played their trump cards already, so to speak.

I'm not. Let them all scramble and pull out the big guns to try to compete. That's capitalism at it's finest, which isn't exactly what we've been seeing in the CPU space for the prior decades. We got lucky that AMD caught Intel with their pants down recently (if only because it strengthens AMD and makes them a better competitor), but a duopoly isn't necessarily what I would consider a good market condition for progress (as we've seen with iOS vs Android). Lots of different experiments with feedback from people on what they find good would be much preferable, and while a constrained CPU such as Apple's isn't perfect, it does represent more choice and pressure on other players to evolve in ways they may have been resistant to previously.

> And maybe they have a behind the scenes collab with Slack and select other app makers so that they can be a part of the "Marathon" program too.

RIP the general purpose computer. :(

    > And maybe they have a behind the scenes collab with 
    > Slack and select other app makers so that they can 
    > be a part of the "Marathon" program too.

    RIP the general purpose computer. :(

Haha. I was truly truly not thinking along any such lines.

Since heterogenuous cores are now a mainstream thing, with a mixture of full-throttle and performance-minded cores on a single die, and the performance cores may be hitting a wall until we get to smaller processes, perhaps the next frontier could be efficiency.

Remember how some software proudly displayed those "optimized for MMX" or "optimized for 3DNow!" badges back in the day? What if there was something like that for apps that optimized for those efficiency cores, and what if the efficiency cores met them halfway by implementing some app-friendly stuff in hardware? Sort of like how some common Javascript string ops have dedicated CPU hardware dedicated to them now.

Anyway, yeah. I'm probably just re-inventing CISC all over again, badly.

Reply on news.ycombinator.com