Hi,
Long time ago I posted a message about wrong optimization with time() (and perhaps something else). Nobody replied, and the problem is still present in recent CVS (7.4.27). So here it is again:
--- snip --- Just found another bug(?) - the construction like: int ts = time() + 10; while (time() < ts) /* nothing */ ; is wrongly optimized - it doesn't work as expected, i.e. the loop is bypassed - so virtually there is no delay.
When I change it to 'while ((n = time()) < ts);' or put something in body, it works. Checked against one day old CVS Pike 7.4 (7.4.17). NB: Is it related to time() only or? :) --- snip ---
Also, there is a (slight) inconvenience with time() function. To retrieve current time with high precision I've to use time(2)+2.0, since only this syntax allow to retrieve time with microsecond precision. But, unfortunately, it adds 2 seconds to the result. Sure, extra float op is nothing (almost), but at least inconvenient and misleading. Would it be a good idea to add an extra option (say, negative argument) to return current time as float without using base (which is the case when argument is > 1)?
And last about time() :) When Pike is compiled with default float size, its float result is absolutely unrealiable (even wrong) - because of very limited precision (just try: time() - (int)(time(2)+2), the difference will impress you).
Yes, I know that there is gethrtime() etc., but I can't use it (directly) with call_out(), for instance (and gethrtime() involves MPI, which is quite slow comparing to floats, even double precision floats).
Regards, /Al
Try System.Time() (or, if you want relative times, System.Timer())
/ Per Hedbor ()
Previous text:
2003-09-14 18:19: Subject: time() and optimization again
Hi,
Long time ago I posted a message about wrong optimization with time() (and perhaps something else). Nobody replied, and the problem is still present in recent CVS (7.4.27). So here it is again:
--- snip --- Just found another bug(?) - the construction like:
int ts = time() + 10; while (time() < ts) /* nothing */ ;is wrongly optimized - it doesn't work as expected, i.e. the loop is bypassed - so virtually there is no delay.
When I change it to 'while ((n = time()) < ts);' or put something in body, it works.
Checked against one day old CVS Pike 7.4 (7.4.17).
NB: Is it related to time() only or? :) --- snip ---
Also, there is a (slight) inconvenience with time() function. To retrieve current time with high precision I've to use time(2)+2.0, since only this syntax allow to retrieve time with microsecond precision. But, unfortunately, it adds 2 seconds to the result. Sure, extra float op is nothing (almost), but at least inconvenient and misleading.
Would it be a good idea to add an extra option (say, negative argument) to return current time as float without using base (which is the case when argument is > 1)?
And last about time() :) When Pike is compiled with default float size, its float result is absolutely unrealiable (even wrong) - because of very limited precision (just try: time() - (int)(time(2)+2), the difference will impress you).
Yes, I know that there is gethrtime() etc., but I can't use it (directly) with call_out(), for instance (and gethrtime() involves MPI, which is quite slow comparing to floats, even double precision floats).
Regards, /Al
/ Brevbäraren
On Sun, Sep 14, 2003 at 12:25:01PM -0400, Per Hedbor () @ Pike (-) developers forum wrote:
Try System.Time() (or, if you want relative times, System.Timer())
In this case I'll need to convert those values to float anyway. Or use bignums. That's workaround but nothing more - and problem with floats remains...
Regards, /Al
In this case I'll need to convert those values to float anyway.
Why?
Anyway, I guess that the best solution would be to add a cast operator to the System.Time class, rather than overloading the arguments to time() even more.
/ Per Hedbor ()
Previous text:
2003-09-14 19:29: Subject: Re: time() and optimization again
On Sun, Sep 14, 2003 at 12:25:01PM -0400, Per Hedbor () @ Pike (-) developers forum wrote:
Try System.Time() (or, if you want relative times, System.Timer())
In this case I'll need to convert those values to float anyway. Or use bignums. That's workaround but nothing more - and problem with floats remains...
Regards, /Al
/ Brevbäraren
Long time ago I posted a message about wrong optimization with time() (and perhaps something else). Nobody replied, and the problem is still present in recent CVS (7.4.27). So here it is again:
It appears to be fixed in Pike 7.5. It may be that the one who fixed it thought that it would be unsafe to backport it.
/ Martin Nilsson (saturator)
Previous text:
2003-09-14 18:19: Subject: time() and optimization again
Hi,
Long time ago I posted a message about wrong optimization with time() (and perhaps something else). Nobody replied, and the problem is still present in recent CVS (7.4.27). So here it is again:
--- snip --- Just found another bug(?) - the construction like:
int ts = time() + 10; while (time() < ts) /* nothing */ ;is wrongly optimized - it doesn't work as expected, i.e. the loop is bypassed - so virtually there is no delay.
When I change it to 'while ((n = time()) < ts);' or put something in body, it works.
Checked against one day old CVS Pike 7.4 (7.4.17).
NB: Is it related to time() only or? :) --- snip ---
Also, there is a (slight) inconvenience with time() function. To retrieve current time with high precision I've to use time(2)+2.0, since only this syntax allow to retrieve time with microsecond precision. But, unfortunately, it adds 2 seconds to the result. Sure, extra float op is nothing (almost), but at least inconvenient and misleading.
Would it be a good idea to add an extra option (say, negative argument) to return current time as float without using base (which is the case when argument is > 1)?
And last about time() :) When Pike is compiled with default float size, its float result is absolutely unrealiable (even wrong) - because of very limited precision (just try: time() - (int)(time(2)+2), the difference will impress you).
Yes, I know that there is gethrtime() etc., but I can't use it (directly) with call_out(), for instance (and gethrtime() involves MPI, which is quite slow comparing to floats, even double precision floats).
Regards, /Al
/ Brevbäraren
I see a checkin by Grubba in treeopt.in (rev 1.72) that apparently tries to fix it, but it doesn't work for me when I try a 7.5. The patch is backported to 7.4, but it's equally non-working there.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-14 18:58: Subject: time() and optimization again
Long time ago I posted a message about wrong optimization with time() (and perhaps something else). Nobody replied, and the problem is still present in recent CVS (7.4.27). So here it is again:
It appears to be fixed in Pike 7.5. It may be that the one who fixed it thought that it would be unsafe to backport it.
/ Martin Nilsson (saturator)
Well, it appears to work for me.
[nilsson@mahoro src]$ pike --dumpversion 7.5.9 [nilsson@mahoro src]$ time pike -e 'int ts=time()+10; while(time()<ts);'
real 0m9.374s user 0m5.310s sys 0m4.070s
/ Martin Nilsson (saturator)
Previous text:
2003-09-15 19:59: Subject: time() and optimization again
I see a checkin by Grubba in treeopt.in (rev 1.72) that apparently tries to fix it, but it doesn't work for me when I try a 7.5. The patch is backported to 7.4, but it's equally non-working there.
/ Martin Stjernholm, Roxen IS
Yes, that works for me too, but this doesn't:
lister:~> cat foo.pike int main() { int ts = time(); while (time() < ts + 10) {} werror ("elapsed: %d\n", time() - ts); } lister:~> d-pike --dumpversion 7.5.12 lister:~> d-pike foo.pike elapsed: 0
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-15 20:13: Subject: time() and optimization again
Well, it appears to work for me.
[nilsson@mahoro src]$ pike --dumpversion 7.5.9 [nilsson@mahoro src]$ time pike -e 'int ts=time()+10; while(time()<ts);'
real 0m9.374s user 0m5.310s sys 0m4.070s
/ Martin Nilsson (saturator)
Also, there is a (slight) inconvenience with time() function. To retrieve current time with high precision I've to use time(2)+2.0, since only this syntax allow to retrieve time with microsecond precision. But, unfortunately, it adds 2 seconds to the result. Sure, extra float op is nothing (almost), but at least inconvenient and misleading.
Would it be a good idea to add an extra option (say, negative argument) to return current time as float without using base (which is the case when argument is > 1)?
And last about time() :) When Pike is compiled with default float size, its float result is absolutely unrealiable (even wrong) - because of very limited precision (just try: time() - (int)(time(2)+2), the difference will impress you).
Yes, I know that there is gethrtime() etc., but I can't use it (directly) with call_out(), for instance (and gethrtime() involves MPI, which is quite slow comparing to floats, even double precision floats).
Regards, /Al
time() was implemented this way *because* of the limited float precision. Basically, you are supposed to do this:
int base_time=time(); float offset=time(base_time); // seconds since 'base_time'
Generally, I put the first line globally in my program.
If you want a better time function, you could implement it like this:
int mstime() // Time in milliseconds { int t=time(); float off=time(t); return (off * 1000) + (t * 1000); }
/Hubbe
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2003-09-14 18:19: Subject: time() and optimization again
Hi,
Long time ago I posted a message about wrong optimization with time() (and perhaps something else). Nobody replied, and the problem is still present in recent CVS (7.4.27). So here it is again:
--- snip --- Just found another bug(?) - the construction like:
int ts = time() + 10; while (time() < ts) /* nothing */ ;is wrongly optimized - it doesn't work as expected, i.e. the loop is bypassed - so virtually there is no delay.
When I change it to 'while ((n = time()) < ts);' or put something in body, it works.
Checked against one day old CVS Pike 7.4 (7.4.17).
NB: Is it related to time() only or? :) --- snip ---
Also, there is a (slight) inconvenience with time() function. To retrieve current time with high precision I've to use time(2)+2.0, since only this syntax allow to retrieve time with microsecond precision. But, unfortunately, it adds 2 seconds to the result. Sure, extra float op is nothing (almost), but at least inconvenient and misleading.
Would it be a good idea to add an extra option (say, negative argument) to return current time as float without using base (which is the case when argument is > 1)?
And last about time() :) When Pike is compiled with default float size, its float result is absolutely unrealiable (even wrong) - because of very limited precision (just try: time() - (int)(time(2)+2), the difference will impress you).
Yes, I know that there is gethrtime() etc., but I can't use it (directly) with call_out(), for instance (and gethrtime() involves MPI, which is quite slow comparing to floats, even double precision floats).
Regards, /Al
/ Brevbäraren
On Thu, Sep 18, 2003 at 11:00:05PM +0200, Fredrik (Naranek) Hubinette (Real Build Master) @ Pike (-) developers forum wrote:
time() was implemented this way *because* of the limited float precision. Basically, you are supposed to do this:
It is limited only by default. Frankly, I see no reason why it is not double precision by default...
int mstime() // Time in milliseconds { int t=time(); float off=time(t); return (off * 1000) + (t * 1000); }
This way I've one extra syscall, and interpeted: three float operations, two function calls and two svalues allocation/deallocation (= subject to gc()).
Not a big deal? Well, then again, I see no reason why default float type is not double precision... :)
Regards, /Al
It is limited only by default. Frankly, I see no reason why it is not double precision by default...
Because in most applications you don't need more than single precision. And to make all pike applications take 50% more memory for that reason would not be something I would like.
This way I've one extra syscall, and interpeted: three float operations, two function calls and two svalues allocation/deallocation (= subject to gc()).
Go with his first suggenstion then and establish a base time. Then you'll only have one syscall extra for the entire run of the application. As for the rest, CPUs are fast. It is 21st century, after all. Besides, you can't hold a reference to an int or a float, so it is not subject to gc().
/ Martin Nilsson (saturator)
Previous text:
2003-09-19 01:05: Subject: Re: time() and optimization again
On Thu, Sep 18, 2003 at 11:00:05PM +0200, Fredrik (Naranek) Hubinette (Real Build Master) @ Pike (-) developers forum wrote:
time() was implemented this way *because* of the limited float precision. Basically, you are supposed to do this:
It is limited only by default. Frankly, I see no reason why it is not double precision by default...
int mstime() // Time in milliseconds { int t=time(); float off=time(t); return (off * 1000) + (t * 1000); }
This way I've one extra syscall, and interpeted: three float operations, two function calls and two svalues allocation/deallocation (= subject to gc()).
Not a big deal? Well, then again, I see no reason why default float type is not double precision... :)
Regards, /Al
/ Brevbäraren
Use gethrtime instead if you want high precision time.
Floats aren't double by default since that'd make the svalue size larger. Perhaps we should move to 8 byte integers and floats soon, but it'd be nice to see some comparisons on the effects of that on different applications first. Care to collect some data?
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-19 01:05: Subject: Re: time() and optimization again
On Thu, Sep 18, 2003 at 11:00:05PM +0200, Fredrik (Naranek) Hubinette (Real Build Master) @ Pike (-) developers forum wrote:
time() was implemented this way *because* of the limited float precision. Basically, you are supposed to do this:
It is limited only by default. Frankly, I see no reason why it is not double precision by default...
int mstime() // Time in milliseconds { int t=time(); float off=time(t); return (off * 1000) + (t * 1000); }
This way I've one extra syscall, and interpeted: three float operations, two function calls and two svalues allocation/deallocation (= subject to gc()).
Not a big deal? Well, then again, I see no reason why default float type is not double precision... :)
Regards, /Al
/ Brevbäraren
On Fri, Sep 19, 2003 at 01:50:02AM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Use gethrtime instead if you want high precision time.
This will use bignums - even worse... Until there is native 64bit int... Well... I'll resort to my own function.
it'd be nice to see some comparisons on the effects of that on different applications first. Care to collect some data?
If there is any good benchmark suite (which will run on 7.4), I can test different options and publish the results.
Regards, /Al
This will use bignums - even worse... Until there is native 64bit int... Well... I'll resort to my own function.
You mean you have a function that returns millisecond time or better and is neither using deltas like time() nor bignums like gethrtime()? Sounds interesting. How does it work?
If there is any good benchmark suite (which will run on 7.4), I can test different options and publish the results.
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.
But I don't think benchmarks will tell the whole story, or even a significant part of it. It's much more interesting to look at real-world applications, say Roxen, Caudium, Aido and your IP-number crunching application (what does it actually do?).
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-19 02:11: Subject: Re: time() and optimization again
On Fri, Sep 19, 2003 at 01:50:02AM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Use gethrtime instead if you want high precision time.
This will use bignums - even worse... Until there is native 64bit int... Well... I'll resort to my own function.
it'd be nice to see some comparisons on the effects of that on different applications first. Care to collect some data?
If there is any good benchmark suite (which will run on 7.4), I can test different options and publish the results.
Regards, /Al
/ Brevbäraren
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:
http://aldem.net/pike/fdbench 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
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
On Fri, Sep 19, 2003 at 04:55:01AM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Aren't there? I see mostly yellow and green dots on http://pike.ida.liu.se/development/pikefarm/7.5.xml. NT has gotten
That's what I have:
---snip--- Compiling interpret.c interpret.c:2593: error: parse error before "if" interpret.c:43:1: unterminated #ifdef WARNING: Compiler failure! Trying without optimization! interpret.c:2593: error: parse error before "if" interpret.c:43:1: unterminated #ifdef ---snip---
At this point build fails (obviously). Just checked in. Will try to figure out what is wrong...
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.
They consume a lot by default anyway. Extra 10% will make no difference, I guess ;)
--with-double-precision and --with-long-long-int on most systems. Memory size for pure arrays goes up almost exactly 50%, which figures.
But at least not 100% :)
It also shows that svalues aren't padded to 16 bytes.
It depends on compiler flags. It might be padded (especially on Win32/MSVC).
Regards, /Al
Arrays will never ever be padded. Since they are allocated as malloc(sizeof(FOO)*elems).
I just checked with AIDO, the size grows about 40%, as could be expected, since there are some images and strings, but mostly mappings and arrays.
I know of no way to benchmark the speed of aido, though, but if you have booth large floats and integers it will probably be slower, since my CPU lacks native 64bit integers.
/ Per Hedbor ()
Previous text:
2003-09-19 06:44: Subject: Re: some results on number crunching
On Fri, Sep 19, 2003 at 04:55:01AM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Aren't there? I see mostly yellow and green dots on http://pike.ida.liu.se/development/pikefarm/7.5.xml. NT has gotten
That's what I have:
---snip--- Compiling interpret.c interpret.c:2593: error: parse error before "if" interpret.c:43:1: unterminated #ifdef WARNING: Compiler failure! Trying without optimization! interpret.c:2593: error: parse error before "if" interpret.c:43:1: unterminated #ifdef ---snip---
At this point build fails (obviously). Just checked in. Will try to figure out what is wrong...
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.
They consume a lot by default anyway. Extra 10% will make no difference, I guess ;)
--with-double-precision and --with-long-long-int on most systems. Memory size for pure arrays goes up almost exactly 50%, which figures.
But at least not 100% :)
It also shows that svalues aren't padded to 16 bytes.
It depends on compiler flags. It might be padded (especially on Win32/MSVC).
Regards, /Al
/ Brevbäraren
Compilers usually include padding in sizeof(x), precisely so that array allocation will preseve alignment.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-09-19 14:58: Subject: Re: some results on number crunching
Arrays will never ever be padded. Since they are allocated as malloc(sizeof(FOO)*elems).
I just checked with AIDO, the size grows about 40%, as could be expected, since there are some images and strings, but mostly mappings and arrays.
I know of no way to benchmark the speed of aido, though, but if you have booth large floats and integers it will probably be slower, since my CPU lacks native 64bit integers.
/ Per Hedbor ()
True. But if sizeof(X) is 12, you can be fairly certain that no aligning is taking place.
/ Per Hedbor ()
Previous text:
2003-09-19 15:03: Subject: Re: some results on number crunching
Compilers usually include padding in sizeof(x), precisely so that array allocation will preseve alignment.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Only to 32-bit boundaries.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-09-19 15:05: Subject: Re: some results on number crunching
True. But if sizeof(X) is 12, you can be fairly certain that no aligning is taking place.
/ Per Hedbor ()
Of course, there's always gethrtime() which returns the time in µs.
/ David Hedbor
Previous text:
2003-09-18 22:59: Subject: time() and optimization again
Also, there is a (slight) inconvenience with time() function. To retrieve current time with high precision I've to use time(2)+2.0, since only this syntax allow to retrieve time with microsecond precision. But, unfortunately, it adds 2 seconds to the result. Sure, extra float op is nothing (almost), but at least inconvenient and misleading.
Would it be a good idea to add an extra option (say, negative argument) to return current time as float without using base (which is the case when argument is > 1)?
And last about time() :) When Pike is compiled with default float size, its float result is absolutely unrealiable (even wrong) - because of very limited precision (just try: time() - (int)(time(2)+2), the difference will impress you).
Yes, I know that there is gethrtime() etc., but I can't use it (directly) with call_out(), for instance (and gethrtime() involves MPI, which is quite slow comparing to floats, even double precision floats).
Regards, /Al
time() was implemented this way *because* of the limited float precision. Basically, you are supposed to do this:
int base_time=time(); float offset=time(base_time); // seconds since 'base_time'Generally, I put the first line globally in my program.
If you want a better time function, you could implement it like this:
int mstime() // Time in milliseconds { int t=time(); float off=time(t); return (off * 1000) + (t * 1000); }
/Hubbe
/ Fredrik (Naranek) Hubinette (Real Build Master)
retrieve current time with high precision I've to use time(2)+2.0, since only this syntax allow to retrieve time with microsecond
How do you do to get microsecond precision even then? The default float in pike (32 bit) has 7½ digits precision, today at 10 digit time result that means about ten minutes precision? That of course is also the main reason of the construct.
/ Mirar
Previous text:
2003-09-14 18:19: Subject: time() and optimization again
Hi,
Long time ago I posted a message about wrong optimization with time() (and perhaps something else). Nobody replied, and the problem is still present in recent CVS (7.4.27). So here it is again:
--- snip --- Just found another bug(?) - the construction like:
int ts = time() + 10; while (time() < ts) /* nothing */ ;is wrongly optimized - it doesn't work as expected, i.e. the loop is bypassed - so virtually there is no delay.
When I change it to 'while ((n = time()) < ts);' or put something in body, it works.
Checked against one day old CVS Pike 7.4 (7.4.17).
NB: Is it related to time() only or? :) --- snip ---
Also, there is a (slight) inconvenience with time() function. To retrieve current time with high precision I've to use time(2)+2.0, since only this syntax allow to retrieve time with microsecond precision. But, unfortunately, it adds 2 seconds to the result. Sure, extra float op is nothing (almost), but at least inconvenient and misleading.
Would it be a good idea to add an extra option (say, negative argument) to return current time as float without using base (which is the case when argument is > 1)?
And last about time() :) When Pike is compiled with default float size, its float result is absolutely unrealiable (even wrong) - because of very limited precision (just try: time() - (int)(time(2)+2), the difference will impress you).
Yes, I know that there is gethrtime() etc., but I can't use it (directly) with call_out(), for instance (and gethrtime() involves MPI, which is quite slow comparing to floats, even double precision floats).
Regards, /Al
/ Brevbäraren
On Thu, Sep 18, 2003 at 11:10:03PM +0200, Mirar @ Pike developers forum wrote:
How do you do to get microsecond precision even then? The default float in pike (32 bit) has 7? digits precision, today at 10 digit time
I am still curious why it is 32 bit by default... There is no reason not to choose double, unless majority of Pike users owns PC XT :)
Regards, /Al
Or the majority of pike users does not like using 4 bytes more for each and every svalue.
/ Per Hedbor ()
Previous text:
2003-09-19 01:07: Subject: Re: time() and optimization again
On Thu, Sep 18, 2003 at 11:10:03PM +0200, Mirar @ Pike developers forum wrote:
How do you do to get microsecond precision even then? The default float in pike (32 bit) has 7? digits precision, today at 10 digit time
I am still curious why it is 32 bit by default... There is no reason not to choose double, unless majority of Pike users owns PC XT :)
Regards, /Al
/ Brevbäraren
On Fri, Sep 19, 2003 at 01:10:01AM +0200, Per Hedbor () @ Pike (-) developers forum wrote:
Or the majority of pike users does not like using 4 bytes more for each and every svalue.
RAM is quite cheap now. It is quite difficult to find anybody running a system with less than 64M of RAM. CPUs are fast. It is 21st century, after all. Is Pike's target market 486dx33 with 8MB RAM? I doubt that.
There are a lot of other places where optimization should be done, and, honestly, I don't think that extra 4 bytes makes any _significant_ difference (svalue is 12 bytes and on most system it will be aligned to 16 anyway - for performance reasons).
Regards, /Al
In the last episode (Sep 19), Alexander Demenshin said:
On Fri, Sep 19, 2003 at 01:10:01AM +0200, Per Hedbor () @ Pike (-) developers forum wrote:
Or the majority of pike users does not like using 4 bytes more for each and every svalue.
RAM is quite cheap now. It is quite difficult to find anybody running a system with less than 64M of RAM. CPUs are fast. It is 21st century, after all. Is Pike's target market 486dx33 with 8MB RAM? I doubt that.
There are a lot of other places where optimization should be done, and, honestly, I don't think that extra 4 bytes makes any _significant_ difference (svalue is 12 bytes and on most system it will be aligned to 16 anyway - for performance reasons).
Hmm?
$ gdb /usr/local/pike/7.4.20/bin/pike (gdb) p sizeof(struct svalue) $1 = 8
On i386 at least. On 64-bit platforms it's already 16 due to the size of pointers.
Why would it align to 8 byte alignment on a Pentium?
Also, svalues are usually allocated as arrays (the stack, or object storage), and only the first value in those will align.
/ Mirar
Previous text:
2003-09-19 03:20: Subject: Re: time() and optimization again
On Thu, Sep 18, 2003 at 07:58:46PM -0500, Dan Nelson wrote:
(gdb) p sizeof(struct svalue) $1 = 8
If it is 12 bytes it most likely will be aligned to 16 (on Pentium at least). It depends on compiler and exact acrh, but anyway. That's what I mean.
Regards, /Al
/ Brevbäraren
On Fri, Sep 19, 2003 at 08:05:02AM +0200, Mirar @ Pike developers forum wrote:
Why would it align to 8 byte alignment on a Pentium?
Depends on options. Some compilers do. Additionally, there is another alignment - malloc()ed, usually 16 bytes (depends on library though).
Regards, /Al
Seems to be 8 for linux malloc. Which means that single svalues double in size with doubles, incidentally.
But they are mostly allocated as arrays anyway.
/ Per Hedbor ()
Previous text:
2003-09-19 08:21: Subject: Re: time() and optimization again
On Fri, Sep 19, 2003 at 08:05:02AM +0200, Mirar @ Pike developers forum wrote:
Why would it align to 8 byte alignment on a Pentium?
Depends on options. Some compilers do. Additionally, there is another alignment - malloc()ed, usually 16 bytes (depends on library though).
Regards, /Al
/ Brevbäraren
Which compiler with which options pads with a whole four bytes? Doesn't it pad the normal 8 byte svalue too?
Malloc alignment isn't much of a factor; there's hardly ever any allocation of single svalues.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-19 08:21: Subject: Re: time() and optimization again
On Fri, Sep 19, 2003 at 08:05:02AM +0200, Mirar @ Pike developers forum wrote:
Why would it align to 8 byte alignment on a Pentium?
Depends on options. Some compilers do. Additionally, there is another alignment - malloc()ed, usually 16 bytes (depends on library though).
Regards, /Al
/ Brevbäraren
It does too. As an example, a running AIDO would grow from 32Mb to 48. While it's true that that's not all that bad, really, its very noticeable.
/ Per Hedbor ()
Previous text:
2003-09-19 01:27: Subject: Re: time() and optimization again
On Fri, Sep 19, 2003 at 01:10:01AM +0200, Per Hedbor () @ Pike (-) developers forum wrote:
Or the majority of pike users does not like using 4 bytes more for each and every svalue.
RAM is quite cheap now. It is quite difficult to find anybody running a system with less than 64M of RAM. CPUs are fast. It is 21st century, after all. Is Pike's target market 486dx33 with 8MB RAM? I doubt that.
There are a lot of other places where optimization should be done, and, honestly, I don't think that extra 4 bytes makes any _significant_ difference (svalue is 12 bytes and on most system it will be aligned to 16 anyway - for performance reasons).
Regards, /Al
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Alexander Demenshin -
Dan Nelson -
David Hedbor ＠ Pike developers forum -
Fredrik (Naranek) Hubinette (Real Build Master) ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (saturator) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Per Hedbor () ＠ Pike (-) developers forum