Challenges/A hundred thousand of them/Run

Run Detail

completedkimi-k3

Unscored

Every model's answer from this round

Recorded for these videos

47:51

Ranking major U.S. Open-Weights Models. (Where does Ripple 65B fit in?)

Nov 6, 2026 · YouTube

38:58

Testing Particle-1: a post-trained DeepSeek V4.1 Flash specializing in coding and efficiency

Oct 28, 2026 · YouTube

29:55

Kimi K3.1 Pro Looked Incredible. Then I Kept Testing.

Oct 26, 2026 · YouTube

22:47

Mistral Large 4 Is Cheap. But Is It Good Enough to Compete?

Oct 6, 2026 · YouTube

16:54

Stealth Union Alpha: Is this another cheap GPT model? (better than Luna, cheaper than Terra?)

Sep 16, 2026 · YouTube

16:45

DeepSeek V4.1 Flash Is Shockingly Good for the Price

Sep 10, 2026 · YouTube

17:14

How much better is GPT-6 Astra over Claude Opus 5? Real Website and Coding Tests

Sep 5, 2026 · YouTube

29:13

Implementing a multiplayer game with GPT-6 Astra (+ Gemini 3.8, Opus 5, Sol Pro)

Sep 5, 2026 · YouTube

19:42

Meta Muse Spark 1.3 Review: A Huge Leap Forward

Sep 2, 2026 · YouTube

17:31

Testing Gemini 3.8 Flash on Real Coding Challenges (vs. other models)

Sep 2, 2026 · YouTube

Provider

openrouter

Challenge Version

v1.0

Turns

Duration

774.8s

Total Tokens

28,692

Input Tokens

727

Output Tokens

27,965

Reasoning Tokens

24,129

Reasoning Effort

default

Est. Cost

$0.4217

Started

8/31/2026, 3:37:38 AM

OR Provider

Moonshot AI

Finish Reason

stop

Generation ID

gen-1788147459-9kjdSuDR0A45kG02KV5n

Turns (1)

Turn #1

727 in27,965 out24,129 reasoning28,692 total774.8s

user

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.

What to build

A canvas, 900 × 600.
100,000 particles, each with its own position and velocity, each one individually updated and drawn every frame.
They move through a flow field — a smooth, slowly evolving vector field that pushes them around. Curl, drift, eddies. It should look like weather, or ink in water, not like confetti.
Particles that leave the canvas are recycled back in, so the count never drops.
The field itself must evolve over time. A static field that particles merely settle into is not what I asked for.

On screen, always visible

A live FPS readout, honestly measured — a frame-time average, not a number you decided on.
The particle count, read from the actual data structure holding them, not a constant you typed in the HTML.

House rules

One file. Everything inline — no CDN, no external stylesheet, font, script or image. data: URIs are fine.
No libraries. No WebGL helper you paste in. If you want to use WebGL, write it yourself.
No network at runtime.
No localStorage, sessionStorage, cookies or indexedDB — sandboxed frame, they throw.
Return the file as exactly one fenced html block.

Answer in exactly these sections

The plan

One paragraph, before the file. Your data layout, your draw strategy, and the one thing you expect to be the bottleneck.

The file

The single fenced html block.

The prediction

This is the section I care most about. Be specific and commit to numbers:

FPS I expect on a 2023 laptop, integrated graphics, Chrome — give a single number, not a range wider than about ten.
Where the time goes — roughly what share is update versus draw, and why.
The first thing that breaks if I raise the count to a million.
What you'd need to go ten times faster. Name the technique, not "optimize further".

If you fell short

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.

How this is scored

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.

assistant

The plan

Particle state lives in four parallel Float32Arrays (SoA: px, py, vx, vy) — 1.6 MB of contiguous, monomorphic data that V8 can chew through without a single allocation per frame. The flow field is the analytic curl of a scalar potential built from products of sines (divergence-free, so particles don't clump — that's what makes it read as ink, not confetti), re-rasterized every frame onto a 128×86 grid using a 4096-entry sine LUT, with phases advancing in time plus a slowly orbiting gyre; each particle bilinearly samples that grid, integrates with damping, and wraps toroidally (recycling that can never drop the count). Drawing skips Canvas2D path/fill APIs entirely: one ImageData viewed as a Uint32Array, a packed per-channel decay pass for trails (c -= c>>5 on all four channels at once), each particle written as a 2×2 splat colored by speed from a 256-entry palette, then a single putImageData. The bottleneck I expect is the draw path — the full-frame fade plus the putImageData upload move ~7 MB of memory per frame and cross the CPU→GPU boundary, while the 100k updates are just ~4M flops on cache-resident arrays.

