5 ms·

You're claiming that (a) Java is better at multicore than C++; and (b) Java has been displacing C++; and (c) that the former is due to the latter. I haven't hea

by 10ren 18y ago

You're claiming that (a) Java is better at multicore than C++; and (b) Java has been displacing C++; and (c) that the former is due to the latter. I haven't heard this idea before. Can you elaborate please? Threading the locks have been integrated into Java from the beginning, with every object having a monitor and functions like wait() and notify(), and a synchronized keyword. These are nice, and do help, but they don't solve the problem. I've heard that Java fixed up some problems with these in version 1.5 or 1.6, but haven't looked at the details. My understanding is that none of the imperative languages are very good at multicore. Erlang is said to be effective at it (because of pure message passing); and some people claim FP will help because it overcomes the problem of shared state by making it immutable (while this is true, I'm not convinced it's particularly helpful in large projects, in practice). So I'm interested in your reasoning.

benreesman 18y ago
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.

by 10ren 18y ago

benreesman 18y ago

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.