Bytecode binary format gets decoded on every function call?

[icefoxen]

I was noodling around in the code and discovered that, as far as I can tell, the bytecode interpreter decodes the binary instructions to Instruction when a function is called, not when the bytecode is loaded. This means that every time a function is called it has to re-decode all the instructions. On a benchmark program (fib implemented the dumb way) on Linux AMD64, it spent about 15% of the time in ketos::bytecode::Instruction::decode(), the highest of any function as recorded by perf.

I haven't successfully made it decode the bytecode and store the result only once yet, but once I manage I'll post comparative benchmarks here.

[murarth]

Yes, bytecode is decoded during execution. Storing bytecode in function objects just seemed like the obvious thing to do at the time. I hadn't considered that instruction decoding might incur a significant performance penalty.

I'd be very interested in seeing the results of your benchmarks, when you get a working implementation.

[murarth]

I did some poking around and it turns out that changing from [u8] to [Instruction] touches a lot of different parts of the code and several public APIs.

I'd still like to merge this change if it improves performance, but a big, public change like this, I'd rather write myself. I'll try to have an implementation done very soon.

[icefoxen]

No problem, I was just mystified why you bothered turning your instructions into a packed-byte format in the first place since you seem to just decode it again immediately aftwarwards.

And yeah, my experiments similarly involved touching lots of different places. Still digging into the codebase and figuring out how everything works, so.

Very neat project, btw. :-) I like the feeling of 21st-century-Common-Lisp it has about it.

[murarth]

It was my first attempt at making a language compiler/interpreter, so a lot of stuff was done either because that's the way some other project was doing it or because "Ooh, that looks like fun."

The bytecode format borrows a lot from GNU CLISP because it had decent online documentation and I didn't know a whole lot about Lisp before starting this project.

[icefoxen]

Good reasons. :D

[murarth]

So, I've put together an implementation (on branch decode-once), but it actually runs slower in the benchmarks. (Granted, there are only two non-compile benchmarks.)

On master:

test bench_factorial_100 ... bench:     104,043 ns/iter (+/- 6,546)
test bench_fib_100       ... bench:      85,719 ns/iter (+/- 5,403)

On decode-once:

test bench_factorial_100 ... bench:     109,705 ns/iter (+/- 6,794)
test bench_fib_100       ... bench:      93,642 ns/iter (+/- 5,882)