AMD64

So far, three projects have added support for AMD64: SETI sends the x86 application and SIMAP and Chess960, native x86-64 applications. Would you consider supporting windows_amd64 and x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu similarly? If so, how can I help?

____________

Later, when we get the project on its feet and running smoothly for sure. We already have the compilers :-) The app (charmm) is not ready for this though, but the charmm team is working on a new version that supports x86_64. (at least on linux)

Andre

So far, three projects have added support for AMD64: SETI sends the x86 application and SIMAP and Chess960, native x86-64 applications. Would you consider supporting windows_amd64 and x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu similarly? If so, how can I help?

So far, three projects have added support for AMD64: SETI sends the x86 application and SIMAP and Chess960, native x86-64 applications. Would you consider supporting windows_amd64 and x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu similarly?

So far, three projects have added support for AMD64: SETI sends the x86 application and SIMAP and Chess960, native x86-64 applications. Would you consider supporting windows_amd64 and x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu similarly?

HashClash now supports AMD64 with a 32-bit Linux application...

FWIW, running two instances of the client, one the 32-bit client, the other, the 64-bit client, on the same 4-core system, but limiting each client to 2 cores, I can compare the relative performance of 32-bit and 64-bit SIMAP's HMMER: the 64-bit version is about 7% faster.

By enabling vectorization (supported by default on AMD64), the SIMAP developers observed other 8% improvement.

Bottom line: porting the project application to AMD64 has the potential to improve performance by 15%!

____________

So far, three projects have added support for AMD64: SETI sends the x86 application and SIMAP and Chess960, native x86-64 applications. Would you consider supporting windows_amd64 and x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu similarly?

HashClash now supports AMD64 with a 32-bit Linux application...

HashClash now supports AMD64 on Windows with a 32-bit application...

So far, three projects have added support for AMD64: SETI sends the x86 application and SIMAP and Chess960, native x86-64 applications. Would you consider supporting windows_amd64 and x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu similarly?

HashClash now supports AMD64 with a 32-bit Linux application...

HashClash now supports AMD64 on Windows with a 32-bit application...

Guess what? Leiden Classical now supports AMD64 on Linux with a 32-bit application. ;-)

Until charmm is ported to x86-64, couldn't Docking send the x86 application to the clients which report windows_amd64 and x86_64-pc-linux-gnu/x86_64-unknown-linux-gnu?

Thanks.

Will 64 bit version charmm be available for Intel processors which have EM64T such as Presler and Conroe too?
Also, in general how much can 64 bit accelerate the computation of charmm? Only a little or greatly?

thanks,
suguruhirahara
____________

I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions.

Will 64 bit version charmm be available for Intel processors which have EM64T such as Presler and Conroe too?
Also, in general how much can 64 bit accelerate the computation of charmm? Only a little or greatly?

thanks,
suguruhirahara

For what I've heard and read on some forums it doesn't improve performance a lot but it is a little boost. EM64T is available in charmm 33b1.

For what I've heard and read on some forums it doesn't improve performance a lot but it is a little boost. EM64T is available in charmm 33b1.

Yes. 64 Bit gave not a great boost. It depends very strongly on the application and the CPU architecture. In my expirance about 5 to 10 %, sometimes up to 15 %.

But it could also be, that the 64 bit application is slower than the 32 bit application.

FWIW, I am a tad surprised that many consider 5 to 10% a tiny performance improvement. I'd say that it's a significant improvement, especially for a mature application such as Charmm.

To put numbers in perspective, a 3% performance improvement is typically considered equivalent to a processor speed-grade upgrade, as in buying the next more expensive processor.

For example, if the 64-bit Charmm performs 10% better than the 32-bit application, it's as though all the clients capable of 64 bits had been upgraded to a processor costing perhaps twice as much. ;-)

____________

FWIW, I am a tad surprised that many consider 5 to 10% a tiny performance improvement. I'd say that it's a significant improvement, especially for a mature application such as Charmm.

To put numbers in perspective, a 3% performance improvement is typically considered equivalent to a processor speed-grade upgrade, as in buying the next more expensive processor.

For example, if the 64-bit Charmm performs 10% better than the 32-bit application, it's as though all the clients capable of 64 bits had been upgraded to a processor costing perhaps twice as much. ;-)

A bit off-topic;

Just out of my curiosity.
Which combination is the best among these?

1. x86-64 CPU, x64 OS, and x86 charmm

2. x86-64 CPU, x64 OS, and x64 charmm

