3 ms·

"While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C,

by bullen 6y ago

"While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only 12 times faster than C means you haven't started optimizing"." - Martin Fowler https://martinfowler.com/bliki/OOPSLA2005.html https://martinfowler.com/bliki/OOPSLA2005.html

fwip 6y ago
Go has both memory management and a quite performant garbage collector, as you probably know. Your article is from 2005, so I take it to mean that Java 6 was doing the interesting things you talk about - from my recollection, the go-to at that time was java.util.concurrent. (I haven't kept up with Java, so it could still be state-of-the-art.) https://www.sciencedirect.com/science/article/pii/S0167642305000663 https://www.sciencedirect.com/science/article/pii/S016764230... - this paper describes the implementation as "The heart of the framework is maintenance of queues of blocked threads, which are restricted here to FIFO queues." If you're not familiar, this is exactly what go channels are, just baked into the language rather than in the standard library.
- pjmlp 6y ago
  The major differences being that java.util.concurrent in Java 16 is a bit more powerful as the one in Java 6, Java doesn't have one single GC rather multiple vendor implementations to choose from, with virtual threads on the horizon. Additionally one benefit over Go, is that in Java (likewise in .NET), the scheduler algorithm is replaceable.
  - fwip 6y ago
    That's valid, I didn't mean to imply that Java was stuck in 2005. I'm having a hard time following the clues that bullen is trying to leave in order to divine their meaning, so I was trying to limit the scope.
- bullen 6y ago
  http://nil.csail.mit.edu/6.824/2016/notes/gomem.pdf http://nil.csail.mit.edu/6.824/2016/notes/gomem.pdf The more you downvote me the stronger I become! :D

by bullen 6y ago

fwip 6y ago

Go has both memory management and a quite performant garbage collector, as you probably know. Your article is from 2005, so I take it to mean that Java 6 was doing the interesting things you talk about - from my recollection, the go-to at that time was java.util.concurrent. (I haven't kept up with Java, so it could still be state-of-the-art.) https://www.sciencedirect.com/science/article/pii/S0167642305000663 https://www.sciencedirect.com/science/article/pii/S016764230... - this paper describes the implementation as "The heart of the framework is maintenance of queues of blocked threads, which are restricted here to FIFO queues." If you're not familiar, this is exactly what go channels are, just baked into the language rather than in the standard library.

pjmlp 6y ago
The major differences being that java.util.concurrent in Java 16 is a bit more powerful as the one in Java 6, Java doesn't have one single GC rather multiple vendor implementations to choose from, with virtual threads on the horizon. Additionally one benefit over Go, is that in Java (likewise in .NET), the scheduler algorithm is replaceable.
- fwip 6y ago
  That's valid, I didn't mean to imply that Java was stuck in 2005. I'm having a hard time following the clues that bullen is trying to leave in order to divine their meaning, so I was trying to limit the scope.
bullen 6y ago
http://nil.csail.mit.edu/6.824/2016/notes/gomem.pdf http://nil.csail.mit.edu/6.824/2016/notes/gomem.pdf The more you downvote me the stronger I become! :D