httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Theory on recent Phoronix benchmark?
Date Tue, 05 Apr 2011 21:58:51 GMT
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


Mime
View raw message