Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

codemines.blogspot.com

Post reply on HN
Print view View original

111–120 of 129 posts

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

#111

Post by mannykannot »

jcelerier wrote: post #103
ajross wrote: post #10

Earlier quoted context omitted.

> spinlocks for performance critical code (mutexes are slow). Gah, no. Userspace spinlocks are the deepest of voodoo and something to be used only by people who know exactly what they are doing and would have no difficulty writing "traditional" threaded code in a C/C++ environment. Among other problems: what happens when the thread holding the spinlock gets preempted and something else runs on the core? How can you p…

> Gah, no. Userspace spinlocks are the deepest of voodoo and something to be used only by people who know exactly what they are doing and would have no difficulty writing "traditional" threaded code in a C/C++ environment. If you ever used pthread_mutex with glibc then you use spinlocks without knowing it. The implementation spins for some time before going for a full kernel mutex.

I think the warning is directed against rolling your own spinlocks without careful consideration, including a realistic evaluation of whether you know every issue involved in doing so.

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

#112

Post by marcosdumay »

andreasgonewild wrote: post #79
marcosdumay wrote: post #68

Earlier quoted context omitted.

Select is a kernel level interface. I don't know how it's implemented at the kernel, but there is no technical reason why it can't follow from an interruption to an array index and a file descriptor without ever passing through a list. Besides, how do you block in user space when there is nothing to read?

Are you saying they are allocating a separate file-descriptor for each channel just to be able to select? I guess you could do that if you wanted to but it's far from the first thing I would try. I remember reading an article on golang about select and having to traverse the list, but I don't really have the motivation to dig deeper right now. Looping with unblocking reads is plenty fast enough though. As for waiting…

Well, select is well known for not scaling well so AFAIK it may very well use a list. What I'm saying is that kernel code can be much more performant than anything you may create on userland because you have access to the interruptions. And that code would be "magic" in the sense that you really can't replace it with a library.

In fact pinging condition-variables after a channel successfully is read is a much more expensive emulation of that same behavior. I'm curious if the Linux kernel actually exports something like that.

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

#113

Post by iainmerrick »

pjmlp wrote: post #94
iainmerrick wrote: post #84

Earlier quoted context omitted.

Really? That's disappointing. Good old bad old NDK strikes again. I really don't understand why Google doesn't seem interested in fixing it.

They are fixing it, but NDK team seems to be a very small team, from the commits and gitHub issues. https://android.googlesource.com/platform/ndk/+/master/docs/... You can already use clang 5.0 on the NDK, so even early C++17 support is possible. I don't know about TLS support. The NDK is only there for high performance graphics (vulkan), realtime áudio, SIMD and bringing native libraries from other platforms. So app…

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.

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

#114

Post by pjmlp »

iainmerrick wrote: post #113
pjmlp wrote: post #94

Earlier quoted context omitted.

They are fixing it, but NDK team seems to be a very small team, from the commits and gitHub issues. https://android.googlesource.com/platform/ndk/+/master/docs/... You can already use clang 5.0 on the NDK, so even early C++17 support is possible. I don't know about TLS support. The NDK is only there for high performance graphics (vulkan), realtime áudio, SIMD and bringing native libraries from other platforms. So app…

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 just would like they would provide better tooling to call framework APIs instead of forcing everyone to write JNI wrappers by themselves.

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

#115

Post by asveikau »

pjmlp wrote: post #92
asveikau wrote: post #53

Earlier quoted context omitted.

I think android ndk still barfs on c++11 tls and the earlier language extensions that came before it like __thread. It's not uncommon to be working with language implementations that are missing things like that. (I remember MS's version of it produced binaries that would not run on XP - maybe less important today but I had a run-in with that circa 2009.)

I don't know about TLS, but NDK is already using clang 5.0 and my code is C++14.

Yes I know they have recent clang. But does tls work? Last I knew, no.

Note clang is not the only variable here. You need support from the dynamic linker.

Edit: some googling suggests they may have added this support last year with some caveats.

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

#116

Post by asveikau »

bluejekyll wrote: post #96
asveikau wrote: post #52

Earlier quoted context omitted.

