3 ms·

I'm curious what benchmarking / research you've done on how much difference it makes to use a compact value representation (like the NaN tagging used in Wren, o

I'm curious what benchmarking / research you've done on how much difference it makes to use a compact value representation (like the NaN tagging used in Wren, or using the low bits of a pointer to specify object type). Is it just a couple of percent perf improvement, or quite a large amount? Also, either with a "compact" representation (Wren) or a less compact one like Lox, have you tried storage small strings in the object itself (<= 7 bytes for a 64-bit object size, or <= 15 bytes for two 64-bit words), and how much difference would that make?

munificent 8y ago
> Is it just a couple of percent perf improvement, or quite a large amount? This is a really really hard question to answer with any generality. Especially when you talk about percentage of perf improvements, then the performance of the rest of the system directly impacts the gain you see from changing the value representation. At the time that I implemented it in Wren, using NaN tagging made about a 10% improvement in the handful of microbenchmarks I was using at the time, on my machine. You can toggle NaN tagging on and off with a #define, so it's worth checking the difference today on different benchmarks and on top of the other changes I've made to Wren since then. The last I checked, Wren spent a large fraction of time in instruction decoding and dispatch (not uncommon for a bytecode VM). In an interpreter where that's more efficient (because of a JIT, threaded code, superinstructions, peephole optimizations, etc.), the value representation will probably make a larger difference. > have you tried storage small strings in the object itself (<= 7 bytes for a 64-bit object size, or <= 15 bytes for two 64-bit words), and how much difference would that make? I haven't, though I've briefly toyed with it. With Wren, I'm trying really hard to keep the implementation small and simple, so I try to avoid special-case optimizations like this that add a lot of complexity. It might be worth it, but I'm not sure. It's a hard call to make. Each optimization or little feature on its own seems small, but when you add them all up, it can be the difference between an approachable, hackable codebase, and a big sprawling one.

munificent 8y ago

> Is it just a couple of percent perf improvement, or quite a large amount? This is a really really hard question to answer with any generality. Especially when you talk about percentage of perf improvements, then the performance of the rest of the system directly impacts the gain you see from changing the value representation. At the time that I implemented it in Wren, using NaN tagging made about a 10% improvement in the handful of microbenchmarks I was using at the time, on my machine. You can toggle NaN tagging on and off with a #define, so it's worth checking the difference today on different benchmarks and on top of the other changes I've made to Wren since then. The last I checked, Wren spent a large fraction of time in instruction decoding and dispatch (not uncommon for a bytecode VM). In an interpreter where that's more efficient (because of a JIT, threaded code, superinstructions, peephole optimizations, etc.), the value representation will probably make a larger difference. > have you tried storage small strings in the object itself (<= 7 bytes for a 64-bit object size, or <= 15 bytes for two 64-bit words), and how much difference would that make? I haven't, though I've briefly toyed with it. With Wren, I'm trying really hard to keep the implementation small and simple, so I try to avoid special-case optimizations like this that add a lot of complexity. It might be worth it, but I'm not sure. It's a hard call to make. Each optimization or little feature on its own seems small, but when you add them all up, it can be the difference between an approachable, hackable codebase, and a big sprawling one.