| ▲ | andai 7 days ago | |||||||||||||||||||||||||||||||||||||||||||||||||
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? | ||||||||||||||||||||||||||||||||||||||||||||||||||
| ▲ | aapoalas 7 days ago | parent | next [-] | |||||||||||||||||||||||||||||||||||||||||||||||||
V8 could probably implement the backing object "trick" with some trouble. I'm half-hoping that Nova will show it to be worth their while and that they will eventually do it. It will be a major refactoring of the engine, however. 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||
| ▲ | munificent 7 days ago | parent | prev | next [-] | |||||||||||||||||||||||||||||||||||||||||||||||||
Optimal memory layout isn't something you can know in advance. The optimal way to lay out objects in memory is exactly in the order that they will be accessed, but the runtime doesn't know that until after the user program has accessed them. 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| ▲ | liontwist 7 days ago | parent | prev [-] | |||||||||||||||||||||||||||||||||||||||||||||||||
1 it takes time and effort to make major architectural changes. Certain design choices made for other reasons may conflict. | ||||||||||||||||||||||||||||||||||||||||||||||||||