Hacker News: pavpanchekha

New comment by pavpanchekha in "Compiler-style optimization for drawing via Skia"

pavpanchekha — Sun, 20 Sep 2026 00:00:14 +0000

Last author here. We've talked to the Chrome folks and they are interested, but it's difficult work. Chrome is big enough that emitting different sequences is hard and would requiring changing a lot of internal abstractions. Skia would love to do it optimization like this but it's a small team with a lot of other priorities. Integrating outside code is hard.

New comment by pavpanchekha in "Compiler-style optimization for drawing via Skia"

pavpanchekha — Sat, 19 Sep 2026 23:33:11 +0000

I am a big fan of DB-style thinking, very much on the same wavelength as you :)

New comment by pavpanchekha in "Compiler-style optimization for drawing via Skia"

pavpanchekha — Sat, 19 Sep 2026 23:21:26 +0000

Let me also add that nanobench was a huge help, not just because it was a good benchmarking tool but also because it gave us some confidence that we're measuring the right thing. It's easy to make _something_ faster but hard to know if it's the right thing. Having that come pre-packaged from the project answers a lot of tricky questions that would otherwise be easy to get wrong.

New comment by pavpanchekha in "Compiler-style optimization for drawing via Skia"

pavpanchekha — Sat, 19 Sep 2026 23:12:46 +0000

Thank you! The SkRecord system was _perfect_ for doing these optimizations. I don't think it would have been possible to do this project without it.

New comment by pavpanchekha in "Compiler-style optimization for drawing via Skia"

pavpanchekha — Sat, 19 Sep 2026 23:08:45 +0000

Last author here, this is very much what I've worked on for most of my career. In this project, I had the idea of optimizing rendering instructions years ago, while I was writing https://browser.engineering/, but the hard part of this project was being very careful with the semantics of Skia itself. It's _super_ easy to write down rewrite rules that _seem_ correct, but are actually only correct when, say, something is opaque, or has the right blend mode, or two things don't overlap, or something like that. Which is why this paper focuses os much on carefully defining that semantics. We actually did the semantics in Lean because otherwise we couldn't consistently write correct rewrite rules.

New comment by pavpanchekha in "Compiler-style optimization for drawing via Skia"

pavpanchekha — Sat, 19 Sep 2026 23:06:07 +0000

Hi folks! Last author here, happy to answer questions, very surprised to see this on HN. We had a blast working on this. Let me add that the Skia team at Google was super supportive, met with us many times to explain a lot of stuff.

