BOINC as library

[Raistmer]

Well, I just pick up sources with that option set active, then changed paths to correspond my installation (different places for ICC and IPP, ICC 10 instead 9, IPP 5.2 instead 5.1 and so on), changed defines to USE_SSE2, changed compiler options to  /QxW.
So now it more correspond to SSE2-build than to anything else When I change to Release32-NoGFX-xW option set I get a lot of errors cause there are old wrong paths IMHO.
The host on that VS installed powered by AMD 64 Venice wich supports SSE2/SSE3 instruction sets but it seems there is no sense to compile with ICC SSE3 for AMD 64.

[Jason G]

The case of the missing intermediate files! .  I must go off to school now but I'll check and see if you found them when I get home.  I think you are right that the setting shouldn't change the intermediate output directory/files as that is inherited from solution configuration anyway.

Well good luck , and maybe I can look some more when I get home (if you haven't already found them).
[We can step by step through AnalyzeFuncs.cpp setiings if you need]

Oh, did you do the seti_boinc Linker include directories as well ?

Jason

[Raistmer]

Yes, linker include paths are changed too.
But (!) when project was compiled under Release32-NoGFX-xW option set it failed to compile as whole, but there is analyzePoT.obj analyzeReport.obj in Release32-NoGFX-xW dir.
And there were no these obj when Release32-NoGFX-xP was used. So at morning I will try accomodate Release32-NoGFX-xW to my setup instead of -xP one. Probably I did something wrong with *-xP option set....
Thank you for support and good luck to you too

[Jason G]

Sounds like progress! .. I hope you made notes the first time through all those settings!, mine are in green felt pen scrawled all over an old envelope, maybe I should make them into a text file one day

[Jason G]

Back along the lines of your original post Raistmer (Boinc as library) ... I've been having some crazy thoughts.

Given the already  fairly neat encapsulation of certain parts of the science application (namely the boinc interface, graphics api, xml utils, jpeg maybe more...) ,and that each instance of the science app (typically 2 to 8 copies) uses these. Might these low traffic functions actually be worthy candidates  for ... *shudder* ... implementation as one or more DLLs? [or equivalent for other OSes, where available]

Certainly reduce the overall memory footprint , especially for many cores. (might influence cache too?)  Can you [or anyone else for that matter] think of other reasons this may be a good or bad idea?

Jason

[Raistmer]

Well, as big fan of QNX OS I think the more modular app is the better as far as it doesnt impact performance Another plus of dll'ed BOINC interface is shortened build times - devs certainly should like this idea

Considering my build attemts, switching to Release32-NoGFX-xW options set brought bunch of compile errors (12 errors) in benchmark.cpp and  cpu_x86.cpp. I have strong impression that Optimizer project just simulated compilation before (with no errors but no objs too).  There are all objs from tis project now besides these two sourses that failed to compile.
Will investigate errors more closely then post.

P.S. after closer look only 3 errors remain (other originated from misplaced #endif, my fault). All belong to these lines of code ( cpu_x86.cpp).
case _INTEL:
         cache.shared_L1_L2 = true;
         bool hyper   = testBit(1,edx_,28);

.\cpu_x86.cpp(143): error: invalid combination of type specifiers

hyper is defined as _int64 somewhere. So changing variable name solves this error (and remaining 2 too).

P.P.S. Well, now got     position_history( 0 ),-related error too  After adding some missing #include statement and forcing const char* to char* conversions (hope it will not corrupt memory at run time %) ) it's the only remaining error.

[Jason G]

Well, now got     position_history( 0 ),-related error too  .....

Yeah, I figured the cryptic message was saying there was no constructor of type position_history( int) .... and position_history seems to be a vector list or some such.    Carefully commenting the '0'  out seemed to let C++ use the default constructor,  that 'seemed' to work for me.

I'm all for either explicitly using an existing correct constructor to initialise with though, or ,making a constructor of the right form if really needed .

Have fun, you're nearly there After a few weeks on and off, I'm still pretty mystified by a lot of it but baby steps and lots of silly questions seems to be clarifying a lot gradually.

Jason

[Raistmer]

Yes, I commented it out too for a moment.
Now encounter some linker errors. Some of these originate from using evaluation version of IPP (so there are slightly different lib names). But remaining are much worse. For example,
linker cant find definition of parse_command_line function. There is declaration
extern int parse_command_line(char*, char**);
in str_util.h but... no definition was found in project sources. I hardly believe this function belongs to IPP. So where to find it's definition still open question ... 

[Jason G]

.... So where to find it's definition still open question ... 

Hmm, in mine that seems to be in Util.C , part of the libboinc solution.  maybe your build order has that being compiled after set_boinc where it is called from main.cpp?  or maybe util.H is not included [at top of main.cpp] for some reason?

[Ahhh, maybe libboinc directory is not added in 'Additional include directories? for seti_boinc soln]

[Raistmer]

In my BOINC sources this function defined boinc\lib\in str_util.c. And this file doesnt included in project source tree. That's why I didnt find definition while conducting search in project files via VS. File search on entire directory via FAR was more successfull
Probably I should include this file in libboinc project in project tree.
(I use one of the latests BOINC sources, doesn't downloaded from this site)

P.S. Now only 3 unresolved links remains. Will search for another missing sources...

P.P.S. LoL Great definitions of missing links from boinc\api\static_graphics.C
void boinc_app_mouse_button(int x, int y, int which, int is_down) {
}
void boinc_app_mouse_move(int x, int y, int left, int middle, int right) {
}
Probably there should be // ToDo comment

I added this file to libboincapi, but it doesn't compile - missing boinc_resolve_filename function declaration. It seems there are some differences in BOINC api that needed to be reflected in project tree.

P.P.P.S. After some modifications of project tree and adding some #include statements I got exe-file. Hope it pass validity tests ... (fingers crossed)

[Jason G]

LOL, Like a house of cards!

[Jason G]

This many generations of Boinc interface  is one of the many things I got an answer about from Joe Segur.  I asked which was the best to use and if there was a preferred version.  The basics of Joe's answer to that were something like 'boinc sources from about the time of that science app build. Which semmed reasonable ... So for some reason I ended up sticking with the boinc sources out of the 1.31 package and never bothered updating sounds like I'll keep it that way, for the time being,  if there are many more differences

[Raistmer]

Well, "results strong similar" but it ~2% slower than optimal one for AMD 64 processors.
Think I create new thread and attach my build (it's sources to be precise) to post. Maybe someone saves time by compiling already modified sources.

[_heinz]

Congratulation.... magnificent !.
heinz

[Raistmer]

Thank you 
With Jason's help and support indeed 

rared distributive took ~22MB... I tried to upload it yesterday night with some comments but at morning discovered that IE crashed .
Maybe it's better to attach to few sequental posts... will try again later.