 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Jon Lennart Aasenden
Guest
|
 Posted: Fri Mar 25, 2005 12:12 pm Post subject: ptr or move? |
 |
|
Hi guys
Well aware of the fastcode project, i have been tinkering with some small
questions:
The following code is obviously crap:
move(src^,dst^,4)
as the following is much faster:
PLongword(ds^t)^:=PLongword(src)^;
so.. what is the minimal limit of bytes required to make the move() function
faster than pointer operations? In my case, im moving scanline data from one
surface to another. I try to move 8 pixels at a time, reducing the number of
loops required. But the size of the copying is never fixed, so i could get a
16 pixel surface, or a 1024 pixel surface.
The latter would obviously be where a move() would be the fastest.
But is there some sort of lower byte range i can use to check?
So far, i use move for anything over 32 bytes, but it is different for all
modes. 32 bytes is not much when it comes to 32bit pixels, or 15 for that
matter..
What would you recomend as a lower limit for the move() statement?
Jon Lennart Aasenden
|
|
| Back to top |
|
 |
Avatar Zondertau
Guest
|
| Posted: Fri Mar 25, 2005 12:24 pm Post subject: Re: ptr or move? |
|
|
| Quote: | Well aware of the fastcode project, i have been tinkering with some
small questions:
The following code is obviously crap:
move(src^,dst^,4)
as the following is much faster:
PLongword(ds^t)^:=PLongword(src)^;
so.. what is the minimal limit of bytes required to make the move()
function faster than pointer operations? In my case, im moving
scanline data from one surface to another. I try to move 8 pixels at
a time, reducing the number of loops required. But the size of the
copying is never fixed, so i could get a 16 pixel surface, or a 1024
pixel surface. The latter would obviously be where a move() would be
the fastest. But is there some sort of lower byte range i can use to
check? So far, i use move for anything over 32 bytes, but it is
different for all modes. 32 bytes is not much when it comes to 32bit
pixels, or 15 for that matter..
What would you recomend as a lower limit for the move() statement?
|
It mostly depends on whether you know the size of the data moved in
advance. If you do you can always implement a faster version of Move
optimal for that fixed size.
It doesn't seem that is the case here though. However each different
Move implementation has different charisteristics. Some may be really
efficient for large blocks of memory, but would be slow for smaller
ones. Others are efficient for small blocks. ISTM you would need to
select one of the latter category here. This would not nessecairily be
the overal winner of the challenge, so you should test them all in the
specific situation you're in.
After selecting the Move that is fastest for your situation, you should
do more speed testing to find out which method is faster - Move or
pointer ops.
There's no getting around speed tests when you want to find out
something like this.
|
|
| Back to top |
|
|
Jon Lennart Aasenden
Guest
|
| Posted: Fri Mar 25, 2005 2:25 pm Post subject: Re: ptr or move? |
|
|
| Quote: | It mostly depends on whether you know the size of the data moved in
advance. If you do you can always implement a faster version of Move
optimal for that fixed size.
|
like i said it can be anything.
I dont want to impose a lower limit for my blitter engine. I use pointer
operations exclusively when copying between surfaces of different type (say,
15bit to 24 bit) as i need to use translations, but for surfaces of the same
type - it makes sense to just copy it in memory. Im not using the fastcode
stuff at the moment, i want to use RTL until the library is done.
| Quote: | It doesn't seem that is the case here though. However each different
Move implementation has different charisteristics. Some may be really
efficient for large blocks of memory, but would be slow for smaller
ones. Others are efficient for small blocks. ISTM you would need to
select one of the latter category here. This would not nessecairily be
the overal winner of the challenge, so you should test them all in the
specific situation you're in.
|
I think you are talking about the fastcode project here. I mentioned it
because i did not want to use that, but i am well aware of it and a huge
fan. I might add it later. The Problem is i want a library that is pure
object pascal, portable (be it to kylix or freepascal or directly to the
vesa framebuffer for that matter) and as fast as safety permits us. So no
hardcoded x86 assembler can be used. That said, i use bitwise operations
like there is no tomorrow..
| Quote: | After selecting the Move that is fastest for your situation, you should
do more speed testing to find out which method is faster - Move or
pointer ops.
|
The blitter function use a:
for y:=0 to FHeight-1 do // loop reduction will be done here later..
FCopyRaster(FParams: PBlitterParams); //avoid a stack frame by using
PRecords..
The copyraster procedure will copy a rasterline from the source to the
target, translating between modes if required. So i can blit an 8 bit
surface directly onto a 32 bit surface with no fuzz.
Current blitter results (no assembler involved in project):
555 -> 555 = 0..8 ticks
555 -> 565 = 0..15 ticks
555 -> 24bit = 0..16 ticks
555 -> 32bit = 0..16 ticks
565 -> 555 = 0..16 ticks (strange, compare 555->565)
565 -> 555 = 0..8 ticks
565 -> 24bit = 0..16 ticks
565 -> 32bit = 0..16 ticks
For the transparent versions, add 8 ticks - alphablending, double the values
except for when source & destination is the same format, in that case add 4
ticks.
Jon Lennart Aasenden
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
