1. Rob: Verne Tice's High Resolution Timing routines
Great News: I found a "patch" solution to time()'s performance issues!
I feel so relieved now! 
Not only does Verne's library offer a high resolution time(), but also
out-performs Euphoria v2.5 time() and is even faster than v1.2 on DOS and about
25% faster on Windows. I made some minor optimizations (which sped up hrtime()
even more), and added memory deallocation routines to his library. I couldn't
test it on Linux or FreeBSD, but I imagine the performance would be much improved
too.
Not that you're is interested, but I thought I'd share the results. :
Sequence operations:
* v1.2 'EX.exe' has slightly faster slicing than v2.5 'EX.exe' w/ hrtime().
* v2.5 'EX.exe' w/ hrtime() performs 2x faster appending than v1.2 'EX.exe'.
* v2.5 'EX.exe' w/ hrtime() beats v1.2 'EX.exe' by a fair margin in all other
sequence tests.
* On Windows hrtime() is about 25% faster than regular time() on most
benchmarks, but is still beaten slightly by v1.2 'EX.exe' in 3 out of 5 sequence
tests (it's a close though, and the other 2 are faster).
Old Sieve:
* v2.5 'EX.exe' w/ hrtime() is ~1.622x faster than normal v2.5 time().
* v2.5 'EX.exe' w/ hrtime() is about 5-10% faster than v1.2 time().
* v2.5 'EXW.exe' w/ hrtime() is the same speed as normal v2.5 time().
New Sieve:
The newer sieve benchmark was designed better with very little reliance on
time() in determinding results. Both time() and hrtime() perform equally well on
both DOS & Windows; both of which are faster than v1.2 time().
The problem is the library uses the RDTSC CPU instruction, which is only
available in Pentium & K6 class CPUs and newer. So if you have a 386 or 486, your
out of luck and would have stick with normal time().
Another problem is if the CPU has dynamic clock frequency adjustment technology
(speed-step, etc.), it would have to be disabled in the BIOS first; otherwise you
could get unreliable timing results or worse.
These issues will probably prevent you from ever implementing this sort of thing
in the official Euphoria interpreters, but you should still mention this library
in the time() comment paragraph, in the reference manual.
Regards,
Vincent
2. Re: Rob: Verne Tice's High Resolution Timing routines
Vincent wrote:
>
> Great News: I found a "patch" solution to time()'s performance issues!
> I feel so relieved now!
>
> Not only does Verne's library offer a high resolution time(), but also
> out-performs
> Euphoria v2.5 time() and is even faster than v1.2 on DOS and about 25% faster
> on Windows. I made some minor optimizations (which sped up hrtime() even
> more),
> and added memory deallocation routines to his library. I couldn't test it on
> Linux or FreeBSD, but I imagine the performance would be much improved too.
>
> Not that you're is interested, but I thought I'd share the results. :
>
> Sequence operations:
> * v1.2 'EX.exe' has slightly faster slicing than v2.5 'EX.exe' w/ hrtime().
> * v2.5 'EX.exe' w/ hrtime() performs 2x faster appending than v1.2 'EX.exe'.
> * v2.5 'EX.exe' w/ hrtime() beats v1.2 'EX.exe' by a fair margin in all other
> sequence tests.
> * On Windows hrtime() is about 25% faster than regular time() on most
> benchmarks,
> but is still beaten slightly by v1.2 'EX.exe' in 3 out of 5 sequence tests
> (it's
> a close though, and the other 2 are faster).
>
> Old Sieve:
> * v2.5 'EX.exe' w/ hrtime() is ~1.622x faster than normal v2.5 time().
> * v2.5 'EX.exe' w/ hrtime() is about 5-10% faster than v1.2 time().
> * v2.5 'EXW.exe' w/ hrtime() is the same speed as normal v2.5 time().
>
> New Sieve:
> The newer sieve benchmark was designed better with very little reliance on
> time()
> in determinding results. Both time() and hrtime() perform equally well on both
> DOS
> & Windows; both of which are faster than v1.2 time().
>
>
> The problem is the library uses the RDTSC CPU instruction, which is only
> available
> in Pentium & K6 class CPUs and newer. So if you have a 386 or 486, your out
> of luck and would have stick with normal time().
>
> Another problem is if the CPU has dynamic clock frequency adjustment
> technology
> (speed-step, etc.), it would have to be disabled in the BIOS first; otherwise
> you could get unreliable timing results or worse.
>
> These issues will probably prevent you from ever implementing this sort of
> thing
> in the official Euphoria interpreters, but you should still mention this
> library
> in the time() comment paragraph, in the reference manual.
I haven't looked at his stuff in any detail,
but maybe there's a way of testing at start-up whether Verne's
routines can be used. If not, I would fall back to using the
normal time().
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Rob: Verne Tice's High Resolution Timing routines
Robert Craig wrote:
> I haven't looked at his stuff in any detail,
> but maybe there's a way of testing at start-up whether Verne's
> routines can be used. If not, I would fall back to using the
> normal time().
You could do it by detecting the processor ID with ASM. Based on that, you would
probably have to determind which Pentium or K6 class (and newer) of processors &
chipsets allow for dynamic clock frequency change (Intel's SpeedStep, AMD's
PowerNow! technologies). We know Intel's Centrino, mobile Pentium 3-4, and
Pentium M CPUs all support SpeedStep; AMD's Turon, mobile Athlon 64, power mobile
Athlon 64, and mobile Sempron CPUs all support PowerNow. You'd probably need to
keep track of a large list of different CPU models from different manufactures:
Intel, AMD, Cyrix, VIA, and Transmeta. You could then construct a chain of "if"
conditions that would determind whether to use the slow DOS interrupt or the fast
ASM high resolution time() routines.
Pete Eberlein demonstrates how to obtain CPU information with Euphoria machine
code (EuASM). It doesn't seem to give any information about SpeedStep or
PowerNow, but it gives you the basic idea.
http://www.rapideuphoria.com/test_cpu.zip
Although I'd love to have a fast time() routine, this would add much more ASM in
the source code then ever before, thus potentially causing more porting
difficulties. It wouldn't be to bad without the CPUID code, but without it, this
particular implementation of time() probably couldn't exist without failing at
some point.
I think until there is a cleaner, less invasive method adopted, we should just
stick with the library solutions. After reading this, you probably agree too.
Regards,
Vincent
4. Re: Rob: Verne Tice's High Resolution Timing routines
Hi Vin,
Do you have to have it work in dos too?
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
5. Re: Rob: Verne Tice's High Resolution Timing routines
- Posted by Vincent <darkvincentdude at yahoo.com>
Dec 18, 2005
-
Last edited Dec 19, 2005
Al Getz wrote:
> Do you have to have it work in dos too?
Assuming your system meets those basic requirements, his library should run on
all platforms Euphoria supports. His library includes much more than just a
hrtime() routine too. I might release my small optimized extention to his library
that performs slightly better and has necessary deallocation of memory, which he
probably forgot to add.
> Take care,
> Al
Regards,
Vincent
6. Re: Rob: Verne Tice's High Resolution Timing routines
- Posted by codepilot Gmail Account <codepilot at gmail.com>
Dec 18, 2005
-
Last edited Dec 19, 2005
Well how about using the normal timer interrupt counter and just using
the read time stamp instruction to interpolate between the timer
ticks, so the worst error would be less than a timer tick, and the
best outcome would increase the resolution of the timer.
Dan
On 12/18/05, Robert Craig <guest at rapideuphoria.com> wrote:
>
>
> posted by: Robert Craig <rds at RapidEuphoria.com>
>
> Vincent wrote:
> >
> > Great News: I found a "patch" solution to time()'s performance issues!
> > I feel so relieved now!
> >
> > Not only does Verne's library offer a high resolution time(), but also =
out-performs
> > Euphoria v2.5 time() and is even faster than v1.2 on DOS and about 25% =
faster
> > on Windows. I made some minor optimizations (which sped up hrtime() eve=
n more),
> > and added memory deallocation routines to his library. I couldn't test =
it on
> > Linux or FreeBSD, but I imagine the performance would be much improved =
too.
> >
> > Not that you're is interested, but I thought I'd share the results. =
:
> >
> > Sequence operations:
> > * v1.2 'EX.exe' has slightly faster slicing than v2.5 'EX.exe' w/ hrtim=
e().
> > * v2.5 'EX.exe' w/ hrtime() performs 2x faster appending than v1.2 'EX.=
exe'.
> > * v2.5 'EX.exe' w/ hrtime() beats v1.2 'EX.exe' by a fair margin in all=
other
> > sequence tests.
> > * On Windows hrtime() is about 25% faster than regular time() on most b=
enchmarks,
> > but is still beaten slightly by v1.2 'EX.exe' in 3 out of 5 sequence te=
sts (it's
> > a close though, and the other 2 are faster).
> >
> > Old Sieve:
> > * v2.5 'EX.exe' w/ hrtime() is ~1.622x faster than normal v2.5 time().
> > * v2.5 'EX.exe' w/ hrtime() is about 5-10% faster than v1.2 time().
> > * v2.5 'EXW.exe' w/ hrtime() is the same speed as normal v2.5 time().
> >
> > New Sieve:
> > The newer sieve benchmark was designed better with very little reliance=
on time()
> > in determinding results. Both time() and hrtime() perform equally well =
on both DOS
> > & Windows; both of which are faster than v1.2 time().
> >
> >
> > The problem is the library uses the RDTSC CPU instruction, which is onl=
y available
> > in Pentium & K6 class CPUs and newer. So if you have a 386 or 486, your=
out
> > of luck and would have stick with normal time().
> >
> > Another problem is if the CPU has dynamic clock frequency adjustment te=
chnology
> > (speed-step, etc.), it would have to be disabled in the BIOS first; oth=
erwise
> > you could get unreliable timing results or worse.
> >
> > These issues will probably prevent you from ever implementing this sort=
of thing
> > in the official Euphoria interpreters, but you should still mention thi=
s library
> > in the time() comment paragraph, in the reference manual.
>
> I haven't looked at his stuff in any detail,
> but maybe there's a way of testing at start-up whether Verne's
> routines can be used. If not, I would fall back to using the
> normal time().
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
>
>
