Author |
Topic: Evaluating IRQ handlers (Read 883 times) |
|
admin
Administrator
member is offline
Posts: 1145
|
 |
Evaluating IRQ handlers
« Thread started 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.
|
|
 Logged
|
|
|
|
19Grumpah42
Junior Member
member is offline
Gender: 
Posts: 57
|
|
Re: Evaluating IRQ handlers
« Reply #1 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
|
|
Logged
|
C-2-Q 3GB, C-2-Duo 2GB, both GeForce 9500 GT, WinXP sp3. Two Linux Ubuntu boxes (rock solid, lean and mean, but they won't run BB4W!).
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Evaluating IRQ handlers
« Reply #2 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.
|
|
Logged
|
|
|
|
|
