Quote:

Can't argue with that...

@walkero

Thank you for all the work you put into making it look like you hardly did anything!

A few notes:

o Clicking on the "Reminder to people trying to register on the website" link gives a "Selected module does not exist!" message.

o Replying to a forum post no longer automatically inserts the name of the post's author at the top.

o Being able to embed YouTube videos is cool!

o Not a strong objection, but I'm not a big fan of the new quoted text display. It wastes a lot of space with the large double-quote image and all the white space around the quote. The orange bar at the left seems to give too much emphasis to quotes. And putting 'Quote:' at the top seems redundant, though perhaps it's useful if you're using a screen reader.

@alfkil

Thanks for the background information. I've browsed the code some and it appears to be well written, which left me puzzled as to why it just wouldn't work. I hope to be able to try it again some day when things get straightened out. In the mean time, I guess further testing will be up to those with access to newer kernels.

@alfkil

I tried Spotless when it first came out, but was unable to make it do anything useful, not even as much as DB101. I was left with the impression that it was mainly a demo of how to make a debugger, and that it wouldn't be developed further. Given that, it seemed pointless to try to do anything more with it, such as submitting bug reports. Has the situation changed?

I think there is a place in AmigaLand for both GDB and a working version of Spotless. Kas1e is right that GDB has far more people working on it, adding new features and honing the existing ones based on lots of real-world use. And for some applications remote debugging is useful or even essential.

