idea. measure speed

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
FedePede04
Atari God
Atari God
Posts: 1211
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

idea. measure speed

Postby FedePede04 » Tue Jun 11, 2019 8:40 pm

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 :oops: :lol:

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 :D
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

mlynn1974
Captain Atari
Captain Atari
Posts: 279
Joined: Mon Mar 03, 2008 10:33 pm
Contact:

Re: idea. measure speed

Postby mlynn1974 » Tue Jun 11, 2019 10:37 pm

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.
Still got, still working: Atari 4Mb STe, 520STFM, 2.5Mb STF.
Hardware: Cumana CSA 354, Ultimate Ripper, Blitz Turbo, Synchro Express II (US and UK Versions).

User avatar
FedePede04
Atari God
Atari God
Posts: 1211
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: idea. measure speed

Postby FedePede04 » Tue Jun 11, 2019 11:02 pm

mlynn1974 wrote: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:
viewtopic.php?t=2804

I think FrankB did a great blitter test program.


Many thanks for the input, the blitter routines work fine :D it clearing the right bp. :D
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 :D
but thanks again for taking you time to reply :D
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

User avatar
thomas3
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 130
Joined: Tue Apr 11, 2017 8:57 pm
Location: the people's republic of south yorkshire, uk.

Re: idea. measure speed

Postby thomas3 » Tue Jun 11, 2019 11:20 pm

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

User avatar
FedePede04
Atari God
Atari God
Posts: 1211
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: idea. measure speed

Postby FedePede04 » Wed Jun 12, 2019 5:43 am

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


hi Thomas, no the road routine is to complex.
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

wietze
Captain Atari
Captain Atari
Posts: 272
Joined: Fri Mar 01, 2013 10:52 pm

Re: idea. measure speed

Postby wietze » Wed Jun 12, 2019 5:54 am

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

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

User avatar
FedePede04
Atari God
Atari God
Posts: 1211
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: idea. measure speed

Postby FedePede04 » Wed Jun 12, 2019 6:00 am

wietze wrote: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 :cheers: :D
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

User avatar
FedePede04
Atari God
Atari God
Posts: 1211
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: idea. measure speed

Postby FedePede04 » Wed Jun 12, 2019 7:50 am

Hi wietze
I have send you the files :D

and thanks again :D
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1986
Joined: Sun Jul 31, 2011 1:11 pm

Re: idea. measure speed

Postby Eero Tamminen » Fri Jun 14, 2019 11:51 pm

FedePede04 wrote: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 :oops: :lol:


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
Atari freak
Atari freak
Posts: 73
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: idea. measure speed

Postby chicane » Sat Jun 15, 2019 8:04 am

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?

User avatar
FedePede04
Atari God
Atari God
Posts: 1211
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: idea. measure speed

Postby FedePede04 » Sun Jun 16, 2019 1:04 am

Eero Tamminen wrote:
FedePede04 wrote: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 :oops: :lol:


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 :D
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

User avatar
FedePede04
Atari God
Atari God
Posts: 1211
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: idea. measure speed

Postby FedePede04 » Sun Jun 16, 2019 1:09 am

chicane wrote: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 :D
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 :D
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1986
Joined: Sun Jul 31, 2011 1:11 pm

Re: idea. measure speed

Postby Eero Tamminen » Sun Jun 16, 2019 9:57 pm

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).

User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1750
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: idea. measure speed

Postby Cyprian » Mon Jun 17, 2019 9:57 am

mlynn1974 wrote: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)
Lynx II / Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 5 guests