The file

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>100,000 particles — curl-noise flow field</title>
<style>
  html,body{margin:0;padding:0;background:#04070b;}
  body{display:flex;align-items:center;justify-content:center;min-height:100vh;}
  #wrap{position:relative;line-height:0;}
  canvas{width:900px;height:600px;background:#000;
         box-shadow:0 0 60px rgba(30,70,110,.35);border-radius:2px;}
  #hud{position:absolute;top:8px;left:8px;line-height:1.45;
       font:12px ui-monospace,SFMono-Regular,Menlo,Consolas,monospace;
       color:#9fd8ee;background:rgba(2,8,14,.55);padding:4px 9px;
       border-radius:4px;pointer-events:none;white-space:pre;
       text-shadow:0 1px 2px #000;}
</style>
</head>
<body>
<div id="wrap">
  <canvas id="c" width="900" height="600"></canvas>
  <div id="hud">starting…</div>
</div>
<script>
(function () {
'use strict';

/* ============================================================
 * 100k particles, simulated on the CPU, plotted as raw pixels.
 *
 *  - State: four parallel Float32Arrays (structure of arrays).
 *  - Field: divergence-free curl of an analytic potential
 *    (products of sines), re-rasterized EVERY FRAME onto a
 *    128x86 grid via a sine LUT, bilinearly sampled per
 *    particle. Phases advance with time and a large gyre
 *    slowly orbits -> the field itself keeps evolving.
 *  - Draw: one ImageData as Uint32Array. Packed per-channel
 *    decay pass leaves trails; each particle is a 2x2 splat
 *    colored by speed; one putImageData per frame.
 *  - Recycle: toroidal wrap — the population cannot shrink.
 * ========================================================== */

var W = 900, H = 600, NPIX = W * H;
var N = 100000;

var cvs = document.getElementById('c');
var ctx = cvs.getContext('2d', { alpha: false, willReadFrequently: true });
var hud = document.getElementById('hud');

/* ---------- particle state (structure of arrays) ---------- */
var px = new Float32Array(N);
var py = new Float32Array(N);
var vx = new Float32Array(N);
var vy = new Float32Array(N);
for (var i = 0; i < N; i++) {
  px[i] = Math.random() * W;
  py[i] = Math.random() * H;
}

/* ---------- flow-field grid (interleaved u,v pairs) ---------- */
var GW = 128, GH = 86;
var fld = new Float32Array(GW * GH * 2);

/* ---------- sine LUT: max error ~0.0015 rad, far cheaper than Math.sin --- */
var SN = 4096, SM = 4095, S2R = SN / (Math.PI * 2);
var sinL = new Float32Array(SN);
for (var s = 0; s < SN; s++) sinL[s] = Math.sin(s / S2R);
function fsin(a) { return sinL[(((a * S2R) | 0) & SM)]; }
function fcos(a) { return sinL[((((a + 1.5707963267948966) * S2R) | 0) & SM)]; }

/* ---------- field: curl of psi(x,y,t) ----------
 * psi = A1*sin(a1)*sin(b1) + A2*sin(a2)*sin(b2) + A3*sin(a3)
 * u = dPsi/dy, v = -dPsi/dx  (divergence-free: incompressible,
 * no clumping — weather/ink, not confetti).                   */
var t = 0;
var K1 = 0.110, K1B = 0.147, K2 = 0.310, K2B = 0.271;
var K3X = 0.050, K3Y = 0.043;
var A1 = 1.00, A2 = 0.55, A3 = 0.35, FSCALE = 4.0;
var CELLW = W / (GW - 1), CELLH = H / (GH - 1);

function updateField() {
  var t1 = t * 0.35, t2 = t * 0.27, t3 = t * 0.53, t4 = t * 0.41, t5 = t * 0.31;
  var cx = 450 + 260 * Math.cos(t * 0.090);   /* slow wandering gyre */
  var cy = 300 + 180 * Math.sin(t * 0.113);
  var p = 0, i, j;
  for (j = 0; j < GH; j++) {
    var wy = j * CELLH;
    var b1 = j * K1B - t2;
    var b2 = j * K2B + t4 + 0.6;
    var sb1 = fsin(b1), cb1 = fcos(b1);       /* hoisted per row */
    var sb2 = fsin(b2), cb2 = fcos(b2);
    var dy = (wy - cy) * 0.002857;            /* /350 */
    for (i = 0; i < GW; i++) {
      var a1 = i * K1 + t1;
      var a2 = i * K2 - t3 + 1.7;
      var a3 = i * K3X + j * K3Y - t5;
      var sa1 = fsin(a1), ca1 = fcos(a1);
      var sa2 = fsin(a2), ca2 = fcos(a2);
      var ca3 = fcos(a3);
      var dpx = A1 * K1 * ca1 * sb1 + A2 * K2 * ca2 * sb2 + A3 * K3X * ca3;
      var dpy = A1 * K1B * sa1 * cb1 + A2 * K2B * sa2 * cb2 + A3 * K3Y * ca3;
      var dx = (i * CELLW - cx) * 0.002857;
      /* curl + slow gyre + gentle mean drift */
      fld[p++] =  dpy * FSCALE - dy * 0.30 + 0.08;
      fld[p++] = -dpx * FSCALE + dx * 0.30;
    }
  }
}

/* ---------- speed -> color palette (rebuilt per frame: slow hue drift) --- */
var pal = new Uint32Array(256);
function buildPal() {
  var base = (t * 6) % 360;
  for (var i = 0; i < 256; i++) {
    var u = i / 255;
    var h = (base + 222 - 192 * u) % 360; if (h < 0) h += 360;
    var sat = 0.92 - 0.60 * u;
    var val = 0.10 + 0.90 * Math.pow(u, 0.65);
    var c = val * sat, hp = h / 60, x = c * (1 - Math.abs((hp % 2) - 1));
    var r = 0, g = 0, b = 0;
    if (hp < 1) { r = c; g = x; } else if (hp < 2) { r = x; g = c; }
    else if (hp < 3) { g = c; b = x; } else if (hp < 4) { g = x; b = c; }
    else if (hp < 5) { r = x; b = c; } else { r = c; b = x; }
    var m = val - c;
    r = ((r + m) * 255) | 0; g = ((g + m) * 255) | 0; b = ((b + m) * 255) | 0;
    pal[i] = (255 << 24) | (b << 16) | (g << 8) | r;
  }
}

/* ---------- pixel buffer ---------- */
var img = ctx.createImageData(W, H);
var buf = new Uint32Array(img.data.buffer);
buf.fill(0xFF000000);

/* ---------- main loop ---------- */
var ACC = 0.070, DAMP = 0.950;    /* vmax ~= maxfield*ACC/(1-DAMP) ~ 2.5px/f */
var IWX = (GW - 2) / W, IWY = (GH - 2) / H;
var GWS = GW * 2;
var PSCALE = 200;
var ALPHA = 0xFF000000;

var last = -1, ema = 16.7, fcount = 0;

function frame(now) {
  requestAnimationFrame(frame);

  var dt = now - last; last = now;
  if (dt > 0 && dt < 250) ema += (dt - ema) * 0.06;   /* honest frame-time EMA */
  t += (dt > 0 ? Math.min(dt, 50) : 16.7) * 0.001;

  updateField();
  buildPal();

  var i, q, n;

  /* packed decay: c -= c/32 per channel; c>>5 <= c so no cross-byte borrow */
  for (i = 0; i < NPIX; i++) {
    q = buf[i];
    buf[i] = (q - ((q >>> 5) & 0x07070707)) | ALPHA;
  }

  n = px.length;                     /* count from the actual data structure */
  for (i = 0; i < n; i++) {
    var x = px[i], y = py[i], ux = vx[i], uy = vy[i];

    /* bilinear sample of the flow field */
    var gx = x * IWX, gy = y * IWY;
    var ix = gx | 0, iy = gy | 0, fx = gx - ix, fy = gy - iy;
    var o = (iy * GW + ix) * 2;
    var u0 = fld[o]         + (fld[o + 2]         - fld[o])         * fx;
    var u1 = fld[o + GWS]   + (fld[o + GWS + 2]   - fld[o + GWS])   * fx;
    var v0 = fld[o + 1]     + (fld[o + 3]         - fld[o + 1])     * fx;
    var v1 = fld[o + GWS+1] + (fld[o + GWS + 3]   - fld[o + GWS+1]) * fx;
    var fu = u0 + (u1 - u0) * fy;
    var fv = v0 + (v1 - v0) * fy;

    ux = ux * DAMP + fu * ACC;
    uy = uy * DAMP + fv * ACC;
    x += ux; y += uy;

    /* recycle: toroidal wrap, count can never drop */
    if (x < 0) x += W; else if (x >= W) x -= W;
    if (y < 0) y += H; else if (y >= H) y -= H;

    px[i] = x; py[i] = y; vx[i] = ux; vy[i] = uy;

    /* 2x2 splat, colored by speed */
    var sx = x | 0, sy = y | 0;
    if (sx > W - 2) sx = W - 2;
    if (sy > H - 2) sy = H - 2;
    var ci = ((ux * ux + uy * uy) * PSCALE) | 0;
    if (ci > 255) ci = 255;
    var col = pal[ci];
    var oo = sy * W + sx;
    buf[oo] = col; buf[oo + 1] = col;
    buf[oo + W] = col; buf[oo + W + 1] = col;
  }

  ctx.putImageData(img, 0, 0);

  if ((++fcount % 10) === 0) {
    hud.textContent =
      (1000 / ema).toFixed(1) + ' fps    ' +
      ema.toFixed(2) + ' ms/frame    ' +
      n.toLocaleString('en-US') + ' particles';
  }
}
requestAnimationFrame(frame);
})();
</script>
</body>
</html>

The prediction

FPS I expect: 60. On a 60Hz panel it will pin at vsync, because the unthrottled frame costs roughly 7–9 ms of CPU work — about 2× headroom under the 16.7 ms budget on a 2023 laptop chip. (Tellingly, on a 120Hz panel the same file should read ~110–120: the number is vsync-bound, not load-bound. If it reads in the 40s on a healthy machine, the prime suspect is a slow putImageData driver path, not the simulation.) The main risk to the 60 is aggressive battery-saver CPU throttling, which I can't see from inside the page.
Where the time goes: ~35% update, ~65% draw. Particle update + bilinear sampling ≈ 30%, field regeneration ≈ 5%. Draw ≈ 60%: the 540k-pixel packed decay pass ~15%, splatting ~10%, putImageData + compositing ~35%. The update loop is dense float arithmetic on ~1.6 MB of hot typed arrays — modern cores do this at well under a nanosecond per op. The draw side instead moves memory: the fade reads+writes 2.16 MB, splats scatter ~400 KB of writes across random cache lines, and putImageData pushes the full 2.16 MB frame across the CPU→GPU boundary. Bandwidth and the driver call dominate; arithmetic is nearly free. That's why the code spends its cleverness budget (LUT sine, packed decay, grid + bilinear instead of per-particle noise) on keeping both sides cheap but the draw side especially simple.
First thing that breaks at 1,000,000: the single-threaded update loop. Ten times the particles is ten times the ALU work (~25–35 ms/frame before anything draws), and 16 MB of particle state stops fitting in L2/L3, so each op also gets slower — you land near 30 fps and falling. Close behind: 1M × 4-pixel splats onto a 540k-pixel canvas is ~7 writes per pixel per frame, so the screen saturates and the trails wash to mush — it fails visually at almost the same moment it fails numerically.
To go ten times faster: move the simulation to the GPU with a ping-pong particle sim — WebGL2 transform feedback (positions/velocities in buffer objects, updated by a vertex shader, drawn as GL_POINTS in the same pipeline), or equivalently float-texture FBO ping-pong. The flow-field math moves into the shader verbatim; per-particle CPU work drops to zero; 1M particles at 60 fps becomes routine. (WebGPU compute is the same technique with a nicer API.) No amount of JS micro-optimization gets you there — the wall is one thread doing 100M+ ops per second.

If you fell short

Nothing dropped.

Attachments

moonshotai/kimi-k3 — page