Who's Online |
165 user(s) are online ( 105 user(s) are browsing Forums)
Members: 0
Guests: 165
more...
|
|
Headlines |
-
amiarcadia.lha - emulation/gamesystem
Apr 28, 2024
-
ifarchive_dl.lha - utility/script
Apr 28, 2024
-
kt_scripts.lha - utility/script
Apr 28, 2024
-
stream.lha - utility/benchmark
Apr 27, 2024
-
thumbnailmaker.lha - video/misc
Apr 26, 2024
-
mce.lha - game/utility
Apr 23, 2024
-
theme_list.lha - utility/misc
Apr 23, 2024
-
faac.lha - audio/convert
Apr 22, 2024
-
faad2.lha - audio/convert
Apr 22, 2024
-
seq.lha - audio/misc
Apr 22, 2024
|
|
|
|
Re: Introducing Profyler
|
Posted on: 2022/1/25 7:29
#141
|
Just popping in
|
@kas1e Here's a simple example that demonstrates the failure to produce source file name and line number information. Save it as "SymbolFail.c".
// Simple example to demonstrate lack of source file name and line
// number in symbol information returned by ObtainDebugSymbol().
#include <exec/types.h>
#include <exec/debug.h>
#include <stdio.h>
#include <proto/exec.h>
int main(int argc, char **argv)
{
struct DebugSymbol *Ourself;
// Get symbol information about ourself.
Ourself = IDebug->ObtainDebugSymbol(&main, NULL);
// Display the base name.
if(Ourself && Ourself->SourceBaseName)
printf("Base name: %s\\n", Ourself->SourceBaseName);
else
printf("No base name!\\n");
// Display the function name.
if(Ourself && Ourself->SourceFunctionName)
printf("Function name: %s\\n", Ourself->SourceFunctionName);
else
printf("No function name!\\n");
// Display the source file name (this always fails).
if(Ourself && Ourself->SourceFileName)
printf("Source file name: %s\\n", Ourself->SourceFileName);
else
printf("No source file name!\\n");
// Display the source file line number (this always fails).
if(Ourself && Ourself->SourceLineNumber)
printf("Source line number: %ld\\n", Ourself->SourceLineNumber);
else
printf("No source line number!\\n");
// We're done with the symbol info.
IDebug->ReleaseDebugSymbol(Ourself);
// All done.
return(0);
}
Build it with this makefile:
CC = gcc
CFLAGS = -O0 -Wall -gstabs
LN = gcc
LDFLAGS =
OBJS = SymbolFail.o
SymbolFail: $(OBJS)
$(LN) $(LDFLAGS) $(OBJS) -lauto -o $@
SymbolFail.o: SymbolFail.c
$(CC) $(CFLAGS) -c $< -o $@
When run, it displays: Base name: SymbolFail Function name: main No source file name! No source line number!
|
|
|
|
Re: Introducing Profyler
|
Posted on: 2022/1/24 4:48
#142
|
Just popping in
|
@IamSONIC You've got the same large differences in printf() speed as I see on my system, so the X5000 doesn't seem to make a difference there. From your tests- Average time for MyPrintf() in original MultiThread example: Launched from shell = 0.277 ms Launched from shell via Run = 1.972 ms Launched from Workbench = 86.481 ms I can see why launching from the shell would be the fastest, as the program can use the shell's I/O streams. 'Run'ing the program also uses the shell's I/O streams, but since they're shared with the shell and potentially with other programs I imagine there's some resource locking involved which would slow things down some. But why Workbench takes so long to write to the console window it opens is a puzzler. Not counting printf(), there doesn't seem to be any significant difference in speed between the GCC 8.3.0 and 11.1.0 versions of the test programs. The GCC 11 code may be a tiny bit faster, but nothing notable. So the difference in speed relative to my tests seems to be entirely due to the X5000. Would it be possible to run the 'Simple' test program? I'd like to see how the two null functions perform for both versions of the compiler. No need to run the program in all the different ways, since the null functions don't print anything and so won't vary depending on the launch method. Quote: Note: In order to execute "SOLibTest" from your original Tests (GCC 8.3.0 built) i had to use my GCC 11.1.0 built "MyLib.so" because it is not included.
Oops! You're right- I totally missed putting that into the archive. Something to fix in the next release.
|
|
|
|
Re: Introducing Profyler
|
Posted on: 2022/1/24 4:38
#143
|
Just popping in
|
@trixie
One of my genetic defects is that I believe in well documented software, and in fact enjoy writing documentation. The down side is that it takes me longer to produce something, since all that writing takes additional time.
Documentation is kind of an iterative process; as I'm writing about how to use the program I sometimes come across some awkwardness in the operation that I might not notice when using the program myself, but that becomes obvious when I have to explain it to someone else. Then I have to go back and fix it in the code. In the case of a technical tool like Profyler I also have to make sure I know what I'm talking about when I explain the technical details, which involves additional research and testing.
|
|
|
|
Re: Introducing Profyler
|
Posted on: 2022/1/23 3:55
#144
|
Just popping in
|
@kas1e
I've seen the location information sometimes in the GR window, but I thought maybe it did its own parsing of the debug data using elf.library, rather than using ObtainDebugSymbol().
As you can see in the makefile for the test programs, I do use -gstabs in the compiler arguments. I didn't think I needed to add it to the linker arguments as well, but I just gave that a try. It didn't make any difference; still no location data.
I'll see if I can come up with a simple, stand-alone program that displays the problem.
|
|
|
|
Re: Introducing Profyler
|
Posted on: 2022/1/23 3:50
#145
|
Just popping in
|
@IamSONIC
I know the X5000 is faster, but I didn't think it was almost twice as fast. And indeed, the MIPS and DMIPS numbers you quote suggest that it's 30% to 50% faster. Yet comparing your profile numbers to those on my X1000 (with the test programs in my case compiled with GCC 8.3.0) shows that your numbers are almost twice as fast.
(Note that you can't readily compare anything that calls printf(), since the speed of writing to a console window depends greatly on how the test program was run, which you didn't indicate. You get one set of numbers if you run it by typing its name in a shell, a different set if you type 'run' and then the program's name in the shell, and a third set if you run it from Workbench by double-clicking it. So when comparing I concentrated on the "average exclusive" times, which don't count calls to MyPrintf().)
That leaves GCC as the unknown quantity. I haven't installed GCC 11 yet, so I can't try it to see what difference I get. Maybe you could try running the test programs as provided with Profyler, which are compiled with GCC 8.3.0, and comparing those results to the ones you get when they're compiled with GCC 11.1.0.
|
|
|
|
Re: Introducing Profyler
|
Posted on: 2022/1/22 1:48
#146
|
Just popping in
|
Thanks everyone, for the welcome.
@afxgroup
Not back, really; I've been here all along (just not posting to forums). I wrote my first Amiga program in AmigaBasic on my A1000 (with no hard drive) back in the late 80s, and uploaded it to CompuServe's Amiga forums via a 2400 baud modem. I've been writing Amiga programs ever since.
@walkero
Yes, you've mentioned PassPocket in your emails. I'll likely have some noob questions of my own, when it comes to using the forum here.
Naturally, I used PassPocket as a test subject for Profyler (if you look closely at the source for the latest version you'll see the profiling macros in there).
@IamSONIC
Glad it works for you, and with a much newer version of GCC. I can only do so much testing on my one OS4 system, so I'll have to depend on the folks here to test it more widely.
I notice you've got some execution times down in the 500 - 600 ns range. The fastest I've ever seen on my X1000 is around 1 us. I don't know if the difference is due to the X5000 (is it that much faster?), or perhaps the newer version of GCC is more efficient at function calls. Interesting.
@kas1e
It was hard to keep quiet during all the past discussions here about OS4 profilers (that's where I heard about Tequila), but I hate to pre-announce stuff as then I feel like I'm under pressure to get it done. Better to sneak up on people.
I've actually been working on Profyler for a year and a half, though there were a number of times where I took a month or two off to work on other projects (both Amiga-related and not).
Regarding ObtainDebugSymbol: I suspect it's more of an unimplemented feature than an actual bug. The DebugSymbol struct it returns has fields for SourceFileName and SourceLineNumber, but there's never anything in them. Perhaps they planned to add that in the future and never got around to it.
You can turn the Location column on using the list browser's pop-up menu; it might be worth checking on some other Amiga systems/kernels to see if the location information is missing on them as well.
Edited by msteed on 2022/1/22 2:43:35
|
|
|
|
Introducing Profyler
|
Posted on: 2022/1/21 3:00
#147
|
Just popping in
|
Hello, everyone! I've been lurking here for years, as there seems to be a high proportion of OS4 programmers here, and the signal to noise ratio is much higher than some other Amiga forums. I've finally gotten around to joining. The occasion that pushed me over the line is the release of my latest project, Profyler (in the upload queue at OS4Depot and Aminet).
There have been a number of discussions about profilers for OS4 here in the past, including the current one about getting gprof to work, so there seems to be some interest in the subject. Inspired by that and by my use of the SAS/C sprof and GUIprof profilers in the past, I've created Profyler to provide a similar capability for OS4 programmers (with, thanks to MUI, a nicer user interface).
I won't go into all the features (and limitations) here, as you can check out the ReadMe to get all the details. Profyler is not going to be the one profiler to rule them all, as it has some significant limitations. But it's one more tool in the OS4 programmer's toolbox, one I hope is useful.
Feedback is welcomed...
|
|
|
|