I had the idea for this project years ago while writing Web Browser Engineering with Chris Harrelson (see https://browser.engineering/). Then a few years ago I made a first attempt at this project with Yuvaraj (https://droidkid.github.io/), but for various reasons we never got very far. I restarted the project with Bhargav (https://bhargavkk.com/) about a year ago, and focused much more seriously on the semantics of Skia itself, which made progress much more rapid. Still, I was, frankly, shocked by how good the results are.

New comment by pavpanchekha in "Racket v9.3"

pavpanchekha — Sat, 15 Aug 2026 04:41:40 +0000

I do a substantial amount of coding in Racket, including maintaining the Herbie numerical compiler (https://herbie.uwplse.org/) over the last decade.

Racket is great! The runtime is reasonably fast, and the standard library is exceptionally featureful, including, for example, a decent plotting library, an HTTP server, decent HTML and JSON support, several forms of multi-threading, and a quite good FFI, all of which Herbie uses extensively. I suppose the parentheses are a question of taste (I like them!) but a lot of the specific syntactic decisions, like the `for` and `match` macros, are quite nice.

New comment by pavpanchekha in "Grok 4.6"

pavpanchekha — Thu, 13 Aug 2026 01:37:32 +0000

It's about chips with a large enough scale up domain. Larger domain allows for bigger model, which is what's driving this jump. You've got to get the chips, test them, tune kernels, then start a big pre train, mid & post-train, and only then do you actually get the model. So it takes time. Anthropic got there first partly because they use different hardware (TPU I think, maybe Trainium) which had larger scale ups earlier.

New comment by pavpanchekha in "Ten advances in mathematics and theoretical computer science"

pavpanchekha — Mon, 03 Aug 2026 18:22:10 +0000

A lot of algorithmic improvement in AI is ultimately bottlenecked by compute. It is very easy to come up with ideas that could improve models! But to prove that they do, especially at scale, is expensive and takes a long time.

New comment by pavpanchekha in "Advancing the price-performance frontier with GPT‑5.6"

pavpanchekha — Thu, 30 Jul 2026 17:31:13 +0000

Making Luna, which was already very cheap and extremely capable, 5x cheaper is crazy. I use Sol at work but Luna at home, and while there's definitely a difference, it doesn't feel like night-and-day. After a year of ever-increasing prices it suddenly feels (between this, Kimi K3, GLM 5.2) that prices are falling again.

New comment by pavpanchekha in "GPT-5.6 Sol, along with Terra and Luna, will launch publicly this Thursday"

pavpanchekha — Wed, 08 Jul 2026 05:25:45 +0000

For compiler work I found that Sol is noticably better than 5.5 (and I generally use OAI models because I like the Codex app), but Fable was still obviously better.

New comment by pavpanchekha in "Notes from the Mistral AI Now Summit"

pavpanchekha — Fri, 29 May 2026 18:54:44 +0000

OpenAI used to make Codex-specific models, but they stopped. What I've gathered from interviews and similar is that training two models isn't worth the (small) lift from having a coding-specific model. You're pre-training on everything anyway, and coding RL is reasonably useful for general-purpose models too.

Can LLMs accelerate science? An experiment

pavpanchekha — Thu, 09 Apr 2026 04:52:23 +0000

Article URL: https://pavpanchekha.com/blog/llk.html

Comments URL: https://news.ycombinator.com/item?id=47699408

Points: 2

# Comments: 1

New comment by pavpanchekha in "Herbie: Automatically improve imprecise floating point formulas"

pavpanchekha — Sat, 04 Apr 2026 18:09:31 +0000

University of Washington Programming Languages and Software Engineering (research group).

I'm not at UW any more, I'm now at Utah, but some of the Herbie team is at UW and they provide the infrastructure

New comment by pavpanchekha in "Herbie: Automatically improve imprecise floating point formulas"

pavpanchekha — Sat, 04 Apr 2026 14:04:09 +0000

Documented here but yes it's an average, of something similar to but not exactly the same as relative error: https://herbie.uwplse.org/doc/latest/error.html

It's true that averages can be misleading but we encourage users to think about it instead as a percentage of inputs. In practice the error distribution is very bimodal, the two modes being "basically fine" (a few ulps of error) and "garbage" (usually 0 instead of some actual value)

New comment by pavpanchekha in "Herbie: Automatically improve imprecise floating point formulas"

pavpanchekha — Sat, 04 Apr 2026 14:01:27 +0000

Author here. The speed up is modeled throughput, though the model is relatively naive. It's possible to disable branches by turning off the regimes flag, see https://herbie.uwplse.org/doc/1.0/options.html

New comment by pavpanchekha in "Herbie: Automatically improve imprecise floating point formulas"

pavpanchekha — Sat, 04 Apr 2026 13:59:55 +0000

Author here. I've got a few papers about this problem (including one in submission), but it is very very hard to do, especially with acceptable overhead. The state of the art is maybe 100x overhead.

New comment by pavpanchekha in "Herbie: Automatically improve imprecise floating point formulas"

pavpanchekha — Sat, 04 Apr 2026 13:58:44 +0000

It is, there's a page in the documentation about how errors are defined. Let me also add: Herbie generally gives the most accurate option it found first, and then the other stuff might be useful for speed (0.5x is way faster than two square roots and a divide!) but it's not as accurate

New comment by pavpanchekha in "Herbie: Automatically improve imprecise floating point formulas"

pavpanchekha — Sat, 04 Apr 2026 13:56:17 +0000

Author here! Yes, the float distribution isn't what you want in practice, but distribution selector isn't really the right thing either, because a low probability bad result can still be pretty bad! Hence the range selector; the float distribution is good at picking extreme values that trigger FP error.

We usually recommend looking for 90%+ accuracy or carefully examining the accuracy plot

New comment by pavpanchekha in "Herbie: Automatically improve imprecise floating point formulas"

pavpanchekha — Sat, 04 Apr 2026 13:49:56 +0000

It was me. Damn it you're right! Will fix!