What is the current test state of the Windows optimized?

---

Test state?

In my tests, it's been running mighty fine. The only problem (and what's keeping me from releasing) is the license.

Results are valid, some of my boxes are using my Windows build already. I just can't legally distribute things I compile until Intel allow people to use their compiler and library packages for free and non-commercial tools for Windows just like for Linux.

However, someone just bought a license, and I'm sincerely hoping he reads and follows my instructions so everyone can get an optimized Windows version.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

Mmkay,

I made a rather startling discovery, and it's starting to firm up.

I've alluded to this before - my first test system was a Virtual Machine (VMWare hosted on Windows) that ran Linux. I did this so I wouldn't have to dedicate a full HD or partition to it and it wouldn't affect my system otherwise.

Well, during testing, the times I got were out of this world (very, VERY quick). In later testing (all done outside a VM), I never got very close to them anymore. This, while annoying, made me think hard about what could be different - since stuff in a VM is using the same hardware as when you install an operating system normally, it should generally be around the same speed (except for graphics, which I disabled anyway).

It didn't seem to be that case, though.

So I bought a P-D 805 system last week which I'm using to benchmark on now because it has 4 operating systems (Windows/Linux 32/64 Bit) installed on it. The times it was pulling with my optimized builds were quite okay even though it was running single channel until today (finally got my second DDR2 module), but they were really nowhere close to what I expected given my first test runs on the VM.

So I thought, let's install a VM on this computer, as well. After that was done, I started crunching some WUs on it, and guess what: it's a lightning bolt.

You can compare the following 4 hosts - they're all one and the same computer with different operating systems:

Linux in a VM on Windows 32 Bit

Windows 32 Bit

Windows 64 Bit

Linux 32 Bit

There aren't a whole big lot of results to compare yet, but the 58.70/58.69 units are all VLARs which take the longest time of all.

Lin32 in a VM average for WLAR WU: ~10600s
Win32 average for VLAR WU: ~16600s
Win64 average for VLAR WU: ~16200s
Lin32 average for VLAR WU: ~17500s (no VLAR yet, _estimated_!)

So that's a HUGE difference there...I still have to benchmark Win32/64 with dual channel again as it should be significantly quicker as well, but not THAT much.

So compare my other host, which has been running dual channel all the time (Athlon64 3500+).

Lin32 in a VM - 8000-10000s/VLAR WU
Windows 32 Bit - ~13400s/VLAR WU

That is more than a little surprising, I must say.

Currently, it looks as if crunching in a VM gives extra speed. It's not logical, but that's how it is.

Average speedup of VM vs. native/same hardware:
!!!!!FIFTY PERCENT!!!!!!

Now THAT's something to write home about.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

Josef,

it should be noted that the tests on Linux were with a client that had no graphics and DID go faster. Hence the smaller speedup of standard vs. optimized on Linux - see my benchmark posts.

I had no graphics-less Windows version to test with, so that's why the tests used this version - which I got via BOINC, so it's the one everyone is using.

Certainly 5.15 needs to be the reference, I was only noting that the appearance of Intel builds being 2x to 3x faster than gcc builds is not a fair comparison.

Windows 5.15 can be run with a -nographics argument in standalone, and that gives another data point to consider. Unfortunately the -nographics argument causes a non-graphic build to quit with an error, which makes automating tests more complex.

One thing I discovered in the last two days is that running standalone with graphics but minimizing the graphics window as soon as it appears also reduces the run time to very near the -nographics case. What I don't know yet is whether running with BOINC but not showing graphics is similar to the minimized window situation.

Also be aware that these times do not scale to all ARs. On some the speedup vs. unoptimized is close to 3x, so that's not entirely untrue. On average, I'd say it's about 30-50% faster on most WUs.

Regards,
Simon.

I think that's a fair estimate. There may be lessons to be learned from the effects at different ARs, an analysis might give clues to where some algorithms can be improved.

                                                         Joe

...Currently, it looks as if crunching in a VM gives extra speed. It's not logical, but that's how it is.

Average speedup of VM vs. native/same hardware:
!!!!!FIFTY PERCENT!!!!!!

Now THAT's something to write home about.

Very interesting indeed!

1: Is the speedup real (wall-clock time) or some fiction of time reporting?

2: Why? What's different in the VM world compared to just the native hardware??

Keep with the kool developments there! ;-)

Regards,
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

Ahh, -nographics :o)

I'll be using that and doing a new run of the same WUs with the default cruncher.
We will see what happens.

Thanks for the info, as always!
Simon

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

...Currently, it looks as if crunching in a VM gives extra speed. It's not logical, but that's how it is.

Average speedup of VM vs. native/same hardware:
!!!!!FIFTY PERCENT!!!!!!

Now THAT's something to write home about.

Very interesting indeed!

1: Is the speedup real (wall-clock time) or some fiction of time reporting?

