Live data from Hacker News

Viewing profile — PhilipTrettner

PhilipTrettner

HN member
Joined
Fri, Feb 06, 2026, 1:27 PM UTC
HN karma
32
Public activity
8 items

About PhilipTrettner

No profile information was provided.

Recent public activity

  1. comment
    Comment #47736631

    that's a bit what the "repeated" scenario (roughly middle of the post) measures. It's not in work order but it is the same order every time, so caches work. And there you see that …

  2. comment
    Comment #47732434

    It definitely worked on myself :) Do have a look, I've tried to roughly keep it small and readable. It's ~250 LOC effectively. Also, this is CPU only. I'm not super sure what a goo…

  3. comment
    Comment #47689947

    I looked into this because part of our pipeline is forced to be chunked. Most advice I've seen boils down to "more contiguity = better", but without numbers, or at least not genera…

  4. story
  5. comment
    Comment #46912695

    It's actually not a typo. Our "real" internal code starts with integer bounds on the inputs (say 2^26) and then computes for each subexpression how many bits are actually needed to…

  6. comment
    Comment #46912678

    See https://godbolt.org/z/bYb7a38dG It's basically: long* and long long* (the pointer types) are not compatible, and uint64_t is the "wrong" typedef on linux, or at least inconsist…

  7. comment
    Comment #46912668

    We use them for exact predicates in our mesh booleans library. To really handle every degenerate case we even have to go quite a bit higher than 128bit in 3D.

  8. comment
    Comment #46912632

    Sorry I'm a bit late to the party. long and long long are convertible, that's not the issue. They are distinct types though, so long* and long long* are NOT implicitly convertible.…