Now that the AMD64 platform is somehow supported, would you consider supporting windows_amd64 similarly?

Thanks.

---

Unlikely as there are no benefits to writing a specifically 64bit programme. AFAIK the current 32bit version runs under most of the presently available 64bit OSes without problems.

---

Grant
Darwin NT

Now that the AMD64 platform is somehow supported, would you consider supporting windows_amd64 similarly?

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

---

In the past I've run the BOINC client without problems on Windows 64 and 64-Vista using the existing clients. I don't know that a specific XP 64 (waste of time there), or Vista 64 client makes that much sense.

The existing clients also seem to play well with the true dual CPU processors (both AMD and Intel).

Now that the AMD64 platform is somehow supported, would you consider supporting windows_amd64 similarly?

Thanks.

---

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%!

---

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%!

just for Info, where you get the 64 Bit Version of Simap Hmmer

this will be interestink....

Greetings from Germany NRW
Ulli

In the past I've run the BOINC client without problems on Windows 64 and 64-Vista using the existing clients. I don't know that a specific XP 64 (waste of time there), or Vista 64 client makes that much sense.

It does in some cases.

The existing clients also seem to play well with the true dual CPU processors (both AMD and Intel).

It does but why running the client & app. in WOW64 emulation if one can get a native 64 bit boinc and s@h application ?!?

---

Join BOINC United now!

just for Info, where you get the 64 Bit Version of Simap Hmmer

this will be interestink....

All one has to do is to run the AMD64 BOINC client and it'll be automatically downloaded (see this).

HTH

---

If You like Linux, I like Windows XP x64 and agree with Crunch3r on this. As any new crunchers will use XP x64 only.

That's why I've suggested the support of the windows_amd64 platform as well.

---

If You like Linux, I like Windows XP x64 and agree with Crunch3r on this. As any new crunchers will use XP x64 only.

That's why I've suggested the support of the windows_amd64 platform as well.

I don't see a need for a "windows_amd64 platform". I do run a native 64 bit boinc and seti application on WinXP64 and it works well.

---

Join BOINC United now!

I think You are confused slightly, I'm talking about the OS, You sound like You're talking about the cpu which I'm not.

No, I'm talking about the OS, Windows x64 whose BOINC platform is windows_amd64, much like the BOINC platform for Windows x86 is windows_intelx86.

HTH

---

I don't see a need for a "windows_amd64 platform". I do run a native 64 bit boinc and seti application on WinXP64 and it works well.

If all you run is SETI or you don't mind messing with app_info.xml files, then it's for you.

Given that AMD64 systems running a 64-bit OS is far more common than Solaris/SPARC or Mac/x86, I don't understand why the BOINC community is dragging its feet supporting AMD64...

Ever since I started suggesting the support of AMD64, 3 projects have decided to support it, one of them in full production status.

I apologize for being such a nag, but it makes sense and it's about time.

---

Then please start calling the OS XP x64, As that is what the OS is called, is known by and as It's entitled by MS, As You're slightly confusing two different terms, as AMD64 is used by Linux distros and by AMD, Not by Microsoft or Its Windows XP x64 OS...

That's the name of the ISA and as I'm advocating support for this ISA on several OS'es, I prefer to continue using AMD64 meaning all AMD64 OS'es.

Thanks.

---

If there should be a platform added due to win xp64 it should be called (the application for example)
windows_intelx86_64 and nothing else.

---

Join BOINC United now!

If there should be a platform added due to win xp64 it should be called (the application for example)
windows_intelx86_64 and nothing else.

Sorry, it is already defined as windows_amd64 by other projects.

---

Well according to Microsoft(Who owns the Legal Copyright to the OS, There is no such OS as "Windows AMD64"

Microsoft can call it anything it wants in its products, the name of the ISA (Instruction Set Architecture) still is AMD64. If all you have to say is about such picayunes, please, feel free to ignore this thread, it's not for you.

---

... It's kind a like giving a Megabyte the abbreviation of MiB when It always has been Mb as there is no "i" in Megabyte, But then Megabyte is a term that was invented in the USA, not elsewhere.

I take it that you do know the difference between MByte (base 10) as abused by Sales People, and the very different binary MiByte?

Also, Mb = Mbit! (x8 smaller than MB.)

And the other good cockup is mhz instead of MHz (milli-somethings instead of Mega Hertz)...

Shame the Marketing types are so hopelessly uneducated for anything other than falsely hyping up whatever "object" is to be flogged...

Happy crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

FYI, the new x86-64 Linux client, version 5.8.11, can be found at boinc_5.8.11_x86_64-pc-linux-gnu.tgz. 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

---

I take it that you do know the difference between MByte (base 10) as abused by Sales People, and the very different binary MiByte?

I was not talking about Mbit at all, When I started out We didn't have the term Mbit. I was talking about as I spelled It out as Megabyte, I never even mentioned MHz once. Now back then I think It was spelled Mb, I just looked It up and It is now MB. So your right on that, On the rest MiB is not a Megabyte at all It's a mebi-byte whatever that is, Must be a "mebi It is a byte", But I won't use It. A Megabyte is a Megabyte and there is No i in "Megabyte", Never has been.

So I take it then that you do not appreciate the difference between "Mega" as used in base 10 (decimal) compared to that used in base 2 (binary).

Marketing people love to push the decimal version. Computer people use the binary version. There is an inconveniently BIG difference.

Look again?

Maybe it didn't matter in the days when 640kBytes was unimaginable...

Happy crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

Yes I do know the difference, I've been using computers since 1980(Atari 400 w/a 410 drive) and the computers maximum memory was 64kB, Not KiB, MiB, etc junk. :p
I just support the traditional words and their abreviations not the IEC, IEEE, EU junk...

I agree.

Unfortunately, the Marketing shallow ploy for "bigger numbers" has poisoned the naming scheme for all.

Hence, the bastardised form of the original units have been abandoned to the Marketing people and their base 10 scams.

Engineers and programmers for whom the difference is important have a new recommended standard that explicitly highlights the binary difference.

I'll agree the "Mi", "ki", etc looks ugly, but it is a necessary evil to ward off the even greater evil of Marketing foisted confusion.

There have been many disasters due to confusion over what units were being used...

Happy crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)