Hey Bob. Still a big fan of this project. Thank you!
This chapter introduces not only strings but the concept of more complex value types that use an auxiliary struct. There's an anecdote related to that which you might find amusing - and maybe a bit appalling.
In the implementation of perl, there's multiple kinds of integer value type in order to support it's complex implicit casting semantics and additional edge cases. To pick the least wonky, there's plain integer values, "IVs", and those which have a stringified representation of the int attached for caching the expensive conversion, "PVIVs". The former store the int in the primary value struct. The latter use an auxiliary struct with extra space.
Now, the reason for all this prep is that in order to make the two behave the same, and not introduce a lot of branches to low level code, perl always uses the indirect access to the integer value (essentially "x->aux.intval"). This works because for basic integer values, it initializes the aux pointer in the main struct to point to the right place in memory before the location of the main struct such that this access always points at the right slot of the main struct. Madness! So much fun!
Shenandoah, one of the GCs in Java uses a similar trick, each time there is an access to a field, instead of directly accessing to it, the VM access to a pointer at the top of the structure that point just to the address below itself, so each field is read using a double indirection. This allows the application to run when the GC move the objects (during the evacuation phase), because each time the GC relocate an object, it also changes the top pointer in the old region to reference the new region. The GC also rewrites the pointers inside the stacks by replacing the pointer to the old region by the value of the top pointer, so the pointers in the stack now reference the new region too.
Ah, and I'd always wanted to read up on that and never prioritized it. Thank you!
This might be a naive question, but how do you do all that redirection under concurrent accesses? Clearly that amount of rewiring isn't going to be atomic? Or am I misunderstand and the only change that needs to be atomic is the top-of-structure redirection?
The perl implementation is full of this sort of stuff. Some corners are hardly penetrable because of it. I'll be visiting the offices in MSN and KIR/SEA next week. Happy to rant over coffee or a drink some night if timing works out.
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?
> 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.
Here's the log I keep which tracks what I did every day I worked on it (except for a few months in the beginning when the project was still kind of nebulous):
You're welcome! I'm still planning to read the Rust book when I get some time. Other people who care about technical writing like you are an inspiration.
There are people who put out books for money, and I can see you are not one of them. I've really enjoyed the passion illustrated in your continually updated series.
They're pretty loosely-coupled. The bytecode VM part assumes you are familiar with the language itself, which is described in an introductory chapter [1]. It also assumes you're familiar with most of the basic structure of an interpreter and the concepts around parsing and stuff, since those are introduced when we do the tree-walk interpreter. If you know those already, you can probably skip straight to the bytecode VM. You can always consult earlier chapters if you get stuck.
No question, just a big thank you. I followed along the first half and wrote my own Lox using Python. I learned a ton about a domain I would never have and may never use professionally. But writing my own interpreter helped me understand Python and love the magic of programming all that much more.
Give it to someone more needy than me. When the book is done and I have the print edition out, the easiest way to say thanks is to buy a copy and/or write a nice review.
Hey Bob, I super love this series. Everyone I know who's into PL likes it, so great work :)
A little thing in your section about the different UTFs: I've heard UTF-16 is a lot better than UTF-8 for East Asian languages because pretty much all those codepoints are multibyte. I don't _necessarily_ think anything you wrote was invalid, but just FYI.
However, this is only the case if you have just a big blob of text and UTF-8 might be better if the east asian text is interspersed with ASCII characters. For example, HTML with east asian text often is smaller when encoded with UTF-8, because a significant portion of the content is HTML markup.
Right well again, if your average East Asian codepoint is 3 bytes in UTF-8, and your average markup codepoint is one byte, then as the percentage of markup in your corpus rises you'll grow asymptotically towards 1. But not all text contains markup ;) Consider any database storage for example, text in a game, e-books, visual novels. I guess anything that isn't the web or JSON is what I'm saying -- which is a lot.
> Alas, if your language needs to run on or interoperate with the browser, the JVM, or the CLR, you might be stuck with [UTF-16]
And Windows. Win32 and COM APIs use UTF-16 natively, so if you want to avoid lots of conversions on Windows, UTF-16 is the way to go. Maybe the best solution would be an abstraction that lets you choose the internal string encoding at compile time.
Nothing like a paper or anything, but just kind of anecdotally I downloaded 西遊記 from Project Gutenberg [1] and measured it. In UTF-8 it's 2,236,564 bytes, in UTF-16 it's 1,554,998 bytes.
>>Don't get "voilà" confused with "viola". One means "there it is" and the other is a tiny string instrument. Yes, I did spend two hours drawing a viola just to mention that
Hi,
Why no rle encoded string length? You cannot access the string then directly, but you can handle arbitrary string lengths and still save a lot of space. inlined strings for short strings or interned strings for faster comparison and sort are also important types. ropes maybe also.
If you want to see strings implemented as immutable representations look to the unicon/icon vm representation. This has been in effective use for well over 30 years and has all sorts of nice properties.
Waves awkwardly, shuffles feet.