I told the customer that using a caching layer such as a CDN would help paper over the worst of the inefficiencies in their application and the network stack.
That was true! The download times halved.
However, benchmarks with F12 developer tools showed that while downloads reduced from 200ms to 100ms, the overall load times were still seconds, of which about 50% was actual CPU time.
(This is typical of large, complex sites built by non-experts or organisations where performance is not a primary concern.)
Web sites like these perform very noticeably better if you have more CPU cores or faster CPU cores.
Essentially, CDNs are easy to deploy and 5G provides nearly gigabit download speeds, so the bottleneck has shifted back to the CPU for a lot of the web.
I guess your point is that sloppy web developers / web companies make poorly performing code and shift the burden of handling it out to visitors’ machines, so those machines have to keep improving to not be left behind?
That might be true, but is pretty depressing.
Faster computers enable easier programming strategies, which improve net productivity. People are expensive, so giving them better "power tools" improves efficiency.
We don't complain that coal miners just need to shovel more efficiently. We give them enormous trucks and hydraulic mining shovels.
I think the cynicism here is that if only these frontend developers would just learn to optimize we would all finally be better off. I think there are two factors that push against this though. First, if you learn to optimize then you can charge more for your labor, and you will likely get a job somewhere else. Second, companies exist for profit, and optimizing is not often the most profitable next step.
That's true and reasonable. And after this 5nm node, TSMC has 3nm and IIRC 2nm. We are at the point where throwing more hardware at slow software is becoming a non solution.
The good news is that in many cases there is a LOT of performance on the table on the software side.
That's not to say that there isn't an enormous amount of improvement available in software. Projects like simdjson prove that there's a 2x or more improvement available for many high-performance use cases by migrating to vector instructions.
I'm currently agonizing over an application that has an 80-120ms response time for 5 hops (including db writes). Yet I know many people who code in my language would find that number amazing for the work being done in those hops.
No SIMD. Nothing too crazy. Just well thought out processing flow and proper separation of the stupid.
The thing is - most web software isn't comparison shopped. It's developed on contract. I work at a company that does a lot of this, and, hypothetically, maybe we'd get hired to do an internal app for some retailer (imagine Best Buy or Walmart). When you build something like that, there's a gun to your head about time-to-deliver. They don't care if it's good — it's just got to meet a "reasonably decent" metric of quality. The only thing they really care about is getting it released on a certain timetable.
And all of this is because of contract law - timetables are provable breach-of-contract. You promised you'd make something by February, but you weren't done until April - that's something that's a provable failure-to-deliver. That's got financial penalties. But quality? Quality's gotta be astoundingly bad to be "provable". "Lag" or "the site's kinda slow" doesn't hold up in a lawsuit. (These things rarely lead to lawsuits, but do lead to 'punishment' by a refusal to renew a contract, knowing that the contractor can't sue the company because the contractor provably failed to deliver what was agreed on.) So they optimize for what's punishable according to the terms of the contract.
That's why all of this corporate enterprise software sucks - because nobody gets punished if it's slow or crappy; they just get punished if it's late, or if it's provably broken, because that's the stuff that's easy to pull out of a contract for.
And it's true that the people paying for it could go elsewhere, but page performance probably weighs pretty low on that list.
- Less heat produced > allows for smaller heatsinks and, as a result, smaller devices or bigger components
- Performance bottlenecks become less likely
- Features like 120hz display refresh rate become possible without the user noticing degradation
- Faster OS boot and app starts
- Ability to do more work locally vs using a server (see the many ML features)
- Tech debt in system code is less of an issue - code can be shipped early and optimized later
You may well be benefitting from running a task longer, at a slower speed, and using less transistors.
I don’t think that’s all that Apple specific as there are increased ISPs and security chips on other phones as well.
Getting iSH on the App Store did take some work on our side; we were in contact with Apple to get it approved and in compliance with the guidelines. You may have seen that the version of iSH on the App Store had package management functionality removed. So far we've been able to keep the ability to run Linux programs, as well as import files, unchanged.
One interesting thing to see from Apple is that they are not just increasing the performance of their chips, but they are investing heavily in making certain operations faster. For example, in the time since tbodt started working iSH Apple has reduced the cost of uncontended atomics to almost zero overhead (this is especially good for Apple because it immediately makes reference counting code faster, which both Swift and Objective-C spend a lot of time in). iSH doesn't currently do anything fancy there, it just uses full locks everywhere, so this is something that we would be interested in pursuing at some point.
Also, one can play games on an iPad, and games will soak up arbitrary amounts of CPU and GPU power.
There's a lot of corner cases there where certain consumers value it a lot.
Also performance per watt is a huge deal. The expanded power envelope that improved PPW brings allows 120hz displays which are battery hogs.
I'm already missing the glorious few months that PUBG could be played on Mac via Stadia.
Changing the chip isn't going to change the code base of the operating system.
So Genshin Impact can look and run beautifully XD
RAW processing is actually a really interesting application, and rendering time depends heavily on what you do with the bits from the sensor.
If you use non-linear interpolation, 2-50x the time to build.
If you do highlight recovery, 2-5x the time to build.
If you only need half the native resolution, build time may be reduced 2-4x.
Basically "viewing a RAW image" can take 100 milliseconds or 15 seconds (on the same hardware!), depending on how you're interpreting the sensor data.
(Source: playing with dcraw and libraw to rasterize raw images for PhotoStructure)
I would also use my iPad as a synthesiser (eg. Magellan) but then record the audio to a "real" computer, ie the Mac, via a recording interface.