From: <bob...@ai...> - 2007-11-17 23:50:30
|
I was looking into the clock resolution for Jython and ran into something that doesn't seen right to me.? I ran simple tests? on Windows XP and Linux and came up with the following results: Windows XP ??? Python ??? ??? time.clock()??? -?? 2 microseconds ??? ??? time.time()??? - 15 milliseconds ??? Jython ??? ??? time.clock() - 15 milliseconds ??? ??? time.time()??? - 15 milliseconds Linux ??? Python ??? ??? time.clock()??? - 10 milliseconds ??? ??? time.time()??? - 5 microseconds ??? ??? ??? Jython ??? ??? time.clock() - 1 millisecond ??? ??? time.time()??? - 1 millisecond Shouldn't time.clock() on Jython for Windows and time.time() on Linux have much better resolution?? I believe that if Jython used Java nanoTime it could reach these levels.? Am I way off base? It also looks like Python may have a problem with time.clock() on Linux, but that is for a different forum. I have simple scripts to demo this if anyone is interested, and will open a problem against the current code if that is where the problem is, but I don't know the plan for Jython to implement clock timing.? ?- Bob ________________________________________________________________________ Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection. |
From: Charlie G. <cha...@gm...> - 2007-11-23 19:44:01
|
On Nov 17, 2007 3:50 PM, <bob...@ai...> wrote: > I was looking into the clock resolution for Jython and ran into something > that doesn't seen right to me. I ran simple tests on Windows XP and Linux > and came up with the following results: > > Windows XP > Python > time.clock() - 2 microseconds > time.time() - 15 milliseconds > > Jython > time.clock() - 15 milliseconds > time.time() - 15 milliseconds > > Linux > Python > time.clock() - 10 milliseconds > time.time() - 5 microseconds > > Jython > time.clock() - 1 millisecond > time.time() - 1 millisecond > > Shouldn't time.clock() on Jython for Windows and time.time() on Linux have > much better resolution? I believe that if Jython used Java nanoTime it > could reach these levels. Am I way off base? I don't think there's anything we can do about the resolution of time.time. I don't see how it could be done with System.nanoTime since that just yields the number of nanoseconds since the first time it was called and has no bearing on the time since the epoch. We could probably use nanoTime for time.clock though and get better numbers. > I have simple scripts to demo this if anyone is interested, and will open a > problem against the current code if that is where the problem is, but I > don't know the plan for Jython to implement clock timing. If you want to file a bug for time.clock with your scripts, I'll see about switching it to use nanoTime. Charlie |
From: <bob...@ai...> - 2007-11-23 23:34:10
|
Thank you Charlie.? You of course are right about time.time().? It couldn't be improved using nanoTime.? Time clock should be relatively easy though and should improve things by quite a bit.? I will put my example scripts together with a naive first pass at a solution and open a problem. I imagine Python uses getTimeOfDay() on unix like systems for time.time().? time.time() could could still be improved using JNI and getTimeOfDay() on Unix like systems and then Jython's resolution would basically match Pythons (since Pythons Windows XP resolution for time.time() really isn't any better than Jythons).? I understand that it isn;'t quite as simple of an enhancement though to use JNI.? Does/would Jython consider using JNI and c for time.time()? ?- Bob -----Original Message----- From: Charlie Groves <cha...@gm...> To: bob...@ai... Cc: jyt...@li... Sent: Fri, 23 Nov 2007 1:43 pm Subject: Re: [Jython-dev] Jython Clock Resolution On Nov 17, 2007 3:50 PM, <bob...@ai...> wrote: > I was looking into the clock resolution for Jython and ran into something > that doesn't seen right to me. I ran simple tests on Windows XP and Linux > and came up with the following results: > > Windows XP > Python > time.clock() - 2 microseconds > time.time() - 15 milliseconds > > Jython > time.clock() - 15 milliseconds > time.time() - 15 milliseconds > > Linux > Python > time.clock() - 10 milliseconds > time.time() - 5 microseconds > > Jython > time.clock() - 1 millisecond > time.time() - 1 millisecond > > Shouldn't time.clock() on Jython for Windows and time.time() on Linux have > much better resolution? I believe that if Jython used Java nanoTime it > could reach these levels. Am I way off base? I don't think there's anything we can do about the resolution of time.time. I don't see how it could be done with System.nanoTime since that just yields the number of nanoseconds since the first time it was called and has no bearing on the time since the epoch. We could probably use nanoTime for time.clock though and get better numbers. > I have simple scripts to demo this if anyone is interested, and will open a > problem against the current code if that is where the problem is, but I > don't know the plan for Jython to implement clock timing. If you want to file a bug for time.clock with your scripts, I'll see about switching it to use nanoTime. Charlie ________________________________________________________________________ Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection. |
From: Charlie G. <cha...@gm...> - 2007-11-24 03:14:22
|
On Nov 23, 2007 3:33 PM, <bob...@ai...> wrote: > Thank you Charlie. You of course are right about time.time(). It couldn't > be improved using nanoTime. Time clock should be relatively easy though and > should improve things by quite a bit. I will put my example scripts > together with a naive first pass at a solution and open a problem. It's a pretty simple change, and I think I've already got it in my local copy. If you just want to create a bug and upload the example script, that'd be good. I was just hoping to test against your expectations before committing it. > I imagine Python uses getTimeOfDay() on unix like systems for time.time(). > time.time() could could still be improved using JNI and getTimeOfDay() on > Unix like systems and then Jython's resolution would basically match Pythons > (since Pythons Windows XP resolution for time.time() really isn't any better > than Jythons). I understand that it isn;'t quite as simple of an > enhancement though to use JNI. Does/would Jython consider using JNI and c > for time.time()? Since the docs don't promise anything better than second resolution for time.time, I don't think it's worth the headaches of JNI to provide better resolution from time.time. There's some talk of using JNA to provide easier access to native functionality for things that don't have a counterpart in straight Java, so if that lands it should be easier to do this sort of thing. Charlie |
From: <bob...@ai...> - 2007-11-24 09:14:28
|
-----Original Message----- From: bob...@ai... To: cha...@gm... Sent: Sat, 24 Nov 2007 2:56 am Subject: Re: [Jython-dev] Jython Clock Resolution Hi Charlie, Well it looks like I've been removed from the Jython project to submit problems in Tracker, probably because I just sort of appointed myself a tester for Jython 2.2 because I was testing my own Jython socket programs at the same time that 2.2 was coming out.? I'll submit a problem if I get access.? For this case, I have just been doing a lot of time resolution stuff and saw that this change could be made relatively easily. My script though is very simple and basic.? I would expect to see about 15 millisecond resolution before the change to using nanoTime and about 25 microseconds resolution after the change on Windows XP, of course actual mileage will vary depending on road conditions, etc.? I think the test is clearly accurate enough for the conditions and for the nearly 3 orders of magnitude resolution improvement for time.clock() that this change should make. The script is as follows: ---------------------------------------------- import time values = [] for i in range(100): ?? ? ?? ?t1 = time.clock() ?? ?t2 = t1 ?? ? ?? ?while t1 == t2: ?? ??? ?t2 = time.clock() ?????? ? ?? ?values.append(t2 - t1) ?? ?#print (t2 - t1) ?? ? print 'Average resolution for time.clock() is: ', ((sum(values) / len(values))*1000), ' ms' ----------------------------------------------------------------------------------------------------- If you have any questions on this script let me know.? If I am doing something wrong that is causing me not to be able to open problems for Jython, let me know that as well. ?- Bob -----Original Message----- From: Charlie Groves <cha...@gm...> To: bob...@ai... Cc: jyt...@li... Sent: Fri, 23 Nov 2007 9:14 pm Subject: Re: [Jython-dev] Jython Clock Resolution On Nov 23, 2007 3:33 PM, <bob...@ai...> wrote: > Thank you Charlie. You of course are right about time.time(). It couldn't > be improved using nanoTime. Time clock should be relatively easy though and > should improve things by quite a bit. I will put my example scripts > together with a naive first pass at a solution and open a problem. It's a pretty simple change, and I think I've already got it in my local copy. If you just want to create a bug and upload the example script, that'd be good. I was just hoping to test against your expectations before committing it. > I imagine Python uses getTimeOfDay() on unix like systems for time.time(). > time.time() could could still be improved using JNI and getTimeOfDay() on > Unix like systems and then Jython's resolution would basically match Pythons > (since Pythons Windows XP resolution for time.time() really isn't any better > than Jythons). I understand that it isn;'t quite as simple of an > enhancement though to use JNI. Does/would Jython consider using JNI and c > for time.time()? Since the docs don't promise anything better than second resolution for time.time, I don't think it's worth the headaches of JNI to provide better resolution from time.time. There's some talk of using JNA to provide easier access to native functionality for things that don't have a counterpart in straight Java, so if that lands it should be easier to do this sort of thing. Charlie Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection. ________________________________________________________________________ Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection. |
From: <bob...@ai...> - 2007-11-24 09:30:16
|
Charlie, Your fix is probably right on.? I just have a a couple of salient points just in case.? 1) Java System.nanoTime() needs java 1.5 so you have to check if you are going to put it in a release that allows < Java 1.5. 2)? //? A suggested solution private static double __initialclock__ = 0.0; public static double clock() { ???? if (__initialclock__ == 0.0) { ??????? // set on first call ??????? __initialclock__ = System.nanoTime();? // keep __initialclock__ in nanoSeconds ??????? return 0.0;? // I would add this return here - it could improve accuracy by a? few microseconds ??? } ??? return (System.nanoTime() - __initialclock__) / 1000000000.0;? // convert the time to seconds here ?- Bob -----Original Message----- From: Charlie Groves <cha...@gm...> To: bob...@ai... Cc: jyt...@li... Sent: Fri, 23 Nov 2007 9:14 pm Subject: Re: [Jython-dev] Jython Clock Resolution On Nov 23, 2007 3:33 PM, <bob...@ai...> wrote: > Thank you Charlie. You of course are right about time.time(). It couldn't > be improved using nanoTime. Time clock should be relatively easy though and > should improve things by quite a bit. I will put my example scripts > together with a naive first pass at a solution and open a problem. It's a pretty simple change, and I think I've already got it in my local copy. If you just want to create a bug and upload the example script, that'd be good. I was just hoping to test against your expectations before committing it. > I imagine Python uses getTimeOfDay() on unix like systems for time.time(). > time.time() could could still be improved using JNI and getTimeOfDay() on > Unix like systems and then Jython's resolution would basically match Pythons > (since Pythons Windows XP resolution for time.time() really isn't any better > than Jythons). I understand that it isn;'t quite as simple of an > enhancement though to use JNI. Does/would Jython consider using JNI and c > for time.time()? Since the docs don't promise anything better than second resolution for time.time, I don't think it's worth the headaches of JNI to provide better resolution from time.time. There's some talk of using JNA to provide easier access to native functionality for things that don't have a counterpart in straight Java, so if that lands it should be easier to do this sort of thing. Charlie ________________________________________________________________________ Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection. |
From: Charlie G. <cha...@gm...> - 2007-11-25 20:12:06
|
On Nov 24, 2007 1:14 AM, <bob...@ai...> wrote: > Well it looks like I've been removed from the Jython project to submit > problems in Tracker, probably because I just sort of appointed myself a > tester for Jython 2.2 because I was testing my own Jython socket programs at > the same time that 2.2 was coming out. I'll submit a problem if I get > access. For this case, I have just been doing a lot of time resolution > stuff and saw that this change could be made relatively easily. That sounds pretty weird. As far as I know, you just need a sourceforge account to create a bug for Jython. I don't see anything special for your account in the admin controls for Jython. What does it say when you try to add a bug? Charlie |
From: <bob...@ai...> - 2007-11-26 01:44:47
|
Well, I just went on and it allowed me to open a problem just fine.? I have no idea what I might have done.? The message when I was not able to open a problem said something about my id not belonging to the Jython group or project or something like that.? Probably user error. ?- Bob -----Original Message----- From: Charlie Groves <cha...@gm...> To: bob...@ai... Cc: jyt...@li... Sent: Sun, 25 Nov 2007 2:12 pm Subject: Re: [Jython-dev] Fwd: Jython Clock Resolution On Nov 24, 2007 1:14 AM, <bob...@ai...> wrote: > Well it looks like I've been removed from the Jython project to submit > problems in Tracker, probably because I just sort of appointed myself a > tester for Jython 2.2 because I was testing my own Jython socket programs at > the same time that 2.2 was coming out. I'll submit a problem if I get > access. For this case, I have just been doing a lot of time resolution > stuff and saw that this change could be made relatively easily. That sounds pretty weird. As far as I know, you just need a sourceforge account to create a bug for Jython. I don't see anything special for your account in the admin controls for Jython. What does it say when you try to add a bug? Charlie ________________________________________________________________________ Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection. |
From: Charlie G. <cha...@gm...> - 2007-11-25 21:03:56
|
On Nov 24, 2007 1:29 AM, <bob...@ai...> wrote: > 1) Java System.nanoTime() needs java 1.5 so you have to check if you are > going to put it in a release that allows < Java 1.5. Yep, this is only going in on trunk which is for 1.5+. > 2) // A suggested solution > > private static double __initialclock__ = 0.0; > public static double clock() { > if (__initialclock__ == 0.0) { > // set on first call > __initialclock__ = System.nanoTime(); // keep __initialclock__ in > nanoSeconds > return 0.0; // I would add this return here - it could improve > accuracy by a few microseconds > } > return (System.nanoTime() - __initialclock__) / 1000000000.0; // > convert the time to seconds here That's pretty much what I did and it's committed in r3723. It gets a resolution of 0.005 ms with your script. Charlie |
From: <bob...@ai...> - 2007-11-26 01:42:02
|
Great!? A 15 millisecond to 5 microsecond improvement in time.clock() resolution is fantastic! ?- Bob -----Original Message----- From: Charlie Groves <cha...@gm...> To: bob...@ai... Cc: jyt...@li... Sent: Sun, 25 Nov 2007 3:03 pm Subject: Re: [Jython-dev] Jython Clock Resolution On Nov 24, 2007 1:29 AM, <bob...@ai...> wrote: > 1) Java System.nanoTime() needs java 1.5 so you have to check if you are > going to put it in a release that allows < Java 1.5. Yep, this is only going in on trunk which is for 1.5+. > 2) // A suggested solution > > private static double __initialclock__ = 0.0; > public static double clock() { > if (__initialclock__ == 0.0) { > // set on first call > __initialclock__ = System.nanoTime(); // keep __initialclock__ in > nanoSeconds > return 0.0; // I would add this return here - it could improve > accuracy by a few microseconds > } > return (System.nanoTime() - __initialclock__) / 1000000000.0; // > convert the time to seconds here That's pretty much what I did and it's committed in r3723. It gets a resolution of 0.005 ms with your script. Charlie ________________________________________________________________________ Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection. |