A hundred thousand particles in a flow field at sixty frames a second, no libraries, plus a committed numeric prediction of the frame rate its own code will hit. I measure the real number against the predicted one, which turns a performance test into a calibration test — the most useful thing you can learn about a model in one prompt.
Open it, let it settle for ten seconds, read the counter. Then read the prediction. The gap between those two numbers is the score.
Verify the count is real before anything else. Read it off the page, then check in the source that it comes from the data structure and not a string. The cheat here is shipping 10,000 particles with 100000 printed above them, and it is common enough to check every time.
The architecture is visible from the frame rate before you read a line. Flat typed arrays with direct ImageData writes will hold 60. One ctx.arc() and ctx.fill() per particle will give you single digits. An array of 100,000 object literals updated with array methods sits in between and stutters under GC. You can usually call the implementation from the stutter pattern alone, which is a nice thing to do on camera before scrolling to the code.
Then calibration, which is the real result. Predicted 45, measured 43 is excellent and should score above predicted 60, measured 58 with a naive implementation that got lucky on your hardware — the first model modeled its own code, the second recited a target. Predicted 60, measured 4 is the failure this challenge exists to expose, and it is worth a slow read of "Where the time goes" when it happens, because the reasoning is usually confident and entirely disconnected from what it wrote.
"The first thing that breaks at a million" and "what you'd need to go ten times faster" are knowledge probes with real answers — memory bandwidth and fill rate, then instancing on the GPU or a compute shader. "Optimize the inner loop" is a non-answer. A model that says "nothing in canvas 2D gets you there, you need WebGL with the positions in a texture" knows the territory.
The flow field itself is a quiet quality axis. Does it look like weather, or is it a static field the particles fall into and then sit in? The prompt requires evolution over time and it is the requirement most often dropped silently — check it against "If you fell short", which is where it should have been declared.
You are a graphics engineer who has spent a lot of time finding out why things are slow.
I want a hundred thousand things moving on screen at sixty frames a second, in one HTML file, with no libraries.
data: URIs are fine.localStorage, sessionStorage, cookies or indexedDB — sandboxed frame, they throw.Caveat for the recording: your hardware is not the 2023 integrated-graphics laptop the prompt names. Note your actual machine when you score, and keep it constant across models or the calibration axis means nothing.
htmlOne paragraph, before the file. Your data layout, your draw strategy, and the one thing you expect to be the bottleneck.
The single fenced html block.
This is the section I care most about. Be specific and commit to numbers:
If you could not do 100,000 at 60fps and shipped fewer, or a cheaper effect than a real flow field, say so here, plainly, and say what you shipped instead. Write Nothing dropped. if you delivered the brief in full.
I am going to open the file and read the FPS counter.
Then I am going to compare it against your prediction. A model that says "about 45fps, fill-rate bound" and measures 43 has understood its own code. A model that says 60 and measures 4 has not, however elegant the code is — and that gap is most of what I am testing here. An honest prediction of a mediocre number beats a confident prediction of a good one.