OS functions, not system calls. Some functions are implemented by the OS but don''t involve context switches. In WinNT they usually lie within DLLs.

And remember the context. This is the IA64 architecture which is a VLIW, executing 4 (or more) instructions per fetch. In order for a memcpy to execute, you need a load word/store word pair of instructions. These instructions also need to be separated by a certain number of cycles, otherwise they stall. So lets say that a normal memcpy function has 8 registers to play with. And let''s say the OS has 4 "hidden" registers. If the cycle time of the memory is 3 cycles, the normal memcpy can load all 8 registers in 2 cycles. It needs to wait a cycle before it can do the store. The OS function can fill all 12 registers it has available to it in three cycles, and immediately begin to execute store word instructions to move the memory.

Also nowhere in the headers is the memcpy call macroed to the RtlCopyMemory function, therefore memcpy, even if it calls RtlCopyMemory, has the overhead of an additional function call.

Fact of the matter is that CopyMemory *is* a separate function from memcpy in this particular combination of NT and IA64. It could actually be faster. Not saying it is, but it could.

Thanks... that''s more information than I needed, but at least I can expect intelligent answers from this forum.

Whether or not to use memcpy or CopyMemory is a trivial matter in my case, as I only use the functions during the loading stages of my game. During realtime gameplay I could use memcpy for graphics, but of course that would be stupid when it''s quicker and easier just to use DirectDraw''s blitter.

Al