3. x64 CPU, x64 OS, and x64 charmm

If there is any difference in performance whether it'll be only a little or huge, how will it be from a view of characteristics of charmm's computation?

thanks,
suguruhirahara

Which combination is the best among these?

1. x86-64 CPU, x64 OS, and x86 charmm

2. x86-64 CPU, x64 OS, and x64 charmm

3. x64 CPU, x64 OS, and x64 charmm

If there is any difference in performance whether it'll be only a little or huge, how will it be from a view of characteristics of charmm's computation?

Talked to the Charmm people recently and they say that there won't be much difference in execution time. 64 bits will help the precision of the calculation though.

AK

Which combination is the best among these?

1. x86-64 CPU, x64 OS, and x86 charmm

2. x86-64 CPU, x64 OS, and x64 charmm

3. x64 CPU, x64 OS, and x64 charmm

If there is any difference in performance whether it'll be only a little or huge, how will it be from a view of characteristics of charmm's computation?

Aren't (2) and (3) the same?

But in order to answer your question, it would be necessary to know the computation phases of Charmm better, whether it spends a lot of time in math functions or doing a lot of its own floating-point computations. In general, and this depends on the application, x86-64 floating-point programs perform significantly better than x86.

HTH

abc@home beta now has a 64 bit application, and are getting 2x-3x speed increase.

Help me understand something. It thought that a 32 bit application will run on 64 bit BOINC clients as-is. It just requires the server to be set up to recognize the 64 bit client, and send instead the 32 bit version. Do I have this right?

If so, couldn't D@H do this with very little time or effort? Maybe I misunderstand.
____________
Dublin, CA
Team SETI.USA

Our 32-bit app runs fine on 64-bit clients, so I am not sure what you are getting at. The current version of charmm does not support 64-bit compiles, but the new version will, so we will definitely look into that later (if the new version will ever be released that is, because it is taking much longer than we ever expected). Also, charmm is a static built on linux and windows, thus we are not using any of the client side libraries.

Thanks
Andre

abc@home beta now has a 64 bit application, and are getting 2x-3x speed increase.

Help me understand something. It thought that a 32 bit application will run on 64 bit BOINC clients as-is. It just requires the server to be set up to recognize the 64 bit client, and send instead the 32 bit version. Do I have this right?

If so, couldn't D@H do this with very little time or effort? Maybe I misunderstand.

Andre,

I believe that what was meant by the post above was a suggestion to make a change in the server to send the x86 application when the BOINC core client identifies itself as x86-64.

Some projects which can afford porting their applications to 64 bits and see a benefit from it, provide a native x86-64 application to such clients (e.g., SIMAP, Chess960, ABC ß). But other projects, in order to support those volunteers running the 64-bit core client because they want to contribute to those projects which support x86-64 natively, just create a copy of the x86 application renaming it to contain the x86-64 moniker instead (e.g., SETI, HashClash, Leiden, Malaria).

HTH
____________

Thanks for the explanation. So if I understand correctly, 64-bit boinc clients do not get any work if we don't specifically create a 64-bit app (or create a copy of the 32-bit app)?

We'll have to look into this, because we haven't dealt with the x86-64 boinc client yet.

Andre,

I believe that what was meant by the post above was a suggestion to make a change in the server to send the x86 application when the BOINC core client identifies itself as x86-64.

Some projects which can afford porting their applications to 64 bits and see a benefit from it, provide a native x86-64 application to such clients (e.g., SIMAP, Chess960, ABC ß). But other projects, in order to support those volunteers running the 64-bit core client because they want to contribute to those projects which support x86-64 natively, just create a copy of the x86 application renaming it to contain the x86-64 moniker instead (e.g., SETI, HashClash, Leiden, Malaria).

HTH

Thanks for the explanation. So if I understand correctly, 64-bit boinc clients do not get any work if we don't specifically create a 64-bit app (or create a copy of the 32-bit app)?

Thanks for the explanation. So if I understand correctly, 64-bit boinc clients do not get any work if we don't specifically create a 64-bit app (or create a copy of the 32-bit app)?

The other method is to use an BOINC client (64 bit in the platform string), download the application manualy, and use the app_info.xml. Also, this works vice versa for a 32 bit BOINC client and a 64 bit platform.

