New version of the KWSN Test & Benchmark Tool with Auto-Installer released

[Simon]

Hi folks,

an updated version of the KWSN Test & Benchmark Tool has been released.

KWSN Test & Benchmark Tool with Auto-Installer - apps without graphics (1.75 MB compressed - 49.2 MB uncompressed - 7z rocks).

]KWSN Test & Benchmark Tool with Auto-Installer - apps with graphics (1.82 MB compressed - 43.3 MB uncompressed).

The apps containing graphics are minimally slower than the ones without - your choice, either eye candy or raw speed.

Double-click the downloaded exe file and unpack its contents. Then run the file with the same name inside the directory it creates.

This version now contains all released Rev 2.0 apps as well as the 1.41 Core 2 one. It also has a slider to select between shorter run time with less accurate results or longer runtime with more accurate ones.

By default, "medium" is selected. On an Athlon64 3500+, "short" took about 4 minutes, "medium" took about 10 minutes and "long" took about 25 minutes.

On hosts that are slower than 1 GHz, "long" is not recommended - even "medium" may take a while. Hint: if the run results are very close, you may want to up it a notch towards accuracy to help you decide. The few extra minutes you spend here will give you days or more in the long run.

Regards,
Simon.

[michael37]

Greetings. 

Simon, thank you for your work on the optimizer. 

Is there a chance you can port this application to Linux?  If not, I'll be glad to work with you and develop a shell script which will have the same function on Linux machines. 

michael37

[Vyper]

Hmm am i doing something wrong?!

I try to run the executable and i only got unable to initiate the program correctly.. 0xc0000135.. Click OK to end the program..

Remarks, this text is written on Swedish.. so i'm trying to translate it to english so some words could be used differently in the english session..

Kind Regards Vyper

[Simon]

Vyper,

looks like you need Microsoft .NET 1.1

Michael,

no, right now I hadn't had a Linux version planned, although I'm interested in getting one made - if you can help, I'd be much obliged.

HTH,
Simon.

[Vyper]

Doh!

Please compile a version that doesn't require .net .. I really don't like to flood my OS with various addons that isn't really necessary 

And if you don't , then bugger for me . lol .

Kind Regards Vyper

[KarVi]

I'm confused. 

Having read the posts about the 2.0 apps, I came to the conclusion, that the generic SSE2 app, would be the fastest for my Athlon 64 X2 3800+ @2564Mhz.

But using Iccpatch on the Intel only SSE2_P4 file, and running the test in most accurate mode, reveals that the Intel "only" app is 8 seconds faster than the generic client. In medium mode SSE2_P4 is 4 seconds faster, and fastest mode its 1 sec faster.

Now 8 seconds doesn't sound of much, but multiply it with average runtimes, and it could be minutes of crunching time saved pr. WU, and in the long run several more WU's crunched by my system pr. week. 

I'm surprised this passed the developement and probably lots of tests, without being found out about, and consequently making _sure_ the generic app was the absolutely fastest app on Athlon64 systems.

[Simon]

KarVi,

don't assume we don't know that

Thing is, the legal situation on ICCPatch is kind of unclear. I do not want to invalidate my expensive ICC/IPP licenses, so I'm not offering prepatched apps.

Comprende?
Simon.

[KarVi]

Allthough my spanish is not all that good, I think I understand. But...

In every single message that I've read about these apps, it has been said that the generic app was the fastest. No hint to that with a little effort you could get even faster crunching. In my view thats borderline lying (don't take offense, its not ment as harsh, but i lack other words as english is not my motherlanguage)....

I fully understand the problems surrounding your license, and off course you have to protect your license from being rewoked.

But letting a hint, and perhaps a link to an explanation and the application to patch the executable yourself (its easy), could be done without endangering the license. As long as you dont distribute the patched executeables you should be safe.

In my view it says a lot about Intel, that they would even use such a threat to hamper the competiitions performance, but thats another discussion.

[Simon]

In the past,
I've posted about this topic a few times already. Still, right now there is no obvious hint about this - but enterprising people like you find out anyway

Just goes to show you: people are resourceful...

In any case, for everyone:

http://www.swallowtail.org/naughty-intel.html
You can find more information on this subject here.


HTH,
Simon.

[BenHer]

Simon,

Did you write the tool in "Auto-It"?

[Simon]

Nope.

I took the sources I had already, modified as necessary and recompiled (VB .NET).

A test/bench/install platform in auto-it would be the next step, but I haven't had time to get into it yet.

Regards,
Simon.

[BenHer]

If someone were very enterprising...and curious about such things...

They could observe the 2.0 crunchers in action and note that the code checks for the specific presence of an Intel processor four times in each of the intel specific .exe files.  The first 4 occurences of 'Genu' 'ineI' 'ntel' in the source code are solely to limit code to Intel only.  Any following occurences are for my CPUID code when identifying CPU. Just for curiosity sake. 

You might also notice that Simon neglected to compute an overall checksum over the entire EXE allowing naughty end users to potentially change the code and still have it run.  Naughty Simon!

[Simon]

Naughty Simon!

Damn straight!

[Youth]

I've installed the .Net Framework 1.1 on my laptop, but when i run the test tool, it still prompt to require the .Net Framework 2.0.50727.

Vyper,

looks like you need Microsoft .NET 1.1

Michael,

no, right now I hadn't had a Linux version planned, although I'm interested in getting one made - if you can help, I'd be much obliged.

HTH,
Simon.

[Arnulf]

If someone were very enterprising...and curious about such things...

They could observe the 2.0 crunchers in action and note that the code checks for the specific presence of an Intel processor four times in each of the intel specific .exe files.  The first 4 occurences of 'Genu' 'ineI' 'ntel' in the source code are solely to limit code to Intel only.  Any following occurences are for my CPUID code when identifying CPU. Just for curiosity sake. 

You might also notice that Simon neglected to compute an overall checksum over the entire EXE allowing naughty end users to potentially change the code and still have it run.  Naughty Simon!

And if someone should try to run the potentially changed code on an Opteron 265 they would notice that the generic SSE2 client is faster than the potentially changed one. 

A.