4 ms·

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 (htt

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.

4 ms·

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 (htt

by cagatayk 16y ago

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.