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

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.