Share this page!

Alex Russell Profile picture
Twitter logo
1 Dec, 9 tweets, 4 min read
Not mad that the coverage of the Qualcomm event lets them totally off the hook for failing to deliver competitive performance at inflated prices, just disappointed.

@verge here with big "our-ai-rewrote-this-press-release-in-the-house-style" energy:

theverge.com/2021/11/30/228…
@anandtech does a bit better by focusing on the details, but fails to mention that "20% faster performance" (QC's claim) would *still* put it behind both the A15 *AND* the A14 on single and multi-core workloads:

anandtech.com/show/17091/qua…
@anandtech How is the tech press so bad at this?

It's, like, the thing you'd expect them to eat up, even if you think tech coverage is generally terrible: breathless reporting on a predictable horse-race w/ easily-quantifiable winners/losers.

Compare this w/ AMD vs. Intel coverage!
The numbers aren't hard to find!

Here's 3 minutes of searching you could screenshot, multiply the 888 numbers by 1.2, and then write hilarious, cutting, sad-trombone headlines all day long:

browser.geekbench.com/android_device…

browser.geekbench.com/ios_devices/ip…

browser.geekbench.com/ios_devices/ip…
For folks who aren't into link clicking, these are Geekbench 5 scores across the Samsung S21+ (QC SD 888):

- single-core: 965
- multi-core: 3045

iPhone 13 (A15):

- single: 1640
- multi: 4409

iPhone 12 (A14):

- single: 1570
- multi: 3836
Which, if Qualcomm is to be believed, will put the Snapdragon 8 Gen 1 (S8G1?) at roughly:

- single: ~1150
- multi: ~3650

...which means the just announced Santa Monica chips will arrive in 2022 with performance that doesn't match Cupertino's parts from *2020*
Now, maybe this is unfair! Perhaps Qualcomm is comparing the 20% uplift to the Snapdragon 888+, announced to similarly fawning, context free coverage:

theverge.com/2021/6/28/2255…
The Moto G200 5G shipped with this part, so let's cut to the scores:

browser.geekbench.com/v5/cpu/11082269

- single: 1039
- multi: 3228

Which, at x1.2, would put the S8G1 at:

- single: ~1250
- multi: ~3875

...or still losing to the iPhone 12 (A14)
This should be dunk-city!

Dunktown.

Dunk central.

The NYT-food-critic-reviewing-the-Times-Square-Hard-Rock-Cafe of chip articles.

Instead, we've got...this, whatever this is:

zdnet.com/article/qualco…

What. Is. Happening?!?!!

• • •

Missing some Tweet in this thread? You can try to force a refresh
　

Keep Current with Alex Russell

Alex Russell Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @slightlylate

Alex Russell Profile picture
27 Oct
Look, I get that a lot of y'all want to dismiss the incredible scale of Web Components deployment these days because you're bought into framework(s) that are bad at DOM and don't play well with others.

But what if that wasn't the future?

Or even the new normal?
What if you didn't need to rely on ad hoc forks of HTML and JS, or at least got decent performance and interop for your trouble?

Dare to dream of a world that's already here.
It isn't helpful to point out how badly the failed promises of vdom and "concurrent mode" played out at scale, so consider instead what can be gained from *actually* writing components once...with miniscule runtimes...without global coordination.
Read 6 tweets
Alex Russell Profile picture
26 Oct
Hard to overstate the technical achievement by teams across Adobe and the Chromium community. Bringing Photoshop to the web has been a massive undertaking:

web.dev/ps-on-the-web/

Particular and specifically proud of all my Project Fugu 🐡 friends and colleagues.
As @fractorious and Nabeel allude to in the post, this has been a long, long journey. Getting the web platform into a place where folks could even *consider* projects this ambitious has been a huge lift.

Thankfully, Adjacency Theory provided a roadmap:

infrequently.org/2020/06/platfo…
Photoshop on the web is huge. But beyond that, what it signifies is a Big Freaking Deal.

When the web gains features to support high-end productivity, those same capabilities can be combined to unlock whole new classes of apps that suddenly don't require heavyweight installs.
Read 4 tweets
Alex Russell Profile picture
25 Oct
You can tell so many stories from the freeform responses to the State of CSS survey, but none of them support the idea that the #applebrowserban on competing engines is pro-developer.

gist.github.com/SachaG/cd7cf12…
These are connected:

Back in 2012 when @stshank wrote that piece, WebKit was near the front of the pack, so lack of competition was less pressing.

That was a long, long, long time ago:

infrequently.org/2021/04/progre…
Read 6 tweets
Alex Russell Profile picture
20 Oct
Having looked pretty deeply at various blockchain tech stacks over the years, this thread seems dead on.

People are holding on to *the dream*, and the fact that the tech will impoverish millions, help destroy the one world we share, and fail to avoid aggregation is immaterial.
I can't stress enough just how transparently wrong the "decentralised" claims are should you care to look.

Not the dream of decentralisation (whatever that is), but the lived reality of all these systems. Bitcoin? Mostly traded through exchanges now. And they will be regulated.
"web3"? Well, you can't find anything...so you get alt-stack, slower, less capable versions of systems we already have:

ens.domains
Read 6 tweets
Alex Russell Profile picture
18 Oct
I can't say it enough: "vdom" is not fast. It is slow.

The only *defensible* claim is that it isn't as slow as one might think given how much overhead it adds...but that doesn't make it competitive or good.
Why is vdom slow?

It does too much work.

Computing diffs through something like React's reconciliation algorithm is a clever way to avoid needing to have knowledge of the potential changes that can occur on either the JS or DOM side.

But it's correspondingly very expensive.
Reactive systems that constrain *either* how you update DOM (e.g. Lit's template system) *or* cabin the effects of JS side-effects (Svelte's "reactive declarations", FAST's Observables) deliver superior performance because they don't need to model + compare the whole world
Read 7 tweets
Alex Russell Profile picture
8 Oct
So @maxlynch hit me right in the feels with this one:



I have deep, deep regrets that I have not been able to convince browser makers to refuse to load 2.7MB of JS, critical path, served uncompressed.
Browser teams (the folks who work on UI) don't think of content as "their problem". For historical reasons, they care about TLS and that has helped them make common cause with security interests.
But no such enlightenment has occurred around performance...and in particular, perf so bad that it endangers accessibility.

Platform teams, meanwhile, focus on making the runtime faster, rather than building common cause between users on high-end and low-end devices.
Read 14 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

Like this author's thread?

Get emails when @slightlylate has new unrolls!

Check out other threads from @slightlylate!

Read all threads by @slightlylate

:(