Spotless, on the other hand, has a nice easy-to-use GUI and feels like an Amiga program, and could be a better choice for beginners and those with less demanding needs (and who aren't already familiar with GDB and how to use it). Spotless could be the debugger of first choice; if it can handle your debugging task, great! If you need more power then move on to GDB.

But Spotless needs more work before that's viable.

@geennaam

Thanks for the informative post. I've never paid that much attention to memory speed, so it was enlightening to read about some of the factors involved. It inspired me to take a closer look at the memory in my X1000.

I wonder how much of what you wrote applies to the X1000? The technical manual indicates that the PA6T's dual DRAM controllers can interleave modules if you have pairs of them installed. It also mentions that the maximum memory speed supported by the controllers is 800 MHz. I've no idea if the controllers (or CFE) support rank interleaving.

I tried running RageMem, and got results similar to those in this thread. I was surprised to see that the X1000 is much faster at memory access than the X5000, even if the latter is using interleaved ranks and modules. In fact, the X1000 is roughly 50% faster at writing, and three to four times as fast at reading. And that's despite the fact that the X5000 is significantly faster at L2 cache access than the X1000.

My X1000 just has the memory that came in it from AmigaKit. It's a single Kingston HyperX KHX8500D2/2G 2GB DDR2 module that was fairly high-spec for the time. It's rated at 800 MHz (5-5-5-18) at the standard 1.8 V supply that the X1000 uses. It has 16 chips on it, so it would seem to be dual rank, though the spec sheet doesn't specifically say that.

Notably, I just have one module, so I'm not taking advantage of controller interleaving. That suggests that it would be even faster if I got a second one, and in fact most of the RageMem results in the link I mentioned earlier are somewhat faster at writing than my results.

Now that OS4 can make use of memory beyond 2GB, it might be worthwhile to get a second module, and make the memory faster as well. Unfortunately, the Kingston module is no longer available. I'll either have to get an A-Tech equivalent (probably a pair of them, to keep both modules the same), or get a used one from eBay.

@kas1e

So if I understand correctly, ObtainDebugSymbol() assumed it was always being called from an exception context, and so always adjusted the address it was given. When called from a normal task context the adjustment is not required, and when it made the adjustment anyway, the address ended up being incorrect. (At least that's the effect, if not the actual problem.) Interesting.

To confirm this, I added a harmless DSI (a read from address zero) to my earlier example program. When the program "crashes" I can use Grim Reaper to display a stack trace, and indeed the source file name and line number are present. (The DSI can be ignored and the example program will terminate normally.)

And as you suggested, compensating for the bug by adding four to the address given to ObtainDebugSymbol() allows the source file name and line number to appear, confirming a workaround.

For those following along, here's the updated example program. By adding and removing comments you can demonstrate the bug or confirm the workaround. You can also remove a comment to trigger the DSI. Use the makefile from my earlier post (#26) to build the program.


I modified Profyler to adjust the function address before passing it to ObtainDebugSymbol(), and confirmed that the source file name and line number now appear for programs being profiled. Nice!

Of course, once the new version of Exec comes out the workaround needs to be removed. If I wanted to test the version of Exec and only apply the workaround to versions prior to the fix, what version of Exec might I want to check for?

@kas1e

Quote:
It has looked correct the few times I've checked, but that's not the sort of thing I look at on a regular basis.

I couple of times now I've used Ranger to confirm that the 'Simple' test program is being tracked, when at the same time Profyler is unable to display the source file name and line number information for the program. So in those cases at least I'd say that address tracking is correct, but ObtainDebugSymbol() still does not return those fields.

Of course, just because it shows up in Ranger doesn't mean that all of the associated debug information is being correctly extracted from the ELF file, but I have no way to test that.

@kas1e

Quote:

Cool! I didn't really think about it being used for benchmarking, so it's nice to see new uses being discovered.

@kas1e

Outside of MyPrintf() your results don't look very different from IamSONIC's. And when you get to MyPrintf() you're dealing with rendering text to the screen, which adds all sorts of variables.

Besides the graphics card and driver, there's the screen mode, the size of the font used by the shell, whether or not the shell needs to scroll to display the text (and if it does, how big the shell window is and whether it's partially obscured by another window), as well as what other programs might be doing graphics operations at the same time. If you're using the debug kernel that will likely affect the speed of graphics operations, too. In short, all the usual kinds of things that add complication when doing benchmarking.

I don't have all the answers, but at least we now have a tool with which to ask the questions.

@IamSONIC

That confirms that there's essentially no difference between the two compiler versions, at least with a very simple program like this one. So the difference in speed between your results and mine are due to the difference in hardware.

FYI, here's what I get on my X1000 running the GCC 8.3.0 version from the shell. I've added a column at the end that reports on the difference in the 'average exclusive' time of my results versus yours, which indicates how much faster the X5000 is.


So, for everything except MyPrintf() the X5000 is more than twice as fast, a difference greater than just the difference in processor speed. Perhaps the X5000 has faster memory access, or more efficient caching. Or the P50x0 is just faster at function calls, which is mainly what the Simple program does.

The difference is much less for MyPrintf(), which just calls the C library printf() to do all the work. printf() is a lot more complex than just function calls, and also has to actually render text to the screen, which brings graphics cards and drivers into play. The X5000 seems to have less of an advantage here. The time to run the entire program is only 15% faster than the X1000, also much closer.

Anyway, an interesting example of the kind of things you can do with a deterministic profiler.

@kas1e

I use the autodocs from the SDK, not from the web site. But I assume they're both the same.

I did see the notice that tracked memory addresses must be used with ObtainDebugSymbol(). But the fact that the function name and some other fields work correctly led me to conclude that DOS automatically adds any program it loads to the tracked address list.

Indeed, if I run the 'Simple' test program that comes with Profyler (convenient because it doesn't immediately exit) and then use Ranger to examine the tracked memory list, I see that Simple is on the list.

By examination of other tracked programs, it looks like the first entry in the tracked address list is the program's code segment. There is such an entry for Simple, which makes me think that the code is in fact in tracked memory. Which means it should work with ObtainDebugSymbol(). The fact that other fields in the DebugSymbol struct are valid would seem to confirm this.

Quote:
I'm not sure I see how that would make a difference. Wouldn't a stack trace point to the same function address?

Can you check with the OS4 team and see if there's a flaw in my logic?

@kas1e

Here's a simple example that demonstrates the failure to produce source file name and line number information. Save it as "SymbolFail.c".


Build it with this makefile:



When run, it displays:

Base name: SymbolFail
Function name: main
No source file name!
No source line number!

@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:
Oops! You're right- I totally missed putting that into the archive. Something to fix in the next release.

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

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

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

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.

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