My AMD64 systems attached to this project keep getting the AMD64 application from the beta project, but failing the download, e.g. this system.
____________
/ 
There are no 64bit applications on the stable yet, only in beta.
I accidently added the 64bit app earlier when I thought I added them to beta,
but quickly removed it. Please stop any pure 64bit boinc core clients
from attaching to the stable yet, because it might generate client errors.
Your help is very much wanted though in the beta for testing the 64bit.
/ 
There is one 64bit comp from beta project. Results are very fast :-)
/ where can I get the 64Bit core client for abc@home beta? can you give me a direct link?
/ where can I get the 64Bit core client for abc@home beta? can you give me a direct link?
You must have 64bit boinc client and then will be 64b core client for abc@home beta downloaded automatically (you must be attached to beta project ofcourse).
You can download 64b boinc client from there:
http://www.lb.shuttle.de/apastron/boincDown.shtml#down
/ where can I get the 64Bit core client for abc@home beta? can you give me a direct link?
See this post.
HTH
____________
/ Please don't use the 64bit from beta on the stable, it's not without
a reason that it is still in beta, because it needs to be tested.
Suppose it contains bugs or does not work properly and generates a lot
of error results, this would hurt the project and other participants.
It will come into stable soon enough.
/ The new x86-64 Linux client, version 5.8.11, can be found at boinc_5.8.11_x86_64-pc-linux-gnu.gz. Again, the x64 Windows client, version 5.4.11, by Crunch3r, at boinc_5.4.11_windows_amd64.zip.
For more information, see BoincStats Forum.
HTH
____________
/ The new x86-64 Linux client, version 5.8.11, can be found at boinc_5.8.11_x86_64-pc-linux-gnu.gz. Again, the x64 Windows client, version 5.4.11, by Crunch3r, at boinc_5.4.11_windows_amd64.zip.
As WCG uses HTTPS in the communications with the client, a file with public encryption keys is needed. Download this new x86-64 Linux client, still version 5.8.11, boinc_5.8.11_x86_64-pc-linux-gnu.tgz and copy all the files in the tar-ball to your system's working BOINC directory.
For more information, see BoincStats Forum.
HTH
____________
/ 
The new x86-64 Linux client, version 5.8.11, can be found at boinc_5.8.11_x86_64-pc-linux-gnu.gz. Again, the x64 Windows client, version 5.4.11, by Crunch3r, at boinc_5.4.11_windows_amd64.zip.
As WCG uses HTTPS in the communications with the client, a file with public encryption keys is needed. Download this new x86-64 Linux client, still version 5.8.11, boinc_5.8.11_x86_64-pc-linux-gnu.tgz and copy all the files in the tar-ball to your system's working BOINC directory.
For more information, see BoincStats Forum.
HTH
FWIW,
New Windows_AMD64 client, version 5.8.11 can be found here boinc_5.8.11_windows_amd64.zip
/ I have a question. Now I am running the 64Bit abc@home client. But it's not three time as fast as I suspected. When I'm running it I have the following benchmark values for my AMD64 4800+:
Measured floating point speed 2164.84 million ops/sec
Measured integer speed 6533.21 million ops/sec
When I'm running the normal 32Bit Windows client, I have these values:
Measured floating point speed 2304.54 million ops/sec
Measured integer speed 4005.93 million ops/sec
Here is a comparision between two WUs which needed nealy the same time on the different platforms:
System CPU time (sec) claimed credit granted credit
64Bit linux(ubuntu) 10,859.82 54.66 102.67
32Bit Windows XP 11,198.55 40.90 66.14
In my opinion I have to had three times the credits for nearly the same crunching time. But it's not doubled at all.
I'm using the following boinc- and project client: 'boinc_5.8.11_i686-pc-linux-gnu' and 'boinc_5.8.11_x86_64-pc-linux-gnu'
So what I'm doing wrong?
Greetings fufu.
/ I don't understand what the problem is, all I see is a healthy credit/hr increase(assuming the linux64 and win32 are the same machine). I guess you are expecting too much :) For comparison mine went from 27cr/hr/core(xp64 - 32bit client) to 46cr/hr/core(ubuntu64 Virtual Machine - 64bit client), NOT double the credits.
____________
Team Boinc@Australia.
/ 
I consider that quite an impressive increase in credits and makes me look closer at moving to 64bit for the machines i have that will handle it.
My only issue is i much prefer to use an official 64bit client but its a long time in coming :(
Please don't see this as another credit wars post its not . But an official Linux and windoze 64bit client would likely lead to less problems on the install and compatibility with other projects so i am a real fan of the idea of an official 64bit but may try Augustine's client once i can afford to take a machine offline and have the time to go through a 64bit install.
____________
/ I have a question. Now I am running the 64Bit abc@home client. But it's not three time as fast as I suspected. When I'm running it I have the following benchmark values for my AMD64 4800+:
Measured floating point speed 2164.84 million ops/sec
Measured integer speed 6533.21 million ops/sec
When I'm running the normal 32Bit Windows client, I have these values:
Measured floating point speed 2304.54 million ops/sec
Measured integer speed 4005.93 million ops/sec
Here is a comparision between two WUs which needed nealy the same time on the different platforms:
System CPU time (sec) claimed credit granted credit
64Bit linux(ubuntu) 10,859.82 54.66 102.67
32Bit Windows XP 11,198.55 40.90 66.14
In my opinion I have to had three times the credits for nearly the same crunching time. But it's not doubled at all.
I'm using the following boinc- and project client: 'boinc_5.8.11_i686-pc-linux-gnu' and 'boinc_5.8.11_x86_64-pc-linux-gnu'
So what I'm doing wrong?
Greetings fufu.
Only look at the granted credits. In your case it's about doubled.
There might be a difference between win and linux, or how you run linux or
windows. Maybe 3x is too much and it's more like 2x.
/ Ok, I believe I expected to much. But I had this comparision between an AMD64 3500+ and an Intel Core2Duo in mind. So I thought my system is probably not running as fast as it could.
Thanks for the fast responses.
Greetings. fufu
/ Maybe 3x is too much and it's more like 2x.
It's not easy to say because I don't have enough data but it seems like it's more than 2X on long WUs and less than 2X on short WUs. There seems to be too many short WUs. Can you make the WUs a little longer? Maybe wait until we are out of the range where we sometimes get the extremely long ones? Or send extremely long ones to me or other people who don't care how long they are?
/ Actually i seem to be getting all long Wu's lol. Want to swap? Anyway ive taken my request for an official 64bit client to the BOINC message boards so i hope it draws some support there.
The way i have been updating my BOINC clients so far is just replacing the 3 bin files (boinc (called "boinc_client" in the Debian build), boincmgr and boinc_cmd) with the ones from the latest build from the boinc website. Can i do similar to upgrade from 32bit to 64bit once i have a 64bit OS installed? I kinda like the autostarting scripts and stuff on the debian repositories.
____________
/ Actually i seem to be getting all long Wu's lol. Want to swap? Anyway ive taken my request for an official 64bit client to the BOINC message boards so i hope it draws some support there.
Don't hold your breath. Meanwhile, Augustine's 64-bit BOINC client for Linux works fine and has standard behavior... it does not alter benchmarks and does not return results immediately. Same appears to be true for Crunch3r's 64-bit BOINC. With those available I doubt Berkeley is going to put much effort into providing 64-bit versions any time soon.
The way i have been updating my BOINC clients so far is just replacing the 3 bin files (boinc (called "boinc_client" in the Debian build), boincmgr and boinc_cmd) with the ones from the latest build from the boinc website. Can i do similar to upgrade from 32bit to 64bit once i have a 64bit OS installed? I kinda like the autostarting scripts and stuff on the debian repositories.
Yes, that should work fine. Augustine and Crunch3r are both providing just the core, not the manager, because a 32-bit manager works OK with a 64-bit core. After decompressing/unarchiving, just rename their file to boinc_client on your Debian system. On other distros rename it to boinc. And put it in the BOINC directory too, as you probably already know, Clownius, but I thought I would add that for other possible newbies.
/ I don't understand what the problem is, all I see is a healthy credit/hr increase(assuming the linux64 and win32 are the same machine). I guess you are expecting too much :) For comparison mine went from 27cr/hr/core(xp64 - 32bit client) to 46cr/hr/core(ubuntu64 Virtual Machine - 64bit client), NOT double the credits.
Yes, I reach the same conclusion with my RAC, thanks to this script developped by Ivanlefou, great member of AF (he also developped the AA5 credit comparison page! ;) hehe
http://itrilium.dyndns.org/af_boinc/rac/get_pc_speed.php
It gets the data from the boinc statistic pages, based on :
- Project = ABC@home
- Computer ID = 6511 (example for mine, C2D T7200 2ghz under Linux Ubuntu6.10-amd64)
- Simultaneous threats (cores or HT) = 2
- WU to analyze = 100
- Offset = 40 (pending credit not to take into account/need to be a multiple of 20 as in stat pages)
Result => approx.RAC = 1536
Compared to the same computer (ID 4654) under winXP 32bits approx.RAC = 798
Almost doubled!! (+92.5%) **smile**
(but 5 hours to get linux working on it! doooh)
Great work Hendrik, Augustine & all contributors!
Happy crunching64 2u2 & cheers from Brussels. J.
/ I have a question. Now I am running the 64Bit abc@home client. But it's not three time as fast as I suspected. When I'm running it I have the following benchmark values for my AMD64 4800+:
Measured floating point speed 2164.84 million ops/sec
Measured integer speed 6533.21 million ops/sec
When I'm running the normal 32Bit Windows client, I have these values:
Measured floating point speed 2304.54 million ops/sec
Measured integer speed 4005.93 million ops/sec
Here is a comparision between two WUs which needed nealy the same time on the different platforms:
System CPU time (sec) claimed credit granted credit
64Bit linux(ubuntu) 10,859.82 54.66 102.67
32Bit Windows XP 11,198.55 40.90 66.14
In my opinion I have to had three times the credits for nearly the same crunching time. But it's not doubled at all.
You should compare apples to apples. In this case, you're comparing 64-bit Linux application built with GCC against 32-bit Windows application build with VS. When ABC ß started sending the 64-bit WUs, a system of mine cranked WUs about 2 to 3 times faster than the 32-bit WUs. At least in typical crunch times, as there may be variations in execution time from WU to WU.
ABC's application actually lends itself very well to 64 bits, because it uses 64-bit long data-types which are processed in one fell swoop by a 64-bit system, instead of breaking up the operations on such data-types into separate 32-bit steps, more than doubling the work for each piece of data.
But do not expect the same order of gain in the typical BOINC project, as most are heavily floating-point oriented, when the gains in a 64-bit application come from more registers and more efficient interfaces, netting gains between 0 to 15%, as this example illustrates.
HTH
____________
/ Rieselsieve also has great improvement apparently (maths / long data-types indeed)
http://boinc.rieselsieve.com/
"2007-02-17 02:04:58 UTC New Linux Sieve Version + PPC/Linux Support Added
It's been a busy, but exciting, night at RieselSieve. We finally have a new Linux/x86 version that correctly reports its timing & status to the BOINC client. It also implements sr2sieve, rather than proth_sieve, so users should see a HUGE speedup."
But I cannot create an account for the moment... Well that's another forum...
I just wonder if your x86_64 linux client 5.4.11 Augustine is also fine for this project? I think so, it must be a temporary server outage.
Thx for the explanations & details.
/ I just wonder if your x86_64 linux client 5.4.11 Augustine is also fine for this project? I think so, it must be a temporary server outage.
It's a straight compilation from the BOINC source repository, so it should work on all projects that support x86-64, including ABC and Riesel.
HTH
____________
/ If you wander by the BOINC@AUSTRALIA forums in the RS section there is a thread on problems RS is having with anything connecting at the moment. So its most likely the same issue as many people are having. The RS admin has set up a proxy you can connect through until a solution is found.
This is the thread to look at
http://xsorbit31.com/users5/boincaustralia/index.php?topic=1691.0
hope it helps
____________
/ Ok, well, also on another french forum I could read the RS x86-64 application may be 32bits and needs some Linus 32b-libraries?!...
So I won't attach to this project and stick to ABC for the time being.
It was only a security, in case there is an ABC WU outage : to have a 2nd project to calculate in the meantime, but with a lower priority in "normal" time.
(but these additional network problems doesn't encourage me further /unstable project for the moment!?)
Also Seti 32b optimized clients by processor (SSE2 / SSSE3) really rock!! +80% performance :)
http://lunatics.at/index.php?PHPSESSID=43832b8e0f1fe5ece6e103b79bb8a499&topic=182.msg2437;topicseen#msg2437
...only when I'm under windowsXP32 and not ubuntu64 ! ;)
Thanks, bye.
/ The project isn't actually at fault this time the data gets lost on the way as can be found out by pinging and or tracing the path. It always stops at the same Level 3 internet server. first Australia went out and then it started spreading. Annoying when the internet fails lol. Id hate to try and run a project myself. So much can go wrong.
____________
/ Correction: the x86-64 Linux client, version 5.8.11, can be downloaded from boinc_5.8.11_x86_64-pc-linux-gnu.tgz (make sure to copy both files to the BOINC working directory). The new x64 Windows client, version 5.8.11, by Crunch3r, can be found at boinc_5.8.11_windows_amd64.zip.
For more information, see BoincStats Forum.
HTH
____________
/ All i can say is wow. Machines that used to make me look bad. Tim and his semperons walked all over me before but now look like slugs. This 64bit app rocks on a C2D. A huge speed improvement. I want 64bit apps for all projects now. i know some projects do better than others but if just one other speeds up like this its worth the effort.
____________
/ Yes, Clownius, the speed is amazing. The only other project that can get similar speed improvements just by going 64-bit is the Chess 960 project. They went 64-bit a while ago. The remaining projects will not see a 2X to 3X speed increase from 64-bit because their computations are mainly floating point operations rather than intger operations. Nevertheless, one such project, SIMAP, got a 15% boost from 64-bit in spite of predominantly floating point operations.
While 15% of the time it takes to crunch 1 WU is only a small amount, we must remember that 15% multiplied by many thousands of WUs at 1 project is a huge amount. I am convinced that if more projects embraced 64-bit and allowed people like Augustine and Crunch3r to show them how to benefit from 64-bit, the DC community could take a huge leap forward. It seems the only things standing in the way are apathy and ignorance.
Predictor also has a 64-bit app for Linux. Unfortunately their validator and scheduler seem to be acting up a bit and it's hard to compare results to see what kind of speed advantage they're getting from 64-bit. They've got a few other problems that need ironing out too but it might just be your cup of tea.
/
I am convinced that if more projects embraced 64-bit and allowed people like Augustine and Crunch3r to show them how to benefit from 64-bit, the DC community could take a huge leap forward. It seems the only things standing in the way are apathy and ignorance.
Well... there's a german saying "Du hast den Nagel auf den Kopf getroffen." don't know the proper translation but i think it's "You nailed it."
It's not only the 64 bit thing there are several examples like cpu affinity wich i hope will find it's way into boinc sources by 5.10.x at least Rom Walton considered it to check it in and that's the last thing i heard of him (He has the source).
/ boinc client crash:
Linux (64-bit Ubuntu 6.10). 32-bit boinc client 5.8.15. Currently 32-bit ABC application 1.02.
When workunit http://abcathome.com/result.php?resultid=1345765 finishes, the boinc client goes into a 100% CPU loop. Must use kill -9 to get rid of it. Was not able to get any kind of trace or dump.
Manually aborted the workunit, to get it out of my system. Several other (shorter) ABC workunits ran correctly.
[However, for my next download I plan to replace the 32-bit ABC a[[lication with the 64-bit ABC application - that's why I'm trying ABC - to get experience with 64-bit applications.]
.
/ @Mikus
Yer gonna luv 64-bit! BTW, if you install the 64-bit BOINC from the Debian package you might run into problems similar to what Richard reported in this thread. If so then it looks like the cure is to install Augustine's client.
@Crunch3r
Glad to hear you're lobbying for CPU affinity. I will lobby too.
I must confess I did not understand affinity until just a few minutes ago. Reading this article has helped. Yes, CPU affinity is definitely something every owner of a dual-core processor would want. The time wasted by cache invalidation when affinity is not implemented is an issue that deserves immediate attention.
The article points out that CPU affinity has been available on Win NT for some time and has been implemented in Linux more recently. Is it also available on all versions of XP and Vista too? What about Mac?
/ I must confess I did not understand affinity until just a few minutes ago. Reading this article has helped. Yes, CPU affinity is definitely something every owner of a dual-core processor would want. The time wasted by cache invalidation when affinity is not implemented is an issue that deserves immediate attention.
And it did get attention in 2005. As of the kernel version 2.16.12 the scheduler introduced the concept of a home processor resulting in a process striving to remain running on the same processor throughout its life. All current Linux distributions use a kernel at least as old, when micro-managing the scheduler through manually setting CPU affinity is not only unnecessary, but counter-productive.
In Windows it's another story indeed. Processes can hop unpredictably between processors even without any event causing it, just randomness in the scheduler. It's been a problem even up to Windows 2003. I sure hope that things are different with Vista, but I cannot verify it.
HTH
____________
/ Aha! OK, I see now the article I "learned" from is dated 2003 and things have improved since then in the Linux world, improved to the point where manual settings are not only unnecessary but counter-productive. So scratch that article's advice regarding manual affinity settings.
Now I wonder... Are there "non-manual" affinity tweaks that could be implemented in BOINC on Linux to increase crunching efficiency? Or is it all taken care of adequately by the OS?
/ It could still use some tweaking. Say forcing a project to only use 1 core. Some projects run better side by side with another project rather than together with another of the same app.
____________
/ An updated x86-64 Linux client, version 5.8.15, can be downloaded from boinc_5.8.15_x86_64-pc-linux-gnu.tgz (make sure to read the file "README.x86_64-pc-linux-gnu" in it).
Crunch3r's x64 Windows client, version 5.8.11, can be found at boinc_5.8.11_windows_amd64.zip.
For more information, see BoincStats Forum.
HTH
____________
/
In Windows it's another story indeed. Processes can hop unpredictably between processors even without any event causing it, just randomness in the scheduler. It's been a problem even up to Windows 2003. I sure hope that things are different with Vista, but I cannot verify it.
For what it's worth, I've been sending my comparisons of Linux and Windows benchmarks for BOINC 5.8.15 on the same dual core machine to BOINC Alpha and I finally got this reply from David:
"The inconsistency seems to happen only on Windows,
so it must be something with thread scheduling in Windows.
It's a shot in the dark,
but I checked in a change to use "processor affinity"
(so that benchmark thread N runs only on CPU N).
This will appear in the next release."
So in the least, your benchmark should be correct on dual core machines on the next Windows release.
- John Watzke
/ Now I wonder... Are there "non-manual" affinity tweaks that could be implemented in BOINC on Linux to increase crunching efficiency? Or is it all taken care of adequately by the OS?
IMHO, the kernel should manage resources and processes in a way as to optimize performance without the developer having to worry whether a program will run on a shared-bus or on a NUMA system, on a multi-core or on a multi-processor system, etc.
I'm confident that the Linux kernel is now doing a lot right by itself. For instance, part of the work in 2005 was to also allocate memory on the local processor (important for Opteron and Athlon64 systems, as they use distributed memory, AKA NUMA) if possible. Not that it's doing everything right, especially under heavy load, with regards to process migration.
Part of this problem was addressed in the 2.6.15 (or 2.6.16?) kernel, considering the topology of NUMA systems if it has to migrate a process or to allocate memory. In this regard, it now mimics what Solaris has been doing for a few years (see "Performance" in http://blogs.sun.com/dp/date/20050301).
Again, I wish that Windows would do the same in Vista... As a matter of fact, I would advise Crunch3r to test if processes still hop often among processors in Vista and, if not, to not try to set CPU affinity when running on Vista. But, if Vista is still like XP and 2003, setting the CPU affinity is a must.
HTH
____________
/ I thought that others might want to know about this interesting experiment about CPU affinity on Solaris, http://www.ssl.berkeley.edu/pipermail/boinc_dev/2007-March/007519.html, confirming with hard data my assessment that it's counter-productive to micro-manage the scheduler when it already does the right thing (i.e., Solaris and Linux for sure).
HTH
____________
/ Yeah Linux is quite good at handling itself :)
____________
/ 
Can someone please give an overview of which projects distribute (true) 64-bit client apps, both for Windows and Linux. I have seen the list somewhere before, but I can't remember where. Blame it on age :p
TIA
____________
BOINC.BE: For Belgians who love the smell of glowing red cpu's in the morning
Tutta55's Lair
/ Can someone please give an overview of which projects distribute (true) 64-bit client apps, both for Windows and Linux. I have seen the list somewhere before, but I can't remember where. Blame it on age :p
I keep a list at the BoincStats Forum.
HTH
____________
/ Can someone please give an overview of which projects distribute (true) 64-bit client apps, both for Windows and Linux. I have seen the list somewhere before, but I can't remember where. Blame it on age :p
I keep a list at the BoincStats Forum.
HTH
Thanks, Augustine. Oh dear, I didn't realize it was that bad. No 64-bit Windows client at all in any production version. Pfft, did I install 64-bit Vista for that. :p So ABC may still be the first.
Since today I'm back in ABC, running the 64-bit Linux app. It gives me a 60% higher output than the 32-bit Windows app.
____________
BOINC.BE: For Belgians who love the smell of glowing red cpu's in the morning
Tutta55's Lair
/ Here's the new recommended version for the x86-64 Linux client:
- Untar the file boinc_5.8.17_x86_64-pc-linux-gnu.tgz at the BOINC working directory.
- Read the file "README.x86_64-pc-linux-gnu".
Again, Crunch3r's x64 Windows client can be found at boinc_5.8.11_windows_amd64.zip.
For more information, see BoincStats Forum.
HTH
____________
/ Here's the new recommended version for the x86-64 Linux client:
- Untar the file boinc_5.8.17_x86_64-pc-linux-gnu.tgz at the BOINC working directory.
- Read the file "README.x86_64-pc-linux-gnu".
Crunch3r's x64 Windows client can be found at boinc_5.8.16_windows_amd64.zip.
For more information, see BoincStats Forum.
HTH
;)
____________
regards
Crunch3r
/ 
Well, Rom put out an Alpha version of the first 64b windows Boinc client. boinc_5.9.4_windows_x86_64.msi. Remember this is an ALPHA build and several install and operational bugs have already been reported.
To compare Benchmarks with Crunch3r's 5.8.11.64 windows_amd64 I ran them on my AMD64 X2 5200. Remember that in 64b windows there are two programfiles that being "programfiles" (64b apps), and "programfiles (X86)(32b em).
5.9.4 x86-64 (the official one) installed to "programfiles".
2532/4494
2538/4499
2537/4495
2536/4497
2536/4492
2536/4495
2539/4495
2535/4492
2538/4497
2537/4494
I then uninstalled and reinstalled the official 5.8.16 to the "programfiles (X86)" and overwrote it with Crunch3r's 5.9.0.64 and got:
5.9.0.64 x86-64 (running under "program files (x86)" not 64b "program files" like the official one)
2637/6770
2637/6774
2639/6774
2637/6772
2640/6771
I then uninstalled again, reinstalled 5.8.16 in "programfiles (X86)", and overwrote it with Crunch3r's 5.8.11.64 windows amd64 and got:
5.8.11.64 windows_amd64 (running under "program files (x86)" not 64b "program files" like the official one)
2547/6588
2545/6724
2546/6732
2547/6719
2546/6700
And although there weren't instructions for this, I tried it anyway. I uninstalled again, this time I installed 5.9.4 X86-64 to "programfiles", I then overwrote it with Crunch3r's 5.8.11.64 windows amd64 and got:
2552/4428
2541/4386
2539/4375
2541/4245
2548/4215
Notice that when Crunch3r's versions are installed over the 32b boinc in "programfiles (86)", the Whetstone is pretty much unchanged and the Dhrystone is 50% higher than 5.9.4 X86-64, but when 5.8.11.64 windows_amd64 is installed over 5.9.4 X86-64 in "programfiles" that the Boinc original and Crunch3r's bencharks are nearly identical across the board.
interesting.
/ Well, Rom put out an Alpha version of the first 64b windows Boinc client. boinc_5.9.4_windows_x86_64.msi. ..
To compare Benchmarks with Crunch3r's 5.8.11.64 windows_amd64 I ran them on my AMD64 X2 5200. Remember that in 64b windows there are two programfiles that being "programfiles" (64b apps), and "programfiles (X86)(32b em)...
Notice that when Crunch3r's versions are installed over the 32b boinc in "programfiles (86)", the Whetstone is pretty much unchanged and the Dhrystone is 50% higher than 5.9.4 X86-64, but when 5.8.11.64 windows_amd64 is installed over 5.9.4 X86-64 in "programfiles" that the Boinc original and Crunch3r's bencharks are nearly identical across the board.
This is quite puzzling indeed.
However, I did chastise the BOINC developers for adopting a platform string (windows_x86_64) that's not compatible with the one being used by ABC, Docking, HashClash and SIMAP (windows_amd64).
It would be nice if the ABC developers would file a complaint with them and see if they can revert this haphazard decision. I brought this up in the boinc_dev mailing list, but the archives were expunged. But there's a new thread here going on.
____________
/ on the brighterside, the "dual core benchmark bug" doesn't seem to exist in ANY 64b windows version of Boinc, but still does in 5.9.4 X86(32b) version.
/ on the brighterside, the "dual core benchmark bug" doesn't seem to exist in ANY 64b windows version of Boinc, but still does in 5.9.4 X86(32b) version.
I'm not aware of it. What's it?
Thanks.
____________
/ on the brighterside, the "dual core benchmark bug" doesn't seem to exist in ANY 64b windows version of Boinc, but still does in 5.9.4 X86(32b) version.
I'm not aware of it. What's it?
Thanks.
The dual core benchmark bug seem to affect dual cores (X2's and Core2duo). The Whetstone will remain constant, but the Dhrystone will vary between runs of the benchmark. For example I ran these last nite on the same machine as the earlier posted 64b data:
5.8.16 x86
2678/3265
2677/3358
2679/4474
2678/2491
5.9.3 x86
2682/4931
2683/3382
2687/3436
2686/3382
5.9.4 x86
2307/3371
2305/3326
2306/4877
2305/3514
The dhrystone seems to be either 1/2, 3/4, or full value.
I ran most Boinc versions starting with 4.05 forward and it existed in all of them. This meant that from the time the first dual core came out, that it's benchmarks were all over the map. I reported it several moons ago. They made up a debug tool to add to the cc_config.xml file to try and track it, but as of yet haven't squashed this bug. (note: I ran these test on multiple machines, and other report it as well)
tony
NOTE: on the 5.9.4 above the Whetstone is 86% of the value reported by multiple boinc versions and has been reported. I believe it's a separate issue.
/ Here's a development version of the x86-64 Linux client:
- Untar the file boinc_5.10.10_x86_64-pc-linux-gnu.tgz at the BOINC working directory.
- Read the file "README.x86_64-pc-linux-gnu".
The official client for x64 Windows client can be found at boinc_5.10.13_windows_x86_64.exe.
The BOINC client 5.10 can now get 32-bit applications from projects that haven't added support for AMD64 (e.g., Lattice, QMC, etc), provided that they run at least the BOINC server 5.0.9. However, such AMD64 clients for Windows may not get applications from some projects that supported AMD64 before due to a platform name change, at least until such projects are updated.
For more information, see the BoincStats Forum.
HTH
____________
/ Even though there's an official AMD64 client for Linux, it refers to too many dynamic libraries and requires a fairly recent Linux setup to run on.
So, one more time, I'm making available the AMD64 Linux client here. It refers to a minimal set of standard dynamic libraries whose version requirements should be satisfied by Linux systems up to 2 or 3 years old, however it was built with a fairly recent version of GCC, 4.1.2.
The drill's still the same:
- Untar the file "boinc_5.10.30_x86_64-pc-linux-gnu.tgz" at an existing BOINC working directory.
- Read the file "README.x86_64-pc-linux-gnu".
The official AMD64 Windows client can be found here.
For more information, see the BoincStats Forum.
HTH
____________
/