I'll test this on our test system tomorrow; sounds pretty easy to deploy; Since we use a static compile on windows and linux, the library versions on the client shouldn't matter (we'll find that out too).

Thx,
Andre

Thanks for the explanation. So if I understand correctly, 64-bit boinc clients do not get any work if we don't specifically create a 64-bit app (or create a copy of the 32-bit app)?

That's correct. My 4 Linux systems, totaling 10 cores, run the x86-64 CC, but haven't crunched any Docking WU yet, only my 2 Windows systems, totaling 2 cores, have. :-/

It would be mighty cool if Docking would at least send the 32-bit application to the 64-bit systems.

TIA

The other method is to use an BOINC client (64 bit in the platform string), download the application manualy, and use the app_info.xml. Also, this works vice versa for a 32 bit BOINC client and a 64 bit platform.

Personally, I find dealing with custom app_info.xml files a nuisance. I tried that for a while with Einstein and Rosetta, but it proved to be a pain because of the relatively high frequency of application updates.

Done. Please be aware this is an experiment; let's see how things turn out.

Andre

Thanks for the explanation. So if I understand correctly, 64-bit boinc clients do not get any work if we don't specifically create a 64-bit app (or create a copy of the 32-bit app)?

Yes. You could create a new platform for x86_64 on the BOINC server, and make a link on the filesystem from the 32 bit application to the name for the 64 bit one. - So far I know was there some detailed explanation at the mailinglists some time ago.
This recommends, that the users has installed the ia32 libs on there 64 bit systems.

Also, there users could use the standard BOINC client, which downloads the 32 bit application automaticly.

The other method is to use an BOINC client (64 bit in the platform string), download the application manualy, and use the app_info.xml. Also, this works vice versa for a 32 bit BOINC client and a 64 bit platform.

is the new x86_64 app for linux or windows?
____________

For now just linux. If that works out well, we do windows as well. The app is the same 32-bit; it just gives 64-bit boinc CC users a chance to crunch docking wu's as well.
AK

is the new x86_64 app for linux or windows?

Done. Please be aware this is an experiment; let's see how things turn out.

I've got 5 WUs in the pipeline already. I'll let y'all know how they go, but so far, so good, they're all making progress.

It seems you haven't implemented the ulimit workaround needed for this problem. Please see the FAQ for details on this. Until that time please suspend that machine.

I will email the other host (1024), because he/she seems to have the same problem.

Thanks!
Andre

I've got 5 WUs in the pipeline already. I'll let y'all know how they go, but so far, so good, they're all making progress.

A WU has just been successfully finished. However, a system running Red Hat (the others run SUSE) is failing all WUs after about 11min.

At about that time, memory seems to grow a bit, by 20MB to 140MB or so, but I can't tell if it's related to the failure.

HTH

It seems you haven't implemented the ulimit workaround needed for this problem. Please see the FAQ for details on this. Until that time please suspend that machine.

It seems you haven't implemented the ulimit workaround needed for this problem. Please see the FAQ for details on this. Until that time please suspend that machine.

Unfortunately we haven't been able to fix this server side yet :-( Many things have been tried (wrappers, scripts, compiler options) and did not work and we are constantly looking for new solutions. This issue HAS to be fixed before we can go to beta, so there is a big push to do so. Easy it is not unfortunately, but we'll come up with something eventually.

Thanks
Andre

It seems you haven't implemented the ulimit workaround needed for this problem. Please see the FAQ for details on this. Until that time please suspend that machine.

This is still needed? I thought it would have been fixed by now. What is the plan to address this long term?

Unfortunately we haven't been able to fix this server side yet :-( Many things have been tried (wrappers, scripts, compiler options) and did not work and we are constantly looking for new solutions. This issue HAS to be fixed before we can go to beta, so there is a big push to do so. Easy it is not unfortunately, but we'll come up with something eventually.

Unfortunately we haven't been able to fix this server side yet :-( Many things have been tried (wrappers, scripts, compiler options) and did not work and we are constantly looking for new solutions. This issue HAS to be fixed before we can go to beta, so there is a big push to do so. Easy it is not unfortunately, but we'll come up with something eventually.

Thanks
Andre

Unfortunately we haven't been able to fix this server side yet :-( Many things have been tried (wrappers, scripts, compiler options) and did not work and we are constantly looking for new solutions. This issue HAS to be fixed before we can go to beta, so there is a big push to do so. Easy it is not unfortunately, but we'll come up with something eventually.

Thanks
Andre

Does the Fortran program use recursion or multithreading/re-entrancy ? It looks like those might conflict with -noauto .

Are you allowed to change the Fortran source code to allocate the arrays from the heap and use pointers or to pre-allocate a group of arrays and use the recursion depth to pick which one to use for that time through the function?

Unfortunately, the last time I used Fortran was about 25 years ago, and it looks like a lot of new capabilities have been added. I don't suppose the next version of CHARMM (when they finally release it) will also address the stack problem for you in the Fortran code? Do they give you the test datasets so you could check that any modifications you make pass the tests?

It's a shame the CHARMM program isn't open source.

Is the Intel Fortran compiler the only one for Linux that has the language features that CHARMM uses?

Hmmm, BOINC is open source. I don't suppose you could make your own distribution of the BOINC client that adds the "ulimit -s unlimited" to the run_client script?

Another possibility might be to look at the source code for bash and see how it implements "ulimit -s unlimited", and write similar code in your wrapper program. I think it's just a function call to Linux, at least for some of the ulimit options.

I have compiled charmm with g77 successfully and it seemed that it worked correctly.

I have compiled charmm with g77 successfully and it seemed that it worked correctly.

Can you release a test version of this compile?

There's no need for that. We tested it in our lab and it crashes just as hard as the Intel version.

Thanks
Andre

I have compiled charmm with g77 successfully and it seemed that it worked correctly.

Can you release a test version of this compile?

Yes. Same result: need the ulimit setting.

Thanks for all the suggestions folks! This way we might find something that we haven't though of yet that works :-)

We'll pursue David's suggestion about the bash ulimit source code as well; that might be promising.

Andre

I have compiled charmm with g77 successfully and it seemed that it worked correctly.

Can you release a test version of this compile?

Have you tried gfortran too?

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 .

Im about to convert my C2D to 64bit Linux. So expect me to go offline on the C2D while i clear its CPDN WU's and return once i get everything sorted. this project supports 64bit with a 32bit app for Linux am i correct?
____________

Nope its got x64 app

Sounds even better
____________

this project supports 64bit with a 32bit app for Linux am i correct?

Yes, our x86_64 app is a 32-bit charmm wrapped in a 64-bit boinc coat. The new version of charmm (that we haven't received as of yet) provides real 64-bit capabilities.

Andre

this project supports 64bit with a 32bit app for Linux am i correct?

Oh, so its just wrapping. If thats the case, can you send work also to 'windows_amd64' platform too, please?

We'll look into that.

AK

Oh, so its just wrapping. If thats the case, can you send work also to 'windows_amd64' platform too, please?

Yes, our x86_64 app is a 32-bit charmm wrapped in a 64-bit boinc coat. The new version of charmm (that we haven't received as of yet) provides real 64-bit capabilities.

Andre

this project supports 64bit with a 32bit app for Linux am i correct?

The ulimit is needed on all linux systems for this version (c32a1) of charmm. We are testing with a 'boinc-less' version of the new charmm c33b1 and this one doesn't seem to be needing the ulimit set to unlimited. Until this charmm has been officially released with the boinc code in it, we cannot use it yet though.

Thanks
Andre

Yes, our x86_64 app is a 32-bit charmm wrapped in a 64-bit boinc coat. The new version of charmm (that we haven't received as of yet) provides real 64-bit capabilities.

Andre

this project supports 64bit with a 32bit app for Linux am i correct?

Does running it on Linux with the 64 bit wrapper do anything about needing the "ulimit" fix?

-- David

The new x64 Windows client, version 5.8.11, by Crunch3r, can be found at boinc_5.8.11_windows_amd64.zip .
Again, 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).

For more information, see BoincStats Forum .

HTH

____________

What is the official boinc platform name for windows 64-bit? It's not mentioned on http://boinc.berkeley.edu/platform.php .

AK

The new x64 Windows client, version 5.8.11, by Crunch3r, can be found at boinc_5.8.11_windows_amd64.zip .
Again, 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).

For more information, see BoincStats Forum .

HTH

What is the official boinc platform name for windows 64-bit? It's not mentioned on http://boinc.berkeley.edu/platform.php .

Hmmm, I would have guessed windows_x86_64 which would have brought it more in line with the linux name. Are 64-bit windows machine able to run 32-bit apps without problems or do you need 32-bit compatibility libs like on 64-bit Linux?

AK

What is the official boinc platform name for windows 64-bit? It's not mentioned on http://boinc.berkeley.edu/platform.php .

The de facto name, in use by ABC, HashClash and RieselSieve and by the client above, is windows_amd64. IMO, a nice counter-point to windows_intelx86. :-)

HTH

Are 64-bit windows machine able to run 32-bit apps without problems or do you need 32-bit compatibility libs like on 64-bit Linux?

Thanks. Just released the amd64 binary for windows. Hope you will be able to get some work soon :-)

