| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: FightAIDS@Home
Thread: 64 bit version of FAAH application - up to 25% faster... |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 32
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Everybody seems to be kind of expecting better results and we are just waiting to see real numbers.
At the very first post of this thread I have suggested to use the real source code of FAAH, recompile it to X64 and compare results. I have no access to this code (or is there somewhere who can help with that ?) but I would plan recompiling Autodock software in both X64 and X86 and then making some conclusion. Autodock is the base software for FAAH, so I believe both the subject itself and it's coding style will be very similar. I would like to suggest (or autosuggest, as I will attempt it to) to check the results given by: 1. Autodock recompiled as X86 code 2. Autodock recompiled as X64 with no modification 3. Autodock recompiled as X64 with some optimizing modifications Should point 2 give 10% or more improvement, this would be clear signal to go for X64, as already 10% can be gained just with recompilation and secondary minor preparations. Point 3 can show us the primisse X64 can give, if more time is devoted to optimization. Wish to know if there are more of us willing to try it. Keep up good work! |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
The science code is not public as can be derived from this help item:
----------------------------------------I have a platform that isn't supported by World Community Grid. Could I get a copy of the research application code and compile it myself? No. The code has to remain in the control of the World Community Grid support team. Even the slightest change in the code, including using a different compiler, could render the research results useless. In addition, the license agreement that we have with the researchers for their code stipulate that only the World Community Grid support team can touch the source code. The source code usually differs slightly from potential public versions of the same code due to changes made for use with the specific grid project. Furthermore, we typically run many tests to make certain there are no problems on a given platform. The programmers had to find the right one, I think from a choice of 100 on some sciences ... so I have a hard chew on a lightly made comment such as 'trivial'. As JmBoullier already nailed it, allot of the benefit is already gained by the mere running on a 64 bit OS/Client... he's done some practical testing comparing how projects run under 32 and 64 bit on the same hardware and posted on the speed gains. Myself I switched from 32 bit Vista to 64 bit W7 and see a pool mean gain of about 15%. It differs per science all depending on what specific portions of the CPU/Co-Processor is used and what exchanges with what memory, real or virtual takes place. As for statistics, rest assured the techs know what computers these results come back from, 32 or 64 bit and what CPU brand and they do not always produce the same result. They've not been exactly out of the blocks on previous queries regarding performance differentials, but the sheer numbers might actually start to add up to justify a test being placed on their planner.
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges: 
|
Well, there's multiple parts to this problem, probably the easiest one to answer is: "How much of production comes from 64-bit capable computers?"
----------------------------------------WCG doesn't show any public info about this, so I'll be using info from SETI@home instead. By looking only on the windows-computers, the current "recently connected client"-list are: version %usage %64bit Now, these numbers can't be directly compared to WCG, since would expect the majority runs v6.2.28, and therefore can't run 64-bit before upgrading clients. But, atleast based on these numbers, it seems most of the users running 64-bit-OS is also the most likely to upgrade clients, since of the users still running v5.10.xx, only 5% of these are running 64-bit, but in the other end, of the v6.10.xx-users, nearly 50% runs 64-bit. Also most interesting, roughly 1 of 3 is 64-bit, so this atleast indicates there's enough demand for a 64-bit application if one was made available... But, so to the very much harder question: "Will a 64-bit application be an advantage to release?" This will often not be the case, for one thing, just grabbing a 64-bit compiler and compile the code won't always work, it's possible one or more changes is needed, just to get a working 64-bit application. Also, you're by no means guaranteeded that the 64-bit application is faster, if you're unlucky, the 64-bit application can actually be slower than the 32-bit (example since you'll need to use a different compiler). Or, the speed-up is maybe 1-2% or something, so the benefit of adding a 64-bit application to the mix is negligible. Or, the result can be mixed, like example 64-bit is 5% faster on some computers, but at the same time 3% slower on other computers, so the total benefit is low. Or, it's a little faster on some of the wu's, but slower on others... Now, if you can get a general speedup of 10% or more, adding 64-bit application will be an advantage. But, if the speedup is less than 5%, even 1/3 of production comes from computers that can handle 64-bit applications, the benefit will drown in the need to debugging and verifying the new 64-bit application gets correct results and so on, that it's basically a waste of time to add it at all. BTW, due to WCG only delivering 32-bit BOINC-client, wouldn't be surprised if less than 5% of WCG-production currently comes from computers that can currently handle a possible 64-bit application... So, WCG would need to start delivering a 64-bit BOINC-client before anything else.  "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
What's really curious in all this is, that when going from Vista 32 bit on a Q6600, stock, to W7-64 bit the Floating Point benchmark did not move up 1 iota, confirming that 32 bit hardware fpu is the limiting factor. The Integer part of the benchmark went up ~30-33%, depending on the mood of the day. Now many have already found out what Help Conquer Cancer, an integer intense science is doing on 64 bit platforms, as 32 bit compiled application. So, what's stopping anyone from that little switch, if you can!
----------------------------------------Saturday Night Live, from the outback, not far from mount Vesuvius.
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
JmBoullier
Former Community Advisor Normandy - France Joined: Jan 26, 2007 Post Count: 3716 Status: Offline Project Badges: 
|
Ingleside,
----------------------------------------Your post is very disappointing. It starts with very interesting general considerations** on the possible benefit of providing 64-bit applications which could explain why WCG is not providing some yet. Next your last paragraph (starting with "BTW, due to WCG only delivering 32-bit BOINC-client") is a total confusion. It implies that - WCG's 6.2.28 client cannot run in a 64-bit Windows, although other 32-bit applications can - a 64-bit science application would not be able to communicate with a 32-bit client. Maybe it is true but I have never read anything (positive or negative) on that matter. I tend to think that as long as they respect the communication protocol there should be no problem - members who would prefer a 64-bit client don't know where to find one - Linux users of 64-bit hardware are not using 64-bit operating systems although they are as easily available as the 32-bit ones and don't cost more (i.e. nothing). After reading this paragraph I wonder if I may trust the rest of your post, hence my disappointment. Could you put aside the fact that WCG has dared to develop a customized version of BOINC without your approval and come back to providing factual information on BOINC and 64-bit applications. Thanks in advance for trying to clarify this topic which interests so many of us. Jean. ** if one ignores your surprising "Now, these numbers can't be directly compared to WCG, since would expect the majority runs v6.2.28, and therefore can't run 64-bit before upgrading clients." First your chart is about 64-bit capable computers, and next, why would 6.2.28 not be able to run in a 64-bit OS? |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges:
|
Ingleside, Your post is very disappointing. It starts with very interesting general considerations** on the possible benefit of providing 64-bit applications which could explain why WCG is not providing some yet. Next your last paragraph (starting with "BTW, due to WCG only delivering 32-bit BOINC-client") is a total confusion. It implies that - WCG's 6.2.28 client cannot run in a 64-bit Windows, although other 32-bit applications can No, there's no problem running 32-bit BOINC on a 64-bit OS. - a 64-bit science application would not be able to communicate with a 32-bit client. Maybe it is true but I have never read anything (positive or negative) on that matter. I tend to think that as long as they respect the communication protocol there should be no problem This is the problem, or more exactly, for windows: 32-bit ** BOINC-clients reports the <platform_name> as "windows_intelx86", and therefore will only be assigned "windows_intelx86"-applications. 64-bit BOINC-clients reports the <platform_name> as "windows_x86_64", and <alt_platform> as "windows_intelx86", and can therefore be assigned both "windows_x86_64" and "windows_intelx86"-applications. Since v6.2.28 won't download a 64-bit application, it won't use it either. Note, if you manually installs a 64-bit application yourself, you can also use it while running 32-bit BOINC-client. (switching from 64-bit client to 32-bit and back to 64-bit on the other hand can lead to problems...) Could you put aside the fact that WCG has dared to develop a customized version of BOINC without your approval and come back to providing factual information on BOINC and 64-bit applications. Thanks in advance for trying to clarify this topic which interests so many of us. Using a customized version has nothing to do with it, but was just trying to point-out there won't be any 64-bit application in beta-testing before they've released a 64-bit BOINC-client beforehand. So, with the expected new WCG client-release early next year, if there aren't a 64-bit client during beta, atleast my interpretation would be it's very doubtful there will be any 64-bit applications released for the currently running WCG-projects... Unfortunately, the opposite wouldn't neccessary be true, even if they do release a 64-bit client, it's not certain they'll see there is a benefit of releasing any 64-bit application. ** There was something about sending x86_64 as alt_platform for 32-bit clients if runs on a 64-bit-OS, but if this was implemented or not I don't know. In any case, it's not present in v6.2.28. "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." [Edit 1 times, last edit by Ingleside at Dec 5, 2009 10:14:23 PM] |
||
|
|
JmBoullier
Former Community Advisor Normandy - France Joined: Jan 26, 2007 Post Count: 3716 Status: Offline Project Badges:
|
Thank you for this info.
----------------------------------------OK, it is mandatory for BOINC design reasons to have a 64-bit client to receive 64-bit applications from the server. But then I don't see why you are focusing on this 6.2.28 version. First you know that it will be replaced in the coming weeks, i.e. before WCG decides to offer 64-bit applications. And even if a 64-bit version of the new WCG version is not offered from the beginning do you seriously think it would be a problem for the techs to release one if/when they decide to offer 64-bit applications? Since they will already have a clean source to recompile that would probably be the least of their problems. In fact, for the reasons you mention, I could understand that they do not want to offer a 64-bit client before they need it in WCG, I mean to not let members think that 64-bit applications are imminent if it is not the case. Thanks again for having clarified this topic. Jean. |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges:
|
Thank you for this info. OK, it is mandatory for BOINC design reasons to have a 64-bit client to receive 64-bit applications from the server. But then I don't see why you are focusing on this 6.2.28 version. First you know that it will be replaced in the coming weeks, i.e. before WCG decides to offer 64-bit applications. And even if a 64-bit version of the new WCG version is not offered from the beginning do you seriously think it would be a problem for the techs to release one if/when they decide to offer 64-bit applications? Since they will already have a clean source to recompile that would probably be the least of their problems. It's no problem for WCG, since it's not WCG that builds and releases BOINC-clients. But, you're forgetting one thing, the uptake of new client-releases is often slow. While you do have some users that immediately upgrades, and even a few that normally runs the latest development-build, the majority of users is much slower to upgrade. As the numbers shows, even it's now over 1 month since the release of v6.10.xx, it's still only responsible for 40% of production. Since v6.4.5 was released in December 2008, roughly 25% of production is from users that haven't upgraded the last year, even there's been multiple new client-releases. I wouldn't expect WCG-upgrading to new client will be much faster than this... Releasing a 64-bit BOINC-client in connection with beta-testing a 64-bit application will be enough to beta-test the application, but if the beta-testing doesn't go really bad, chances are it will take many months before even 50% of the users running 64-bit OS has switched to a 64-bit client. Hmm, you can think of it like something like: If 64-bit application gives 30% higher production that 32-bit on 64-bit OS: Today, WCG doesn't have a 64-bit client. 1/3 runs 64-bit OS, let's say 5% of these runs 64-bit client: Benefit for WCG: 0.5% increase in production. Release 64-bit OS: ** 10% runs 64-bit client: Benefit for WCG: 1%. 1 month: 25% runs 64-bit client: Benefit for WCG: 2.5% 3 months: 50% runs 64-bit client: Benefit for WCG: 5% 1 year: 75% runs 64-bit client: Benefit for WCG: 7.5% By releasing the 64-bit client at same time as upgraded 32-bit, WCG will have a head-start if they ever releases a 64-bit application, so instead of starting at 0.5%, they'll go directly to 5% and maybe even higher. In fact, for the reasons you mention, I could understand that they do not want to offer a 64-bit client before they need it in WCG, I mean to not let members think that 64-bit applications are imminent if it is not the case. If they later decides to release a 64-bit application, already having users running 64-bit clients is only an advantage. Also, while very few cross-project users runs the WCG-version, there is the ocassional one, and the lack of 64-bit can be a problem for these. ** For all the numbers I've expected 1 of 3 runs 64-bit OS, and has made a more or less rough estimate how many of these has upgraded to a 64-bit BOINC-client (the % 64-bit-numbers). I've set the 1-month-numbers for WCG lower than SETI@home indicates, since would guess a larger fraction of seti-users runs 64-bit, and users with high-end CUDA-cards is more likely to have upgraded giving larger fraction of production for v6.10.xx-clients than is normal in other projects. Now, could of course start guessing, that if WCG did release a 64-bit-application being 30% faster, users would upgrade BOINC-client faster, and also that users would start switching from 32-bit to 64-bit OS. Even without a faster application, would expect majority of users upgrading to win7 would choose 64-bit, and majority of new computers will be 64-bit, so after 1 year the benefit would maybe be 20% or something... BTW, the switching OS is interesting... Taking a quick look on WCG's numbers, of the top-100 cpu's by RAC, if not mistaken all the listed amd's and intel-core2 and later is 64-bit-cpu's, meaning only the p4 and similar is 32-bit-only. This again means, of the top-100, only 12.2% of production is from non-64-bit-cpu's. The top-100 is responsible for 81.85% of current production, so even with the very unlikely worse-case-scenario, 72% of the production comes from cpu's that is 64-bit-capable. So, would guess roughly 80% of WCG-production is from 64-bit-cpu's. That roughly only 25% of the production comes from computers running 64-bit OS is therefore disappointing, but does show there is large rooms of improvements if it's possible to get users switching to 64-bit OS. "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." [Edit 1 times, last edit by Ingleside at Dec 6, 2009 2:34:50 PM] |
||
|
|
Rickjb
Veteran Cruncher Australia Joined: Sep 17, 2006 Post Count: 666 Status: Offline Project Badges: 
|
I've followed this thread with interest, and offer the following, in no particular order:
* If you are running WCG under a 64-bit O/S with a 64-bit BOINC client, don't compare its speed with that of a 32-bit O/S, based on credits claimed or awarded. As pointed out above, the integer benchmarks from 64-bit BOINC clients are much higher than those from 32-bit clients on the same machine & O/S. BOINC clients claim credit based on the CPU benchmarks, and the 64-bit client would claim more credits even if the WU runtimes were the same. In turn, credits claimed is one of the factors used to determine credits awarded. Using a 64-bit client at this point in time just causes inflation in the credits system. (I have 1 machine running XP-64, but I'm running 32-bit BOINC 6.2.19 as I think 64-bit BOINC is cheating). If you want to compare a 64-bit O/S to a 32-bit O/S, you have to compare WU throughput. * Using your favourite search engine to find "64-bit vs 32-bit", etc, can turn up more info on the pros and cons of each. Some factors working against 64-bit: - The 64-bit code is much bulkier than 32-bit code. System-wide, it takes up more disk space. It takes longer to load programs into memory. - 64-bit compilers usually align objects on 64-bit boundaries instead of 32-bit ones. Data, as well as code, take up more memory. The increased code and data memory requirements can counteract performance improvements: - they gobble up the CPU cache memory. Machines with limited cache will be most affected, eg notebooks, AMDs, Celerons, low-end CPUs. - they require more memory bandwidth. Again the low-end CPUs can suffer, but quad-core LGA775 CPUs may not be exempt either. As Ingleside suggests, the relative performance of a 64-bit program vs a 32-bit one will depend on the CPU type, the instruction mix in the program, the compilers used, etc. * It may be possible for some keen person to get some idea of the benefit or otherwise of going to 64-bit AutoDock (currently used in FAAH and HFCC, was used in DDDT Phase 1 and Flu). The source code of AutoDock is in the public domain, available under the GPL from the link at http://autodock.scripps.edu/. However, getting data for testing it may be a problem, since the WCG WUs use "grid-enabled" files that will be incompatible. There may be sample input data in the tutorials ( http://autodock.scripps.edu/faqs-help/tutoria...ck4-for-virtual-screening ) Otherwise you might be able to borrow some data from other AutoDock users - try the AutoDock forum (link on above page). Someone out there may already have compiled a 64-bit version, too. If you do get some sample test data going, it may still be difficult to emulate the memory footprint & hence cache effectiveness of the actual WCG projects. * As usual, I'm sure the WCG techs are working on things more urgent than 64-bit science apps, eg fixing the bugs that we encountered in the DDDT Phase 2 beta. And they may not wish to increase the number of project strands that they and the WCG server system have to deal with. - HTH |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I have compared work of 32 and 64 bit machines, with Boinc 32 bit and 64 bits installed on each machine. The actual application crunching results is unfortunately still 32 bits only.
The result: The 64 bit machine did 8% more Work Units than the 32 bit. Here are daily work units performed per each machine: 64bit: 18 15 16 17 32 07 38 12 Total:137 32bit: 15 15 15 15 25 16 28 14 Total:128 Difference 8.3% So after trying this I am sure that 64 bit machines do more work than if they would have 32 bit OS installed. Now we have to do similar comparison compiling application in 64 bit, this would be so much interesting to see. I am trying to compile autodoc 4.2, in 64 bit, if anybody did that already please contact me. Test machine: Two equal machines, one Vista 32 bits, other Vista 64 bit, Intel i7-920 processor at 2,66 Ghz. |
||
|
|
|