idea. measure speed

[FedePede04]

hi
do anybody have a good idea how to measure speed.
i know you can get Hatari to do a profile, but i think, that i am not smarting enough to do that

the situations is this, the original road routine is first clearing the left side of the road, print left, right side of the road and then filling it, then its clearing the right side.
if no road is present at that line then it clear the whole line.
(its doing all about on all 4 bp)

i have found that the road is not printed on bp3,bp4 , so i use the blitter to clear bp3, bp4 on the whole bottom array, so now i only have to clear bp1 and bp2 left and right, and print the road, on either bp1 or bp2. (use the blitter on all about)

but i have been thinking of just clear the whole button array (all 4 bp) using movem.l
when i can save a lot of test and loop for all the clear routine and all the init of the blitter, up to 3 times on every line,
but i will clear one bp more that is necessary but only where the road is. so my question is, is it faster, i think it could be but it would be nice to know for sure.

I welcome all idea and inputs

[mlynn1974]

I haven't been able to get the profiler in Hatari to produce any meaningful results.

I think the problem using the blitter is the STs interleaved bitplanes making it difficult to leave certain bitplanes untouched whereas the Amiga's non-interleaved bitplanes make it much easier to clear one bp at a time.

Is the road built offscreen and then the whole thing composited on the back buffer (road + sprites)?
The varying height of the road means memory use and processor time to draw the road varies. Previous sections of road are basically a scrolling buffer but the edges only have to be calculated and masked once and then scrolled down. The split in the road is a complication. No wonder the arcade machine had a separate 68000 just to draw the road!

This topic may help:
http://www.atari-forum.com/viewtopic.php?t=2804

I think FrankB did a great blitter test program.

[FedePede04]

I haven't been able to get the profiler in Hatari to produce any meaningful results.

I think the problem using the blitter is the STs interleaved bitplanes making it difficult to leave certain bitplanes untouched whereas the Amiga's non-interleaved bitplanes make it much easier to clear one bp at a time.

Is the road built offscreen and then the whole thing composited on the back buffer (road + sprites)?
The varying height of the road means memory use and processor time to draw the road varies. Previous sections of road are basically a scrolling buffer but the edges only have to be calculated and masked once and then scrolled down. The split in the road is a complication. No wonder the arcade machine had a separate 68000 just to draw the road!

This topic may help:
http://www.atari-forum.com/viewtopic.php?t=2804

I think FrankB did a great blitter test program.

Many thanks for the input, the blitter routines work fine it clearing the right bp.
it just if i redo most of the road routine, it would be nice to see if i got any speed gain.

btw i have been reading a little about the cannonball project, and it also said how they did the road (not in detail) but they did use a lot of pre-calculate data and lists.
but they are really happy for mul, div, lsl.l #8 lsr.l #8 in the Atari version , but my knowledge of pseudo racer are just to small to change it.

they are calculate the width of the road using mul and div not only one every line, at least 3, (but i have to look it up to know precise).
but i would say if you have the z position and know if the road is, example a 6 lane, you could have the width in a list, instead of using mul and div.
yes the Sega had a 68000 running at 12.5 mhz only for the road, but what is even worse was, it was optimize for speed, and the Atari is not :'(

i think that ill try and redo the road routine tomorrow, maybe i can see something positive on the fps
but thanks again for taking you time to reply

[thomas3]

Is the road clear/redraw routine too convoluted to simply count the cycles?

[FedePede04]

Is the road clear/redraw routine too convoluted to simply count the cycles?

hi Thomas, no the road routine is to complex.

[wietze]

I can profile for you if you have different routines to compare.

Just send both projects over, and ill run a compare tonite.

[FedePede04]

I can profile for you if you have different routines to compare.

Just send both projects over, and ill run a compare tonite.

Many thank, ill send them, when i have made the new routine

[FedePede04]

Hi wietze
I have send you the files

and thanks again

[Eero Tamminen]

do anybody have a good idea how to measure speed.
i know you can get Hatari to do a profile, but i think, that i am not smarting enough to do that

Nowadays using it should be fairly straightforward.

1. compile your program with debug symbols
2. enter the debugger (AltGr+Pause) after your program starts => debugger loads debug symbols automatically from the program
3. set breakpoints to start and end of the part you want to profile "a <address/symbol name>"
4. enable profiling ("profile on")
5. continue emulation ("c") until you get the breakpoint at the end => debugger gives backtrace to current place in code and tells how many instructions / cycles / time was spent between breakpoints / debugger invocations
6. you can now investigate the collected profiling data directly with commands you see with "profile help": https://hatari.tuxfamily.org/doc/manual.html#Profiling
7. To get new data, just continue emulation again

Personally I prefer saving annotated disassembly to a file ("profile save profile.txt") and read that directly. From the profile.txt you can see how many cycles each instruction address took, how many times each of them was excuted, and were there unexpected instruction cache misses & expected data cache hits.

