httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Oliver <acoli...@gmail.com>
Subject Re: Theory on recent Phoronix benchmark?
Date Wed, 06 Apr 2011 01:37:10 GMT
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. <wrowe@rowe-clan.net>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
>
>

Mime
View raw message