Futures for C++11 at Facebook • Hacker News Board

Re: Futures for C++11 at Facebook

#21

Post by mikeyk » Fri, Jun 19, 2015, 7:08 PM UTC

tangled wrote: post #8

I'd be interested in seeing why instagram didn't implement the suggested user service as a batch process that populated some KV store. Online evaluation is great for guaranteeing up-to-date results, but the tradeoff is that you now have to bring up and maintain a fairly critical production service. > The SU service fetches candidate accounts from various sources, such as your friends, accounts that you may be interes…

We've seen huge gains from making the system as realtime as possible. Consider a new user who hasn't followed anyone yet--each new follow is super helpful in informing the recommendation system.

Re: Futures for C++11 at Facebook

#22

Post by hatred » Fri, Jun 19, 2015, 7:10 PM UTC

fugalh wrote: post #9

hatred wrote: post #6

Can someone explain to me what does it add over http://www.boost.org/doc/libs/1_58_0/doc/html/thread/synchro... and pros/cons ? Thanks.

It is along the same lines as boost's futures implementation. We have a different mechanism for expressing thread management, born out of trial and error and Facebook engineer feedback. At the time we set out to write this boost futures were slow and buggy (1.53), and C++ standard monadic futures proposals were in very early stages (it now appears that there will be monadic futures in C++17). I do not know if boost f…

thanks for the explanation.

Re: Futures for C++11 at Facebook

#23

Post by obstinate » Fri, Jun 19, 2015, 7:11 PM UTC

pron wrote: post #16

obstinate wrote: post #2

I'm totally on board with futures, IF your application needs to scale to the point that blocking, threaded computation is infeasible. However, I honestly don't think that's the case for most folk. Blocking, direct-call computation is way simpler than futures.

Or use fibers (lightweight threads) and enjoy the best of both worlds: simple, blocking code with the scalable performance of async.

Fibers are fine as an idea. But all the C++ implementations I'm aware of require the programmer to mark up their code for cooperative scheduling. That's a non-starter for me.

Re: Futures for C++11 at Facebook

#24

Post by santaclaus » Fri, Jun 19, 2015, 7:14 PM UTC

vvnraman wrote: post #11

Excellent library and writeup !! This is very similar to HPX, the general purpose C++ runtime system for parallel and distributed applications by the Stellar Group - https://github.com/STEllAR-GROUP/hpx . I recently saw the excellent video presentation by Hartmut Kaiser on this https://www.youtube.com/watch?v=5xyztU__yys and a lot of concepts in folly futures are quite similar. However the most striking thing in HPX…

Kaiser also gave a pretty good keynote at Meeting C++, "Plain Threads are the GOTO of todays computing:" https://www.youtube.com/watch?v=4OCUEgSNIAY

Same talk maybe?

Re: Futures for C++11 at Facebook

#25

Post by wcummings » Fri, Jun 19, 2015, 7:15 PM UTC

millstone wrote: post #19

I've never programmed seriously with futures, and I'm a little apprehensive. For example, let's say I type the string "123". If there's a future / promise / async whatever anywhere, we risk processing the characters out of order. We may not catch that in testing, because it's usually fast enough that it comes out in the right order. > It is more efficient to make service A asynchronous, meaning that while B is busy c…

Are you asking "how do you do concurrent programming?" These problems aren't specific to promises.

Re: Futures for C++11 at Facebook

#26

Post by gohrt » Fri, Jun 19, 2015, 7:34 PM UTC

forrestthewoods wrote: post #17

chadaustin wrote: post #10

Rats, the terminology is backwards from the E/JavaScript promise/future distinction: https://en.wikipedia.org/wiki/Futures_and_promises#Read-only... There's been a push to standardize "Promise" to be the read-only side and "Future" to mean the resolver/promise pair, but Folly Futures use the opposite convention. Agreeing on terminology is hard. :) Edit: I think it's fine that Folly adopted the C++11 convention. I'm j…

I fucking hate the terms future and promise so god damn much. The names are beyond stupid. They're just confusing as hell. No one can read the names and make an educated guess as to which is which it what they do. The following is my favorite interview response of all time. Q: what's a quaternion? A: I don't know... But I bet it has four parts. Genius! An honest answer followed by a wise educated guess. Now, what's a…

