3 ms·
A remake of those old p2p file-sharing networks but instead of advertising file availability nodes would advertise availability of particularly well-optimized v
by usrusr 5y ago
A remake of those old p2p file-sharing networks but instead of advertising file availability nodes would advertise availability of particularly well-optimized versions of the basic code unit every node already has?
Sounds ridiculous and even a bit pointless because you'd still need the capacity to run lots of compilations along not-yet-optimized code during startup (e.g. after redeploy), but with cluster size being highly variable and usage cost more and more replacing capacity cost as the primary concern this might actually work out. For very large clusters and certain workloads. And the more you modulate cluster size depending on demand, the bigger the benefit from reusing across nodes. Sure, it would be more straight-forward to just clone a fully baked node, but there's a nice peace of mind in not having to decide between cold start and hot clone, just leave it to the self-organization mechanism.
- chrisseaton 5y agoI think you're a bit confused about the basic idea. > every node already has? No every node doesn't already have it. That's the point. One node computes on behalf of everyone. > you'd still need the capacity to run lots of compilations along not-yet-optimized code during startup Well no - nodes also have interpreters so they don't wait. And it's not any slower for someone else to run the compilation on your behalf - the result comes in the same time. And most code doesn't change between redeploys so doesn't need to be recompiled.
- usrusr 5y agoEvery node already has the bytecode and the interpreter, or more likely fast, superficial JIT without expensive optimisation. But that's slow, so when you need to serve a given load you'll need more nodes before they have settled into a hot optimization state. Regarding unchanged code after redeploy, usage patterns might change a lot even for code that hasn't changed at all. With profile guided optimizations (which I'd expect to be more norm than exception for something like azul), this would mean that nominally unchanged code could suffer hard from running in a version optimized for a different calling environment (the previous version of the application). In the grand scheme of things, I'd assume that this would be the main benefit and goal of a JIT outcome sharing mechanism like this: allowing nodes to cooperate by each profiling a different part of their shared code, kind of like becoming experts in a tiny specialization, and then sharing that expertise.