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

Re: Futures for C++11 at Facebook

#71

Post by georgerobinson » Sat, Jun 20, 2015, 12:24 PM UTC

> Threads are heavyweight — switching threads is inefficient, they have considerable memory overhead, and the OS will bog down if you make too many of them.

I didn't realize Posix threads were that inefficient?

First, I can't see why the memory overhead would be anything more than having a separate stack and entry in the TCB?

Second, can you not just save the stack pointer, program counter and registers into the TCB, then do the reverse when restoring a thread?

Finally, I wouldn't have thought you'd have too many TLB misses either, thus leaving the only expense being trapping to the kernel to switch between threads?

Can anyone explain?

Re: Futures for C++11 at Facebook

#72

Post by Matthias247 » Sat, Jun 20, 2015, 12:31 PM UTC

Aleman360 wrote: post #5

On a related note, MS has PPL on Windows: https://msdn.microsoft.com/en-us/library/dd492427.aspx Very similar to C#'s TPL. And VS2015 has experimental support for async/await in C++: http://blogs.msdn.com/b/vcblog/archive/2014/11/12/resumable-...

There's also pplx, which is a cross-plattfor implementation of ppl: http://microsoft.github.io/cpprestsdk/namespacepplx.html

Re: Futures for C++11 at Facebook

#73

Post by wcummings » Sat, Jun 20, 2015, 1:02 PM UTC

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.

Futures model async tasks, there's no reason you couldn't write an executor which uses OS threads using this framework (as they say in the post...)

>we provide a flexible mechanism for explicitly controlling the execution context of callbacks, using a simple Executor interface

Re: Futures for C++11 at Facebook

#74

Post by albinofrenchy » Sat, Jun 20, 2015, 1:15 PM UTC

georgerobinson wrote: post #71

> Threads are heavyweight — switching threads is inefficient, they have considerable memory overhead, and the OS will bog down if you make too many of them. I didn't realize Posix threads were that inefficient? First, I can't see why the memory overhead would be anything more than having a separate stack and entry in the TCB? Second, can you not just save the stack pointer, program counter and registers into the TCB,…

I can't explain completely, but check out http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma....

Relatively speaking, I don't think context switching is _that_ expensive compared to other areas you can focus on like doing smarter memory management.

I don't know exactly what they mean by threads having heavy memory overhead, but possibly they mean cache interference mentioned in that link? I'd be curious if there is an actual large memory chunk other than stack/scheduling details in play here too.

On modern cores too, there are a decent chunk of registers, including floating point registers. I've looked into timings before for embedded applications and the performance hit here isn't trivial when looking at interrupts and the like; but I'd be surprised if it was that overwhelming on servers.

Re: Futures for C++11 at Facebook

#75

Post by [deleted] » Sat, Jun 20, 2015, 1:23 PM UTC

georgerobinson wrote: post #71

> Threads are heavyweight — switching threads is inefficient, they have considerable memory overhead, and the OS will bog down if you make too many of them. I didn't realize Posix threads were that inefficient? First, I can't see why the memory overhead would be anything more than having a separate stack and entry in the TCB? Second, can you not just save the stack pointer, program counter and registers into the TCB,…

[deleted]

Re: Futures for C++11 at Facebook

#76

Post by masklinn » Sat, Jun 20, 2015, 1:24 PM UTC

yelnatz wrote: post #67

Aleman360 wrote: post #28

Earlier quoted context omitted.

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

That term actually makes the subject much more understandable.

It doesn't. "Task" has a notion of side-effect and no notion of yielding a value. Except a task can yield a value and have no side-effect.

Re: Futures for C++11 at Facebook

#77

Post by Serow225 » Sat, Jun 20, 2015, 2:34 PM UTC

electrum wrote: post #61

Serow225 wrote: post #45

Earlier quoted context omitted.

Since it seems like you're at FB, do you know if anyone's working on an equivalent of FB's Swift but for C++ instead of Java? If so, I'd love an email to express interest in such a thing. Thanks in advance!

Swift uses annotations (reflection) and generates bytecode on the fly. This fits much better with modern Java development practices and tooling than source code generation. Is such a thing feasible C++, especially in an idiomatic way? Or perhaps I am misunderstanding your question. To my knowledge, our C++ Thrift code is here: https://github.com/facebook/fbthrift (I work on Presto and occasionally Swift at Facebook,…

Thanks for the reply! You're right, I should have been more clear - the goal would be to autogenerate Thrift IDL at compile-time from annotations in our C++ source, to avoid having to hand write the IDL. So more in the sprit of Swift rather than a direct parallel.

Re: Futures for C++11 at Facebook

#78

Post by jmtulloss » Sat, Jun 20, 2015, 2:56 PM UTC

Cakez0r wrote: post #50

Aleman360 wrote: post #28

Earlier quoted context omitted.

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

and also the aptly named "TaskCompletionSource", which would be the promise equivalent (using Facebook's terminology)

That is, their terminology for this project. In facebook's Bolts framework for iOS they use Task and TaskCompletionSource https://github.com/BoltsFramework/Bolts-iOS#tasks

Re: Futures for C++11 at Facebook

#79

Post by jasdlfkja » Sat, Jun 20, 2015, 3:26 PM UTC

Names go against C++ convention, should be. Future => future makeFuture => make_future

Re: Futures for C++11 at Facebook

#80

Post by TheMagicHorsey » Sat, Jun 20, 2015, 3:31 PM UTC

This is quite nice. I still wish C++11 would add some CSP style channels into the core language, with appropriate elegant syntax (maybe they could steal Go's syntax for channels).

I'm sure there is a good performance reason they haven't done this yet. I don't know enough about the design of programming languages to know all the complexities involved. I'm just idly wishing.