1. The New Asm's mhz.ex
- Posted by xerox_irs at lvcm.com
May 23, 2003
This is a multi-part message in MIME format.
------=_NextPart_000_0005_01C320A7.0979A460
charset="iso-8859-1"
Well this is actually an old problem, and I just never reported =
it(sorry) because I could fix it in a half-second. In the mhz.ex, the =
reading is inaccurate, it reports 167ish for my 700mhz, thats because =
over the course of 5 seconds, it generate about 3.5 billion ticks, and =
if it is just a slite tad faster, say generating 4.167 billion tick, =
well it drops off the '4' (cause 4billion is bigger than 32bit) or the =
amount (cyclemark2-cyclemark1) may be negetive leading me to believe it =
generates 4bill - 167mill.
Either way it either needs the full 64bit number,(which you can do as =
there are mmx instructions on most comps with rdtsc) or shorten the time =
of five seconds, so it doen't overflow, but yes this does decrease the =
accuracy.
This is a little tiny problem, not worth mentioning though, so its not a =
huge priority. But it may take a massive amount of effort to correct =
this(ie changing the 5 to a 1 or 2 in one place).
Thanks for the library
Daniel Kluss
------=_NextPart_000_0005_01C320A7.0979A460
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Well this is actually an old problem, =
and I just=20
never reported it(sorry) because I could fix it in a half-second. In the =
mhz.ex,=20
the reading is inaccurate, it reports 167ish for my 700mhz, thats =
because over=20
the course of 5 seconds, it generate about 3.5 billion ticks, and if it =
is just=20
a slite tad faster, say generating 4.167 billion tick, well it =
drops off=20
the '4' (cause 4billion is bigger than 32bit) or the amount=20
(cyclemark2-cyclemark1) may be negetive leading me to believe it =
generates 4bill=20
- 167mill.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Either way it either needs the full =
64bit=20
number,(which you can do as there are mmx instructions on most comps =
with rdtsc)=20
or shorten the time of five seconds, so it doen't overflow, but yes this =
does=20
decrease the accuracy.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This is a little tiny problem, not =
worth mentioning=20
though, so its not a huge priority. But it may take a massive amount of =
effort=20
to correct this(ie changing the 5 to a 1 or 2 in one =
place).</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks for the library</FONT></DIV>
------=_NextPart_000_0005_01C320A7.0979A460--
2. Re: The New Asm's mhz.ex
When I wrote that program I just used the same method as I had seen in a
C-program written by someone-i-can't-remember.. Since a cycle is such a
short period of time, especially on newer processors, the timing needs to be
spot-on, which can be hard to achieve. The difference you experienced seems
a little extreme though. Maybe it did overflow, I wasn't even aware there
was 64 bits of accuracy.
>From: xerox_irs at lvcm.com
>Subject: The New Asm's mhz.ex
>
>
>Well this is actually an old problem, and I just never reported it(sorry)
>because I could fix it in a half-second. In the mhz.ex, the reading is
>inaccurate, it reports 167ish for my 700mhz, thats because over the course
>of 5 seconds, it generate about 3.5 billion ticks, and if it is just a
>slite tad faster, say generating 4.167 billion tick, well it drops off the
>'4' (cause 4billion is bigger than 32bit) or the amount
>(cyclemark2-cyclemark1) may be negetive leading me to believe it generates
>4bill - 167mill.
>
>Either way it either needs the full 64bit number,(which you can do as there
>are mmx instructions on most comps with rdtsc) or shorten the time of five
>seconds, so it doen't overflow, but yes this does decrease the accuracy.
>
>This is a little tiny problem, not worth mentioning though, so its not a
>huge priority. But it may take a massive amount of effort to correct
>this(ie changing the 5 to a 1 or 2 in one place).
>
>Thanks for the library
>Daniel Kluss
>
>
>
>TOPICA - Start your own email discussion group. FREE!
3. Re: The New Asm's mhz.ex
- Posted by xerox_irs at lvcm.com
May 23, 2003
edx is the upper, eax is the lower
edx:eax = 64bit!!
Daniel Kluss
----- Original Message -----
From: <stabmaster_ at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: The New Asm's mhz.ex
>
>
> When I wrote that program I just used the same method as I had seen in a
> C-program written by someone-i-can't-remember.. Since a cycle is such a
> short period of time, especially on newer processors, the timing needs to
be
> spot-on, which can be hard to achieve. The difference you experienced
seems
> a little extreme though. Maybe it did overflow, I wasn't even aware there
> was 64 bits of accuracy.
>
>
> >From: xerox_irs at lvcm.com
> >Reply-To: EUforum at topica.com
> >To: EUforum <EUforum at topica.com>
> >Subject: The New Asm's mhz.ex
> >Date: Thu, 22 May 2003 21:13:48 -0700
> >
> >
> >Well this is actually an old problem, and I just never reported it(sorry)
> >because I could fix it in a half-second. In the mhz.ex, the reading is
> >inaccurate, it reports 167ish for my 700mhz, thats because over the
course
> >of 5 seconds, it generate about 3.5 billion ticks, and if it is just a
> >slite tad faster, say generating 4.167 billion tick, well it drops off
the
> >'4' (cause 4billion is bigger than 32bit) or the amount
> >(cyclemark2-cyclemark1) may be negetive leading me to believe it
generates
> >4bill - 167mill.
> >
> >Either way it either needs the full 64bit number,(which you can do as
there
> >are mmx instructions on most comps with rdtsc) or shorten the time of
five
> >seconds, so it doen't overflow, but yes this does decrease the accuracy.
> >
> >This is a little tiny problem, not worth mentioning though, so its not a
> >huge priority. But it may take a massive amount of effort to correct
> >this(ie changing the 5 to a 1 or 2 in one place).
> >
> >Thanks for the library
> >Daniel Kluss
> >
> >
> >TOPICA - Start your own email discussion group. FREE!
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
4. Re: The New Asm's mhz.ex
- Posted by xerox_irs at lvcm.com
May 23, 2003
the changes to mhz should look something like this
--code below
-- MHZ.EX. Measures the clock-speed of your processor.
-- /Mic, 2000
include asm.e
atom t,dt,cyclemark1,cyclemark2,mhz,cyclemark1h,cyclemark2h
integer key
constant val = allocate(8)
constant RDTSC = get_asm("pusha rdtsc mov [value],eax mov [value+4],edx popa
ret")
resolve_param("value",val)
puts(1,"Don\'t run this test unless you\'ve got a Pentium compatible or
greater.\n")
puts(1,"Press [Esc] to abort now, any other key to continue.\n")
key = -1
while key=-1 do
key = get_key()
end while
if key=27 then
abort(0)
end if
clear_screen()
dt = 10--seconds are nothing!!!, can be up to about 100 or so years before
overflow now
--but with 32 bit 5 seconds would overflow half of the time with 700mhz
allthetime with 850mhz
printf(1,"Timing performance, wait %d seconds.\n",dt)
t = time()
call(RDTSC)
cyclemark1 = peek4u(val)
cyclemark1h = peek4u(val+4)
while (t+dt>time()) do
end while
call(RDTSC)
cyclemark2 = peek4u(val)
cyclemark2h = peek4u(val+4)
mhz =
(cyclemark2-cyclemark1)/(1000000*dt)+(cyclemark2h-cyclemark1h)/(1000000*dt/#
100000000)
--if mhz<0 then mhz = -mhz end if
printf(1,"This processor is running at approx %1.3f MHz\n",mhz)
----- Original Message -----
From: <xerox_irs at lvcm.com>
To: "EUforum" <EUforum at topica.com>
Sent: Friday, May 23, 2003 3:02 AM
Subject: Re: The New Asm's mhz.ex
>
>
> edx is the upper, eax is the lower
> edx:eax = 64bit!!
>
> Daniel Kluss
> ----- Original Message -----
> From: <stabmaster_ at hotmail.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Friday, May 23, 2003 2:46 AM
> Subject: Re: The New Asm's mhz.ex
>
>
> > When I wrote that program I just used the same method as I had seen in a
> > C-program written by someone-i-can't-remember.. Since a cycle is such a
> > short period of time, especially on newer processors, the timing needs
to
> be
> > spot-on, which can be hard to achieve. The difference you experienced
> seems
> > a little extreme though. Maybe it did overflow, I wasn't even aware
there
> > was 64 bits of accuracy.
> >
> >
> > >From: xerox_irs at lvcm.com
> > >Reply-To: EUforum at topica.com
> > >To: EUforum <EUforum at topica.com>
> > >Subject: The New Asm's mhz.ex
> > >Date: Thu, 22 May 2003 21:13:48 -0700
> > >
> > >
> > >Well this is actually an old problem, and I just never reported
it(sorry)
> > >because I could fix it in a half-second. In the mhz.ex, the reading is
> > >inaccurate, it reports 167ish for my 700mhz, thats because over the
> course
> > >of 5 seconds, it generate about 3.5 billion ticks, and if it is just a
> > >slite tad faster, say generating 4.167 billion tick, well it drops off
> the
> > >'4' (cause 4billion is bigger than 32bit) or the amount
> > >(cyclemark2-cyclemark1) may be negetive leading me to believe it
> generates
> > >4bill - 167mill.
> > >
> > >Either way it either needs the full 64bit number,(which you can do as
> there
> > >are mmx instructions on most comps with rdtsc) or shorten the time of
> five
> > >seconds, so it doen't overflow, but yes this does decrease the
accuracy.
> > >
> > >This is a little tiny problem, not worth mentioning though, so its not
a
> > >huge priority. But it may take a massive amount of effort to correct
> > >this(ie changing the 5 to a 1 or 2 in one place).
> > >
> > >Thanks for the library
> > >Daniel Kluss
> > >
> > >
> > >TOPICA - Start your own email discussion group. FREE!
> >
> >
> > TOPICA - Start your own email discussion group. FREE!
> >
> >
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
5. Re: The New Asm's mhz.ex
>the changes to mhz should look something like this
>--code below
I was thinking more like...
*************** CODE BEGINS *******************
include asm.e
atom t,dt,cyclemark1,cyclemark2,mhz
integer key
constant val = allocate(8)
constant RDTSC = get_asm("rdtsc mov [value],eax mov [value+4],edx ret")
resolve_param("value",val)
puts(1,"Don\'t run this test unless you\'ve got a Pentium compatible or
greater.\n")
puts(1,"Press [Esc] to abort now, any other key to continue.\n")
key = -1
while key=-1 do
key = get_key()
end while
if key=27 then
abort(0)
end if
clear_screen()
dt = 5
printf(1,"Timing performance, wait %d seconds.\n",dt)
t = time()
call(RDTSC)
cyclemark1 = peek4u(val)
cyclemark1 += peek4u(val+4)*power(2,32)
while (t+dt>time()) do
end while
dt = time()-t
call(RDTSC)
cyclemark2 = peek4u(val)
cyclemark2 += peek4u(val+4)*power(2,32)
mhz = (cyclemark2-cyclemark1)/(1000000*dt)
if mhz<0 then mhz = -mhz end if
printf(1,"This processor is running at approx %1.3f MHz\n",mhz)
*********************** CODE ENDS ***************************
It's still about 1% off for my processor though, but maybe it fixes the
overflow-problem for faster processors at least.
6. Re: The New Asm's mhz.ex
- Posted by xerox_irs at lvcm.com
May 23, 2003
thats that same thing, I just dont know how much of a 64bit integer you can
fit into a double(i think 54 bits of presision), thats why I split mine up,
into two and did the math seperatly. But this will work just fine. Thanks
for making it 64bit, now I don't have a 167mhz processor, I have a 704mhz
processor. Just proof the realtime clock is not super accurate, it would be
even more fun to run this on a computer with Spread Spectrum Modulation on
the cpu, you would get very funny numbers.
Daniel Kluss
----- Original Message -----
From: <stabmaster_ at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Sent: Friday, May 23, 2003 6:29 AM
Subject: Re: The New Asm's mhz.ex
>
>
> >the changes to mhz should look something like this
> >--code below
>
> I was thinking more like...
>
> *************** CODE BEGINS *******************
>
> include asm.e
>
> atom t,dt,cyclemark1,cyclemark2,mhz
> integer key
>
> constant val = allocate(8)
> constant RDTSC = get_asm("rdtsc mov [value],eax mov [value+4],edx ret")
> resolve_param("value",val)
>
>
> puts(1,"Don\'t run this test unless you\'ve got a Pentium compatible or
> greater.\n")
> puts(1,"Press [Esc] to abort now, any other key to continue.\n")
> key = -1
> while key=-1 do
> key = get_key()
> end while
> if key=27 then
> abort(0)
> end if
>
> clear_screen()
> dt = 5
> printf(1,"Timing performance, wait %d seconds.\n",dt)
>
> t = time()
>
> call(RDTSC)
> cyclemark1 = peek4u(val)
> cyclemark1 += peek4u(val+4)*power(2,32)
> while (t+dt>time()) do
> end while
> dt = time()-t
>
> call(RDTSC)
> cyclemark2 = peek4u(val)
> cyclemark2 += peek4u(val+4)*power(2,32)
>
> mhz = (cyclemark2-cyclemark1)/(1000000*dt)
> if mhz<0 then mhz = -mhz end if
>
> printf(1,"This processor is running at approx %1.3f MHz\n",mhz)
>
> *********************** CODE ENDS ***************************
>
> It's still about 1% off for my processor though, but maybe it fixes the
> overflow-problem for faster processors at least.
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
