News for hackers. Stuff that matters.
Re:Zero-cost futures in Rust by gpderetta on Thursday August 11, 2016 @05:03PM (#12271514)
Virtual dispatch per se is not terribly slow, as long as the branch is predictable by the CPU. The problem is that virtual dispatch prevents the sort of aggressive inlining and interprocedural opimizatios that C++ compilers are known to do. C# and Java JITers get around that via runtime analysis and speculative inlining, but that is done at runtime and eats away some of the precious little time available for optimisations.

Edit: spelling

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/

Re:Zero-cost futures in Rust by gpderetta on Thursday August 11, 2016 @05:23PM (#12271648)
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.
Re:Zero-cost futures in Rust by gpderetta on Thursday August 11, 2016 @05:35PM (#12271732)
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.
Re:Zero-cost futures in Rust by haimez on Thursday August 11, 2016 @10:25PM (#12273066)
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?
Re:Zero-cost futures in Rust by gpderetta on Friday August 12, 2016 @09:39AM (#12275502)
None of the teams I've worked with had such a policy and certainly I wouldn't work in a team like that.