On 17 Sep 2008, [EMAIL PROTECTED] wrote:

> Isn't this a bit absurd? Maybe I'm missing something but all I can see
> is that your code adds these two optimizations:
>
>       32 - variable -> const
>       hashcode >> variable -> hashcode >> const

The hashcode is also used in the inline function RT_READ_SLOT.  I
added the asserts to protect against error on my part in this
implementation.  They can be removed if there are no reported
problems.  However, I was also unsure whether the URN lookups are
supported?  The splitting of the URN case is also a fairly large gain.
For a non-URN lookups, there is only one branch (if versus if/else).
Non-URN seems to be the most common form of query; this test can be
moved to the caller which can be constant over the node iteration.  A
call through a function pointer is not usually that big a hit (there
was a function call to a fixed address already).  Not having a has_urn
variable also seems to decrease register pressure.  The code size is
very small compared to the 2-256k tables.

Try objdump -S qrp.o to see the code size difference between
qrp_can_route_default and the macro code.  For cases like
'qrp_can_route_16', shifts are not always needed as 32/16/8 bit
manipulation can accomplish some of the work.  The 'qrp_can_route_16'
is the most common case in any runs I have observed.  Also not the
frame addressing [on x86 like -0x15(%epb)].  In the macro version,
most variables are in registers.

Regarding the temperature, I do not take it to be completely accurate.
However, all three temperature sensors have decrease by similar
amount.  Eight degrees is significant.  If it were two or three
degrees it would not be; I realize they are not high precision
instruments.  The clock frequency reported by 'powertop' would also
have be out (and gprof, etc).  I am looking into disabling the
frequency switching to get more accurate numbers via vmstat and top.

However, it is still beneficial to know if it performs better on PPC,
etc.

Sorry about the C++ comments.  Emacs did that automatically.

Regards,
Bill Pringlemeir.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

Reply via email to