This is cool, but I'm wondering
(1) Why doesn't V8, whose whole point is performance, lay out memory in an optimal way?
(2) Will Nova need to also implement all of V8's other optimizations, to see if Nova's layout makes any significant difference?
(1) Why doesn't V8, whose whole point is performance, lay out memory in an optimal way?
(2) Will Nova need to also implement all of V8's other optimizations, to see if Nova's layout makes any significant difference?
The heap vector "trick" is basically impossible, I believe. It wouldn't be a refactoring so much as it would be a complete rewrite of the engine. The entirety of V8 assumes it deals in pointers, and all of that would need to change to using indexes instead. I will eat my hat if they do it. Without heap vectors they can still split object data apart using pointer-keyed hash maps, so maybe they could take advantage of some of the ideas still.
V8 does offer ways to run code without optimisations, which we can use for a more apples-to-apples comparison. The most important optimisation that Nova really needs before any big performance comparisons become meaningful is property access inline caching, which requires implementing object shapes.
I'd say that once object shapes are done, then limited performance comparisons can probably be made, especially if V8's JIT is disabled.
If V8 copied all of Nova AND adopted Rust, I might consider laying Nova to rest and going into V8 development. But I'd probably also be really angry at V8 just taking all of Nova's good ideas and peddling them off as their own without crediting Nova. So probably I'd still keep developing Nova while stewing in my anger and inability to do anything about it :)
I hope Nova can be a spark that ignites the JavaScript world into a bit of a renaissance with some of its ideas, but the point is not to burn bright and burn out. The point is to burn bright and stay lit.
Who knows, maybe they'd even give you credit (while still taking the idea)?
And if the program accesses a set of objects in different orders at different times, there is no one optimal layout.
I did ask Lars Bak once if they spent a lot of time thinking about cache usage and organizing objects in memory to take best advantage of it and, if I recall correctly, his answer was basically "no". They definitely think about it terms of packing objects into small amounts of memory. But in a dynamically typed language like JavaScript where every property is a reference to some other object elsewhere in memory, using the cache well is just profoundly hard.
Hell, it's hard even in Java where at least you do know the set of fields any given class has.
Certain design choices made for other reasons may conflict.