How to test time for piece of code

[Powergoo]

Hi everybody,

today I decidedly full of questions.

how to test the time it takes a piece of code.

I never used timers on amiga.

Now I change the color 0 of the copperliste but it is not very accurate.

thank you.

Powergoo

[phx]

Originally Posted by Powergoo

how to test the time it takes a piece of code.

I never used timers on amiga.

Now I change the color 0 of the copperliste but it is not very accurate.

Why? Which kind of accuracy do you need?

When you have a frame-based program (usually a game), then modifying a color is definitely a good method to see how much time it needs from the available frame length.

It is useless when you're interested in the Milliseconds or CPU cycles.

[Powergoo]

in fact I wish I could do:

value1 = actual_precise_timer
instructions
instructions
instructions
instructions
...
value2 = actual_precise_timer

timeofcode = value2 - value1

there are times to no copperliste

yes i'm interested in the Milliseconds or CPU cycles.

[phx]

Untested, but try something like this:

CIAB            equ     $bfd000

CIATALO         equ     $400
CIATAHI         equ     $500
CIACRA          equ     $e00


        ; clear and start Timer A
        lea     CIAB,a0
        moveq   #0,d0
        move.b  d0,CIATALO(a0)
        move.b  d0,CIATAHI(a0)
        ; force load, one-shot mode, start timer
        move.b  #%00011001,CIACRA(a0)

        ; ... do something ...

        ; stop timer and read result

        lea     CIAB,a0
        move.b  #$00,CIACRA(a0)
        moveq   #0,d0
        sub.b   CIATAHI(a0),d0
        lsl.w   #8,d0
        sub.b   CIATALO(a0),d0

        ; d0: time in 02 clocks

I chose CIA-B Timer A as the CIA-B timers are not used by the operating system. But note that other programs may use them, like for example a protracker playing routine.

I have set the timer to one-shot mode, so it stops when it underflows. Then you have a chance to detect such a case. When the code to measure requires more time than 65536 02-clocks (ca. 92ms) you can add Timer B and let it count underflows of Timer A. You would set bit 6 of CIACRB for that.

The CIA timers are counting backwards, so the result is subtracted from zero. To get the time in milliseconds or microseconds you need to know that the timer runs with 709379Hz on a PAL and with 715909Hz on an NTSC system.

If you want to be very precise you have to subtract the time for

        lea     CIAB,a0
        move.b  #$00,CIACRA(a0)

from the result.

[Powergoo]

Thanks you phx, I try this code this night

[Powergoo]

phx I tried your code but I still get 0 in the register d0

[Powergoo]

I feel that we must initialize the timer with a value other than 0.

I modified like this and I think it works ( d0 increase now )

In any case it's going to allow me to test whether a routine is faster than another.

If you see any problems do not hesitate to tell me because I have not really understand the 8520.

Thanks you phx for your help !

 
CIAB            equ     $bfd000

CIATALO         equ     $400
CIATAHI         equ     $500
CIACRA          equ     $e00

        ; clear and start Timer A
        lea     CIAB,a0
        moveq   #-1,d0
        move.b	d0,CIATALO(a0)
        move.b	d0,CIATAHI(a0)
        ; force load, one-shot mode, start timer
        move.b  #%00011001,CIACRA(a0)

        ; ... do something ...

	nop
	nop
	nop
	nop
		
        ; stop timer and read result

        lea     CIAB,a0
	move.b  #$00,CIACRA(a0)
        move.b	CIATAHI(a0),d1
        move.b	CIATALO(a0),d2
	moveq   #-1,d0
	lsl.w	#8,d1
	move.b	d2,d1
	sub.w   d1,d0

[meynaf]

Sorry to wake you up if your problem is solved already

Using CIA timers is perhaps a little bit overkill for that kind of use.
Personnally I start a vblank counter with AddIntServer() and run a loop containing the code i wish to test so that it takes a few seconds.

[Lonewolf10]

Originally Posted by meynaf

Using CIA timers is perhaps a little bit overkill for that kind of use.
Personnally I start a vblank counter with AddIntServer() and run a loop containing the code i wish to test so that it takes a few seconds.

So you're just trying to see how many times that code executes within a few seconds??

[Thorham]

Originally Posted by Lonewolf10

