3 ms·

All I see is 1% performance improvement for 1,000% complexity increase.

by sbf501 4y ago

chrisseaton 4y ago
But a very small team of compiler people take on the extra complexity so a huge team of users can get the performance improvement.
kazinator 4y ago
Not boxing floating-point values on the heap can be a big deal. I retrofitted NaN boxing into a production Lisp implementation literally in one evening and morning, with minimal impact to all the existing code in the implementation that is built around the pointer tagging scheme that existed for 13 years. It's nicely delimited with #if CONFIG_NAN_BOXING. Accumulator-incrementing loop on pointer tagging: This is the TXR Lisp interactive listener of TXR 281. Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet. 1> (compile-toplevel '(for ((i 1.0) (acc 0.0)) ((< i 100000000.0) acc) ((inc acc i) (inc i)))) #<sys:vm-desc: 188b8d0> 2> (pprof [*1]) malloc bytes: 0 gc heap bytes: 6399999936 total: 6399999936 milliseconds: 5860 4.99999995e15 NaN Boxing: This is the TXR Lisp interactive listener of TXR 281. Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet. 1> (compile-toplevel '(for ((i 1.0) (acc 0.0)) ((< i 100000000.0) acc) ((inc acc i) (inc i)))) #<sys:vm-desc: 24b7dc0> 2> (pprof [*1]) malloc bytes: 0 gc heap bytes: 0 total: 0 milliseconds: 4079 4.99999995e15 The speedup is 43.6% here. 3> (/ (- 5860 4079) 4079) 0.436626624172591 This is not native code. The difference would be more emphasized in native code. However, code that doesn't do floating-point calculation (or even some that does) will see a small performance penalty due to the more complex access to all values. That is a bummer. At least users can choose; if you don't care about floating-point, build it with pointer tagging.
- sbf501 4y ago
  I was referring to the table on their original web page. The last two rows are a 1.5% performance difference.
userbinator 4y ago
It's more like 10% (https://news.ycombinator.com/item?id=32874523 https://news.ycombinator.com/item?id=32874523)
dzaima 4y ago
Besides the people already saying the performance difference is much larger, the memory savings are quite important too, and I'd argue the complexity isn't that bad either. Sure, NaN-boxing isn't completely trivial, but it's largely a one-time cost for quite a small part of the definition of your vm. It even brings some nice things with it, like being able to use regular 64-bit routines to work with tagged data, and having a single nice 64-bit int to copy&paste around while using a debugger, whereas otherwise you'd have a whole struct.

All I see is 1% performance improvement for 1,000% complexity increase.

by sbf501 4y ago

All I see is 1% performance improvement for 1,000% complexity increase.

But a very small team of compiler people take on the extra complexity so a huge team of users can get the performance improvement.

kazinator 4y ago

Not boxing floating-point values on the heap can be a big deal. I retrofitted NaN boxing into a production Lisp implementation literally in one evening and morning, with minimal impact to all the existing code in the implementation that is built around the pointer tagging scheme that existed for 13 years. It's nicely delimited with #if CONFIG_NAN_BOXING. Accumulator-incrementing loop on pointer tagging: This is the TXR Lisp interactive listener of TXR 281. Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet. 1> (compile-toplevel '(for ((i 1.0) (acc 0.0)) ((< i 100000000.0) acc) ((inc acc i) (inc i)))) #<sys:vm-desc: 188b8d0> 2> (pprof [*1]) malloc bytes: 0 gc heap bytes: 6399999936 total: 6399999936 milliseconds: 5860 4.99999995e15 NaN Boxing: This is the TXR Lisp interactive listener of TXR 281. Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet. 1> (compile-toplevel '(for ((i 1.0) (acc 0.0)) ((< i 100000000.0) acc) ((inc acc i) (inc i)))) #<sys:vm-desc: 24b7dc0> 2> (pprof [*1]) malloc bytes: 0 gc heap bytes: 0 total: 0 milliseconds: 4079 4.99999995e15 The speedup is 43.6% here. 3> (/ (- 5860 4079) 4079) 0.436626624172591 This is not native code. The difference would be more emphasized in native code. However, code that doesn't do floating-point calculation (or even some that does) will see a small performance penalty due to the more complex access to all values. That is a bummer. At least users can choose; if you don't care about floating-point, build it with pointer tagging.

sbf501 4y ago
I was referring to the table on their original web page. The last two rows are a 1.5% performance difference.

userbinator 4y ago

It's more like 10% (https://news.ycombinator.com/item?id=32874523 https://news.ycombinator.com/item?id=32874523)

dzaima 4y ago

Besides the people already saying the performance difference is much larger, the memory savings are quite important too, and I'd argue the complexity isn't that bad either. Sure, NaN-boxing isn't completely trivial, but it's largely a one-time cost for quite a small part of the definition of your vm. It even brings some nice things with it, like being able to use regular 64-bit routines to work with tagged data, and having a single nice 64-bit int to copy&paste around while using a debugger, whereas otherwise you'd have a whole struct.