Posts by Augustine

1)

Message boards : Number crunching : Exceeded CPU time quota.

( Message 4792 )
Posted 3118 days ago by Augustine
Rather disappoint that a WU like this is crunched for about 8h only to be aborted because a too pessimistic CPU time limit...
2)

Message boards : Number crunching : Moving to Beta D@H

( Message 4398 )
Posted 3243 days ago by Augustine
charmm seems to randomly generate this error: -177 (0xffffffffffffff4f) ERR_RSC_LIMIT_EXCEEDED

A resources usage, such as disk space or CPU time, has been exceeded. Typically, exceeding the CPU time is more common, as it's often underestimated.

In my anecdotal experience it's more often underestimated in Linux because this OS, unlike Windows, runs BOINC processes (or any other nice process) at the lowest CPU speed (see this ), whereas it seems to be common that projects use Windows runs to estimate the CPU time limit for WUs.

HTH
3)

Message boards : Unix/Linux : Upgrading from 32 bit to 64 bit

( Message 4384 )
Posted 3244 days ago by Augustine
The best approach is to let your projects drain by disabling them from downloading more WUs. Then, it's safe to upgrade.

However, it's quite possible and normal that you'll end up with duplicate hosts, as a 32-bit client reports a different platform than the 64-bit client. But then you can merge the duplicate hosts by name.

HTH
4)

Message boards : Number crunching : Problem with Vista64Bit Client

( Message 4364 )
Posted 3249 days ago by Augustine
Interesting enough, Task Manager shows Charmm34_6.15_windows_x86_64 with a *32 after the name, meaning it is a 32bit application... *LOL* why then even name it x86_64?

Because older 64-bit clients didn't support alternative platforms, when making sure that the platform name matched what the client requested, even if it were a mere 32-bit application renamed, was necessary.

Therefore, it's done in order to support legacy clients, as you can see here .

HTH
5)

Message boards : Number crunching : AMD64

( Message 3643 )
Posted 3523 days ago by Augustine
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:


The official AMD64 Windows client can be found here .

For more information, see the BoincStats Forum .

HTH

6)

Message boards : Number crunching : AMD64

( Message 3509 )
Posted 3649 days ago by Augustine
Here's a development version of the x86-64 Linux client:


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

7)

Message boards : Application Info : charmm_5.7_windows_x86_64

( Message 3225 )
Posted 3752 days ago by Augustine
This is the proper platform name for 64 bit windows. This is only the 4th project that I know of to support it.

Perhaps it's not necessary for projects to add explicit support for the windows_x86_64 platform if they don't have a native AMD64 application. The new platform string is only used by the new clients still in beta which implement platform redundancy by first trying to get an application using the platform windows_x86_64 and then if this fails it tries to get an application using the platform windows_intelx86, i.e., it falls back to the 32-bit application automatically.

I guess that projects can continue supporting the custom built windows_amd64 client, but no action is needed to support the official windows_x86_64 client unless a native AMD64 application for Windows is developed.

HTH
8)

Message boards : Number crunching : AMD64

( Message 3101 )
Posted 3762 days ago by Augustine
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. :-)

As you probably know, disregarding what ABC, Docking, HashClash and SIMAP have been doing since as far as September 2006, the BOINC developers redefined the 64-bit Windows platform to be "windows_x86_64", in disregard with the practice by these pioneer projects.

It's perhaps not too late and maybe you could chime in here and see if they change their minds. I tried unsuccessfully to argue for "windows_amd64" as the de facto standard in the boinc_dev mailing list, but its archive has been expunged.
9)

Message boards : Application Info : 64-Bit / 32 bit, SSE3 and other extensions?

( Message 3088 )
Posted 3767 days ago by Augustine
I'll ask Memo to look into this. Enabling some optimization for 64-bit clients makes sense to me. We'll have to see if we can enable extensions so specifically with compiler options and whether the app will still work if that extension wouldn't be available.

The AMD64 ABIs for both Linux and Windows require SSE2 support. Therefore, when a 64-bit application is built by default it uses SSE and SSE2 for all single and double-precision floating-point calculations. And given that SSE and SSE2 can be taken for granted on AMD64 systems, it follows that vectorization can also be used.

So, Aaron is right on suggesting that the 32-bit application sent to AMD64 clients could have SSE and SSE2 enabled as well as vectorization.

IIUC, Docking uses the GCC compiler. Therefore, make sure to add "-msse2 -mfpmath=sse -ftree-vectorize" (-msse2 implies -msse) when building a 32-bit application for AMD64 clients.

The Intel compiler generates code for several processors and at run-time runs the code better suited depending on the features supported. However, it's known to run the slowest code the possible when run on AMD processors.

The MS compiler however doesn't support vectorization, but it does support SSE and SSE2 through the option "/arch:sse2".

HTH
10)

Message boards : Number crunching : AMD64

( Message 2703 )
Posted 3806 days ago by Augustine
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:

Or, to be more precise: 


        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

HTH


Next 10 posts