2: Why? What's different in the VM world compared to just the native hardware??

Keep with the kool developments there! ;-)

Regards,
Martin

No, this is in *real* time. The clock in the VM is exactly the same as on the Host OS it's running on. Check the times recorded in the results :o)

As to the difference - THERE AIN'T ANY! Rather, it should be slower due to added overhead, if anything. That's why I'm so amazed. I just can't believe that Linux would work more quickly hosted on Windows. Results show that this is the case, however, on more than one host (though I'm still not positive it's correct and not due to some strange warp in space-time).

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

First KWSN, thanks for all your work and experiments :)

Lin32 in a VM average for WLAR WU: ~10600s
Win32 average for VLAR WU: ~16600s
Win64 average for VLAR WU: ~16200s
Lin32 average for VLAR WU: ~17500s (no VLAR yet, _estimated_!)

Average speedup of VM vs. native/same hardware:
!!!!!FIFTY PERCENT!!!!!!

Probably silly idea (I don't use/know VMWare), but if
win32 is faster than lin32
win64 is faster than win32
lin32 in a VM is faster than win64...

what about win64 in a win64 hosted VM ? *%)

---

@KWSN - Chicken of Angnor:

I compiled the application, but I got a lot of warnings. The most are:

"../../db/schema_master.h(31): warning #187: use of "=" where "==" may have been intended
return !(db_is_open=0);"


But I got 1 catastrophic error (in project boinc_seti):

"analyzeFuncs.cpp
..\\analyzeFuncs.cpp(70): catastrophic error: could not open source file "ipp_w7.h"
#include <ipp_w7.h>"

I did all the changes exactly like in the instruction.

Is it possible, to discuss this via ICQ (My Nr.: 310857779)?

---

That file is in c:\\program files\\intel\\ipp\\8.0.2\\ia32\\tools\\staticlib.
This path should be in the Include paths (check there and whether it's correct).

You can ignore the warnings, I get them too. They don't matter, really.

Good luck :o)
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

KWSN: Can you hit me again in ICQ, something got wrong. I saw the window, but I could not write to you...

---

First KWSN, thanks for all your work and experiments :)

Lin32 in a VM average for WLAR WU: ~10600s
Win32 average for VLAR WU: ~16600s
Win64 average for VLAR WU: ~16200s
Lin32 average for VLAR WU: ~17500s (no VLAR yet, _estimated_!)

Average speedup of VM vs. native/same hardware:
!!!!!FIFTY PERCENT!!!!!!

Probably silly idea (I don't use/know VMWare), but if
win32 is faster than lin32
win64 is faster than win32
lin32 in a VM is faster than win64...

what about win64 in a win64 hosted VM ? *%)

Ah, it was too nice...couldn't believe it was true anyway, and it isn't.

I've since used a real stopwatch to see whether an hour in real time equals an hour in processing time. Well, it doesn't. Seems Virtual Machines live in some kind of time-dilation field. The system clock keeps going correctly, but the elapsed time goes like molasses - between 20 and 40 percent more slowly than normal. So I'd say that the apparent gains from running in a VM are purely in the numbers, which can lie too as can be seen.

Must be going near light speed to make time go more slowly...*grin*

In any case, guess I can not recommend crunching in a VM after all, as it seems to skew the results.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

Do you have the vmware tools installed in the guest OS (linux)? I saw some truly strange timing issues in my vm hosts before I got the guest tools installed. Even after installing it, there can be some weird quirks but it does help out a lot.

I am also happy to report that my dual core is happily crunching along and its results are finally being validated. No errors so far. Looks like your careful testing has been successful.

---

A member of The Knights Who Say NI!
For rankings, history graphs and more, check out:
My BOINC stats site

Thanks Toby!

And yes, I guess the tools should help with timing issues there.

I still don't get why the system clock works correctly but the program counts time more slowly though, but I'll put that down to VM peculiarities.

I'll test more after installing the VMWare tools.

Ni!

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

FYI the two dual core machines on my account are indeed different machines and are virtually identical except that one runs amd64 linux and one runs 32 bit windows. The linux one also has 2 GB of memory to the windows' 1 but other than that they both have the same motherboard and similar hardware all around. This might be useful for some comparisons as well... All the recent work units on the linux one are of course processed with your optimized app but if you go back a few pages you can compare how the two did with the stock app.

linux host (at work)
windows host (at home)

---

A member of The Knights Who Say NI!
For rankings, history graphs and more, check out:
My BOINC stats site

There aren't that many differences (besides clock speed) from a 486 to an early Pentium, IIRC.

The cool stuff starts with the later K6's and PII's.

True, And I've seen them all. Soon I'll be 46 on July 6th, Party on the 1st though as members of My extended family can only be together all at once then. But I crunch on and on. The Uncle B's are in front of Me and I must pass them somehow.

