5 ms·

As limited as the threading model of synchronization is, it can be used to fairly easily write programs that scale up to some reasonable number of threads (10-1

As limited as the threading model of synchronization is, it can be used to fairly easily write programs that scale up to some reasonable number of threads (10-100). This is less to do with the convenience of having keywords like 'synchronized' and more to with the fact that modern Java has a proper memory model. The C++ people are trying to put together a memory model, but it's not here yet and there's some doubt about the ability to integrate it successfully with existing (pthreads etc.) code. Without a memory model you're going to be writing more code that is less correct at a substantially higher cost. If you're interested in this google for a Google Tech Talk by Josh Bloch on 'Java Memory Model'. This basically comes down to my ability to get at architecture specific stuff (CAS, fencing) in a platform independent way and have it work. Cliff Click has a really neat tech talk on writing a lock-free hash table in Java, don't bother trying to write it in C++. Ultimately we will need a better model for concurrency, which will be some combination of functional programming and lightweight processes (actors). Erlang/Scala/Clojure/Haskell are in the right neighborhood (maybe Gambit Scheme, don't know much about it), but Erlang and Haskell are really hard to teach to mere mortals like myself. I don't know enough category theory to understand 'hello world' in Haskell, but I can write Scala and Clojure programs that work (and leverage my existing investment in the JVM). edit: i left off something imporant. if anything saves imperative programming it will be transactional memory, which is exremely hard. hardware TM and code written for TM are in a chicken-and-egg situation. the answer is hybrid hardware/software TM and the sun guys are way ahead on this too.

arohner 18y ago
if anything saves imperative programming it will be transactional memory, which is exremely hard. hardware TM and code written for TM are in a chicken-and-egg situation. the answer is hybrid hardware/software TM and the sun guys are way ahead on this too. What's interesting is STM is only hard in imperative languages. It's relatively straightforward in Clojure and Haskell. See http://enfranchisedmind.com/blog/posts/the-problem-with-stm-your-languages-still-suck/ http://enfranchisedmind.com/blog/posts/the-problem-with-stm-...
- benreesman 18y ago
  Awesome article! Also check out ch. 24 of Beautiful Code, which is about implementing STM in Haskell. <brag>Now seems like a reasonable chance to brag that Doug Crockford signed my copy of BC the other day! God I'm such a geek.</brag>
- zzygan 18y ago
  Also recently there was a very interesting article in Communications of the ACM about STM vs HTM and the problems with both in a general sense. http://delivery.acm.org/10.1145/1410000/1400228/p40-cascaval.html?key1=1400228&key2=9950411421&coll=ACM&dl=ACM&CFID=33768312&CFTOKEN=64607598 http://delivery.acm.org/10.1145/1410000/1400228/p40-cascaval... Edit: Prettier version http://mags.acm.org/communications/200811/?folio=40&CFID=33768312&CFTOKEN=64607598 http://mags.acm.org/communications/200811/?folio=40&CFID...
10ren 18y ago
Thanks, I appreciate that. You've addressed (a), but what of (b) and (c)? Or is it more that sensible people would prefer C++ for multicore (who are largely recognizable as being sensible people by the mere fact that they hold this view.) Incidentally, I have an entertaining alternative theory, that silicon will becomes specialized in the way that organs in the body are (and firms), perhaps mimicking the architecture of large programs which have intercommunication patterns that are established and predictable. A games examples: a Lua CPU, a physics CPU, an AI CPU. The Enterprise is even more ripe for this, as they have been trying to separate architectural components with SOA (which is a form of concurrency). It doesn't seem to have gone well, but something may have been learned there. Another example of large-scale concurrency is the internet: perhaps replicate a google server farm on a chip? These ideas are a bit horrific, because they are horribly inefficient through standardizing on large scale components, so we lose the opportunity to optimize between them. But they work.
- benreesman 18y ago
  My assertion that Java is displacing C++ is admittedly very anecdotal, this is a difficult claim to discuss in rigorous terms. My claim is based on personal experience, the experience of colleagues, and "some people I've talked to on the interwebs", so by all means take with a grain of salt and do some research yourself if you're skeptical. For any long-running process the JIT is going to turn your Java (Clojure, Scala, ...) into extremely well-optimized machine code. In fact, the amount of knowledge that the JIT has about the actual run time behavior of the software allows it to do better optimizations than you ever could by hand in certain situations (an ever-growing number of situations). GC is another point, the HotSpot GC is arguably faster at allocating small, short-lived objects than malloc is. It is reeeaaaaallllyyy good these days, probably the best GC that you'll find in production just about anywhere these days. The thing is a monster. And the new one, the G1 collector, was sent from the future by SkyNet to kill John Conner. Add to this the fact that you can easily exploit common multiprocessing patterns (thread pool, consumer/producer) with almost no code, and that advanced multiprocessing code can be written in a platform independent way, and it's a pretty small subset of applications that still make sense to write in C++. Add to all of that the fact that even Java (let alone all the other amazing JVM languages) are orders of magnitude more productive than C++ for your programming staff, and the set of situations in which it makes sense to use C++ rather than the JVM is looking pretty tiny. Oh and then there's portability. C++ isn't even portable across compilers (versions of the same compiler!), and for all the early trouble with Java portability, it really is write-once-run-anywhere now. Really.
