This is too slow

[frktons]

OK guys. It was a nice debugging session. Now it is 3 o'clock in the morning. In few hours
I have to go somewhere else other than Virtual world. We'll carry on the good job another time.

Testbed is still work in progress. Many things will change along the way. And Alex Algo Manager
is still waiting to be implemented.  :P

Stay tuned. I'll be back.  :lol

Good night

Frank

[dedndave]

as to the CPU features.....

i am not just talking about the code in the algos
i am seeing MMX code in the TestBed procs

my suggestion is - you may want to re-think using any code in the testbed
program that prevents it from being used on older CPU's
it is nice to be able to run test algos on older machines

good nite Frank   :bg

[Antariy]

Testbed is still work in progress. Many things will change along the way. And Alex Algo Manager
is still waiting to be implemented.  :P

Well, your testbed is updated with such frequency, that is not possible - to insert of the Manager into each next updated release :P

[GregL]

I just threw those procedures out there so I wasn't making a suggestion without some code.  It doesn't matter to me which code is used.  I agree with Dave's last post too.

[dedndave]

he'll get there, Alex   :bg

good work   :U

[Antariy]

my suggestion is - you may want to re-think using any code in the testbed
program that prevents it from being used on older CPU's
it is nice to be able to run test algos on older machines

MMX code can be runned from 1997 PI MMX, I guess - it is old enough CPU :eek :lol

Initially Frank wants to make algos as SSE2, but I'm dissuade him from this, with hardness.  :lol

[dedndave]

yah, Greg - i wasn't aware that Alex already had code written
i am sure they will make it fly right   :P



Alex - yah - come to think of it, my oldest pentium machine is a P1-MMX (one of the first MMX, i guess)
it is suitible as a win 98 test machine - not really enough guts for XP
200 MHz - i run it at 225   :lol

[Antariy]

Alex - yah - come to think of it, my oldest pentium machine is a P1-MMX (one of the first MMX, i guess)
it is suitible as a win 98 test machine - not really enough guts for XP
200 MHz - i run it at 225   :lol

Yes, for XP is PII is eno-o-o-o-o-o-o-ough...  :bg

Good old machine, when M/B have switches for multiplier :wink
But I guess you are overclock it by system bus?

[dedndave]

jumpers
no book - i found them by reading the silkscreen on the m/b   :P

[Antariy]

no book - i found them by reading the silkscreen on the m/b   :P

:lol

[GregL]

I think MMX, SSE and SSE2 code is OK in the TestBed as long as you test for it and provide alternative code.  Which is what Frank was talking about doing.

[Antariy]

I think MMX, SSE and SSE2 code is OK in the TestBed as long as you test for it and provide alternative code.  Which is what Frank was talking about doing.

That's right, of course!
But such thing as testbed, I guess - would be better to provide one code path, no need in the different patchs with runtime switching. This will make testbed's code entangled enough, without any reason. Speed isn't critical in the testbed, which runs tests for about of millions clocks.

That's because I have suggested to Frank to use MMX code instead of SSE2 code. He strongly wants to do testbed very fast, and I suggest to do this in way of better compatibility.  :lol

[frktons]

as to the CPU features.....

i am not just talking about the code in the algos
i am seeing MMX code in the TestBed procs

my suggestion is - you may want to re-think using any code in the testbed
program that prevents it from being used on older CPU's
it is nice to be able to run test algos on older machines

good nite Frank   :bg

The Testbed is also my learning  project. This is one of the reason it changes so often  :P

The Conditional assembly will be done the reverse way:

I start with the minimum CPU requisites, and if the user wants to switch to internal
faster PROC, he has to change the switch/es because he should know what machine
he is running. The default settings should be "old enough compatible".  :lol
And if they aren't, somebody will say it.   :P

I think MMX, SSE and SSE2 code is OK in the TestBed as long as you test for it and provide alternative code. 
Which is what Frank was talking about doing.

Yes this is my project. I'll  learn many ways of doing the same thing, and give the prog
sort of flexibility. Alex is rightly proud of his flexible "Algo Manager", but I had not time
to rearrange the code in order to use it. The future is ahead, by  the way.

But such thing as testbed, I guess - would be better to provide one code path, no need in the different patchs with runtime switching. This will make testbed's code entangled enough, without any reason. Speed isn't critical in the testbed, which runs tests for about of millions clocks.

That's because I have suggested to Frank to use MMX code instead of SSE2 code.
He strongly wants to do testbed very fast, and I suggest to do this in way of better compatibility.  :lol

You are right my friend. But I learn more making more errors than fewer.  :lol
And I should only use old code. This way I can use also more recent one.

MMX is not that young, nobody has noticed it with all the tests done.
SSE2/3/4 are another thing. For those, better to have switches, in order to allow
people who want to try them, to be able to do it.

Because I'll be away most of the week, I leave you the last version, corrected with your
help, that should be able to run on whatever [I'm exaggerating] pc with a pentium ans windows
98 upwards. Sorry not being able to make it DOS compatible and 286 standard  :lol :lol :lol :lol

Frank

Tested with Win XP SP3:

Code Select Expand


┌─────────────────────────────────────────────────────────────[22-Nov-2010 at 11:29 GMT]─┐
│OS  : Microsoft Windows XP Professional Service Pack 3 (build 2600)                     │
│CPU : Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz with 2 logical core(s) with SSSE3      │
├──────────────────────────────────┬─────────┬──────────┬──────────┬──────────┬──────────┤
│        Algorithm notes           │Proc Size│ Test # 1 │ Test # 2 │ Test # 3 │ Test # 4 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│01 ustrv$ + GetNumberFormat       │    95   │   35.571 │   35.407 │   35.333 │   35.281 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│02 udw2str + GetNumberFormat      │    65   │   34.130 │   34.297 │   34.346 │   34.246 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│03 wsprintf + GetNumberFormat     │    73   │   41.227 │   41.215 │   41.189 │   41.197 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│04 Clive - IDIV and Stack         │   120   │    2.952 │    2.963 │    2.990 │    3.030 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│05 Clive - reciprocal IMUL        │   157   │    1.931 │    1.975 │    1.932 │    2.012 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤
│06 Hutch ustr$ + format algo      │   159   │    6.262 │    6.274 │    6.300 │    6.280 │
├──────────────────────────────────┼─────────┼──────────┼──────────┼──────────┼──────────┤


[ramguru]

kinda strange, when I re-Run the benchmark, timings differ by 1 to 4 seconds, is this considered accurate ?

[frktons]

kinda strange, when I re-Run the benchmark, timings differ by 1 to 4 seconds, is this considered accurate ?

What do you mean 1-4 seconds? The time is calculated in CPU cycles, in billionth of seconds.
If the tests differ 1-4 cycles it is quite normal.