I have attached another piece of example code for MASM32, it is a tool for testing the speed and allocation strategy of different types of memory.
Regards,
hutch@movsd.com
Regards,
hutch@movsd.com
hutch,
nice tool, but I think something is still wrong there... here are the results from my test:
Seems like the Page File Size / Free is wrong :rolleyes:
I am running WindowsXP Pro with 1536mb RAM :grin:
nice tool, but I think something is still wrong there... here are the results from my test:
[b]Start:[/b]
Percentage used = 15%
Physical Size = 1610051584 bytes
Physical Free = 1354633216 bytes
Page File Size = -692609024 bytes
Page File Free = -811290624 bytes
Virtual Size = 2147352576 bytes
Virtual Free = 2121613312 bytes
After [b]OLE String[/b] (took [b]511ms[/b]):
Percentage used = 22%
Physical Size = 1610051584 bytes
Physical Free = 1249628160 bytes
Page File Size = -692609024 bytes
Page File Free = -916287488 bytes
Virtual Size = 2147352576 bytes
Virtual Free = 2016751616 bytes
After [b]GlobalAlloc[/b] (took [b]510ms[/b]):
Percentage used = 22%
Physical Size = 1610051584 bytes
Physical Free = 1248956416 bytes
Page File Size = -692609024 bytes
Page File Free = -915976192 bytes
Virtual Size = 2147352576 bytes
Virtual Free = 2016595968 bytes
After [b]VirtualAlloc[/b] (took [b]501ms[/b]):
Percentage used = 22%
Physical Size = 1610051584 bytes
Physical Free = 1248559104 bytes
Page File Size = -692609024 bytes
Page File Free = -916033536 bytes
Virtual Size = 2147352576 bytes
Virtual Free = 2016600064 bytes
After [b]CoTaskMemAlloc[/b] (took [b]501ms[/b]):
Percentage used = 22%
Physical Size = 1610051584 bytes
Physical Free = 1248071680 bytes
Page File Size = -692609024 bytes
Page File Free = -916131840 bytes
Virtual Size = 2147352576 bytes
Virtual Free = 1911738368 bytes
After [b]Memory Mapped File[/b] (took [b]541ms[/b]):
Percentage used = 22%
Physical Size = 1610051584 bytes
Physical Free = 1247432704 bytes
Page File Size = -692609024 bytes
Page File Free = -916156416 bytes
Virtual Size = 2147352576 bytes
Virtual Free = 1911742464 bytes
Seems like the Page File Size / Free is wrong :rolleyes:
I am running WindowsXP Pro with 1536mb RAM :grin:
hmm it takes me about 200+ms less then bAZiK's machine for each call (all about 300-310ms). I wonder how that can be :|
I think my PC is older than his.
I think my PC is older than his.
Sven,
Thanks for running the tests, I tested it on NT4 and the,
Always read zero so I can expect some variation between OS versions, the results are the output from a call to "GlobalMemoryStatus" which may perform differently on different versions.
These are my win95b results.
The times are wandering a lot as I have my net connection running that effects benchmarks but the results are reasonably close so I cannot see any great advantage using the larger granularity allocation methods except in unusual circumstances. The other factor is that memory mapped files are running respectably fast enough even with the additional overhead.
Regards,
hutch@movsd.com
LATER: Just ran the tests on my p4 on win98se and apart from the times dropping some, averaging about 490 ms with very little variation, about 1 or 2 ms, the results are the same.
Thanks for running the tests, I tested it on NT4 and the,
Percentage used = 15%
Always read zero so I can expect some variation between OS versions, the results are the output from a call to "GlobalMemoryStatus" which may perform differently on different versions.
These are my win95b results.
At startup
Percentage used = 12%
Physical Size = 801665024 bytes
Physical Free = 624320512 bytes
Page File Size = 1345814528 bytes
Page File Free = 1345814528 bytes
Virtual Size = 2143289344 bytes
Virtual Free = 2028208128 bytes
OLE 732 ms
Percentage used = 19%
Physical Size = 801665024 bytes
Physical Free = 519475200 bytes
Page File Size = 1345814528 bytes
Page File Free = 1345814528 bytes
Virtual Size = 2143289344 bytes
Virtual Free = 2028208128 bytes
GlobalAlloc 730 ms
Percentage used = 19%
Physical Size = 801665024 bytes
Physical Free = 519471104 bytes
Page File Size = 1345814528 bytes
Page File Free = 1345814528 bytes
Virtual Size = 2143289344 bytes
Virtual Free = 2028208128 bytes
VirtualAlloc 728
Percentage used = 19%
Physical Size = 801665024 bytes
Physical Free = 519364608 bytes
Page File Size = 1345814528 bytes
Page File Free = 1345814528 bytes
Virtual Size = 2143289344 bytes
Virtual Free = 1923350528 bytes
CoTaskMemAlloc 730 ms
Percentage used = 19%
Physical Size = 801665024 bytes
Physical Free = 519356416 bytes
Page File Size = 1345814528 bytes
Page File Free = 1345814528 bytes
Virtual Size = 2143289344 bytes
Virtual Free = 1923350528 bytes
Memory Mapped File 725 ms
Percentage used = 19%
Physical Size = 801665024 bytes
Physical Free = 519237632 bytes
Page File Size = 1345814528 bytes
Page File Free = 1345814528 bytes
Virtual Size = 2143289344 bytes
Virtual Free = 1923350528 bytes
The times are wandering a lot as I have my net connection running that effects benchmarks but the results are reasonably close so I cannot see any great advantage using the larger granularity allocation methods except in unusual circumstances. The other factor is that memory mapped files are running respectably fast enough even with the additional overhead.
Regards,
hutch@movsd.com
LATER: Just ran the tests on my p4 on win98se and apart from the times dropping some, averaging about 490 ms with very little variation, about 1 or 2 ms, the results are the same.
Hiro,
From memory you are running a dual processor machine which may effect the file algo speed some but you may also have faster memory, I don't get a big increase with my p4 because it has SDRAM which is 133meg.
Regards,
hutch@movsd.com
From memory you are running a dual processor machine which may effect the file algo speed some but you may also have faster memory, I don't get a big increase with my p4 because it has SDRAM which is 133meg.
Regards,
hutch@movsd.com
Hutch,
I think you should make some changes to your tool:
- The allocated memory is zeroed out by your tool. That is bad, since this action is due to far more than 90% of total time. When I deactivate that part of the code the tool reports just 0 or 1 (sometimes 2 milliseconds). So it seems to me resolution of GetTickCount doesn't suffice the needs here.
- Theres a bug in your code making the app crash when memory allocation fails. Reason seams to be that you push a register in macro ClockItStart (and is assumed to be pop it in ClockItStop) but ClockItStop isn't executed in this case (therefor hiding pushs/pop in macros isn't very good coding practice ):)
Regards
japheth
I think you should make some changes to your tool:
- The allocated memory is zeroed out by your tool. That is bad, since this action is due to far more than 90% of total time. When I deactivate that part of the code the tool reports just 0 or 1 (sometimes 2 milliseconds). So it seems to me resolution of GetTickCount doesn't suffice the needs here.
- Theres a bug in your code making the app crash when memory allocation fails. Reason seams to be that you push a register in macro ClockItStart (and is assumed to be pop it in ClockItStop) but ClockItStop isn't executed in this case (therefor hiding pushs/pop in macros isn't very good coding practice ):)
Regards
japheth
Japheth,
Thanks, you are right, the two macros assume one follows the other so a pop is missing.
I did the memory fill for a reason, to make sure each memory type was committed, IE, if you can write to it, its there.
Timing is a problem on very short durations in ring3. For having played with many rountines for timing, they all have about the same error percentage in ring3. using RDTSC would be useful in ring0 but that defeats the purpose for what is being tested.
i do not know an accurate way to test memory allocation speed by itself, while its easy enough to loop through allocation and deallocation, I am guessing there is some other factor coming into play.
Regards,
hutch@movsd.com
I just looked up MSDN and the GlobalMemoryStatus may not work correctly on win2k or later. There is a later function but it is not supported on 9* - me so its not useful for code that must run on all versions.
Thanks, you are right, the two macros assume one follows the other so a pop is missing.
I did the memory fill for a reason, to make sure each memory type was committed, IE, if you can write to it, its there.
Timing is a problem on very short durations in ring3. For having played with many rountines for timing, they all have about the same error percentage in ring3. using RDTSC would be useful in ring0 but that defeats the purpose for what is being tested.
i do not know an accurate way to test memory allocation speed by itself, while its easy enough to loop through allocation and deallocation, I am guessing there is some other factor coming into play.
Regards,
hutch@movsd.com
I just looked up MSDN and the GlobalMemoryStatus may not work correctly on win2k or later. There is a later function but it is not supported on 9* - me so its not useful for code that must run on all versions.
Ouch...
Everytime i press allocate memory, the application crashed on my windows 2k.
Everytime i press allocate memory, the application crashed on my windows 2k.
roticv,
Sorry about that but it appears to be version difference, it works OK on win95/98se and NT4.
One value on NT4 does not display correctly.
The memory function appears to be implemented differently on NT/2k/XP based machines.
Regards,
hutch@movsd.com
Sorry about that but it appears to be version difference, it works OK on win95/98se and NT4.
One value on NT4 does not display correctly.
The memory function appears to be implemented differently on NT/2k/XP based machines.
Regards,
hutch@movsd.com
My Win2k ran is OK.
In my system, average is 360 ms, maybe because RDRAM.
In my system, average is 360 ms, maybe because RDRAM.
Everytime i press allocate memory, the application crashed on my windows 2k.
I have to agree with this :confused:
It crashes at my 2k too (it takes some time, then crashes).
If any of the win2k people have the time, a small suggestion that may make it work OK. Take this piece of code and replace it.
With
I used the "GlobalMemoryStatus" function which does not return the memory used value on NT/Win2k so the crash is probably on machines that cannot handle a 100 meg buffer to test with.
Regards,
hutch@movsd.com
; ????????????????????????????????????????????
; set maximum memory size to test to EITHER
; (a) half physical memory
; OR
; (b) 100 meg
; whichever is the smaller.
; ????????????????????????????????????????????
mov mst.dwLength, sizeof MEMORYSTATUS
invoke GlobalMemoryStatus,ADDR mst
mov eax, (100*1024*1024)
mov ecx, mst.dwTotalPhys ; total physical memory
shr ecx, 1
.if ecx > eax
mov setsize, eax
.else
mov setsize, ecx
.endif
; ????????????????????????????????????????????
With
mov setsize, number ; set the value manually to a size that can run on your machine.
I used the "GlobalMemoryStatus" function which does not return the memory used value on NT/Win2k so the crash is probably on machines that cannot handle a 100 meg buffer to test with.
Regards,
hutch@movsd.com
It works.
100MB give me 1122 ms with GlobalAlloc()
(I have used for number = 100*1024*1024)
100MB give me 1122 ms with GlobalAlloc()
(I have used for number = 100*1024*1024)
After I followed by huch--, :cool:
my win2k is still OK, but now average is only 480 ms.
:tongue:
my win2k is still OK, but now average is only 480 ms.
:tongue:
310-311 ms on all tests except memory map; it came in at 331.
Athlon 1.2
256MB PC133
Windows XP Pro
Athlon 1.2
256MB PC133
Windows XP Pro