Re:Zero-cost futures in Rust
by SideburnsOfDoom on Thursday August 11, 2016 @05:17PM
(#12271613)
Put it this way:
Cost of a branch misprediction is 10s of cpu cycles. (1) Measured in gigahertz (10^9 cycles per second).
Time to turn around a web request is, if you're very lucky and have done the work, mainly about getting a value from an in-memory cache at multiple milliseconds (2). That's 1 / (10^3) seconds.
If you're not lucky, 10s or 100s of milliseconds to generate the response.
It seems that the second duration is best case around 10^6 times longer. I would not sweat the first one.
1) http://stackoverflow.com/a/289860/5599 2) http://synsem.com/MCD_Redis_EMS/
Contrary to popular belief, not all C++ programs (or rust FWIW) are web servers serving HTTP requests over the Internet.
Re:Zero-cost futures in Rust
by SideburnsOfDoom on Thursday August 11, 2016 @05:27PM
(#12271671)
Yep, that's why I'm asking about the use-cases in the grandparent comment.
As an example, many real-time systems are often a giant ball of messy asynchronous code and state machines. Futures can help with that, although lately I have found that somtimes the best, cleanest, way to implement a state machine is to make it explicit.
How much do you attribute that to the benefit of creating a high barrier to entry for modifying that code? Could this be summarized as: code that inexperienced devs can't understand, stays performant because they can't figure out how to change it?
Edit: spelling