Seti@Home optimized science apps and information
Optimized Seti@Home apps => Windows => Topic started by: Simon on 13 Aug 2006, 12:59:33 pm
-
Hi everyone,
as all of you who tried to use VS 2005 to compile your own apps were bound to notice, it doesn't work so well with the current code base.
However, there are only a few minor fixes required to change that, as it turns out. I will update the available source package with a pre-edited version that should work for both VS 2003 and VS 2005 (after import, that is).
The reason that you will still have to import the project is that otherwise, VS 2003 will not be able to use the project any more. Alternatively, I may offer two versions, one for VS 2003, one for 2005. Still deciding, it's a matter of web space, really.
Anyway, new version(s) should be up today or tomorrow. This should also pave the way for 64-bit app development - so far, using 2003, I always had linker errors when I tried to make real 64-bit apps. Intel and Microsoft both say in their docs that VS 2005 works better in that regard (and that ICC/IPP will be developped for VS 2005 in the near future only).
Regards,
Simon.
-
and that ICC/IPP will be developped for VS 2005 in the near future only)
Confused about this phrase Simon...does it mean the VS 2005 version you will be posting won't use CPP to compile?
-
Sorry for the confusion :)
What I meant is this - Intel will not further develop VS 2003 compatibility for ICC and IPP. Future versions will require VS 2005, to my knowledge (though right now, it still works, and they will continue to offer all versions on their FTP server).
HTH,
Simon.
-
I've been testing the binary compiled with VS 2005 vs. 2003, and the first things to note are these:
Amazingly, the size of the .exe is quite a bit larger (8.2 MB vs. 6.9), even though we're using the same compiler and libraries. No idea whether the VS 2005 compiler tries to inline/unroll things more aggressively, or why else the file is larger, but it works and produces valid results.
The VS 2005 app was marginally quicker in my test runs, so maybe it does optimize more aggressively.
Regards,
Simon.
-
This is REALLY good news. Keep up the good work.
For now i have a AMD X2 system and as soon as there is a 64bit version out there or a way to get a compile to get through in VS2005 im going to dig after my Win XP Pro 64 bit trial version and try to compile a 64bit version or if we get a client to test it on..
Kind Regards Vyper
-
I've put up a little rtf-file with all the changes that are necassary to use the free Express Version of VS2005. Also included are changes to get rid of all the warnings flooding your screens while building seti_boinc. My code base was the actual CVS source from v5.17 (14.08.2006). If you want, feel free to copy and paste the lines.
Urs
[attachment deleted by admin]
-
Thanks Urs :)
Will take a look at your changes and compare to what I have right now.
Regards,
Simon.
<edit>You were a lot more thorough than I was, and removed all warnings (I only fixed the errors). Thanks for taking the time to bring them into an easily perusable document :)</edit>
-
I hope that will speed up your compile and build process a little bit. In your How-To document you wrote something about 10-15 minutes.
Urs
-
As BenHer noted in a different post (http://lunatics.at/index.php/topic,52.msg542/topicseen.html#msg542), whole program optimization is what takes most of the actual compile time. WPO and IPO, in fact.
/Qipo - Try to do multi-source-file optimizations.
Inline small functions from one source file at call points in functions from other files
Use registers to pass paramenters from some functions to others (rather than stack)
many other items
TAKES LONG TIME!! - Uses up to 1.4Gig of RAM + swap file
The build itself is done within a minute and a half on my 1.6 GHz clocked P4 laptop. The linking/WPO process takes forever :) My main build host (that I have not yet upgraded to VS 2005) takes 8-11 minutes clocked @ 3.85 GHz with 1 GB Ram to do a build with WPO - MMX takes the shortest time, then SSE, SSE2, SSE3 each take a slight bit longer.
Thanks for the hint with the Manifest file, by the way. My 5.15 codebase imported fine on VS 2005 and made its own manifest file without complaining. The 5.17 CVS sources I just built did not, and without that hint it would probably have taken way more time to convince VS to just get on with it.
Regards,
Simon.
-
Urs,
I've taken the liberty of forwarding your RTF file to Eric Korpela along with another proposed source fix. Lets hope future versions may already incorporate some of our changes and make everyone's life just that little bit easier ;)
Regards,
Simon.
-
Simon & Urs,
As a side note I have a separate "configuration" under the configuration manager for testing ideas.
It doesn't have /Quipo or a few other optimizations turned on...and so I can
change a function -- compile -- link -- begin a test run of the changes within a few seconds.
Then I aslo have the original configuration provided by Simon for full (long compile+link) if I want to go there.
-
Sounds like a good idea - especially for quick testing whether something compiles or links properly.
In other news, my 5.17 compilates are showing varying degrees of speed - but so far, they do seem a bit quicker than 5.15, as opposed to my last attempt at compiling 5.17 where they were slower.
So my degree of optimism as far as 5.17 is concerned is growing - crunched results all validate so far.
Regards,
Simon.
-
hey,
I have some good news and bad news.
The good news it that if you need/want any help testing let me know and I will see what I can do.
The bad news is that I am moving next week and I will be taking all os my systems offline for an unknow period of time.
PM me if there is anything that I can do to help.
citroja
-
Urs,
I've taken the liberty of forwarding your RTF file to Eric Korpela along with another proposed source fix. Lets hope future versions may already incorporate some of our changes and make everyone's life just that little bit easier ;)
Regards,
Simon.
Thanks Simon,
that saves me the time to publish a post at the setibeta-forums with that rtf.file attached. Hopefully Eric Korpela will have the time to look into the modifications and rate them carefully if necessary or not. And, as i wrote in my file, this was only compilerlevel 3. There is a Level 4 waiting to show, were the real bugs are in the seti@home-sources (Changes at that level would fill a book).
At the moment i do not have Intel's ICC/IPP. I use only the VS2005 Express version, but intend to buy the standard C++ version, because it seems to me a very useful worktool. On my Pentium M 2.0 a build only needs about a few seconds. So even a try and error method is a possible way of developing (think and type is much more fun and more efficient).
Urs
-
...
In other news, my 5.17 compilates are showing varying degrees of speed - but so far, they do seem a bit quicker than 5.15, as opposed to my last attempt at compiling 5.17 where they were slower.
So my degree of optimism as far as 5.17 is concerned is growing - crunched results all validate so far.
Regards,
Simon.
Don't put that optimism to high, especially not onto 5.17. There have been posted so many compute errors in the beta forums that a new version with lesser bugs seems oblige for the developer. I've tried now many, many combinations of the MS compilerswitches and have found a combination that is on par with the standard 5.17 DevC++/MinGW build. Only, i had to enable SSE. But ICC/IPP seems to be according speedup a better way.
Another way i've seen shortly at the seti forums in a post by Piednoel Francois: structure of structures. His explanations look promising. But will that way work on other platforms without 128bit SSE4 instructions?
Last there are good books to read at that topic: Algoritms in C++ by Robert Sedgewick shows ways how to parallelize FFTs and other algos. Maybe there is something in there that can be used.
Urs
-
@Simon
how far is the version for win x64?
-
Keeps getting a linker error, which so far I haven't been able to resolve - I'm going to ask Intel Premier support, maybe they have a solution for me.
Regards,
Simon.
-
Simon,
Found this today while poking around the web...might it influence?
When targeting x64 platforms in Visual Studio .NET* 2005, programmers are no longer able to use inline assembly code as they did for 32-bit code.
at this link (http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/pentium4/257129.htm)
-
Keeps getting a linker error, which so far I haven't been able to resolve - I'm going to ask Intel Premier support, maybe they have a solution for me.
Regards,
Simon.
Ouch, this sounds not good ::)
Still hope that you can fix it.
Regards
TG
-
Hello:
Thanks for all your hard work in supplying optimized clients. Do you plan to complie and offer the 5.17 S@H client?
-
Yes and no.
Yes, I will definitely release an updated S@H app once the default app gets updated, as well.
However, as it looks right now, 5.17 may never make it to the main project, but 5.18 might. When that happens, I will be ready with an optimized version of it, as well.
HTH,
Simon.