Happened to note that linux implements the posix clock_gettime(3) interface, so I fixed 7.7 to use that for gethrtime and gethrvtime. And lo and behold, it now has nice nanosecond resolution with thread local accounting for cpu time. :) (At least with a fairly modern linux - ymmv.)
For those that don't know, this has been miserable before. The best function supported by glibc has been times(2) which has lousy resolution (10 ms!) and isn't thread local. That has rendered gethrvtime and gauge practically useless.
So I was thinking of adding a nanosecond variety of gauge {...} too. It's not strictly necessary; the current gauge in a pike compiled with standard 32 bit floats can just barely cope with the time for the shortest possible pike snippet:
sprintf ("%e %.9f", gauge {}, 1 + gauge {});
Result: "7.210e-07 1.000000715"
A gauge that returns integer nanoseconds could however be useful if one adds together a lot of short intervals, and it's very easy to add. In lack of better ideas, I was thinking of calling it "hr_gauge". What do you think? Note that the name would become a new keyword.
Hm. Maybe it's time to start to compile Pike per default to 64-bit int and double floats? :)
Since pointers on many (most?) systems today are 64-bit, I think it would be natural to at least start using double as default float type, since the svalue struct will be 16 byte (!) anyway.
[config.info]
pointer size........ 8 bytes svalue size......... 16 bytes (2+2+8)
Is there any benefit of using 32-bit integers on 64-bit systems?
Most _new_ systems are probably 64 bit now, but people aren't really that upgrade crazy. None of my three boxen at home are 64 bit, for instance, and I'm still quite happy with them.
On 64 bit systems both floats and ints are 64 bit too, since the space is already wasted there anyway. It's been like that for a long time. Doesn't it work for you?
Oh, that's nice. I wouldn't know, I've been compiling with that manually (--with-long-long-int etc) for years...
Anyway, if floats are double precision the need for integer gauge is very small.
pike-devel@lists.lysator.liu.se