> you have to declare the synchronization semantics for every global when you do. (That is, they have to be read only, or thread local, or atomic, or protected by a lock.) That doesn't sound like it helps you determine which one of those is appropriate. So it seems rather like a system that will lead to unexpected bottlenecks when you parallelize. (Somebody deep inside the stack arbitrarily decided locking was the mo…

> a system that will lead to unexpected bottlenecks when you parallelize This is a funny comment. You are implying that performance is of higher value than correctness. Speed without correctness is dangerous, and leads to significant bugs, especially when you're talking about concurrent modification of state across threads. I'll take correct and need to improve performance over incorrect and fast where the cost of tr…

Let's not equivocate here. Threads don't exist merely as a fun exercise to introduce more interesting bugs. They are for performance. If you don't care about that I may advise to stay away from threads.

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

#117

Post by gardnr »

shaklee3 wrote: post #38
devwastaken wrote: post #24

Earlier quoted context omitted.

The thing I see glanced over a lot in multithreading is the actual implimentation of messaging people are talking about. What is being used to actually just 'send' messages to the main thread while the sender thread continues on? I know qt has slots and signals, but I haven't found a good native method that does something like that if I wanted to for example use an std::future and also receive messages back that can…

If you use dpdk it has some of the fastest (if not the fastest) ring implementation available.

In case anyone else is wondering a "ring" is a queue data structure which provides a different set of trade-offs. The documentation specifically compares it to a linked list:

    The advantages of this data structure over a linked list queue are as follows:

    * Faster; only requires a single Compare-And-Swap instruction of sizeof(void *) instead of several double-Compare-And-Swap instructions.
    * Simpler than a full lockless queue.
    * Adapted to bulk enqueue/dequeue operations. As pointers  are stored in a table, a dequeue of several objects will not produce as many cache misses as in a linked queue. Also, a bulk dequeue of many objects does not cost more than a dequeue of a simple object.

    The disadvantages:

    * Size is fixed
    * Having many rings costs more in terms of memory than a linked list queue. An empty ring contains at least N pointers.
http://dpdk.org/doc/guides/prog_guide/ring_lib.html

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

#118

Post by whatidonteven »

jcelerier wrote: post #103
ajross wrote: post #10

Earlier quoted context omitted.

> spinlocks for performance critical code (mutexes are slow). Gah, no. Userspace spinlocks are the deepest of voodoo and something to be used only by people who know exactly what they are doing and would have no difficulty writing "traditional" threaded code in a C/C++ environment. Among other problems: what happens when the thread holding the spinlock gets preempted and something else runs on the core? How can you p…

> Gah, no. Userspace spinlocks are the deepest of voodoo and something to be used only by people who know exactly what they are doing and would have no difficulty writing "traditional" threaded code in a C/C++ environment. If you ever used pthread_mutex with glibc then you use spinlocks without knowing it. The implementation spins for some time before going for a full kernel mutex.

There's a bit of a terminology confusion here. When they say "spinlock", most people mean a pure spinlock that spins forever until it succeeds.

"Mutex" on the other hand might have a fast-path that spins a few times before inserting the thread onto a wait list.

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

#119

Post by CyberDildonics »

agumonkey wrote: post #27
nemoniac wrote: post #21

Earlier quoted context omitted.

So, functional programming then?

I'm tired of thinking this in my head but - skimming through doug lea concurrency articles: FP - thread safe C: pure functions, shared nothing: FP - comment above: FP at what point will people start to call it what it is ?

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 share nothing then your communication is done by copying. This is not a magic bullet and isn't an option for many scenarios. If you do shared state for join parallelism you can cover other scenarios, but now you are sharing data.

Atomics are very fast and work very well when they line up with the problem at hand. Then again, you are creating some sort of data structure that is made to have its state shared.

If the problem was so easy to solve, it wouldn't be nearly as much a problem. Handwaving with 'just use FP' is naive and is more of a way for people to feel that they have the answer should anyone ask the question, but reality will quickly catch up.

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

#120

Post by agumonkey »

CyberDildonics wrote: post #119
agumonkey wrote: post #27

Earlier quoted context omitted.

I'm tired of thinking this in my head but - skimming through doug lea concurrency articles: FP - thread safe C: pure functions, shared nothing: FP - comment above: FP at what point will people start to call it what it is ?

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.
Post reply on HN