Forum > Windows

BOINC as library

<< < (4/9) > >>

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! :o.  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! :D .. 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 :P

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page