AK

Are 64-bit windows machine able to run 32-bit apps without problems or do you need 32-bit compatibility libs like on 64-bit Linux?

Yes, all Windows x64 systems run 32-bit applications just fine, for the 32-bit libraries are automatically installed.

As a matter of fact, several components in Windows x64 are still 32 bits, such VS debug monitor, etc.

HTH

Thanks. Just released the amd64 binary for windows. Hope you will be able to get some work soon :-)

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

____________

The project intends to do some homogeneity tests and needs version 5.8.17 of the x86-64 Linux client, which can be downloaded from boinc_5.8.17_x86_64-pc-linux-gnu.tgz (make sure to read the file README.x86_64-pc-linux-gnu in it).

This is a beta version of the client, so use it carefully.

For more information, see BoincStats Forum .

HTH

____________

Augustine,

We have discovered several problems with 5.8.17 for linux since the announcement: it doesn't work with glibc 2.3.x systems (only with 2.4.x) and our server doesn't recognize the platforms running 5.8.17 (seems like a problem with a string length of the model spec). It is better to wait for a new release were these problems are fixed.

See also this post.

Thanks
Andre

The project intends to do some homogeneity tests and needs version 5.8.17 of the x86-64 Linux client, which can be downloaded from boinc_5.8.17_x86_64-pc-linux-gnu.tgz (make sure to read the file README.x86_64-pc-linux-gnu in it).

