3 ms·

Some of that would depend upon how much the work can be localized per processor, since there are multiple caches with multiple CPUs. But, yes, I very much wond

Some of that would depend upon how much the work can be localized per processor, since there are multiple caches with multiple CPUs. But, yes, I very much wonder as well. "you can't write memcached in Java" http://roboprogs.com/devel/2010.12.html http://roboprogs.com/devel/2010.12.html Or can you??? (efficiently, given the right JVM?)

cagatayk 16y ago
The linked article is naive as to GC algorithms used in current Java VM's. These go to a lot of trouble to avoid tracing or scanning the heap. Card marking (http://www.ibm.com/developerworks/java/library/j-jtp11253/#2.0 http://www.ibm.com/developerworks/java/library/j-jtp11253/#2...) is one way to avoid this cost. As to building something like memcached, you can use native memory directly using direct byte buffers in Java; this is essentially what Terracota BigMemory (http://www.terracotta.org/bigmemory http://www.terracotta.org/bigmemory) does.
- Roboprog 16y ago
  At some point, I am going to have to experiment with the java command line options and redo my string whacking benchmark program. Still, I can't help but think that while these refinements limit the trips made wandering about the heap, there still are a good number of times when all of those gigabytes of pages still have to be marched through CPU caches displacing active work to check on things that haven't changed status. Perhaps with enough cores, some of them are simply left alone that vast majority of the time to do productive work with data in cache. I'd like to see some measurements of this, and how the effectiveness is affected by worker threads vs CPU cores available, as well as how many background GC threads there are. Data, anybody??? At any rate, the defaults for Java are slower than those for Perl when doing many string operations on a single thread. Measurements: http://roboprogs.com/devel/2009.12.html http://roboprogs.com/devel/2009.12.html. I have since rerun these tests on a 6 core AMD, with largely similar results. Of course, when doing threads or fork, the comparison breaks down as these constructs are implemented so differently between these languages, to say the least.
kjetil 16y ago
There are plenty of "distributed hash table" solutions for Java, some are at least as old as memcached. It's true that large heaps (multiple GBs) can cause long GC pause times (which is one of the problems Azul tried to solve). This can be mitigated by simply running more cache servers with smaller heaps.

cagatayk 16y ago

The linked article is naive as to GC algorithms used in current Java VM's. These go to a lot of trouble to avoid tracing or scanning the heap. Card marking (http://www.ibm.com/developerworks/java/library/j-jtp11253/#2.0 http://www.ibm.com/developerworks/java/library/j-jtp11253/#2...) is one way to avoid this cost. As to building something like memcached, you can use native memory directly using direct byte buffers in Java; this is essentially what Terracota BigMemory (http://www.terracotta.org/bigmemory http://www.terracotta.org/bigmemory) does.

Roboprog 16y ago
At some point, I am going to have to experiment with the java command line options and redo my string whacking benchmark program. Still, I can't help but think that while these refinements limit the trips made wandering about the heap, there still are a good number of times when all of those gigabytes of pages still have to be marched through CPU caches displacing active work to check on things that haven't changed status. Perhaps with enough cores, some of them are simply left alone that vast majority of the time to do productive work with data in cache. I'd like to see some measurements of this, and how the effectiveness is affected by worker threads vs CPU cores available, as well as how many background GC threads there are. Data, anybody??? At any rate, the defaults for Java are slower than those for Perl when doing many string operations on a single thread. Measurements: http://roboprogs.com/devel/2009.12.html http://roboprogs.com/devel/2009.12.html. I have since rerun these tests on a 6 core AMD, with largely similar results. Of course, when doing threads or fork, the comparison breaks down as these constructs are implemented so differently between these languages, to say the least.

kjetil 16y ago

There are plenty of "distributed hash table" solutions for Java, some are at least as old as memcached. It's true that large heaps (multiple GBs) can cause long GC pause times (which is one of the problems Azul tried to solve). This can be mitigated by simply running more cache servers with smaller heaps.