Re: Flat Short of MEMORY_BLOCK

--- Berend de Boer wrote:
> 
> As you posted some actual code, I was able to test it (unfortunately
> not on Windows).

I tested the following code on Windows:

#include <string.h>
#include <windows.h>

#define MAX 100000
#define REPEAT 5000

__int64 performance_counter()
{
	LARGE_INTEGER l;

	(void)QueryPerformanceCounter(&l);
	return (l.QuadPart);
}

__int64 performance_frequency()
{
	LARGE_INTEGER l;

	(void)QueryPerformanceFrequency(&l);
	return (l.QuadPart);
}

double high_res_time()
{
	return ((double)performance_counter() /
		performance_frequency());
}

void test(int how)
{
int r;
int i;
char a_byte = 12;
char buffer[MAX];

if (!how)
{
for (r=0;r<REPEAT;r++)
{
for (i=0;i<MAX;i++)
{
buffer[i] = a_byte;
}
}
}
else
{
for (r=0;r<REPEAT;r++)
{
for (i=0;i<MAX;i++)
{
memcpy (&buffer[i], &a_byte, 1);
}
}
}
}

main ()
{
double before, after;

before = high_res_time();
test (0);
after = high_res_time();

printf ("array %f\n", after - before);

before = high_res_time();
test (1);
after = high_res_time();

printf ("memcpy %f\n", after - before);
}

with the free Borland C compiler that comes with EiffelStudio:

>bcc32 -O2 stuff.c
...
>stuff
array 3.371186
memcpy 76.529421

Yes, those are seconds, but I think we expected that from a free 
compiler. I also tested with VC++ 6.0:

>cl -O2 stuff.c
...
>stuff
array 0.000009
memcpy 0.000010

Several runs indicated that the difference was +/1 1 usec. 
Disassembly of the optimized code revealed that `test' was completely 
optimized out. That is, `test' consisted of a single instruction 
`ret'. So I moved buffer into global scope (a standard trick) and 
recompiled with the following results:

array 1.488316
memcpy 1.478088

Several runs again indicated that there was no difference between 
array and memcpy. Investigation of the disassembly confirmed that 
array and memcpy were implemented in the same way.

The times seem to indicate that Franck and Berend's tests were 
invalid because `test' was optimized out. I would run them again with 
buffer moved into global scope.

I also attempted the test with 2 byte and 4 byte values. Again array 
and memcpy were the same within some allowable error.

I then tested the following code:

#include <string.h>
#include <windows.h>

...

for (i=0;i<MAX;i++)
{
memcpy (&buffer[i], &a_byte, how);
}

...

printf ("memcpy %f\n", after - before);
}

which gave the following results:

array 1.490002
memcpy 42.758552

Inspection of the disassembly indicates that memcpy was not inlined. 
My original fear was that eiffel code would also suffer the same 
fate, that is, it would not be inlined. As you can see if memcpy is 
not optimized out the results can be dramatic. I suppose the best 
answer would be to compare the benchmarks of two MANAGED_POINTERs 
that are implemented using array access and memcpy.

Brian



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Upgrade to 128-bit SSL Security!
http://us.click.yahoo.com/LPJzrA/yjVHAA/TtwFAA/saFolB/TM
---------------------------------------------------------------------~->

To Post a message, send it to:   [email protected]
To Unsubscribe, send a blank message to: [email protected] 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/gobo-eiffel/

<*> To unsubscribe from this group, send an email to:
     [email protected]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/