scott_s 18y ago
Why do you say "don't bother trying to write it in C++" referring to Click's lock-free hash table? His algorithms are based on compare-and-swap, which is the same operation I'd use to implement a lock-free data structure in C/C++.
- benreesman 18y ago
  The algorithm requires a fence too. I found remarks at one point by Cliff about why he couldn't do it in c++, if I find them again I will post them here. edit: on iPhone so I can't post the link, but the comments section of cliff's blog has a discussion about java vs. C for this data structure. summary: maybe you could do it but it would be tricky and extremely non-portable, I.e. almost definitely not worth it. hope I didn't overstate, wasn't trying to dismissive (need to watch my language online).
  - scott_s 18y ago
    It is possible to make it portable, you just need a portable API for synchronization. That's not too hard to do - take a look at atomic operations in the Linux kernel. Click was probably talking about the fact that Java has a consistent and defined memory model. C and C++ have no such memory model, but there always is one. It's just the memory model of the underlying architecture - which is sometimes extremely subtle.
jerf 18y ago
"but Erlang and Haskell are really hard to teach to mere mortals like myself." No, just Haskell. Learning Erlang is roughly on par with learning Javascript well; it may involve a couple of new paradigms (like Javascript imposes event-oriented programming and prototypes, which may be new to you), but the language itself is straightforward. Different, but straightforward. The concurrency may blow your mind, but the syntax and basic mode of operation is unlikely to do so, in contrast to Haskell. Don't be scared away from Erlang.
- benreesman 18y ago
  I definitely intend to give Erlang another try soon, if for no other reason than because I really want to hack on RabbitMQ. Last time I tried I failed though.
- alphazero 18y ago
  Agreed. Erlang is actually very friendly. (Much more so than Clojure, for that matter ..)

arohner 18y ago

if anything saves imperative programming it will be transactional memory, which is exremely hard. hardware TM and code written for TM are in a chicken-and-egg situation. the answer is hybrid hardware/software TM and the sun guys are way ahead on this too. What's interesting is STM is only hard in imperative languages. It's relatively straightforward in Clojure and Haskell. See http://enfranchisedmind.com/blog/posts/the-problem-with-stm-your-languages-still-suck/ http://enfranchisedmind.com/blog/posts/the-problem-with-stm-...

benreesman 18y ago
Awesome article! Also check out ch. 24 of Beautiful Code, which is about implementing STM in Haskell. <brag>Now seems like a reasonable chance to brag that Doug Crockford signed my copy of BC the other day! God I'm such a geek.</brag>
zzygan 18y ago
Also recently there was a very interesting article in Communications of the ACM about STM vs HTM and the problems with both in a general sense. http://delivery.acm.org/10.1145/1410000/1400228/p40-cascaval.html?key1=1400228&key2=9950411421&coll=ACM&dl=ACM&CFID=33768312&CFTOKEN=64607598 http://delivery.acm.org/10.1145/1410000/1400228/p40-cascaval... Edit: Prettier version http://mags.acm.org/communications/200811/?folio=40&CFID=33768312&CFTOKEN=64607598 http://mags.acm.org/communications/200811/?folio=40&CFID...

