[Implemented] ClearMemory()

[Joakim Christiansen]

ClearMemory(*MemoryBuffer)
Null every byte in the buffer

[gnozal]

ClearMemory(*MemoryBuffer)
Null every byte in the buffer

You could use RtlZeroMemory_(*Buffer, BufferLen.l) (Windows only).

The RtlZeroMemory routine fills a block of memory with zeros, given a pointer to the block and the length, in bytes, to be filled.

VOID
RtlZeroMemory(
IN VOID UNALIGNED *Destination,
IN SIZE_T Length
);

Parameters
Destination
Pointer to the memory to be filled with zeros.
Length
Specifies the number of bytes to be zeroed.

Return Value

None

[Dare]

That is very fast! Thanks gnozal.

I was doing this, which is quite fast:
FreeMemory(mem) : mem=AllocateMemory(size)
Faster than my custom-built asm memfiller anyway.

[travismcgee]

You can even fill the memory with some other value than zero with rtlFillMemory_(*buffer, length, bytevalue)

[Dare]

lol. nearly 8 times faster than my best with rep movsb. Thanks travismcgee.

[Trond]

lol. nearly 8 times faster than my best with rep movsb. Thanks travismcgee.

I'm almost beating it already, and I've got a kickass optimization up my sleeve for tomorrow. Here's my current code:

Code: Select all

!jmp ZeroMemoryEnd
!ZeroMemory:
; eax = ptr
; ecx = counter
!add ecx, eax
!ZeroMemoryLoop:
!mov dword [ecx], 0
!sub ecx, 4
!cmp ecx, eax
!jnz ZeroMemoryLoop
!mov dword [ecx], 0
!ret
!ZeroMemoryEnd:


#Len = 1*1024*1024
Define Memory = AllocateMemory(#Len)

#Tries = 500
time = GetTickCount_()
For I = 0 To #Tries
  RtlZeroMemory_(Memory, #Len)
Next
MessageRequester("", Str(GetTickCount_()-time))
time = GetTickCount_()
For I = 0 To #Tries
  !mov eax, [v_Memory]
  !mov ecx, 1*1024*1024
  !call ZeroMemory
Next
MessageRequester("", Str(GetTickCount_()-time))

[dioxin]

For clearing (or filling or moving) large blocks of memory, the limiting factor is not CPU speed, it's memory bandwidth.
To make the fastest memory filler you need to use as few memory accesses as possible which means using large registers so you should consider using mmx or sse.

You also need to write your code to take advantage of the hardware by keeping things in large, contiguous blocks. This doesn't apply to a memory fill which is inherently done that way, but does to memory copy where you should read-a-large-block then write-a-large-block rather than read a word then write a word.

Then, use the CPU instructions designed for the purpose. Shifting large blocks of data in slow RAM using fast CPUs has been a problem for years so the CPU designers improved the instruction set to help.
This can cause problems if the code is to be run on older processors which may not have the instructions, but any modern CPU will have the MOVNTQ and PREFETCH instructions which can significantly speed up storing and loading of data respectively.

Paul.

[Dare]

lol. nearly 8 times faster than my best with rep movsb. Thanks travismcgee.

I'm almost beating it already, and I've got a kickass optimization up my sleeve for tomorrow.

Thanks for the code snip, Trond.

And yeah, my fill code sucked big time. So does my pattern fill which has two limitations: It only fills the destination in increments of the fill pattern size (no partial fill) and it takes even longer than my filler.


Hi dioxin,

Thanks for the info. (Now to try to understand it )

[dioxin]

Dare,

(Now to try to understand it )

Rather than try to explain it, just look at the following code.
I set the size of the data block to fill to 100,000,000 bytes to allow for reasonable timing.

Trond:

Code: Select all

!mov ecx,100000000
!mov eax,StartAddress
ZeroMemory:
'; eax = ptr
'; ecx = counter
!add ecx, eax
ZeroMemoryLoop:
!mov dword [ecx], 0
!sub ecx, 4
!cmp ecx, eax
!jnz ZeroMemoryLoop
!mov dword [ecx], 0

takes 102ms on my Athlon 2600+
But try the following changes,
1) use MMX register 0 instead of eax
2) since mm0 is twice as big (64 bits) we double the loop increment from 4 to 8 bytes
3) use MOVNTQ instead of MOV or MOVQ to skip the cache which otherwise slows things down

Code: Select all

zero=0  'a 64 bit variable, set to zero.

!mov eax,StartAddress
!mov ecx,100000000
!movq mm0,zero
lp2:
!MOVNTQ [eax+ecx],mm0
!sub ecx,8
!jns lp2
!emms    'since we used mmx we have to switch back to FPU or it'll cause confusion

.and it now runs in 38ms, almost 3 times faster.

In this case we're moving 100,000,000 bytes in 38ms = 2.63GB/sec which is near the maximum possible memory throughput on my PC.

Paul.

[Joakim Christiansen]

Now Fred only need to copy that asm code to make the new command!

[Trond]

.and it now runs in 38ms, almost 3 times faster.

In this case we're moving 100,000,000 bytes in 38ms = 2.63GB/sec which is near the maximum possible memory throughput on my PC.

Paul.

There's a small problem with our codes: It will write outside the allocated memory if the size of the allocated memory % 4 (or 8 in your case) is not zero. I think.

[dioxin]

Trond,
the code as posted was not meant to be complete. The intention was to show how to speed up the main part of the loop on a modern CPU.
Complete code would need to check for non-aligned bytes at the start of the block, then fill the main block as shown, then check for extra bytes at the end of the block.

Paul.

[dioxin]

Trond,

I'm almost beating it already, and I've got a kickass optimization up my sleeve for tomorrow.

it's tomorrow. Are we going to get to see what's up your sleeve?

Paul.

[Trond]

Trond,

I'm almost beating it already, and I've got a kickass optimization up my sleeve for tomorrow.

it's tomorrow. Are we going to get to see what's up your sleeve?

Paul.

It won't be close to beating yours since you're using mmx, but I'm working on it.

Edit: It seems to not make any difference at all.

[dioxin]

Trond,
the likely reason you couldn't get it any faster is that it was probably running as fast as it could go anyway.
Improvements to the code will just leave the CPU idling longer between memory accesses while it waits for main RAM to catch up.

You need to use the MOVNTxxx instructions to go significantly faster as they access the memory in a different, more efficient, way when using large blocks of memory.

Paul.