So you're just trying to see how many times that code executes within a few seconds??

That works perfectly fine. Or you could execute code an appropriate number of times and count how many frames it takes. On my 50 mhz 68030 I usually execute code snippets one million times and count the number of frames. I also turn off the system so that the OS doesn't affect the measurements.

[ReadOnlyCat]

Originally Posted by Lonewolf10

So you're just trying to see how many times that code executes within a few seconds??

Yes. If it's code that you can easily isolate then Meynaf's method wil give you relatively precise measurements because of the large number of loops.

However if you want to profile specific pieces of code inside a running program, just like a c/c++ compiler would for each function then you are better off with using timers.

This said, if you want to reduce overhead you could simply use the VPOS and HPOS registers. Keep a Vblank counter, then each time you want to store the current time, just dump VHPOSR, VPOSR, vblank counter (in this order) somewhere. You can then easily reconstruct the corresponding time later.

You probably will have to take into account that VPOS can increase between the moment you store HPOS and the moment you store VPOS but this is easily detected. The advantage of this method is that it is quite precise and requires very simple code to dump the current time to memory and thus has a small overhead.

[Leffmann]

Using the timers is not overkill if you want accuracte measurements, but if you care that much about accuracy then you can look up the cycle counts in the M68K User's Manual, then you'll know exactly how much time a piece of code will need.

But IMO skip the timers and the interrupts, and definitely skip membership in the "Cycle Counter Party", and just run your code multiple times and use the TOD clocks instead. You'll never have an error greater than about 64 µs, which means your result will be accurate within 0.01% even if you only measure over a single second.

EDIT: Example. Divide the result by the horizontal scan frequency if you want the time in seconds:

    (make sure the system interrupts are disabled while you run this)

    moveq   #0, d1
    move.b  CIABTODHI, d1
    swap    d1
    move.b  CIABTODMID, d1
    lsl.w   #8, d1
    move.b  CIABTODLO, d1

    (your code here)

    moveq   #0, d0
    move.b  CIABTODHI, d0
    swap    d0
    move.b  CIABTODMID, d0
    lsl.w   #8, d0
    move.b  CIABTODLO, d0

    sub.l   d1, d0
    bpl     .1
    add.l   #1<<24, d0

.1  (result in D0)

[ReadOnlyCat]

Originally Posted by Leffmann

But IMO skip the timers and the interrupts, and definitely skip membership in the "Cycle Counter Party", and just run your code multiple times and use the TOD clocks instead. You'll never have an error greater than about 64 µs, which means your result will be accurate within 0.01% even if you only measure over a single second.

EDIT: Example. Divide the result by the horizontal scan frequency if you want the time in seconds:

    (make sure the system interrupts are disabled while you run this)
    [...]
.1  (result in D0)

Nice. This has about the same overhead as dumping VHPOSR and VPOSR and requires a simpler conversion but is less precise (for one measurement).

I guess which of these methods to use really boils down to what the end usage is:
- If you want to profile many functions in an existing interactive program: use VHPOSR/VPOSR.
- If you want to time a specific function in isolation and does not need ultra precision: use Meynaf's VBL counter.
- If you want to time a specific function in isolation and *do* require high precision and do not want to wait: use Leffmann's time of day suggestion.

[meynaf]

Originally Posted by Leffmann

Using the timers is not overkill if you want accuracte measurements, but if you care that much about accuracy then you can look up the cycle counts in the M68K User's Manual, then you'll know exactly how much time a piece of code will need.

Cycle counts don't always work. For 68000, ok, no problem. But for 68020+, when cache misses and memory accesses (especially chipmem) come into play, timings become more and more unpredictable.

[hooverphonique]

Originally Posted by meynaf

Cycle counts don't always work. For 68000, ok, no problem. But for 68020+, when cache misses and memory accesses (especially chipmem) come into play, timings become more and more unpredictable.

but this will affect measurements using a timer as well, and the only solution to that is taking the average of many iterations.

[meynaf]

Originally Posted by hooverphonique

but this will affect measurements using a timer as well, and the only solution to that is taking the average of many iterations.

... which is exactly what i'm doing with my vbl trick. For very short code i could execute it up to 50,000,000 times.

[Lonewolf10]

Thorham and ReadOnlyCat,

Thanks for answering my question and confirming my suspicions