Byte counters reset at ~4GB

[Harti Brandt]

On Mon, 15 Mar 2004, Brooks Davis wrote:

BD>On Mon, Mar 15, 2004 at 07:48:21PM -0500, Mike Jakubik wrote:
BD>> Max Laier said:
BD>>
BD>> > Sure, you measure it ;) ... no, of course it is more expensive to update a
BD>> > 64bit counter on a 32bit arch, but the key (once again) is descision:
BD>> > While
BD>> > (almost) all of the pf counters are 64bit types you can configure it not
BD>> > to
BD>> > use the loginterface or whatsoever more. So it's up to you: You need 64bit
BD>> > counters? You shall have them! You need *fast* 64bit counters? AMD sells
BD>> > nice processors (they say)! ... you get the idea.
BD>>
BD>> Got it. In just curious though... realistically, how big of an impact on
BD>> performance is this on a modern CPU? Is it not simply the original 32bit
BD>> calculation x 2?
BD>
BD>No, you have to do overflow handling so that adds some to the cost.
BD>
BD>I was curious what the actual overhead was so I ran the following
BD>program with both uint32_t and uint64_t counters.  With 64-bit counters,
BD>it was a bit over four times slower on a the dual 2.2GHz Xeon (~2sec vs
BD>~8.4sec).  On a dual opteron, the 32-bit math had a slight edge, but
BD>not much.  Intestingly, runtime was longer then on the Xeon (~3.1s for
BD>32-bit and ~3.8 for 64-bit.)
BD>
BD>If you do this test, be sure not to use any optimizer flags or the whole
BD>loop gets optimized out.
BD>
BD>-- Brooks
BD>
BD>#include <stdio.h>
BD>#include <stdint.h>
BD>
BD>int
BD>main (int argc, char **argv)
BD>{
BD>	uint32_t j = 0;
BD>
BD>	for (j = 0; j < 1000000000; j++) {}
BD>	printf("%d\n", j);
BD>}

Isn't the actual problem the required atomicity? While on 32-bit
architectures you can increment a 32-bit value without taking a lock,
you need a lock to increment a 64-bit value.

harti