OJ Board

I haven't seen such thing before in any Ranklist of this site..
http://acm.uva.es/cgi-bin/OnlineJudge?P ... 5:125:1.00
It shows that in place 134 (that's today in 6th july, 2k3) of the problem 10057 - A mid-summer night's dream. author DoubleS Edwin used time 0:03.1000
that means 4 sec. ha ha.

134 0:03.1000 8208 DoubleS Edwin C 2003/03/20-12:48:38.686 1472858 (H0)

ain't that funny?

oh.....haha
"nice" to see that
I think they should fix that asap

Hey , that's quite funny.

I also have a query, sometimes The same program thakes different time to execute, although the difference is very little. But why should, such differences exist.

I think if you've seen this then you could have probably figured it out. I can't understand why you still haven't. The answer is simple: every run on you're program is slightly different because of the different load on machine's CPU. And I guess you know that there are no two perfectly identical things/events/etc. All you get by timing is some average value.

Ivor

In addition to previous post: I don't believe they will get .1000 bug fixed. I don't believe it's their bug at all. It must be some deeper very rare thingy in timing system. I don't know whether they can or cannot correct timings in ranklists manually but I think they can't.

Ivor

Hello! Again Ivor!

Yes! You correct..........! The processor with it's time sharing property...it may be idle or working fast or working on another multithreads depends on their priority.......... and that is why same program may take different time to execute........but it don't differ that much does it ???

One can get very different runs. Usually the difference is about 0.002-0.006 but sometimes can be as much as 0.010-0.020 (very rarely and meaning to take a lot more time than avg.). Before the kernel(?) update the timing precision was 0.010. Then the differences were bigger 0.010-0.040. But sometime in past nine month (I don't know exactly when because I was in army serving my country) they made an upgrade and the precision was brought to 0.001 (or rather 0.002 at avg.).

Ivor

Hmm... but what you tell about size?

Can you tell me how they mesure the size of the program executing....???

if you talk about memory usage then it's roughly correct when your program runs at speed slower than 0.100-0.110. Below this limit you can get 64k even though you used about 5Mb memory.

Ivor

Hmm, the diferences aren't about the kernel timing, but I think they occur due to the caching process. For example, if you are submiting a problem that get's "Accepted", and read the input of about 300k let's say with fread, and after a second or two you submit again your problem, you might get a better time.
I tested this, and it isn't about timing error due to hevy loading, it's about caching, because the trick will work even better when the processor is not heavy loaded ( times of day when submissions are more rare, so the input's of other problems won't get in the cache ).

Just think that the processor has 256k cache ( or something ... ), your program might by no mor than 20k, and the input might be 150k. So resubmiting (fast) the source code would give a better time.

there just might be something about this caching thing. But still I don't believe you win much unless there are very high stakes and 0.002 sec is all that matters. there are such cases. But usually I haven't seen a difference bigger than 0.010. Lately at least.

Ivor