Re: Fixed length data types issue - Mailing list pgsql-hackers

From Kevin Brown
Subject Re: Fixed length data types issue
Date
Msg-id 20060911042204.GE11514@filer
Whole thread Raw
In response to Re: Fixed length data types issue  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fixed length data types issue
List pgsql-hackers
Tom Lane wrote:
> (does anyone know the cost of ntohl() on modern
> Intel CPUs?)

I wrote a simple test program to determine this:

#include <arpa/inet.h>

int main (int argc, char *argv[]) {       unsigned long i;       uint32_t a;
       a = 0;       for (i = 0 ; i < 4000000000L ; ++i) {
#ifdef CALL_NTOHL               a = ntohl(i);
#endif       }       return a;
}


I have a system with an Athlon 64 3200+ (2.0 GHz) running in 64-bit
mode, another one with the same processor running in 32-bit mode, a a
third running a Pentium 4 1.5 GHz processor, and a fourth running a
pair of 2.8 GHz Xeons in hyperthreading mode.

I compiled the test program on the 32-bit systems with the -std=c9x
option so that the constant would be treated as unsigned.  Other than
that, the compilation method I used was identical: no optimization,
since it would skip the loop entirely in the version without the
ntohl() call.  I compiled it both with and without defining
CALL_NTOHL, and measured the difference in billed CPU seconds.

Based on the above, on both Athlon 64 systems, each ntohl() invocation
and assignment takes 1.04 nanoseconds to complete (I presume the
assignment is to a register, but I'd have to examine the assembly to
know for sure).  On the 1.5 GHz P4 system, each iteration takes 8.49
nanoseconds.  And on the 2.8 GHz Xeon system, each iteration takes
5.01 nanoseconds.


That seems reasonably fast to me...




-- 
Kevin Brown                          kevin@sysexperts.com


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] contrib uninstall script fixes
Next
From: Jeremy Drake
Date:
Subject: Re: Fixed length data types issue