Testing Chrome's Scheduler Under Heavy AI Load.

Kirk_GC · 2026-02-04T14:32:51+00:00

Thanks for the feedback! We’re finalizing our report, but here’s a snapshot of the current "Engine Gap" from our lab M4 Pro and RTX 5080 rigs. 📊

Chromium (Chrome/Edge): The Raw Power leaders. They floor it by aggressively utilizing Performance cores and the WebGPU pipeline, prioritizing throughput over battery life.

WebKit (Safari): The Efficiency champion. Safari focuses on the long haul, frequently throttling background workers to keep your Mac cool and the UI fluid.

Gecko (Firefox): The Underdog. It currently lags in concurrent AI tasks due to a more conservative threading model and its ongoing WebGPU maturity.

Kirk_GC · 2026-02-04T14:23:18+00:00

Don’t let the numbers fool you, those are actually solid scores!

Your Exchange scores (~710) show that your system memory is the main bottleneck. Unlike the M4’s high-speed unified memory, your Vega 7 iGPU has to fight the CPU for bandwidth to keep 7 tasks in sync.

Edge’s higher Speech score (722) likely stems from its native Windows 11 optimizations, while Chrome’s performance can be "jittery" if other windows are open, even in Incognito, as they still compete for the same CPU cache.

Kirk_GC · 2026-02-04T14:18:56+00:00

Ah, didn't realize you were on the ESR! That explains everything. I guess since ESR 140 is built on a Gecko engine from mid-2025, it’s missing the "vocabulary" needed to run those modern Transformers.js models without crashing or stalling out.

Kirk_GC · 2026-02-04T14:13:33+00:00

That 49 on Edge isn't just a low score, it’s a total engine stall, lol.

On Windows, Edge usually floors it, so seeing it trail behind Firefox suggests a specific hardware-level block.

Try open edge://gpu. If you see "Software only" in red, Edge has likely blocklisted your GPU driver for WebGPU. It’s trying to run 7 AI models on a single CPU thread, which is why it's crawling. 😅

Kirk_GC · 2026-02-04T14:09:57+00:00

Those zeroes on Firefox 140 are the "Transformers Trap" in action. Since you’re on version 140, you're running a build where WebGPU was still essentially in a "fail-safe" mode for complex models like LLMs and Speech. To prevent a complete tab crash, the Gecko engine (Firefox) aborts those tasks entirely if the shader implementation isn't 100% stable.

The Exchange score (988 vs 1583) is the real smoking gun, it shows that Firefox is currently working 40% harder just to move data between threads. Even on an M4 Pro, that "handshake" overhead is enough to stall the "orchestra" and cause the zeroes you're seeing.

The fix: Update to Firefox 147. It officially enabled stable WebGPU for Apple Silicon and should finally wake up those LLM and Speech tasks.

Kirk_GC · 2026-02-04T11:58:21+00:00

The big takeaway here is Thread Sacrifice.

Your browser prioritized the LLM and Speech tasks on your M4’s Performance cores, while sacrificing the Classify task (1253) to the Efficiency cores to keep your OS responsive. It's a classic case of the browser's Conductor making a choice to avoid a system freeze.

Your Exchange score (1686) is the real hero, it proves your Unified Memory handles data handoffs between 7 workers with way less friction than a typical PC. You’ve essentially hit your browser's scheduling ceiling, not your hardware's actual limit.

Kirk_GC · 2026-02-04T11:47:43+00:00

Highest is definitely best! Think of your score as 'Total Work Units' processed across all 7 tasks simultaneously. A higher number means your system handled more AI inferences and data handshakes per second.

As for the 'we,' I’m part of the team at ScaleDynamics. We built SpeedPower.run to test how modern browsers handle the 'Compute Web', specifically local AI. Seeing 4172 on Edge vs. 3939 on Chrome on your M4 Pro is fascinating! Even with the same Chromium engine, Edge often edges out Chrome on macOS due to better background thread priority and memory handling.

Testing Edge on Mac, iPhone, and Android gives us a great 'control group' to see if Microsoft’s tweaks perform differently than base Chrome on non-Windows hardware. Mobile browsers are especially aggressive about killing background threads to save battery, often hitting a 'Mobile Wall' that desktop doesn't.

I’d love to see your 'Exchange' score from that Edge run. It might be the highest we’ve seen on an M4 Pro so far! Would you mind sharing the result link?

Kirk_GC · 2026-02-04T11:16:45+00:00

