Right now, when the core client is built for AMD64, it can only download applications for AMD64. Therefore, when such a core client is used, it can run a very limited number of projects, SETI@home Beta right now and also Chess960@home soon.

However, AFAIK, all OS'es for AMD64 can run x86 applications just fine. Can this be treated as a special case by the core client by trying to get an AMD64 application and if it fails trying again, but to get an x86 application?

---

It's rather puzzling that x86 Mac is a supported platform and AMD64 isn't, especially when it can run the x86 project application just fine and the number of installed systems dwarfs that of x86 Mac by at least an order of magnitude. :-/

BTW, SETI, SIMAP and Chess960 now support the AMD64 Linux platform, the latter two with native AMD64 applications.

---

Will BOINC 5.5 report AMD64 as a CPU capability when running on a 64-bit OS? That way, projects whose application get a performance boost on AMD64 could send one such application even to systems running the x86 core client. Is it?

Thanks,

---

Which project has a 64bit application that is faster than the 32bit application?
All projects using FLOPs for their application (Seti, Einstein) don't care about the CPU you have in your computer. They care about the FPU in the CPU. And since the FPU is unchanged between 32bit and 64bit CPUs, there is no real need for a 64bit BOINC or application in those cases.

---

Which project has a 64bit application that is faster than the 32bit application?... And since the FPU is unchanged between 32bit and 64bit CPUs, there is no real need for a 64bit BOINC or application in those cases.

Excuse me, but in 64 bits there are twice as many registers as in 32 bits. SSE is also standard with AMD64 and some OS's provide faster and more accurate math routines for it.

The Chess960 application is about 30% faster in 64 bits than in 32 bits.

BTW, I ported the official SETI Classic application to AMD64 and right off the bat it was 10% faster by just recompiling it.

---

Chess960 isn't exactly a project open to all. It's still in Alpha phase.

So tell me again, which projects, open to all, have 64bit applications?
And why won't the rest try to go for FLOP counting as well, as then it doesn't matter which CPU you have?

The last time that someone tried a 64bit application on a 64bit Linux version of BOINC and WinXP64, with Seti I think it was, the speed increase was an overwhelming 3%.

The latest versions of BOINC (5.5.x) have got SSE and 3DNow optimizations included. That may be your 10% increase. Yet we all see that, with the by the projects optimized apps coming out. Further optimization can be done if you own an Intel compiler and you can optimize Open Source applications. Which means Seti and Seti Beta for this moment only.

Einstein just released their own optimized application. It's faster than their previous version.

So, what more do you want?

---

Chess960 isn't exactly a project open to all. It's still in Alpha phase.

So tell me again, which projects, open to all, have 64bit applications?

SIMAP, as I mentioned above.

SETI@home now uses FFTW heavily and under AMD64 it's between 10 and 20% faster, as you can see by comparing these charts here and here.

---

SETI@home now uses FFTW heavily and under AMD64 it's between 10 and 20% faster, as you can see by comparing these charts here and here.

One thing are explicitly set compiler flags, another is those default ones.

Quote from Debian on AMD64 page: gcc defaults to SSE2 math instead of 387 FPU. Probably other AMD64 ports use that as well.

So, unless one explicitly sets -mfpmath=sse when compiling for i386, math doesn't really compare.

---

Metod ...

Quote from Debian on AMD64 page: gcc defaults to SSE2 math instead of 387 FPU. Probably other AMD64 ports use that as well.

So, unless one explicitly sets -mfpmath=sse when compiling for i386, math doesn't really compare.

As I said above, the AMD64 ABI is more efficient and can be taken for granted, unlike x86 which requires run-time checks and development and maintenance of different code-paths to handle the huge disparity of processor capabilities in its installed base.

The fact that x86 defaults to x87 is just part of the problem and the whole majority of BOINC projects only uses x87. Out of the 28 I run, only 3 use SSE in their Linux applications. So, in the real world, they do compare.

---

The fact that x86 defaults to x87 is just part of the problem and the whole majority of BOINC projects only uses x87. Out of the 28 I run, only 3 use SSE in their Linux applications. So, in the real world, they do compare.

Well, it seems that main dispute between pro-AMD64 and contra-AMD64 camps comes from basic dilemma: do we prefer backwards comapitibility or do we want performance at any cost?

The fact that only 3 out of 28 projects in your portfolio use/offer SSE clients for i386 platform shows that these don't really squeeze maximum performance out of their participants machines. The reason is either they don't have resources (knowledge, motivation) for doing that or it's simply not possible (due to whatever reason beyond their control). Either way it's not entirely sensible to expect them to offer AMD64 science application.

Indeed, I've read somewhere that newer versions of BOINC server application allows to send out scientific application that really is not native for particular host platform and thusly it's possible to send out an i386 application if host platform is AMD64. But, do you really expect all of those projects jump on it? It has been proven that producing i386 application that includes CPU capability detection and selection of SSE/387 math routines accordingly does good to project goals. Still, only a few projects exploit that ...

Me, being more of a backward-compatibility guy, I expect that if BOINC CC was available for AMD64 platform, a lot of users would become unhappy quickly as they wouldn't be able to participate in their belowed project. Further more, they would mainly blame BOINC CC for that, not their project management (or even themelves for not doing research on project supported platforms).

Again, BOINC is a GPL software. Which means you're more than free to do with it just anything you want to. Including compiling it for your preferred platform. It's doable without any problems. However, just because of running AMD64 port of BOINC CC you won't gain anything.

We have a typical chicken-egg problem: it's useless to produce scientific application for AMD64 platform until there's BOINC CC for that platform. And the later is useless until there are scientific applications. The glue here is backward compatibility which will, hopefully, be implemented by most of the projects ASAP.

[edit]: spellings

---

Metod ...

Metod,

That's the problem that I had in mind when I proposed above that, given that an AMD64 OS can run x86 smoothly, even an x86 CC could load an AMD64 application if it detects that both the processor and the OS support AMD64.

In spite of the CC being open-source, many applications aren't. I can help myself compiling the CC and I've been helping some projects to port their applications to AMD64. But the CC could be smarter and fully support bi-architecture OS'es as smoothly as the OS'es themselves do.

---

In spite of the CC being open-source, many applications aren't. I can help myself compiling the CC and I've been helping some projects to port their applications to AMD64. But the CC could be smarter and fully support bi-architecture OS'es as smoothly as the OS'es themselves do.

I believe that the correct way is the way taken by SAH: when client says it's platform is x86_64-unknown-linux-gnu (or x86_64-pc-linux-gnu), then send out i386 science binary.

Now we have to persuade project managements to implement it.

---

Metod ...

Now we have to persuade project managements to implement it.

That's what I've been trying to do in the past couple of weeks. I posted in all projects about supporting AMD64 in any way. So far, SIMAP and Chess960 heard my appeals and now support it. Any help is appreciated.

I do find it amusing that some projects were quick to support Mac/x86 with so few of such systems out there and yet ignored AMD64. Go figure...

---

I do find it amusing that some projects were quick to support Mac/x86 with so few of such systems out there and yet ignored AMD64. Go figure...

Yeah, it's frustrating. The name of the game is backward compatibility. You don't really have that for Max/x86.

---

Metod ...

Which project has a 64bit application that is faster than the 32bit 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.

That's a potential performance improvement of 15% when porting the project application to AMD64.

---