Linked List: October 26, 2021

Tuesday, 26 October 2021

Putting M1 Max GPU Performance in Context ★

Andy Somerfield, lead for (the great) Affinity Photo app:

In Photo, an ideal GPU would do three different things well: 1.) High compute performance 2.) Fast on-chip bandwidth 3.) Fast transfer on and off the GPU.

Way back in 2009, no GPU did all three things well - but we thought that eventually the industry would get there, so we took a risk and designed the entire architecture based on that assumption. Things didn’t go entirely to plan.

We shipped Photo in 2015 - six years after the design phase - without GPU compute support :(

A GPU which did all the things we needed simply didn’t exist. We wondered if we had backed the wrong horse. Happily, a short while later it did exist - but it was in an iPad 😬!

Fast-forward a few tweets in the thread to today:

The #M1Max is the fastest GPU we have ever measured in the @affinitybyserif Photo benchmark. It outperforms the W6900X — a $6000, 300W desktop part — because it has immense compute performance, immense on-chip bandwidth and immediate transfer of data on and off the GPU (UMA).

A laptop GPU outperforming a $6,000 300-watt (300 watts!) desktop GPU. Bananas. But here I am, typing this sentence on that laptop.

The entire Apple silicon story — along with the Affinity Photo team’s prescient bet — feels like a perfect illustration of the Bill Gates axiom: “We always overestimate the change that will occur in the next two years and underestimate the change that will occur in the next ten. Don’t let yourself be lulled into inaction.”

The Information: ‘Apple Very Likely to Face DOJ Antitrust Suit’ ★

More antitrust news, from Josh Sisco, reporting for The Information (alas, paywall-protected):

And Apple’s opponents have raised other issues including the company’s “Sign in with Apple” offering, a button placed on apps and websites that allows people to sign in using their Apple username and password. The Information first reported the DOJ’s interest in the sign-in button earlier this year.

I strongly suspect that it’s not “Sign In With Apple” itself, but the corresponding App Store rule that requires any app that offers the ability to sign in with a third-party service (which, in practice, primarily targets Google and Facebook, and to a lesser degree Twitter) to also support “Sign In With Apple”.

The probe also is examining complaints about how Apple places restrictions on location tracking that its own apps don’t have to follow, said several people with knowledge of the matter.

They say that, but I get prompted to re-confirm allowing Apple’s iOS Weather to always access my location frequently. I wish I could make it ask me less frequently. The complaints aren’t really about Apple’s apps having access to your location but the system itself having access.

Of particular concern to app developers is Apple’s App Tracking Transparency, which requires iPhone and iPad users to affirmatively opt in to let developers share personal information, such as a device’s location, with other apps and advertisers. Apple isn’t requesting such permission to track users of its own apps, giving it an unfair advantage in serving ads in the App Store and elsewhere, developers argue. Apple has said that unlike Facebook, it doesn’t share user data with others for advertising purposes, and that the changes are designed to protect customers’ privacy.

Apple should just abandon selling ads in the App Store. I’m convinced the antitrust problems those ads are causing (not to mention loss of developer goodwill) are not worth the money they generate.

Details From the Newly Unredacted Antitrust Complaint Against Google ★

This Twitter thread from @fasterthanlime has a bunch of scathing highlights from the full 173-page PDF of the filing.

A few nuggets. Re: false claims about AMP performance (p. 90):

After crippling AMP’s compatibility with header bidding, Google went to market falsely telling publishers that adopting AMP would enhance page load times. But Google employees knew that AMP only improves the “median of performance” and AMP pages can actually load slower than other publisher speed optimization techniques. In other words, the ostensible benefits of faster load times for a Google-cached AMP version of a webpage were not true for publishers that designed their web pages for speed. Some publishers did not adopt AMP because they knew their pages actually loaded faster than AMP pages.

The speed benefits Google marketed were also at least partly a result of Google’s throttling. Google throttles the load time of non-AMP ads by giving them artificial one-second delays in order to give Google AMP a “nice comparative boost.” Throttling non-AMP ads slows down header bidding, which Google then uses to denigrate header bidding for being too slow. “Header Bidding can often increase latency of web pages and create security flaws when executed incorrectly,” Google falsely claimed. Internally, Google employees grappled with “how to [publicly] justify [Google] making something slower.”

You can’t justify it.

On using Chrome, the browser, as a workaround for tracking users across the entire web, by conflating logging into Chrome with logging into Google’s own web properties (p. 95):

To get publishers to give Google exclusive access over their ad inventory, Google set publishers up for a lose/lose scenario. First, Google started to leverage its ownership of the largest web browser, Chrome, to track and target publishers’ audiences in order to sell Google’s advertising inventory. To make this happen, Google first introduced the ability for users to log into the Chrome browser. Then, Google began to steer users into doing this by using deceptive and coercive tactics. For example, Google started to automatically log users into Chrome if they logged into any Google service (e.g., Gmail or YouTube). In this way, Google took the users that choose not to log into Chrome and logged them in anyways. If a user tried to log out of Chrome in response, Google punished them by kicking them out of a Google product they were in the process of using (e.g., Gmail or YouTube). On top this, through another deceptive pattern, Google got these users to give the Chrome browser permission to track them across the open web and on independent publisher sites like The Dallas Morning News. These users also had to give Google permission to use this new Chrome tracking data to sell Google’s own ad space, permitting Google to use Chrome to circumvent reliance on cookie-tracking technology. The effect of this practice is to rob publishers of the exclusive use of their audience data (e.g., data on what users read on The Dallas Morning News), thereby depreciating the value of publishers’ ad space and benefitting ad sales on Google’s properties (e.g., YouTube).

My post earlier today about Photoshop for the web going into public beta exemplifies the aspects of Google’s expansive vision for Chrome’s technical capabilities that make many web developers love Chrome and dislike Safari.

The details in this antitrust filing exemplify everything that is wrong — deeply contrary to the intended open nature of the web — about Google controlling the most popular web browser in the world.

See also: This lengthy thread from Financial Times reporter Patrick McGee. E.g., one of Google’s own employees compared Google owning the dominant ad bidding exchange as akin to “if Goldman or Citibank owned the NYSE”.

Photoshop for the Web Public Beta ★

Thomas Nattestad (Google) and Nabeel Al-Shamma (Adobe), writing for the Chrome Web.dev site:

Over the last three years, Chrome has been working to empower web applications that want to push the boundaries of what’s possible in the browser. One such web application has been Photoshop. The idea of running software as complex as Photoshop directly in the browser would have been hard to imagine just a few years ago. However, by using various new standardized web technologies, Adobe has now brought a public beta of Photoshop to the web.

Unsurprisingly, supported only in Chrome and Microsoft Edge, but an impressive demonstration of just how rich a platform Chrome is for something like this.

A Prototype Original iPod ★

Cabel Sasser, celebrating the 20th anniversary of the first iPod:

Now, there are a lot of mysteries in the Panic Archives (it’s a closet) but by far one of the most mysterious is what you’re seeing for the first time today: an original early iPod prototype.

We don’t know much about where it came from. But we’ve been waiting 20 years to share it with you.

It doesn’t look anything like an actual iPod, but that’s how prototypes work. But the date on this unit was remarkably late in development:

Clearly, this revision of the prototype was very close to the internals of the finished iPod. In fact, the date there — September 3rd, 2001 — tells us this one was made barely two months before it was introduced.

I’ve long wondered whether Apple might have intended to introduce the iPod a few weeks earlier than they actually did, but, well, September 11 happened. I remember that original iPod introduction as much for the iPod itself as for it feeling like a welcome early step in the world returning to normalcy.

Tony Fadell:

This is a P68/Dulcimer iPod prototype we (very quickly) made before the true form factor design was ready. Didn’t want it look like an iPod for confidentiality - the buttons placement, the size - it was mostly air inside - and the wheel worked (poorly).

John Whitley:

@panic @cabel HA! GOT YOU! I have seen exactly that before. I was one of the PortalPlayer firmware devs who went onsite @ the Apple skunkworks site during iPod main development, and again to make sure the GM release shipped on time.