Hi All,
Are there any good profilers for the Amiga? I know we have Hieronymus but it does not support my Amiga One.
I check online and found this guy: http://sourceforge.net/projects/shinyprofiler/?source=dlp
I can see how helpful this type of tool would be.
Cheers,
Bill
What's special about your AmigaOne? Also, though I'd hate to add confusion, are you talking about a "real" AmigaOne or a new machine based on the concept but not hardware like a Sam or X1000?
I ask as I just downloaded it from the location below and it works on my AmigaOne setup. (XE.) According to the readme it only works reliably on an AmigaOne machine. What does it do on your machine?
http://os4depot.net/share/development/debug/hieronymus.lha
Hi Hypex,
I think my proc is not supported:
> Hieronymus
Sorry, Hieronymus can't run on that hardware at the moment
My AmigaOne has the 74XX@800 mhz according to Ranger.
Cheers,
Bill
Hi, I am really excited to see people want to use such tools and ... Hieronymus!
tekmage: Good news, version under development actually supports your machine. The processor is not the problem but the machine is: the program won't work on Pegasos but it works on AmigaOne (with G3 or G4 processors).
I recently started major changes in Hieronymus but if you need, I suppose I can release a small update quickly.
Edit: Such a small update would be easy as the project has a (private) SVN repository. Go to the revision with the needed patch, compile, pack and upload :-)
@Corto
Will be also nice if you can support peg2 as well (i can help with all the tests)
kas1e: Using my nominal approach, it is impossible because that requires some work in the OS, like what was done on Sam440.
But I started another approach recently that could allow Pegasos2 for example to provide valid results. I need more time to finish to implement that but I have many ideas for Hieronymus in the future.
I wonder what stops it working on any hardware? After all isn't it a program that uses the OS? Unless it really needs to be tied to one piece of hardware and CPU because it hardware hacks a memory location or runs a raw PowerrPC interrupt I don't see why it isn't working. OS4 must still be a poor OS if it doesn't provide standard OS4 compiled programs with features that work on all platforms. The OS should do it in the abstract and refer to a HAL to do the low level work. :-?
Oh BTW, from the description of tekimage's machine, it looks like he has an AmigaOne G4. So why doesn't it work? ;-)
hypex: I understand your analysis but that is not that simple. This program does not work on all platforms because to get information I need from the interrupt server, consider a driver is required, that is platform dependent.
If tekmage's machine is not supported in the available version, that is just because I made the bad assumption that AmigaOne machines were build with a G3 processor. And detecting the G4 processor was not enough, I had to find if the machine was a Pegasos 2 or an AmigaOne.
Anyway, the second approach I've started to work on will not have the same limitations (even if it will be based on the performance monitor that is not available on Sam4x0 or is different on PA6T).
Hey guys, yesterday evening, I uploaded Hieronymus 0.21, here on os4depot. It is available now, I had a free 30-minute slot yesterday :-)
This version only provides a better hardware detection, what allows users of AmigaOne machines with a G4 processor to run the tool.
I have really many ideas to improve it, I'm really excited about implementing them and see the benefits it can provide to developers.
Please use it and provide feedback, ask questions if there is something you don't understand.
@corto
Thanks for this update.
Are you considering trying to report hits only in terms of "user" code (I mean, to avoid 60% of hits anywhere in rtg.library when doing heavy rendering for example). I don't know if it would be easy to implement but it would definitely be very useful. I think there are functions to browse stack frames in the new SDK. Rom code is mapped to a special address range, maybe at least for kickstart modules it would be possible (without hacking ?) to quickly know if you can try to go up one stackframe and possibly land in an exe.
Centaurz: If you talk about ignoring hits from supervisor mode and only keep hits from user mode, I think I can't at the moment. If I succeed in using the performance monitor in Hieronymus, it mayb be possible, I don't remember exactly.
Can't you just ignore code from libraries? Note that if 60% is spent in rtg.library that makes me think that:
- It is a high rate! Maybe that hightlights a problem in the caller design?
- In any cases, that would be really valuable to have some libraries with their debug symbols (maybe you would see that the most called functions are not the ones your suspected).
I will look at new functions about the stack frame. But to manipulate that, I think that would require a software with a GUI. I started one at the beginning of Hieronymus but it was too early in the project.
About how to display the report, I think I will reorganize it, more like Linux perf tool, per functions and not perf program and then per function.
@corto
No, I mean for those hits in kernel modules (or disk-based libraries devices) which actually correspond to calls from a user program, try to report the name of the user function hit instead of the place where the PC was at the time you sampled it. Because it will be more meaningful to the application programmer. Here's an example :
Say you have those 2 functions in your program : render_gradient() and blit_my_bitmap(). Both involve costing calls to graphics.library which in turns calls rtg.library (P96). So almost all hits in those functions will end up in rtg.library and you can't tell which one takes more CPU time and is a good candidate for optimization.
Ok, I see. That would be great, I will try (and I write that in the todo list). It would also be helpful to have libraries with symbols but without them, what you propose would allow to get information event when the library doesn't want to provide some.
@corto
The program is more complicated than I was thinking. And goes a lot deeper. I was thinking of it profiling one program itself but it is system wide. That also makes it look hard to dicern one program from the rest! :-)