Welcome Guest. Please Login or Register. Apr 5th, 2018, 10:23pm
ATTENTION MEMBERS: Conforums will be closing it doors and discontinuing its service on April 15, 2018. Ad-Free has been deactivated. Outstanding Ad-Free credits will be reimbursed to respective payment methods.
If you require a dump of the post on your message board, please come to the support board and request it.
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!).
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.
Logged
