That's an interesting point. The reason this peaked my interest is it isn't really in line with my last JVM benchmarking (granted some time ago). Performance degradation was a factor in particular when I didn't increase the heap size a little, but I've not seen this level of degradation. Having enjoyed the pleasure of 16-32bit thunking when I "got" to write an OS/2 device driver a good bit back, I rather like your theory for that. I wrote the Phoronix dude(ette/s) and if (he/she/it/they) don't reply I'll take a crack at it on 11.04.
Thanks, Andy On Tue, Apr 5, 2011 at 5:58 PM, William A. Rowe Jr. <[email protected]>wrote: > On 4/5/2011 3:52 PM, Stefan Fritsch wrote: > > On Tuesday 05 April 2011, Andrew Oliver wrote: > >> That is just the thing. Other things that should have been > >> similarly affected in the benchmark were not. Take a gander if > >> you would at some of the rest of that article... > > > > HTTPD uses lots of pointers when handling per-dir and per-module > > configuration data. I agree with Bill that the 2x size increase in > > pointers is likely a major performance factor. Maybe the other > > workloads don't use so many pointers. They don't have a java benchmark > > AFAICS, which should be similarily affected. > > > > Or it is just bad luck that with 32bit, HTTPD's working set just fits > > into some cache while with 64bit, it doesn't. It would be interesting > > to see the same comparison with 2.3.11. There were some optimizations > > which should reduce CPU cache usage. > > I'm actually not entirely clear if they were using 64 bit executables > throughout all of their tests for x86_64, in fact I suspect they weren't. > > If it is a 32 bit binary (and CC="gcc -m64" ./configure might be needed > here depending on gcc defaults), there is a painful threshold of thunking > 32 bit calls into the 64 bit kernel. > > But one interesting thing about their 'stellar' performance stats on the > x86_64 is that most apps are powered by assembler and very specific word > size manipulations, e.g. the sound waveform or image bitmap memory > footprint > doesn't change, and openssl gets to employ SSE2 (post i686) manipulations. > > Finally, I'd expect no advantage from system caching for httpd moving > from 2GB to 24GB of ram, which > >
