It is as simple as it can be. Just remove deltas from time() and always return float value (at least double precision - I never use anything with less precision).
That requires, as you say, double precision. If you're compiling Pike with double precision you can just as well use 64 bit integers since the svalue size already will be 12 bytes. Then gethrtime won't return bignums.
It doesn't compile (CVS version). I tried several times last days, and it seems that it is intermediate version (there are no succesfull builds on farm either, anyway).
Aren't there? I see mostly yellow and green dots on http://pike.ida.liu.se/development/pikefarm/7.5.xml. NT has gotten broken recently, though. Can't see any clear error for it. :\
/.../ Roxen/Caudium and similar apps won't use so significant amount of float ops nor large arrays of them, so it is unlikely that it will affect their performance/memory usage.
I also suspect performance won't be affected that much. That's one interesting aspect since it shows the impact on a normal non-math intensive application. Both kinds ought to be measured.
The memory occupied by strings, mappings and intermediate objects is so significant that increasing of svalue size is not really makes any difference.
I'm not at all certain of that. It's primarily the memory consumption that's interesting to see in large apps like Caudium and Roxen.
Memory consumption is 2x more in case of long-double and long-long-int,
I think the interesting case is when both are 8 bytes, i.e. --with-double-precision and --with-long-long-int on most systems. Memory size for pure arrays goes up almost exactly 50%, which figures. It also shows that svalues aren't padded to 16 bytes.
but timings are better
Afaics they go down 26% for double/int and 30% for long double/long long int. That surprises me a bit; I didn't think such a large part of the time could be spent in pure calculations so that the larger floats could have that effect.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-19 04:04: Subject: Re: some results on number crunching
On Fri, Sep 19, 2003 at 03:25:03AM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
You mean you have a function that returns millisecond time or better and is neither using deltas like time() nor bignums like gethrtime()?
It is as simple as it can be. Just remove deltas from time() and always return float value (at least double precision - I never use anything with less precision). Or use time(2)+2.0 (but I don't like extra ops, especially interpreted).
Test with 7.5 instead? That should work just as well. It shouldn't be too difficult for you to backport the benchmark tests to 7.4 either.
It doesn't compile (CVS version). I tried several times last days, and it seems that it is intermediate version (there are no succesfull builds on farm either, anyway). Some weirdness in #defines or something like that...
But I don't think benchmarks will tell the whole story, or even a significant part of it.
If benchmark artifically tests exceptional case of number crunching - it will. Roxen/Caudium and similar apps won't use so significant amount of float ops nor large arrays of them, so it is unlikely that it will affect their performance/memory usage. The memory occupied by strings, mappings and intermediate objects is so significant that increasing of svalue size is not really makes any difference.
Anyway... I quickly did it... The app and results at:
Memory consumption is 2x more in case of long-double and long-long-int, but timings are better (not so big difference, taking into account byte-code interpreter).
Regards, /Al
/ Brevbäraren