News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Yet Another Benchmark Interface ! :)

Started by hutch--, November 23, 2010, 02:43:10 AM

Previous topic - Next topic

hutch--

The attached zip file is basically a template for a simlified dialog interface for testing algorithms and displaying results. Its a rewrite of the last one that uses radio buttons to indicate which algo is being tested and it has had the CPUID code added to recognise the processor. It may not handle old processors correctly but its tests for CPUID and tries to get the processor string if CPUID is supported by the processor. The dialog was created with Ketil Olsen's ResEd and it should be reasonably straight forward to modify if you have or download ResEd. It has both a manifest file and a version control block to keep the idiot end of AV scanners happy.

When I remember how to do the OS version I will add that as well.  :P

Output is a text file that looks like this.


Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz
Results 8 pass average
timing utoa       455 ms
timing utoa_ex    126 ms
timing udw2str    859 ms
timing vcrt ustr$ 671 ms
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

dedndave

GetVersionInfoEx, if i remember

results prescott w/htt
Intel(R) Pentium(R) 4 CPU 3.00GHz
Results 8 pass average
timing utoa       872 ms
timing utoa_ex    293 ms
timing udw2str    2638 ms
timing vcrt ustr$ 2785 ms

oex

Interesting, the version control block compiled correctly for me this time with 6.15 I've had problems with it in the past....

Having said that it's just crashed :lol

Not sure why but it's hanging after the tests have run

I get the following errors when compiling (I changed the drive letter correctly in the Makeit.bat


rsrc.rc(3) : fatal error RC1015: cannot open include file 'include'.
Microsoft (R) Windows Resource To Object Converter Version 5.00.1736.1
Copyright (C) Microsoft Corp. 1992-1997. All rights reserved.

CVTRES : fatal error CVT1101: cannot open rsrc.res for reading
Microsoft (R) Macro Assembler Version 6.15.8803
Copyright (C) Microsoft Corp 1981-2000.  All rights reserved.

Assembling: bmtemplate.asm


Tried again and it didnt even run the algorithms.... Not hugely important for me, probably something I'm doing wrong
We are all of us insane, just to varying degrees and intelligently balanced through networking

http://www.hereford.tv

dedndave

i had that problem on the last one

on this one - i just ran it
let it run 8 times (takes a while)
if i messed with the buttons on the last version while it was running, it died

as for getting reliable numbers.....
rather than running the test 8 times for 0.5 seconds (or however long) and taking the average,
i am getting good repeatable numbers by running each test 10 times in a loop (50 mS each), keeping only the lowest time

        mov     ecx,10
        mov     edx,-1

time_loop0:
        push    ecx
        push    edx
        counter_begin 59524,HIGH_PRIORITY_CLASS
        INVOKE  crt__itoa,dwVal,offset OutBuf,dwRadix
        counter_end
        pop     edx
        pop     ecx
        cmp     eax,edx
        jae     time_loop1

        xchg    eax,edx

time_loop1:
        dec     ecx
        jnz     time_loop0

        print   ustr$(edx),13,10

note: in the example, dwVal = 0FFFFFFFFh and dwRadix = 2
i adjusted the loop count to achieve ~0.5 seconds total time

oex

Oh nice 1.... Cheers Dave I thought I'd f*cked up :lol

AMD Sempron(tm) Processor 3100+
Results 8 pass average
timing utoa       939 ms
timing utoa_ex    267 ms
timing udw2str    1078 ms
timing vcrt ustr$ 2927 ms
We are all of us insane, just to varying degrees and intelligently balanced through networking

http://www.hereford.tv

hutch--

Apart from thge batch file having my local path, I don't see why you are getting build problems unless you are running an unusual setup.

If you look at the benchmark algo it has this line above it.


    iterate equ <15000000>


which means it runs each algo 15 million times in each pass. You can lower the iteration count if it is too long for an older processor. Beware of the technique of taking the lowest time, it is unreliable in real time on a working machine, if an algorithm fluctuates by any large degree in real time then it probably has its limitations.

Its easy enough to disable the buttons while the test is running.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

hutch--

Here is a tweaked version, iteration count dropped by 33% and buttons disabled while the test is running. I removed the drive letter from my local paths.

This much, will you try the EXE before you build it just to avoid any build diffferences.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

oex

Yep bug fixed it was just slow on my machine and I thought it had hung when I couldnt click after first test.... dont understand the rsrc error I may have changed something this end on my setup....

Again (because it got drowned in bug code) ty for the manefest code I've had problems building that in before but with this app it worked like a dream with 6.15, now I just have to work out what I did wrong before :bg

AMD Sempron(tm) Processor 3100+
Results 8 pass average
timing utoa       585 ms
timing utoa_ex    177 ms
timing udw2str    666 ms
timing vcrt ustr$ 1826 ms
We are all of us insane, just to varying degrees and intelligently balanced through networking

http://www.hereford.tv

dedndave

QuoteBeware of the technique of taking the lowest time, it is unreliable in real time on a working machine, if an algorithm fluctuates by any large degree in real time then it probably has its limitations.

you have to convince me on that one, Hutch
we want to measure clock cycles consumed in an algo
not how much time the system decides to give your thread   :bg

hutch--

Dave,

This is the problem, cycle counts on a multithread processor is a theory where real time is what an algorithm runs under. Its the performance in real time in a task switching environment that matters as algorithms that run in applications run in real time, not theoretical cycle counts.

This is why I suffer the irritations of timing in real time, I get a result that is something like how an algo will work in practice.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

frktons

Couldn't compile with Make.bat, no time to check why. Going to the airport.
Runned test:


Enjoy

Frank - Win/7 64 bit Areo OFF  :P Soon this will be displayed as well   :wink
Mind is like a parachute. You know what to do in order to use it :-)

dedndave

well, Hutch, we can always devise a test to find out how things go
i will be interested to see an example where testing one way over another reverses your final selection of code

we may not think about it very often, but we use Michael's timing macros in 2 different ways, really
1) comparing algos in the laboratory
2) piece-by-piece selection of small code sequences during the optimization process

the later is more or less an individual task, that we don't always see in the forum
but, perhaps the 2 goals require different solutions

ToutEnMasm

Quote
Intel(R) Celeron(R) CPU 2.80GHz
Results 8 pass average
timing utoa    574 ms
timing utoa_ex 189 ms
timing utoa2   375 ms
timing utoa3   500 ms

lingo

#13
It is my small improvement of the utoa_exe algo from here: :wink
Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz
Results 8 pass average
timing utoa    267 ms
timing utoa_ex 78 ms
timing utoa2   156 ms
timing utoa3   234 ms
timing utoa_exLingo   62 ms


clive

Intel(R) Atom(TM) CPU N450 @ 1.66GHz
Results 8 pass average
timing utoa    1353 ms
timing utoa_ex 524 ms
timing utoa2   850 ms
timing utoa3   1388 ms
timing utoa_exLingo   515 ms
It could be a random act of randomness. Those happen a lot as well.