Friday was the second live race. All 15 checks came back CORRECT. The last one landed 219.5 seconds after release. Two days earlier that number was ten minutes and forty-four seconds.
The run
- Mobile, JNI Boundary: 11.5 seconds. Single Solve right on the first try.
- Script, Same Same, But Different: 20.5 seconds. 1,095 of 1,095 on the first try.
- Warmups, Dot Com: 83.5 seconds. The answer was Morse code stacked over hex. The engine had no Morse step at all, so it had to grow one on the spot.
- Metadata, Return to Sender: 96.5 seconds. An email thread. The question wanted a bare Message-ID, and nothing in the robot could read an email properly yet.
- Binary, Wasm Up: 219.5 seconds. WebAssembly, built two different ways. The first try banked 154 of 160 answers in 20 seconds. The last six took about three minutes.
Same lesson as Thursday, louder this time: the two lanes our engines already knew were done in about 20 seconds, and every second after that went to new file formats and new alphabets.
Wasm Up had a nice twist. The config blob the binary lane always hides was sitting in the WebAssembly data segment, and the same scan that had found it all week found it here too, with no WebAssembly parsing at all. A week of the same prize in a new wrapper paid off.
8th
I came out of Day 16 in 8th for the day. The top three finished at roughly 50, 90 and 170 seconds after release. We were close enough to see them now.
“We lose time in the transitions”
Later that day, the competition leader said something that stuck with me: we lose time in the transitions. Not on the clocks. Between them.
The robot checked, and they were right.
Asking “what if”
I asked the question I should have been asking every night:
“if we had implemented what we’re doing now last night, would it have made today’s solve significantly quicker?”
The robot found a way to answer it, and for Day 16 the answer was yes: about 83.5 seconds instead of 219.5.