This is a beta version of the client, so use it carefully.

For more information, see BoincStats Forum .

HTH

We have discovered several problems with 5.8.17 for linux since the announcement: it doesn't work with glibc 2.3.x systems (only with 2.4.x) and our server doesn't recognize the platforms running 5.8.17 (seems like a problem with a string length of the model spec).

$ ldd ~/boinc/boinc_5.8.17_x86_64-pc-linux-gnu

        libdl.so.2 => /lib64/libdl.so.2 (0x00002b05e242a000)

        libc.so.6 => /lib64/libc.so.6 (0x00002b05e252e000)

        libm.so.6 => /lib64/libm.so.6 (0x00002b05e275e000)

        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b05e28b4000)

        /lib64/ld-linux-x86-64.so.2 (0x00002b05e230d000)

Actually, I always link my clients against GLIBC 2.3.5 and kernel 2.6.5. I also link statically any non-system libraries (e.g., CURL, OpenSSL, etc), so that it runs on most systems:

        Version information:

        /home/emenezes/boinc/boinc_5.8.17_x86_64-pc-linux-gnu:

                ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2

                libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2

                libm.so.6 (GLIBC_2.2.5) => /lib64/libm.so.6

                libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0

                libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6

                libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6

Actually, I always link my clients against GLIBC 2.3.5 and kernel 2.6.5. I also link statically any non-system libraries (e.g., CURL, OpenSSL, etc), so that it runs on most systems:

$ ldd ~/boinc/boinc_5.8.17_x86_64-pc-linux-gnu

        libdl.so.2 => /lib64/libdl.so.2 (0x00002b05e242a000)

        libc.so.6 => /lib64/libc.so.6 (0x00002b05e252e000)

        libm.so.6 => /lib64/libm.so.6 (0x00002b05e275e000)

        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b05e28b4000)

        /lib64/ld-linux-x86-64.so.2 (0x00002b05e230d000)

WRT to the server side of things, this system seems to be crunching WUs merrily with CC 5.8.17...

Yeah, I'm hoping they actually compile against glibc 2.3 with the GCC 4.1.2 compiler. I think I've proven that the additional benchmark improvement have come from the compiler and have nothing to do with the glibc version. However, the builder must be using some distro that happens to have glibc 2.4 along with GCC 4.1. I reported to them that Suse 10.1 has GCC 4.1 and glibc 2.3 but I've yet to see a build from them since 5.8.17 so we'll see if they decide to fix it.

Also, the problem with the string length, it's actually NOT a problem in the client. 5.8.17 is compiled with GCC 4.1 but it also recognizes more CPU features as well as the Family/Model/etc. It's the *server* that has the problem. David checked in a fix to allow the server to handle and parse the larger cpu string. So, hopefully, they'll get the server release out for people and let them know that the problem is in fact in the server. Also, it only seems to be the AMD CPUs that break that string size for the server.

- John Watzke