A promise what you get when you can't get a result immediately: a promise to deliver a result later. "Future" is nonsense terminology.

Re: Futures for C++11 at Facebook

#27

Post by lfowles » Fri, Jun 19, 2015, 7:40 PM UTC

millstone wrote: post #19

I've never programmed seriously with futures, and I'm a little apprehensive. For example, let's say I type the string "123". If there's a future / promise / async whatever anywhere, we risk processing the characters out of order. We may not catch that in testing, because it's usually fast enough that it comes out in the right order. > It is more efficient to make service A asynchronous, meaning that while B is busy c…

> What if the first request is "set sharing permissions to private" and the second request is "upload this compromising photo?" Obviously it would be bad to process these out of order. How is this handled?

Upgrade the user wetware. Have them wait until confirmation that sharing permissions are now private before beginning upload.

Re: Futures for C++11 at Facebook

#28

Post by Aleman360 » Fri, Jun 19, 2015, 7:43 PM UTC

forrestthewoods wrote: post #17

chadaustin wrote: post #10

Rats, the terminology is backwards from the E/JavaScript promise/future distinction: https://en.wikipedia.org/wiki/Futures_and_promises#Read-only... There's been a push to standardize "Promise" to be the read-only side and "Future" to mean the resolver/promise pair, but Folly Futures use the opposite convention. Agreeing on terminology is hard. :) Edit: I think it's fine that Folly adopted the C++11 convention. I'm j…

I fucking hate the terms future and promise so god damn much. The names are beyond stupid. They're just confusing as hell. No one can read the names and make an educated guess as to which is which it what they do. The following is my favorite interview response of all time. Q: what's a quaternion? A: I don't know... But I bet it has four parts. Genius! An honest answer followed by a wise educated guess. Now, what's a…

Microsoft uses "Task". I like that way better.

Re: Futures for C++11 at Facebook

#29

Post by obstinate » Fri, Jun 19, 2015, 7:54 PM UTC

forrestthewoods wrote: post #17

chadaustin wrote: post #10

Rats, the terminology is backwards from the E/JavaScript promise/future distinction: https://en.wikipedia.org/wiki/Futures_and_promises#Read-only... There's been a push to standardize "Promise" to be the read-only side and "Future" to mean the resolver/promise pair, but Folly Futures use the opposite convention. Agreeing on terminology is hard. :) Edit: I think it's fine that Folly adopted the C++11 convention. I'm j…

I fucking hate the terms future and promise so god damn much. The names are beyond stupid. They're just confusing as hell. No one can read the names and make an educated guess as to which is which it what they do. The following is my favorite interview response of all time. Q: what's a quaternion? A: I don't know... But I bet it has four parts. Genius! An honest answer followed by a wise educated guess. Now, what's a…

Make a header file for your project that exports the Facebook headers and typedefs the names to something that makes sense. I like source and sink. Producer and consumer are fine too. Emitter and receiver are fine as well. And writer/reader. If you do this, then you only have to make sense of which side is which once, then forever after you'll have sensible names for the things (at least in your project).

The important thing is to always treat the name the same. Generally, I treat types as nouns. So an emitter is something that emits something. It's passed to the routine that consumes the data. On the other hand, a consumer consumes, so it's passed to a routine that emits something for consumption.

Re: Futures for C++11 at Facebook

#30

Post by obstinate » Fri, Jun 19, 2015, 7:58 PM UTC

gohrt wrote: post #26

forrestthewoods wrote: post #17

Earlier quoted context omitted.

I fucking hate the terms future and promise so god damn much. The names are beyond stupid. They're just confusing as hell. No one can read the names and make an educated guess as to which is which it what they do. The following is my favorite interview response of all time. Q: what's a quaternion? A: I don't know... But I bet it has four parts. Genius! An honest answer followed by a wise educated guess. Now, what's a…

A promise what you get when you can't get a result immediately: a promise to deliver a result later. "Future" is nonsense terminology.

You could as easily say that a promise is a promise you've made to produce a piece of data in the future. That's the problem with the term -- it's equally easy to interpret it as the consumption or production side of the equation. As an exercise in skeuomorphism, it's poor, since just like in real life, you can equally give and receive a promise.