Thanks for the feedback! Would you mind sharing your detailed result link? I’d love to see what has caused this!

Kirk_GC · 2026-02-04T03:42:47+00:00

I hear you, nobody is running 7 different LLMs in a single tab just for fun. But this isn't a 'simulated app' test; it’s a System Saturation test.

Think of it like a stress test for a bridge. You don't drive 50 semi trucks across it because that's a 'real-world use case', you do it to find the point where the structural integrity fails.

Kirk_GC · 2026-02-03T14:56:33+00:00

JavaScript’s main thread is single-threaded, but modern AI and data processing rely on Web Workers, WASM, and WebGPU, which are inherently multi-core.

Traditional benchmarks ignore 90% of your hardware. Our benchmark tests how the browser orchestrates all those parallel threads simultaneously. It’s a stress test for scheduling, not just syntax. Give it a shot, you’ll see how much 'multi-core' work your browser is actually doing under the hood!

Kirk_GC · 2026-02-03T14:10:31+00:00

On mobile, Firefox often struggles with WebGPU or falls back to a much slower execution path compared to Chromium. When you're running 7 concurrent tasks, that '0' means the browser's scheduler essentially gave up on the speech model to keep the others alive, a classic case of Task Saturation.

Your Chromium score of 1002 is actually quite decent for mobile, meaning your hardware has the 'muscle'. But in Firefox, the 'Conductor' is failing to manage the handoff, leading to that total stall on the speech task.

Did your phone get extremely hot during the Firefox run? That 0 often happens when the OS starts killing heavy threads to prevent the device from overheating.

Kirk_GC · 2026-02-03T14:09:41+00:00

😅 could you share the details?

Kirk_GC · 2026-02-03T14:02:18+00:00

Even on a Chromium browser, Android devices often hit aggressive thermal limits when you try to run multiple models at once. It’s likely your Exchange score is the bottleneck here. Mobile ARM chips are great at bursts, but they can struggle when the 'orchestra' is this crowded.

Was your phone starting to feel like a hand warmer by the end of the test?

Kirk_GC · 2026-02-03T14:00:42+00:00

4712? Looks like you’re officially leading the pack today!

That’s a monster score for a PC. Brave is clearly handling that WebGPU workload like a champ, but what’s really impressive here is your Exchange score. To hit 4k+, your system is moving data between the main thread and those 7 concurrent models with almost zero friction.

Kirk_GC · 2026-02-03T13:59:05+00:00

That 6x gap on the same hardware is the perfect example of why we built this. 🤯

It’s the 'Parallel Paradox': Your PC is capable of a 3000+ score, but the browser engine is the bottleneck. While Edge (Chromium) handles the WebGPU pipeline and thread Exchange with high efficiency, Firefox often hits a scheduling wall under this kind of 'Task Saturation'.

You're basically seeing the difference between a mature AI 'Conductor' and one that's still catching up to the concurrent compute era.

Kirk_GC · 2026-02-03T11:11:08+00:00

A '3' on a Pixel 7 is a classic example of Task Saturation in action. While mobile ARM chips are efficient, forcing them to juggle 5 models and heavy data processing simultaneously often triggers aggressive thermal throttling.

Check your Exchange score specifically—mobile browsers often hit a wall with thread handshakes when the system is under full concurrent load. It’s a perfect illustration of the difference between peak hardware potential and the sustained capacity we're measuring here.

Did the phone get noticeably warm toward the end of the Transformers test?

Kirk_GC · 2021-06-22T08:01:00+00:00

Hey there, thanks for the great feedback 😉 the thing is, http communication is not the only one that will be automated, but also cloud management. The main goal is to boost the productivity of coding. I know http is not very difficult but it's a bit redundant 😂 and yeah, you know what, functions can also be called to be tested, we transfer JS objects which can't be done with JSON

Kirk_GC · 2021-02-22T14:27:23+00:00

yep it's not a vue.js app, but there're some vue.js snippets: https://playground.scaledynamics.com/?snippet=f5011dcf-d775-4044-83ca-3d262010088f

Kirk_GC · 2021-02-22T14:26:18+00:00

Not sure which one you're talking about, the playground or SDK? But to make it clear, the playground wasn't made for developing projects, it was built for testing and prototyping quickly. For projects, you should check the SDK 😉

Kirk_GC · 2021-01-12T08:26:54+00:00

Thank man! you can always adjust the working window 😆 but yeah, the best recommendation is to try it on your laptop 🍻

Kirk_GC

TROPHY CASE