Date: Sat, 22 Jan 2005 23:37:13 +0200 From: Alin-Adrian Anton <aanton@spintech.ro> To: Chris Landauer <cal@rush.aero.org> Cc: freebsd-hackers@freebsd.org Subject: Re: time and timing errors in c code on 5.x/i386 (longish) Message-ID: <41F2C789.3000704@spintech.ro> In-Reply-To: <200501212249.j0LMnfpJ091129@calamari.aero.org> References: <200501212249.j0LMnfpJ091129@calamari.aero.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Landauer wrote: > some summary output lines that illustrate the problem > > n46 r08 295.722u 0.417s 5:17.59 93.2% > n46 r09 32031.689u 41.815s 9:34:08.17 93.1% > n46 r10 5672.848u 2096.191s 635:23:04.54 0.3% > > (the last column is edited from the output from time in csh; the other two > columns are problem parameters, and the mathematics of the problem is such > that these values should increase rapidly with increasing r; in this case, the > user time has wrapped or otherwise failed in the last line, and since the > machine was only running the one program in addition to the usual kde or gnome > or something in all 4 cases, it should have been about 93% usage or so like > the previous two) > > i looked at the time structure and it should be big enough to prevent wrapping > for some long period of time, but the same thing happens with /usr/bin/time > (of course, since it takes a few weeks for each experiment, i didn't do very > many of them) - the i/o counts also wrap around, but i don't care about that > > so i added some code that uses rusage() to the program, and the same failure > occurs (my own code for this computation is included next) - a snippet from > the time lines in the printed output: > > user 378925.483628 syst 286.845375 elapse 381328.785295 pct 99.44% > user 379089.748458 syst 286.962284 elapse 381493.700660 pct 99.45% > user 379255.472355 syst 287.088004 elapse 381660.106387 pct 99.45% > user 379417.184286 syst 287.190223 elapse 381822.457863 pct 99.45% > user 379417.184286 syst 451.110470 elapse 381986.906692 pct 99.45% > user 379417.184286 syst 615.737725 elapse 382152.058304 pct 99.45% [..] > > i would be happy to perform experiments to solve this problem, and i know that > i have to be patient (after all, each experiment takes over two weeks) > > more later, > cal > > Dr. Christopher Landauer > Aerospace Integration Science Center Does this problem occur on another machine? Does it occur on FreeBSD 4.x? Does it occur on another OS? The fact that float = 4 bytes and long = 4 bytes doesn't mean double = long+float. Double datatype takes 8 bytes, yes, but I don't know how many bits are reserved for what, inside the 64 bits. (though this could be digged somewhere). It deals with gcc, probably with system architecture too. I could make suppositions but they are not usefull. You could also try evoyding the scientific notations and the usage of "double" for keeping time, as it is only a matter of +/- one second, as it shows from the code snippet you attached. One second for this matter is so relative, that it is simply irrelevant considering that the accuracy of measuring time inside a C program is itself an aproximation. It deals with an enormous number of factors, where most are incontrolable. So just try keeping time in long format, for seconds. See if it still fails. Yours Sincerely, -- Alin-Adrian Anton GPG keyID 0x1E2FFF2E (2963 0C11 1AF1 96F6 0030 6EE9 D323 639D 1E2F FF2E) gpg --keyserver pgp.mit.edu --recv-keys 1E2FFF2E Never ask a man what OS he uses. If it's FreeBSD, he'll tell you. If it's not, why embarrass him? ..I'm sorry..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41F2C789.3000704>