Hell is a multi-threaded C++ program (2006) • Hacker News Board

Re: Hell is a multi-threaded C++ program (2006)

#121

Post by lookACamel » Tue, Sep 05, 2017, 3:03 AM UTC

hellofunk wrote: post #3

Unless you use this excellent library: https://actor-framework.org/

Note that this blog post was written in 2006.

The other major model for multi-threading is known as message-passing multiprocessing. Unless you're familiar with the Occam or Erlang programming languages, you might not have encountered this model for concurrency before.

Two popular variants of the message-passing model are "Communicating Sequential Processes" and the "Actor model".

Why would you want to learn about this alternative model, when Pthreads have clearly won the battle for the hearts and minds of the programming public? Well, besides the sheer joy of learning something new, you might develop a different way of looking at problems, that'll help you top make better use of the tools that you do use regularly. In addition, as I'll explain in Part II of this rant, there's good reason to believe that message-passing concurrency is going to be coming back in a big way in the near future.

Re: Hell is a multi-threaded C++ program (2006)

#122

Post by mbessey » Tue, Sep 05, 2017, 5:08 AM UTC

I really need to do an update of that article, with C++ std::thread, libDispatch, and some of the other stuff that's come along in the intervening 11 years. I still spend a lot of time tracking down other people's threading bugs (in an entirely-different codebase, these days) though.

Re: Hell is a multi-threaded C++ program (2006)

#123

Post by mbessey » Tue, Sep 05, 2017, 6:09 AM UTC

agumonkey wrote: post #120

CyberDildonics wrote: post #119

Earlier quoted context omitted.

Because thinking that functional programming is going to solve all your problems is simple, easy, and wrong. Anyone who has written high performance software knows this. First, garbage collection without locks is extremely exotic, so likely all your memory allocations and deallocations will lock and with typical functional programming you will be doing a lot of them. Then you can get into what you mean by FP - if you…

What about immutability and shared structure. You can stream your computation in a way to avoid copying, avoid locking (unless you have to synchronize on a change). Persistent DS are rarely mentioned, I only know Demaine's course.