To post-process the saved file, you need your program symbols in ASCII format: "gst2ascii <program> > symbols.txt". Post-processing with "hatari_profile.py -stp -r symbols.txt profile.txt" gives you symbols (functions / subroutines / loops) that cost most in regards to number of calls, instructions, cycles and i-cache misses. Cycles is naturally most relevant of those. More info: https://hatari.tuxfamily.org/doc/manual ... processing

The main hard thing is having good symbol data. If suitable places in code don't have a symbol, the provided data can be misleading (garbage in -> garbage out). All subroutines and interrupt routines should preferably have symbols, and none of the loops, unless you explicitly want info on some specific loop (loop symbols can slow down profiling a lot, and loop start call count could be misunderstood).

[chicane]

When I was working on Pole Position, the inbuilt demo mode came in handy for profiling purposes because it ran exactly the same demo sequence every time. I put in some code to count the total number of frames drawn during the execution of the demo and then displayed this on the title screen once the demo was complete. A higher number of frames would indicate better optimized code. It's something of a blunt approach but I got a lot of mileage out of it.

Am I right in remembering that ST Out Run has a demo mode, and if so, could the above approach (or a variation of it) be used to help you test the performance impact of your changes?

[FedePede04]

do anybody have a good idea how to measure speed.
i know you can get Hatari to do a profile, but i think, that i am not smarting enough to do that

Nowadays using it should be fairly straightforward.

1. compile your program with debug symbols
2. enter the debugger (AltGr+Pause) after your program starts => debugger loads debug symbols automatically from the program
3. set breakpoints to start and end of the part you want to profile "a <address/symbol name>"
4. enable profiling ("profile on")
5. continue emulation ("c") until you get the breakpoint at the end => debugger gives backtrace to current place in code and tells how many instructions / cycles / time was spent between breakpoints / debugger invocations
6. you can now investigate the collected profiling data directly with commands you see with "profile help": https://hatari.tuxfamily.org/doc/manual.html#Profiling
7. To get new data, just continue emulation again

Personally I prefer saving annotated disassembly to a file ("profile save profile.txt") and read that directly. From the profile.txt you can see how many cycles each instruction address took, how many times each of them was excuted, and were there unexpected instruction cache misses & expected data cache hits.

To post-process the saved file, you need your program symbols in ASCII format: "gst2ascii <program> > symbols.txt". Post-processing with "hatari_profile.py -stp -r symbols.txt profile.txt" gives you symbols (functions / subroutines / loops) that cost most in regards to number of calls, instructions, cycles and i-cache misses. Cycles is naturally most relevant of those. More info: https://hatari.tuxfamily.org/doc/manual ... processing

The main hard thing is having good symbol data. If suitable places in code don't have a symbol, the provided data can be misleading (garbage in -> garbage out). All subroutines and interrupt routines should preferably have symbols, and none of the loops, unless you explicitly want info on some specific loop (loop symbols can slow down profiling a lot, and loop start call count could be misunderstood).

thanks, its a little to complicate for me, but wietze was very nice to help me out, but i can see what you mean with it can be hard to tell the different, between useful data and not so useful data.

but thanks again for the input

[FedePede04]

When I was working on Pole Position, the inbuilt demo mode came in handy for profiling purposes because it ran exactly the same demo sequence every time. I put in some code to count the total number of frames drawn during the execution of the demo and then displayed this on the title screen once the demo was complete. A higher number of frames would indicate better optimized code. It's something of a blunt approach but I got a lot of mileage out of it.

Am I right in remembering that ST Out Run has a demo mode, and if so, could the above approach (or a variation of it) be used to help you test the performance impact of your changes?

it a little the same with this program same demo every time
so i think it a good idea, but i needed it on a more a single routine level, i had made 3 different program, with the same routine that had been alter. but i did not think the different would be so that i could use you trick.
but maybe it could be fun to add into the original version and the latest just to see the different

[Eero Tamminen]

If there's a demo sequence, it possible to use Hatari debugger & profiler to automatically identify slowest frame in the demo and automatically provide profile for it.

It's quite convoluted to set up, but it was very handy with Falcon Bad Mood (especially as it could do that both for CPU and DSP side at the same time, and provide backtraces to what caused (very slow) disk accesses that resulted from in-RAM resource cache misses).

[Cyprian]

I think the problem using the blitter is the STs interleaved bitplanes making it difficult to leave certain bitplanes untouched whereas the Amiga's non-interleaved bitplanes make it much easier to clear one bp at a time.

actually the BLiTTER can clear whatever bitplane combination you want in a one pass.

also if you need you can do one bitplane in a first pass, and next bitplane in a second pass. In best case only two instructions are needed for starting next the BLiTTER pass:

Code: Select all

   move.w d0,(a0)
   move.b d1,(a1)