Is the Apr 10 Linux/X86_64 application a wrapper around the 32_bit spplication, or is it native?

I am successfully runnning the 64_bit_native applications for several projects with my 32_bit boinc client on my 64_bit Ubuntu 6.10 system. If Docking has a 64_bit application, I would like to do the same here. However, Docking does not give me permission to directly download the application executable from its directory on the server -- whereas other projects do allow that.
.

Charmm x86_64 is still the 32-bit version put in the 64-bit wrapper.We are looking into a 64-bit compile of charmm or at least enabling some of the x86_64 processor extensions later.

Thanks
Andre

Is the Apr 10 Linux/X86_64 application a wrapper around the 32_bit spplication, or is it native?

I am successfully runnning the 64_bit_native applications for several projects with my 32_bit boinc client on my 64_bit Ubuntu 6.10 system. If Docking has a 64_bit application, I would like to do the same here. However, Docking does not give me permission to directly download the application executable from its directory on the server -- whereas other projects do allow that.
.

What is the official boinc platform name for windows 64-bit? It's not mentioned on http://boinc.berkeley.edu/platform.php .

The de facto name, in use by ABC, HashClash and RieselSieve and by the client above, is windows_amd64. IMO, a nice counter-point to windows_intelx86. :-)

Dude.. you're just a fanboi. *snickers*

I prefer 'windows_x86_64'.

I'm sure there are both Intel and AMD fans here.

For the record, I have 4 systems, 2 Intel and 2 AMD.

I'd like to point out that having both companies competitive helps all of us. IMO, without both of them in the market, we'd probably see CPU prices 2 - 3 times what they are today. Without AMD pushing Intel, there'd probably be no Core 2 Duo/Quad. Intel used to be in the position where it gave us what it wanted, when it wanted, and charged whatever it wanted. IMHO, 64 Bits was reserved for Itanium and it's very likely that they would have used process shrinks to get the P4 (32 bit only) architecture problems solved at whatever leisurely schedule they wanted. Everyone that buys an AMD CPU is helping Intel buyers get more advanced and cheaper CPUs for their money. Let's just hope that there's enough balance of sales between the two companies so we can all continue to benefit.

Those are my opinions. You're welcome to express yours but please keep it friendly.

Happy Crunching,

-- David Ball
____________
The views expressed are my own.
Facts are subject to memory error :-)
Have you read a good science fiction novel lately?

I'm sure there are both Intel and AMD fans here.

I'm sure there are both Intel and AMD fans here.

To be honest I have both, but more for "value for money" reasons.
Don't blame me... I'm dutch.

;-)

There's some great bargains out there now, but you have to be careful about electricity usage. Fortunately, I'm not a gamer so my systems all use the cheap video built into the motherboard. Aside from costing a fortune, some of todays fancy video cards use more electricity than the rest of the system put together.

Wow! Makes me glad I don't play games! My electric bill is high enough!
____________
John

MacPro
2 x 2.66GHz Dual-Core Xeon | 2GB RAM | ATI x1900 | BOINC 5.9.5

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

____________

Bit of a bump there I thought I felt!

I was thinking of upgrading one of my machines to an E6850, but on paper at least, the similarly priced Q6600 is a better BOINCer.
____________
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

Bit of a bump there I thought I felt!

I was thinking of upgrading one of my machines to an E6850, but on paper at least, the similarly priced Q6600 is a better BOINCer.

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

____________

Bit of a bump there I thought I felt!

I was thinking of upgrading one of my machines to an E6850, but on paper at least, the similarly priced Q6600 is a better BOINCer.

I've been wondering about that. The Q6600 has a 1066 MHz FSB for 4 cores, but the new dual cores have a 1333 MHz FSB.

Has anyone tried the new E2160 or E4300 on BOINC? They only have an 800 MHz FSB, but I've been wondering if two of them would produce as much as a Q6600...

BTW, You can price out a Q6600 system with 2 GB RAM and an 80 GB SATA HD from Dell beginning at just $609. Two of my teammates are trying them now and are very pleased so far...

-- David

@j2satx

Thanks for the info. I'd love to see some comparisons from other projects if it's not too much trouble.

I'm going to have to investigate BOINCview.

Thanks!!!

@j2satx

Thanks for the info. I'd love to see some comparisons from other projects if it's not too much trouble.

I'm going to have to investigate BOINCview.

Thanks!!!

What other projects do you participate in?

What other projects do you participate in?

Mostly Rosetta, QMC, and MalariaControl.

Thanks!