LOL, I hear ya - just turned 41 myself a few weeks ago. Fun to watch the evolution from no personal computers to hobby kits and on and on until here we are today, giving away our spare CPU cycles for projects like this.

---

Kung Fu and Powerlifting

KWSN- Chicken of Angnor wrote:

So I bought a P-D 805 system last week which I'm using to benchmark on now because it has 4 operating systems (Windows/Linux 32/64 Bit) installed on it. The times it was pulling with my optimized builds were quite okay even though it was running single channel until today (finally got my second DDR2 module), but they were really nowhere close to what I expected given my first test runs on the VM.

???

If you can afford to buy all this HW on a whim, why not just pay $600 for an Intel license?

---

Who said it was all on a whim? Also, how is my budget anyone else's but my business? Why do you think I bought a system for bottom-dollar?

Eric, not to belittle you, but you keep asking me why not this why not that. So let me ask you: why not you? No technical ability required here. Just money.

I haven't asked for anyone to donate anything to me (and will not). Why not spend a further 600 dollars? Rent, for one. I'd like to be keep living where I am, thank you. So er...kindly refrain from comments like that, it's a bit much to expect me to cough it up just because everyone would feel so much happier if I did. Really.

Add to that the time I spent putting together easy-to-follow instructions for people, testing, benchmarking...

You couldn't pay me for it, most likely, if I started calculating how much someone would have to pay me to do what I did in this short time. I really cannot afford it, else I would have already bought it. Clear enough?

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

Who said it was all on a whim? Also, how is my budget anyone else's but my business? Why do you think I bought a system for bottom-dollar?

Eric, not to belittle you, but you keep asking me why not this why not that. So let me ask you: why not you? No technical ability required here. Just money.

I haven't asked for anyone to donate anything to me (and will not). Why not spend a further 600 dollars? Rent, for one. I'd like to be keep living where I am, thank you. So er...kindly refrain from comments like that, it's a bit much to expect me to cough it up just because everyone would feel so much happier if I did. Really.

Add to that the time I spent putting together easy-to-follow instructions for people, testing, benchmarking...

You couldn't pay me for it, most likely, if I started calculating how much someone would have to pay me to do what I did in this short time. I really cannot afford it, else I would have already bought it. Clear enough?

Regards,
Simon.

Very well put Simon. Thank you once again for all your hard work.

---

Hi again. I've temporarily got a hold of VS .net 2003 :-)
I've come across the same problem as Bluesilvegreen. The ipp_7t.h file doesn't exist an my computer :(. i think it maybe because the only version i could find on intels website is ipp 5.1 whilst your seems to be 8.0.2 first time and versin 5.0 next. oh and i dont have a staticlib folder in tools. i have a stubliib in the main directory thought?

Will this cause me roblems. Not worried by all the warings as you say

Whilst mooching around i noticed the 'optimizaion' tab in c/c++ folder icon when you've rightclicked into properties. I sthis redundent since you've used the command line route.. I ask because the commands are slightly didderent forprocessor specific. QaxP for pentium 4 SSE3 maybe that might get me better performance in my settup?
Also is the MKL math stuff automatically used when you've included them as per your instructions. I ask because in preproccesor commands you added use_IPP. does it need use_MKL?

[EDIT]
Went through more thorought and it seems its all to do with trying to impliments SSE ect. You prbly knew that already. looking thruoght that part the code i can see i dont have any of those #include files except ipp.h:

// In order to use IPP, set -DUSE_IPP and one of -DUSE_SSE3, -DUSE_SSE2,
// -DUSE_SSE or nothing(generic), IPP precedes FFTW, ooura // TMR
#if defined(USE_IPP)
#pragma message ("-----IPP-----")
#if defined(USE_SSE3)
#define T7 1
#pragma message ("-----sse3-----")
#include <ipp_t7.h>
#elif defined(USE_SSE2)
#define W7 1
#pragma message ("-----sse2-----")
#include <ipp_w7.h>
#elif defined(USE_SSE)
#define A6 1
#pragma message ("-----sse-----")
#include <ipp_a6.h>
#else
#pragma message ("-----mmx-----")
#include <ipp_px.h>
#endif // T7
#include <ipp.h>
#elif defined(USE_FFTWF)
#pragma message ("----FFTW----")
#include "fftw3.h"
#else
#pragma message ("----ooura----")
#include "fft8g.h"
#endif // USE_IPP

these are the files i do have. Any chance one of them is the right one and i can edit the code to use it instead?:
ipp.h - ippac.h - ippalign.h - ippcc.h - ippch.h - ippcore.h - ippcv.h - ippdefs.h - ippi.h - ippj.h - ippm.h - ipps.h - ippsc.h - ippsr.h - ippvc.h - ippvm.h

Thanks very much again. Made this all extremely interesting. learnt more going thought your tutorial than did in the last week with a couple of old c++ and VB books