Yeah, immutability was something that got kind of glossed over in that article (I'm the author). And Functional Programming was a lot less mainstream then. Maybe I should do an update.

Re: Hell is a multi-threaded C++ program (2006)

#124

Post by gpderetta » Tue, Sep 05, 2017, 10:46 AM UTC

Skunkleton wrote: post #58

comex wrote: post #55

Earlier quoted context omitted.

On all architectures, releasing a mutex requires at least a branch (to see if you need to wake up sleeping threads) that you don’t need with a pure spinlock. But if you don’t have a guarantee the lock owner won’t be preempted, well, spinning for a whole timeslot is quite a bit more expensive…

Spin locks are a tough sell in a preemptable context. Say you have two processes that share some memory location. They both briefly access it for a very short time, so you protect it with a spin lock. Well, what happens in the case when one of the threads is preempted while holding the lock? The other thread would try to aquire it, and just spin for its entire timeslot. No bueno. When you call spin_lock() in the kern…

You are not wrong in general but note that there are ways to disable preemption in userspace in practice, be it SCHED_FIFO[1] or isolcpu with cpu pinning.

[1] you better be careful with spinlocks and priorities here as you can livelock forever.

Re: Hell is a multi-threaded C++ program (2006)

#125

Post by CyberDildonics » Tue, Sep 05, 2017, 1:58 PM UTC

agumonkey wrote: post #120

CyberDildonics wrote: post #119

Earlier quoted context omitted.

Because thinking that functional programming is going to solve all your problems is simple, easy, and wrong. Anyone who has written high performance software knows this. First, garbage collection without locks is extremely exotic, so likely all your memory allocations and deallocations will lock and with typical functional programming you will be doing a lot of them. Then you can get into what you mean by FP - if you…

What about immutability and shared structure. You can stream your computation in a way to avoid copying, avoid locking (unless you have to synchronize on a change). Persistent DS are rarely mentioned, I only know Demaine's course.

> What about immutability and shared structure > You can stream your computation in a way to avoid copying

Where is the synchronization in this scenario? You either have to decide how to split up the read only memory to different threads (fork join) or you have one thread make copies of pieces and 'send' them to other threads somehow. Arguably these are the same thing. This is one technique, but again, it doesn't cover every scenario.

I don't know if calling it 'immutability' changes anything.

> avoid locking (unless you have to synchronize on a change)

Synchronizing on changes is the whole problem, you can't just hand wave it away as if it is a niche scenario. Anyone can create a program that has threads read memory and do computations. If you can modify the memory in place with no overlap between threads, even better. These however are the real niche scenarios, because the threads eventually need to do something with their results whether it's sending to video memory, writing to disk, or preparing data for another iteration or state in the pipeline. Then you have synchronization and that's the whole issue.

Re: Hell is a multi-threaded C++ program (2006)

#126

Post by agumonkey » Tue, Sep 05, 2017, 3:34 PM UTC

CyberDildonics wrote: post #125

agumonkey wrote: post #120

Earlier quoted context omitted.

What about immutability and shared structure. You can stream your computation in a way to avoid copying, avoid locking (unless you have to synchronize on a change). Persistent DS are rarely mentioned, I only know Demaine's course.

> What about immutability and shared structure > You can stream your computation in a way to avoid copying Where is the synchronization in this scenario? You either have to decide how to split up the read only memory to different threads (fork join) or you have one thread make copies of pieces and 'send' them to other threads somehow. Arguably these are the same thing. This is one technique, but again, it doesn't cov…

What I meant is that a FP language could go its own way and let the side effects happen.. well on the side. Sure you will have to communicate computations to other systems but you can have these part clearly segregated and synchronized.

I must confess, I have no experience there, it's just years of reading about and writing functional code and seeing a potential trail here.

Re: Hell is a multi-threaded C++ program (2006)

#127

Post by agumonkey » Tue, Sep 05, 2017, 3:35 PM UTC

mbessey wrote: post #123

agumonkey wrote: post #120

Earlier quoted context omitted.

What about immutability and shared structure. You can stream your computation in a way to avoid copying, avoid locking (unless you have to synchronize on a change). Persistent DS are rarely mentioned, I only know Demaine's course.

Yeah, immutability was something that got kind of glossed over in that article (I'm the author). And Functional Programming was a lot less mainstream then. Maybe I should do an update.

Well you're excused, 2006 was a really different world. FP was still alien and multithreading probably a lot less mainstream.

That said if you have new thoughts on the subject, please write them :)

Re: Hell is a multi-threaded C++ program (2006)

#128

Post by iainmerrick » Wed, Sep 06, 2017, 2:21 AM UTC

pjmlp wrote: post #114

iainmerrick wrote: post #113

Earlier quoted context omitted.

Yeah, it just seems like they have the resources to support a bigger NDK team if they cared to do so. There plenty of apps that could really use a well-supported NDK. Games and audio apps for a start.

Google released ARCore last week. "ARCore works with Java/OpenGL, Unity and Unreal and focuses on three things:" https://android-developers.googleblog.com/2017/08/arcore-aug... Which makes quite clear that even in AR, the role of the NDK is to support Java, Unity and Unreal applications, not to be used alone. I am fine with it, given the security issues with the native code so we should actually minimize its use, I j…

As a counter-example, they also just announced AAudio, and that's a C API: https://developer.android.com/ndk/guides/audio/aaudio/aaudio...

So they are still using C as a lingua franca for some low-level parts of the system. But without putting much effort into improving the C toolchain.

I'm not very familiar with Unreal but I understand it's a C++ library, so it seems like that would benefit from a solid C++ toolchain too.

Re: Hell is a multi-threaded C++ program (2006)

#129

Post by CyberDildonics » Wed, Sep 06, 2017, 11:18 AM UTC

agumonkey wrote: post #126

CyberDildonics wrote: post #125

Earlier quoted context omitted.

> What about immutability and shared structure > You can stream your computation in a way to avoid copying Where is the synchronization in this scenario? You either have to decide how to split up the read only memory to different threads (fork join) or you have one thread make copies of pieces and 'send' them to other threads somehow. Arguably these are the same thing. This is one technique, but again, it doesn't cov…

What I meant is that a FP language could go its own way and let the side effects happen.. well on the side. Sure you will have to communicate computations to other systems but you can have these part clearly segregated and synchronized. I must confess, I have no experience there, it's just years of reading about and writing functional code and seeing a potential trail here.

How exactly does functional programming solve this problem though? How does it differ from imperative programming?