3 ms·

I think you are overstating the problems writing multithreaded code a little here. Yes, it's a lot harder than single-threaded code, yes you need to know what y

by w0utert 13y ago

I think you are overstating the problems writing multithreaded code a little here. Yes, it's a lot harder than single-threaded code, yes you need to know what you are doing, yes you need to carefully design your code to enable efficient and safe multithreading, and no you don't get speed for free. All true, but you are making it sound as if writing multithreaded code is rocket science, some kind of mad skill only the top 0.5% programmers can handle. It's not that bad you know... If you're a half-way decent programmer and don't litter your single-threaded code with globals, shared memory and functions with side-effects, like you shouldn't anyway, parallelizing it after the fact to at least is usually pretty straightforward even. Maybe not optimal, but safe, and faster than single-core on multi-core hardware.

fulafel 13y ago
Sure, you can write the code if you're a half-way decent programmer. But getting it to work correctly and bug free in presence of nondeterministic behaviour and races is in the domain of the very small minority, when you're talking about large code bases. I'm betting the minority is less than 0.5%. Half way decent C++ programmers aren't many % of programmers, and people who can make a reliably working parallelized do-over for a nontrivial code base are maybe 1% of that. I'll say 0.05% max.
- w0utert 13y ago
  The challenge is to design your code in a way that either makes it impossible to end up with race conditions or non-deterministic behavior, or if at least limit the number of possible points-of-failure. This requires a good understanding in what coding styles and data structures to avoid or pay extra attention to, but if you're aware of the pitfalls, it's actually not all that difficult. Just make sure your workers don't share any state, collect their outputs in a single thread-safe queue, use off the shelf components to represent threads, thread pools and locking mechanisms, be aware of things like multiple-read-single-write locks, and if you really can't avoid writes to shared state, only then start thinking about mutexes or semaphores. If you're smart about how you set up the code, more often than not you can get away with just some thread-safe queues. Take a look at Objective-C's block syntax and GCD for example, it makes maybe 90% of tasks suitable for multithreading dead easy. Your estimate only 0.05% of programmers could write reliable multithreaded code is extremely pessimistic, cynical even. I almost feel flattered, having written a fair amount of multithreaded code that works perfectly myself, but I most definitely would dare count me with the 0.05% top programmers or whatever. My estimate is that with proper preparation, at least 50% of all programmers could learn to write reliable multithreaded code, and the remaining 50% probably wouldn't have a use for it anyway.
  - fulafel 13y ago
    I was talking about the percentage of existing programmers with the abilities to pull it off. I'm sure more than 0.05% have the potential to learn it eventually, given enough time, motivation and opportunity. Like musicians & theremin!

by w0utert 13y ago

fulafel 13y ago

Sure, you can write the code if you're a half-way decent programmer. But getting it to work correctly and bug free in presence of nondeterministic behaviour and races is in the domain of the very small minority, when you're talking about large code bases. I'm betting the minority is less than 0.5%. Half way decent C++ programmers aren't many % of programmers, and people who can make a reliably working parallelized do-over for a nontrivial code base are maybe 1% of that. I'll say 0.05% max.

w0utert 13y ago
The challenge is to design your code in a way that either makes it impossible to end up with race conditions or non-deterministic behavior, or if at least limit the number of possible points-of-failure. This requires a good understanding in what coding styles and data structures to avoid or pay extra attention to, but if you're aware of the pitfalls, it's actually not all that difficult. Just make sure your workers don't share any state, collect their outputs in a single thread-safe queue, use off the shelf components to represent threads, thread pools and locking mechanisms, be aware of things like multiple-read-single-write locks, and if you really can't avoid writes to shared state, only then start thinking about mutexes or semaphores. If you're smart about how you set up the code, more often than not you can get away with just some thread-safe queues. Take a look at Objective-C's block syntax and GCD for example, it makes maybe 90% of tasks suitable for multithreading dead easy. Your estimate only 0.05% of programmers could write reliable multithreaded code is extremely pessimistic, cynical even. I almost feel flattered, having written a fair amount of multithreaded code that works perfectly myself, but I most definitely would dare count me with the 0.05% top programmers or whatever. My estimate is that with proper preparation, at least 50% of all programmers could learn to write reliable multithreaded code, and the remaining 50% probably wouldn't have a use for it anyway.
- fulafel 13y ago
  I was talking about the percentage of existing programmers with the abilities to pull it off. I'm sure more than 0.05% have the potential to learn it eventually, given enough time, motivation and opportunity. Like musicians & theremin!