4 ms·
Runtime system knows approximate latency to intended recipient Actor of a message, e.g., this core, nearby core, nearby chip on the package, nearby chip in the
by ProfHewitt 7y ago
Runtime system knows approximate latency to intended recipient Actor of a message, e.g., this core, nearby core, nearby chip on the package, nearby chip in the same server, nearby server in the same rack, nearby server in the same datacenter, another datacenter, another IoT, etc. However, Actors can dynamically move and so the answer can change over time.
- mgummelt 7y agoLatency differences aren't just a difference in degree. They're a difference in kind. Some interactions have to be sufficiently fast or they shouldn't happen at all. A runtime that minimizes global latency guarantees isn't sufficient. You also need to guarantee that certain individual Actor interactions are sufficiently fast, which is only possible through colocation. You could add a colocation constraint to your Actor scheduler, but now you're pretty much back to where you started. And latency is only one of the problems. Partial failure is another. It's often convenient for authors of colocated actors to assume fate sharing. If they can't, they have to handle a much wider set of failure modes.
- ProfHewitt 7y agoDo you think that the "difference in kind" should be frozen in application source code? I agree that latency needs to be carefully controlled. But the software engineering can be complex!
- mgummelt 7y agoOften, yes. Parameterization adds complexity, so for interactions I know must always be colocated, it makes sense to hard code the provisioning of a local actor.
- ProfHewitt 7y agoGood luck finding all the places that various kinds of colocation have been hard-coded, e.g., same core, nearby core, same chip, same package, same rack, same datacenter, etc.