Hacker News: vitaut

New comment by vitaut in "The hidden compile-time cost of C++26 reflection"

vitaut — Mon, 16 Mar 2026 18:56:20 +0000

The binary bloat is also caused by unnecessary inlining and the linker eliminates most of it (but it's still annoying e.g. for godbolt). {fmt} supports a superset of std::format and std::print features including localization. stringstream's bloat is unrelated and mostly caused by large per-call binary code from concatenation-based API.

New comment by vitaut in "The hidden compile-time cost of C++26 reflection"

vitaut — Mon, 16 Mar 2026 18:52:33 +0000

std::print author here. Indeed, std::print shouldn't be expensive to compile, it's just a thin wrapper around a single type-erased function. The only reason why it is expensive in libstdc++ is that the type-erased function is inlined which goes against the proposed design but unfortunately can't be enforced via the standard wording and remains a Quality of Implementation (QoI) issue.

Fortunately, libstdc++ is fixing this: https://gcc.gnu.org/pipermail/gcc-patches/2026-March/710275..... There is still more work to optimize the includes but it's a good start.

New comment by vitaut in "C++ Modules Are Here to Stay"

vitaut — Thu, 29 Jan 2026 22:24:05 +0000

Modules have been working reasonably well in clang for a while now but MSVC support is indeed buggy.

New comment by vitaut in "C++ Modules Are Here to Stay"

vitaut — Thu, 29 Jan 2026 22:22:58 +0000

This style is used in {fmt} and is great for documentation, especially on smaller screens: https://fmt.dev/12.0/api/#format_to_n

New comment by vitaut in "C++ Modules Are Here to Stay"

vitaut — Thu, 29 Jan 2026 22:21:17 +0000

We did see build time improvements from deploying modules at Meta.

Astrological CPU Scheduler

vitaut — Wed, 28 Jan 2026 16:49:41 +0000

Article URL: https://github.com/zampierilucas/scx_horoscope

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

Points: 4

# Comments: 0

New comment by vitaut in "Banned C++ features in Chromium"

vitaut — Sun, 25 Jan 2026 15:32:15 +0000

The main effect of this is that some of the conversions between char and char8_t are inefficient.

Bitwise conversion of doubles using only FP multiplication and addition (2020)

vitaut — Sun, 25 Jan 2026 14:55:03 +0000

Article URL: https://dougallj.wordpress.com/2020/05/10/bitwise-conversion-of-doubles-using-only-floating-point-multiplication-and-addition/

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

Points: 57

# Comments: 6

New comment by vitaut in "Floating-Point Printing and Parsing Can Be Simple and Fast"

vitaut — Sat, 24 Jan 2026 15:50:39 +0000

I was impressed how fast the Rust folks adopted this! Kudos to David Tolnay and others.

New comment by vitaut in "Floating-Point Printing and Parsing Can Be Simple and Fast"

vitaut — Sat, 24 Jan 2026 15:49:55 +0000

Note that ~3-6ns is on modern desktop CPUs where extra few kB matter less. On microcontrollers it will be larger in absolute terms but I would expect the relative difference to also be moderate.

New comment by vitaut in "Floating-Point Printing and Parsing Can Be Simple and Fast"

vitaut — Sat, 24 Jan 2026 03:27:22 +0000

I don't have exact numbers but from measuring perf changes per commit it seemed that most improvements came from "printing" (e.g. switching to BCD and SIMD, branchless exponent output) and microoptimizations rather than algorithmic improvements.

New comment by vitaut in "Floating-Point Printing and Parsing Can Be Simple and Fast"

vitaut — Sat, 24 Jan 2026 03:24:34 +0000

If you compress the table (see my earlier comment) and use plain Schubfach then you can get really small binary size and decent perf. IIRC Dragonbox with the compressed table was ~30% slower which is a reasonable price to pay and still faster than most algorithms including Ryu.

New comment by vitaut in "Floating-Point Printing and Parsing Can Be Simple and Fast"

vitaut — Sat, 24 Jan 2026 03:20:15 +0000

It is possible to compress the table using the technique from Dragonbox (https://github.com/fmtlib/fmt/blob/8b8fccdad40decf68687ec038...) at the cost of some perf. It's on my TODO list for zmij.

New comment by vitaut in "Floating-Point Printing and Parsing Can Be Simple and Fast"

vitaut — Sat, 24 Jan 2026 03:18:01 +0000

Note that it has the same table of powers of 10: https://github.com/rsc/fpfmt/blob/main/bench/uscalec/pow10.h

New comment by vitaut in "Banned C++ features in Chromium"

vitaut — Fri, 23 Jan 2026 23:44:42 +0000

Somewhat notable is that `char8_t` is banned with very reasonable motivation that applies to most codebases:

> Use char and unprefixed character literals. Non-UTF-8 encodings are rare enough in Chromium that the value of distinguishing them at the type level is low, and char8_t* is not interconvertible with char* (what ~all Chromium, STL, and platform-specific APIs use), so using u8 prefixes would obligate us to insert casts everywhere. If you want to declare at a type level that a block of data is string-like and not an arbitrary binary blob, prefer std::string[_view] over char*.

New comment by vitaut in "Floating-Point Printing and Parsing Can Be Simple and Fast"

vitaut — Tue, 20 Jan 2026 14:10:04 +0000

The shortest double-to-string algorithm is basically Schubfach or, rather, it's variation Tejú Jaguá with digit output from Dragonbox. Schubfach is a beautiful algorithm: I implemented and wrote about it in https://vitaut.net/posts/2025/smallest-dtoa/. However, in terms of performance you can do much better nowadays. For example, https://github.com/vitaut/zmij does 1 instead of 2-3 costly 128x64-bit multiplications in the common case and has much more efficient digit output.

New comment by vitaut in "Is Rust faster than C?"

vitaut — Wed, 14 Jan 2026 23:17:32 +0000

Other examples are CTRE (https://github.com/hanickadot/compile-time-regular-expressio...) and format string compilation (https://fmt.dev/12.0/api/#compile-api). The closest C counterpart is re2c which also requires external tooling.

New comment by vitaut in "Is Rust faster than C?"

vitaut — Wed, 14 Jan 2026 23:15:03 +0000

It's easier to write faster code in a language with compile-time facilities such as C++ or Rust than in C. For example, doing this sort of platform-specific optimization in C is a nightmare https://github.com/vitaut/zmij/blob/91f07497a3f6e2fb3a9f999a... (likely impossible without an external pass to generate multiple lookup tables).

LLVM: The bad parts

vitaut — Mon, 12 Jan 2026 14:18:13 +0000

Article URL: https://www.npopov.com/2026/01/11/LLVM-The-bad-parts.html

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

Points: 389

# Comments: 77

New comment by vitaut in "Zmij: Faster floating point double-to-string conversion"

vitaut — Sat, 20 Dec 2025 05:00:15 +0000

Please note that there is some error in your port:

Error: roundtrip fail 4.9406564584124654e-324 -> '5.e-309' -> 4.9999999999999995e-309

Error: roundtrip fail 6.6302941479442929e-310 -> '6.6302941479443e-309' -> 6.6302941479442979e-309

Error: roundtrip fail -1.9153028533493997e-310 -> '-1.9153028533494e-309' -> -1.9153028533493997e-309

Error: roundtrip fail -2.5783653320086361e-312 -> '-2.57836533201e-309' -> -2.5783653320099997e-309