BBC BASIC for Windows
Programming >> Operating System >> Evaluating IRQ handlers
http://bb4w.conforums.com/index.cgi?board=os&action=display&num=1327230812
Evaluating IRQ handlers
Post by admin on Jan 22nd, 2012, 10:13am

Quote:
The programme currently handles incoming from ON MOVE, ON MOUSE, ON SYS, ON TIME, and -- very much to my testing point -- a PROCedure which runs off a system timer and generates bursts of fake IRQs by poking its parameters into the appropriate buffer.

It would probably be better to generate real 'interrupts' by using SYS "SendMessage". That would be a more realistic test than anything you can 'fake'.

Quote:
You can view this well in MS-Wordpad (not with MS-Notepad !)

I'd appreciate you making it Notepad-compatible. I assume that simply means terminating the lines with CRLF?

Quote:
I further expect that someone can explain the clear anomaly in the byte() SWAP when one array is LOCAL, the other Global

The fact that the byte case is disproportionately affected is probably just chance, but the likely reason why a GLOBAL/LOCAL swap is slower is because (being at very different memory addresses) the CPU's cache is being used less efficiently.

Incidentally you don't say whether the real (by which I presume you mean variant) measurements were in *FLOAT40 (5 bytes per value) or *FLOAT64 (8 bytes per value) mode.

Richard.
Re: Evaluating IRQ handlers
Post by 19Grumpah42 on Jan 22nd, 2012, 11:58am


The fact that the byte case is disproportionately affected is probably just chance, but the likely reason why a GLOBAL/LOCAL swap is slower is because (being at very different memory addresses) the CPU's cache is being used less efficiently.

As I said, this is no big deal for me, but does the above explain why the ranking for a G/L SWAP was B:I:R:S 1120:660:650:730. The numbers are repeatable +/- 10.

And whatever do you mean by "chance"?
--Grahame
Re: Evaluating IRQ handlers
Post by admin on Jan 22nd, 2012, 12:54pm

on Jan 22nd, 2012, 11:58am, 19Grumpah42 wrote:
And whatever do you mean by "chance"?

For example, the speed of access will depend on the address alignment so if a variable happens to be DWORD-aligned (i.e. at an address which is a multiple of 4) the access may be considerably faster than if it isn't. In any given circumstance there is a 1-in-4 probability that the variable will have this desirable alignment, and it's in that sense that I used the word 'chance'.

So you could easily find that an insignificant change to your program makes (say) the G/L swap faster and the G/G swap slower, simply because of alignment changes. There's nothing 'random' about it, but because the speed change will have had no obvious connection with the code modification it may appear that way.

Richard.