@Raziel

Quote:
Ah, I see. You're right, when a numpad key that varies with the NumLock state is pressed, it's possible to deduce the state- if you get a '0' from the numpad then NumLock must be on, and if you get an 'Insert' it must be off.

That won't work with numpad keys like '5' and '+' that don't vary with the NumLock state though, and of course someone has to press a numpad key before you can update the state. That might be good enough, depending on what you're looking to do with the NumLock state, but it's not a general purpose way to know the current state.

@Capehill
@Raziel

It looks like the numlock key does not generate a keycode on the Amiga. At least, when I run the Input Event Sniffer (http://os4depot.net/?function=showfil ... isc/inputeventsniffer.lha) and watch for RAWKEY and EXTENDEDRAWKEY events nothing happens when I press numlock.

Quote:
Given that, it would be good defensive programming practice to set 'status' to 0 before making the call, so if the call aborts without setting the status at all then at least you'll get a consistent failure, rather than a random result depending on what happens to be on the stack. That would have saved kas1e a lot of time playing with printf().

@kas1e

What if you put the printf() or Delay() at the very beginning of your function, before making any of the SDL calls? Does it work there? What if you put it at the very end, just before the "return SDL_TRUE;"? (Which means it won't even be called if compiling the shaders fails.) Or does it have to be in between the two sets of SDL calls in order to make a difference?

And what if you use IExec->DebugPrintF() rather than printf()?

I waited for a bit in case anything else came up, but nothing did. So I've released version 1.1 of Profyler, which adds a workaround for the bug in ObtainDebugSymbol() and so can now display the source file name and line number for every profiled function.

The workaround shuts off starting with Exec version 54.47, so hopefully the bug fix will be present in that version when it appears.

@kas1e

Remember that while printf() looks simple in the source code, there's a lot going on under the hood, involving the console (which decides where the printed text goes), the graphics library (which renders the font characters into pixels), and the graphics card driver (which gets the pixels to the screen).

Somewhere in all of that there's almost certainly something that has to Wait(), which gives other tasks a chance to run. So printf() doesn't just take some time to execute. but it also allows other tasks to run. Your for() loop takes time, but most likely doesn't cause a task switch (assuming the delay isn't so long that it's preempted). Calling Delay() of course also allows other tasks to run, without all the other complexity of printf().

I'm not a 3D graphics guru, so I have no idea what those graphics calls are doing. But if it involves another task that's running asynchronously, then letting that task run while you're delaying may give it a chance to complete some necessary work that doesn't get done in time otherwise.

@LiveForIt

It's not precisely what you asked for, but the autodoc for version.library has this table for the version number of version.library itself:

@walkero

I saw this same thing once a few days ago, when visiting as a guest (not logged in)- news items from 2006 or 2007, and if I scrolled down to the bottom of the home page the page selection buttons had me on some page number in the hundreds, instead of page 1.

I don't remember what I did to fix it- I think I just clicked on 'Home', but I may be remembering wrong. I imagine I could have clicked on the page 1 button, too.

I haven't seen the problem since, so it's not readily reproducible.

@geennaam

Any chance I could get a copy of your benchmark program? I'm curious what the X1000 numbers would be.

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?