I tested the new fast floor-division trick on 2,000,000 inputs. It's correct — and no faster here.

A new blog post this week claims a faster way to compute signed 64-bit floor division by a constant — the kind of division where -1 / 86400 rounds to -1, not 0, the way timestamps-before-1970 need it to. The author calls it the missing chapter of Hacker's Delight and reports 10–20% faster throughput on ARM and ~5–10% on x86 for most divisors, "with ideal compilation."

That qualifier — ideal compilation — is doing a lot of work. So I implemented the headline case, division by 86400, and ran it on my machine: an AMD EPYC 9D25, gcc 13.3, -O2.

The trick

The new algorithm for divisor 86400 is three lines:

#include <stdint.h>

static inline int64_t fast_floordiv_86400(int64_t x) {
    const int64_t M = ((__int128)1 << 79) / 86400 + 1;
    const int64_t m = M + (x >> 63);
    return (int64_t)((__int128)x * m >> 79);
}

The idea is elegant: a sign-selected multiplier. For non-negative x you use M; for negative x you use M + (x >> 63), which is M - 1, and a single 128-bit multiply plus a shift lands you on the floor instead of the truncated quotient. No branch, no second division, no remainder fixup. Compare the "common" fix most codebases actually use:

static inline int64_t common_floordiv_86400(int64_t x) {
    int64_t d = x / 86400;
    int64_t r = x % 86400;
    return d - (r < 0);
}

Correctness first: 2,000,000 inputs, zero mismatches

Before timing anything, I checked it against the reference (truncated division plus the remainder fixup) on 12 edge cases and 2,000,000 random 64-bit inputs:

edge x=0                  fast=0                ref=0                OK
edge x=-1                 fast=-1               ref=-1               OK
edge x=86400              fast=1                ref=1                OK
edge x=-86400             fast=-1               ref=-1               OK
edge x=-86401             fast=-2               ref=-2               OK
edge x=9223372036854775807  fast=106751991167300  ref=106751991167300  OK
edge x=-9223372036854775808 fast=-106751991167301 ref=-106751991167301 OK
edge x=-86400000000       fast=-1000000         ref=-1000000         OK
random N=2000000 mismatches=0

All 12 edges pass, including INT64_MIN, and all 2,000,000 random inputs agree. The trick is correct, at least for divisor 86400 on this implementation. That part of the claim holds up completely.

Speed: no win here

Then the disappointing part. Two benchmark styles — a synthetic loop and a 50-million-element random array, three rounds each, gcc -O2:

synthetic loop, 200M iterations per round:
  fast    1.11 / 1.10 / 1.07 ns/op
  common  0.85 / 0.84 / 0.85 ns/op
  trunc   0.84 / 0.82 / 0.82 ns/op

random array, 50M elements per round:
  fast    1.38 / 1.82 / 1.15 ns/op
  common  1.61 / 1.70 / 1.78 ns/op
  trunc   1.11 / 1.04 / 1.04 ns/op

Read that plainly: the new trick is roughly tied with the common fixup on random data and about 30% slower on the synthetic loop — and both lose to plain truncated division, because the compiler already turns division by a constant into a multiply-shift sequence. The 128-bit multiply in the new trick is the cost the author's "ideal compilation" presumably removes on other targets; on gcc 13 / x86-64, it doesn't get removed, and it shows up in the timings.

This does not refute the author's benchmarks. They were measured on different hardware (M4 Pro, Snapdragon, Ryzen 9 9950X3D) with what sounds like a tuned reference implementation, and the post is explicit that the win is platform-dependent — slower in the remaining x86 cases, with worse latency. My machine appears to be one of those remaining cases. But it does mean the practical advice is narrower than the headline: if your compiler already optimizes constant division (and gcc and Clang both do), the trick you already have — truncated division plus a one-line remainder fixup — is already the fast path, and swapping in a 128-bit multiply buys you nothing here.

The take

Correctness: verified, 2,000,000 for 2,000,000. Speed: not reproduced on AMD EPYC + gcc 13 -O2, where the new code lands between tied and ~30% slower than the boring version. The algorithm is a genuinely neat piece of arithmetic, and on ARM or with a compiler that lowers the 128-bit multiply better, the author's numbers may well hold. On my machine, though, the fastest floor division by 86400 is the one the compiler was already generating for you. Measure before you adopt — including, especially, the clever thing.

Sources: Ben Joffe, "A faster way to compute signed 64-bit floor division by constants" (October 27, 2026); benchmarks run on AMD EPYC 9D25, gcc 13.3.0, -O2, October 29, 2026.