A New Testbed for MASM32 Forum

[dedndave]

lol - "about 2" - it is either 2, or it is something else   :lol
should still reflect MMX level - MMX, 3dNow!, 3dNow!+

Code Select Expand

┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS  : Microsoft Windows XP Professional Service Pack 2 (build 2600)                     │
│CPU : Intel(R) Pentium(R) 4 CPU 3.00GHz about 2 logical core(s) with SSE3               │
│                                                                                        │
│Test: Conversion of a screen buffer from DOS to Windows CHAR_INFO structure             │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│        Algorithm notes           │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX - PUNPCKLBW MOVQ    │    64   │    7.341 │    7.092 │    7.487 │    7.171 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP        │    43   │   14.645 │   13.592 │   13.673 │   13.622 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA   │    44   │    4.393 │    4.414 │    4.755 │    4.449 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ  │    64   │    9.320 │    9.298 │    9.447 │    9.332 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT        │    42   │   13.642 │   13.540 │   13.566 │   13.554 │

[Antariy]

lol - "about 2" - it is either 2, or it is something else   :lol
should still reflect MMX level - MMX, 3dNow!, 3dNow!+

That is Russian phrase construction: Процессор о двух ядрах, Ружьё о двух стволах etc.

That mean not "something average" that meant - "a thing which have quantity of something" :P

AMD is not implemented - if you want - you can do that yourself :P - if you have spare time.

[dedndave]

in English, it seems the same as "approximately 2"   :lol

[Antariy]

in English, it seems the same as "approximately 2"   :lol

Well, I just do not wants to repeat the same word in the same short phrase:
Intel(R) Pentium(R) 4 CPU 3.00GHz with 2 logical core(s) with SSE3
so - I used other word. That is the rule of the Russian language. But you can still change the sources for right rules of the your native one.

[MichaelW]

This looks right to me:

Intel(R) Pentium(R) 4 CPU 3.00GHz with 2 logical core(s) and SSE3

[Antariy]

This looks right to me:

Intel(R) Pentium(R) 4 CPU 3.00GHz with 2 logical core(s) and SSE3

Well - this one is looks very good, thanks Michael!

Frank, can you change the text?
Just find the %s about %u logical core(s) with %s string in the sources, and replace to %s with %u logical core(s) and %s as Michael was suggested.



Alex

[frktons]

OK  :U The shorter version is now fixed as per request.  :P
Attached.

Frank

[Antariy]

OK  :U The shorter version is now fixed as per request.  :P

Results, Frank, post results :P

Code Select Expand


┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS  : Microsoft Windows XP Professional Service Pack 2 (build 2600)                     │
│CPU : Intel(R) Celeron(R) CPU 2.13GHz with 1 logical core(s) with SSE3                  │
│                                                                                        │
│Test: Conversion of a screen buffer from DOS to Windows CHAR_INFO structure             │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│        Algorithm notes           │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX - PUNPCKLBW MOVQ    │    64   │    9.543 │    9.513 │    9.521 │    9.495 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP        │    43   │   13.889 │   13.912 │   13.938 │   13.889 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA   │    44   │    4.610 │    4.603 │    4.615 │    4.601 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ  │    64   │   11.657 │   11.651 │   11.668 │   11.660 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT        │    42   │   13.908 │   13.926 │   13.924 │   13.906 │


Would be fine to test with multicore CPUs.

[frktons]

here you are:

Code Select Expand


┌────────────────────────────────────────────────────────────────────────────────────────┐
│OS  : Microsoft Windows 7 Ultimate Edition, 64-bit (build 7600)                         │
│CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz with 2 logical core(s) with SSSE3           │
│                                                                                        │
│Test: Conversion of a screen buffer from DOS to Windows CHAR_INFO structure             │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│        Algorithm notes           │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 Alex / MMX - PUNPCKLBW MOVQ    │    64   │    3.125 │    3.121 │    3.133 │    3.124 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 Frank / 486 - MOV-BSWAP        │    43   │    8.370 │    8.376 │    8.369 │    8.378 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 Frank / XMM PUNPCKLBW MOVDQA   │    44   │    2.338 │    2.338 │    2.341 │    2.338 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Alex / MMX - PUNPCKLBW MOVNTQ  │    64   │    6.061 │    6.058 │    6.081 │    6.098 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Frank / 386 - MOV-SHIFT        │    42   │    8.199 │    8.548 │    8.484 │    8.453 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤


So, what about putting the algos to test in external include files, and to change the structure of
the program in order to use them, like this:


- general includes
- flags to indicate how many algos to run:

  TestAlgo1   EQU ON
  TestAlgo2   EQU ON
  TestAlgo3   EQU ON
  ------
  TestAlgo12 EQU OFF

- flag to indicate if using Display Mode 12 or 24 algos

  DisplayMode EQU DM12/DM24

- include of data
- include of main program flow

- conditional include of the algos to test:

IF  DisplayMode = DM12

  IF  TestAlgo1

       include  M12Algo1.inc; the code to manage the algo with inside the include of the Algo1.inc code to test

  ENDIF

  IF  TestAlgo2

       include  M12Algo2.inc; same as above

  ENDIF

  --------

  IF  TestAlgo12

       include  M12Algo12.inc; same as above

  ENDIF

ENDIF

And the last part:

include ProgPROC

?

In this way to test the algos the only necessary things to do should be:

1) set ON the flag of the Algo number to test
2) write a small include Algo1.inc, Algo2.inc ..... Algo12.inc with the code to test
3) put a simple description on the same include file like:

   Algo1Desc   DB  "Alex - MMX and PUNPCKLBW",0

And also it should be easier to manage the 12/24 Display Mode.

What do you think?

FRank

[Antariy]

In short: now you have one line more with short CPU description - no need in SplitString and two lines.
You can put lines compactly, and needed to remove the description of the test (yes, yes  :green2). So, I guess, needed to make display statical - too many things with configuration of the testbed... For example - 15 or 17 algos would be enough for almost all cases.

One more: needed to make testing of the algos as something unified - macro, or code which prepares tested proc for running, and run in between timing macros'.
For that is needed this? - for making testing unified, and for possibility of exclusion of the algos, which is not supported by CPU.
Any algo can be described with its own unified structure - code which prepare algo to run checks all needed things - and manage cases when test in not possible due any reasons.

etc.



Alex

[Antariy]

Inclusion of the algos into external include files with unified names is a good idea
I guess - all tested code must be placed externally, ALL.
Needed to done testbed's code in the way, that allow compile code, add/remove new procs with changing only external include file of the tested algo, and, probably - common include file.

Because current test-bed is not so simple as old one - changing/addition/removing of the test would be not so funny, if made it in 60 KB source file with its own structure...

[frktons]

In short: now you have one line more with short CPU description - no need in SplitString and two lines.
You can put lines compactly, and needed to remove the description of the test (yes, yes  :green2). So, I guess, needed to make display statical - too many things with configuration of the testbed... For example - 15 or 17 algos would be enough for almost all cases.

So you are suggesting we start again from the beginning, deciding how many algos to test,
what kind of display to use, redesign the screen format, and so on?

Well, take your time and do it by all means.  :lol

I'd rather prefer to complete the project and not start again from these points.  :P

One more: needed to make testing of the algos as something unified - macro, or code which prepares tested proc for running, and run in between timing macros'.
For that is needed this? - for making testing unified, and for possibility of exclusion of the algos, which is not supported by CPU.
Any algo can be described with its own unified structure - code which prepare algo to run checks all needed things - and manage cases when test in not possible due any reasons.

etc.
Alex

I am not sure I understand what you mean. Can you try to explain these concepts in other words?

Inclusion of the algos into external include files with unified names is a good idea
I guess - all tested code must be placed externally, ALL.
Needed to done testbed's code in the way, that allow compile code, add/remove new procs with changing only external include file of the tested algo, and, probably - common include file.

Because current test-bed is not so simple as old one - changing/addition/removing of the test would be not so funny, if made it in 60 KB source file with its own structure...

Yes Alex, this is the reason to have external include files, to have a simple access to the testbed.  :U

Frank

[Antariy]

So you are suggesting we start again from the beginning, deciding how many algos to test,
what kind of display to use, redesign the screen format, and so on?

I'd rather prefer to complete the project and not start again from these points.  :P

............

I am not sure I understand what you mean. Can you try to explain these concepts in other words?

............

Yes Alex, this is the reason to have external include files, to have a simple access to the testbed.  :U

Why from beginning? No - only redesign the screen - all code already written, no many changes to do. Just other DOS-screen. OS/CPU string can be the same at the same place. Just increase console window to 40 lines (for example), or exclude something from current console layout.

I just suggest more straighforward way as more faster and robust - that is your choise what is do.

I meant that thing, which I explained in second post, and I see - you are understand it.
I just want to say, that needed make testbed unified - to not change its code, but external tested code. For this is needed some rules (I mentinioned "structure") which would be parsed by testbed to know - which things is needed to do the test.

I'm sure, my new description is the same "strange" :P

[frktons]

The actual screen is 34 rows and 90 cols. If we go to 15 algos to test, we arrive at 40 rows
as you suggested. Probably for wide screen, 19" or more, it should be fine to see the data
displayed. I'm not sure with smaller monitors if it is clear enough to read.

Why do you think that 24 algos mode is not viable? Are they too many or what?

And a last thing, why would you prefer to remove the description of the task?
Do you prefer to have a screen with a lot on info but that is not saying what is it
all about?

Frank

[Antariy]

The actual screen is 34 rows and 90 cols. If we go to 15 algos to test, we arrive at 40 rows
as you suggested. Probably for wide screen, 19" or more, it should be fine to see the data
displayed. I'm not sure with smaller monitors if it is clear enough to read.

Why do you think that 24 algos mode is not viable? Are they too many or what?

And a last thing, why would you prefer to remove the description of the task?
Do you prefer to have a screen with a lot on info but that is not saying what is it
all about?

Frank

1024x768 (most general of the days) would be enough for ~45 lines of the console with 16 font, I guess.

As sayed - I suggest fixed screen mode as fastest and reliablest to do. But if you wants more training - implementation of it would be good thing.
But you must remember, that the unification of the testing of the algos is not done yet - that will be much more big and interesting thing to do, than switching of the screens.

If you remove description of the task, AND PUT THAT DESCRIPTION ON THE CONSOLE TITLE (SetConsoleTitle) - that would be do the same job, but with +1 line more on the console...



Alex