10ren 18y ago

Thanks, I appreciate that. You've addressed (a), but what of (b) and (c)? Or is it more that sensible people would prefer C++ for multicore (who are largely recognizable as being sensible people by the mere fact that they hold this view.) Incidentally, I have an entertaining alternative theory, that silicon will becomes specialized in the way that organs in the body are (and firms), perhaps mimicking the architecture of large programs which have intercommunication patterns that are established and predictable. A games examples: a Lua CPU, a physics CPU, an AI CPU. The Enterprise is even more ripe for this, as they have been trying to separate architectural components with SOA (which is a form of concurrency). It doesn't seem to have gone well, but something may have been learned there. Another example of large-scale concurrency is the internet: perhaps replicate a google server farm on a chip? These ideas are a bit horrific, because they are horribly inefficient through standardizing on large scale components, so we lose the opportunity to optimize between them. But they work.

benreesman 18y ago
My assertion that Java is displacing C++ is admittedly very anecdotal, this is a difficult claim to discuss in rigorous terms. My claim is based on personal experience, the experience of colleagues, and "some people I've talked to on the interwebs", so by all means take with a grain of salt and do some research yourself if you're skeptical. For any long-running process the JIT is going to turn your Java (Clojure, Scala, ...) into extremely well-optimized machine code. In fact, the amount of knowledge that the JIT has about the actual run time behavior of the software allows it to do better optimizations than you ever could by hand in certain situations (an ever-growing number of situations). GC is another point, the HotSpot GC is arguably faster at allocating small, short-lived objects than malloc is. It is reeeaaaaallllyyy good these days, probably the best GC that you'll find in production just about anywhere these days. The thing is a monster. And the new one, the G1 collector, was sent from the future by SkyNet to kill John Conner. Add to this the fact that you can easily exploit common multiprocessing patterns (thread pool, consumer/producer) with almost no code, and that advanced multiprocessing code can be written in a platform independent way, and it's a pretty small subset of applications that still make sense to write in C++. Add to all of that the fact that even Java (let alone all the other amazing JVM languages) are orders of magnitude more productive than C++ for your programming staff, and the set of situations in which it makes sense to use C++ rather than the JVM is looking pretty tiny. Oh and then there's portability. C++ isn't even portable across compilers (versions of the same compiler!), and for all the early trouble with Java portability, it really is write-once-run-anywhere now. Really.

scott_s 18y ago

Why do you say "don't bother trying to write it in C++" referring to Click's lock-free hash table? His algorithms are based on compare-and-swap, which is the same operation I'd use to implement a lock-free data structure in C/C++.

benreesman 18y ago
The algorithm requires a fence too. I found remarks at one point by Cliff about why he couldn't do it in c++, if I find them again I will post them here. edit: on iPhone so I can't post the link, but the comments section of cliff's blog has a discussion about java vs. C for this data structure. summary: maybe you could do it but it would be tricky and extremely non-portable, I.e. almost definitely not worth it. hope I didn't overstate, wasn't trying to dismissive (need to watch my language online).
- scott_s 18y ago
  It is possible to make it portable, you just need a portable API for synchronization. That's not too hard to do - take a look at atomic operations in the Linux kernel. Click was probably talking about the fact that Java has a consistent and defined memory model. C and C++ have no such memory model, but there always is one. It's just the memory model of the underlying architecture - which is sometimes extremely subtle.

jerf 18y ago

"but Erlang and Haskell are really hard to teach to mere mortals like myself." No, just Haskell. Learning Erlang is roughly on par with learning Javascript well; it may involve a couple of new paradigms (like Javascript imposes event-oriented programming and prototypes, which may be new to you), but the language itself is straightforward. Different, but straightforward. The concurrency may blow your mind, but the syntax and basic mode of operation is unlikely to do so, in contrast to Haskell. Don't be scared away from Erlang.

benreesman 18y ago
I definitely intend to give Erlang another try soon, if for no other reason than because I really want to hack on RabbitMQ. Last time I tried I failed though.
alphazero 18y ago
Agreed. Erlang is actually very friendly. (Much more so than Clojure, for that matter ..)