httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: svn commit: r1026668 - /httpd/httpd/trunk/modules/proxy/mod_proxy.h
Date Sat, 23 Oct 2010 21:28:43 GMT
On Sat, Oct 23, 2010 at 5:13 PM, Graham Leggett <minfrin@sharp.fm> wrote:
> On 23 Oct 2010, at 10:24 PM, Jeff Trawick wrote:
>
>>>> No; this is a dis-optimization.  You have added int-bitmath cpu cycles
>>>> to a simple int test, without gaining any storage.  Huh?
>>>
>>> Are you sure?
>>>
>>> I would expect a compiler optimiser to do the most appropriate thing, and
>>> it
>>> gets us out of the habit of allocating an int or a char every time we
>>> need a
>>> boolean flag.
>>
>> It can't reorder fields, and pointers and integers need to be on
>> "natural" boundaries for performance (or even outright functionality
>> on some platforms).  So there will be padding after the bit.
>>
>> Some Intel ABI spec would show alignment requirements for a notable
>> example platform, absent of any packing pragmas.
>
> I was referring specifically to the "int-bitmath cpu cycles". Any data size
> smaller than the bus width involves an AND at least, just to isolate the
> byte or int. It's been a while since I was doing pure assembly, but would be
> surprised if this was slower.

I dunno about any load-bit instructions...  Seems like the bit field
always has an extra step compared with the int for the platforms where
I have a laughable recollection of assembly.

But these bit fields are only for merging logic, right?  Hardly a
performance concern, even with htaccess compared with stat and all
that.

(It is nicer to have the is-set flag next to the related field, but I
guess that's nothing to lose sleep over.)

Mime
View raw message