Windows 64bit, Boinc64bit

M. Schmitt
M. Schmitt
Joined: 27 Jun 05
Posts: 478
Credit: 15,872,262
RAC: 0
Topic 196352

but I never get any Gravitational S6 Wave LineVeto seach (X64). This is a miracle to me.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 458,445,412
RAC: 60,558

Windows 64bit, Boinc64bit

Quote:
but I never get any Gravitational S6 Wave LineVeto seach (X64). This is a miracle to me.

Not a miracle, but a feature: An x64 app is only available for the Linux OS: http://einstein.phys.uwm.edu/apps.php

The reason is that many 64 bit Linux installations these days do not have alkl 32 bit compatibility libs installed by default. 64 bit Windows by contrast can always execute 32 bit executables, so there is no need for a 64 bit Windows app, which would probably not even be faster (e.g. the 64 bit Linux app is not faster than its 32 bit counterpart)

Cheers
HB

M. Schmitt
M. Schmitt
Joined: 27 Jun 05
Posts: 478
Credit: 15,872,262
RAC: 0

If the 32bit App is faster,

If the 32bit App is faster, why don't you deliver the 32bit App to 64bit Linux machines?
I see that my i7 2600K crunches the 32bit much faster than the X64 Linux App?
Windows with 32bit App: 12,001.28 CPU time: 11,861.91
Linux X64 on the same host: 13,123.66 Cpu time: 13,052.07
Don't you tell me there is no difference.

My Linux host is fully equipped with 32bit libs.

Most other distributions can install them later, so what?

[edit]Remember the time, there wasn't a 64bit App?
I remember the time - I compiled myself a BOINC-client for 64bit and run 32bit Apps on it.

Jord
Joined: 26 Jan 05
Posts: 2,952
Credit: 5,696,787
RAC: 313

RE: My Linux host is fully

Quote:

My Linux host is fully equipped with 32bit libs.

Most other distributions can install them later, so what?


The problem here is that neither BOINC nor the project will detect whether users have all the correct libraries installed. Neither can even do that without breaking into users computers.

So any work that the project sends to the user will have a greater probability of all being erroneous, before the user detects this, if at all he will. Then that user comes here, asks what's going on and only then will he go and install the compatibility libraries. Sometimes it's weeks before the user notices there's something wrong. Which means there's tons of work unncessarily sent to his computer, bandwidth used up etc.

Thus a 64bit app to a 64bit Linux is easier in this way.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 458,445,412
RAC: 60,558

Exactly! WE would love to

Exactly!

WE would love to have just one Linux CPU app version (32 bit), having to build two apps, test two apps, having separate code paths for the assembly part .... that all is additional effort, but we think it's a necessary concession to users who don't have the 32 bit compatibility libs installed.

Cheers
HB

M. Schmitt
M. Schmitt
Joined: 27 Jun 05
Posts: 478
Credit: 15,872,262
RAC: 0

I disagree, there where times

I disagree, there where times the project delivered only 32bit apps. Anybody had to install the 32bit libs on Linux 64bit hosts.

I have several VirtualBox installations on my hosts, all 32bit because of albert@home. Maybe I should add E@H to them. With an proper app_info.xml I should receive only BRP4 tasks for my GPU's.

Is that what you want?

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6,126
Credit: 127,356,222
RAC: 8,091

Alas most users are not

Alas most users are not sufficiently technically minded for the purpose at hand here ie. probably could not recognise/describe most of the relevant verbs/nouns/phrases in this thread ( even if English language literate ). So it's more a matter of either not making assumptions about, or reducing the load upon, their intellect or domain knowledge.

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter. Blaise Pascal

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 3,946
Credit: 201,964,363
RAC: 49,770

Well, recent versions of

Well, recent versions of BOINC should be able to detect whether 64Bit machines can run 32Bit Apps, and report the 32Bit platform as "alternative platform" or not. There are only a few 64Bit version of older Clients around where this doesn't work.

But the main reason for shipping the 64Bit App version to all 64Bit Linux clients was that I'm still trying to understand the chain of events that lead to errors like that:
http://einsteinathome.org/task/290221415
i.e.

  • * "libgcc_s.so.1 must be installed for pthread_cancel to work"
    * "signal handler called: signal 6"
    * "process got signal 11"

The key question is: A "libgcc_s.so.1" lib should be installed on every Linux system nowadays, why can't it be found? The idea was that the installed one would be 64Bit and thus doesn't match that of the 32Bit application. Unfortunately this doesn't seem to be the case, as this still happens, obviously on "pure" 32Bit machines.

And I still need to verify that the 64Bit App is noticeably slower on nowadays machines. If this really is the case, I could easily change the configuration such that all machines that can run the 32Bit App will get it.

BM

BM

Stephan Goll
Stephan Goll
Joined: 13 Dec 05
Posts: 25
Credit: 27,834,196
RAC: 0

RE: Well, recent versions

Quote:

Well, recent versions of BOINC should be able to detect whether 64Bit machines can run 32Bit Apps, and report the 32Bit platform as "alternative platform" or not. There are only a few 64Bit version of older Clients around where this doesn't work.

But the main reason for shipping the 64Bit App version to all 64Bit Linux clients was that I'm still trying to understand the chain of events that lead to errors like that:
http://einsteinathome.org/task/290221415
i.e.

  • * "libgcc_s.so.1 must be installed for pthread_cancel to work"
    * "signal handler called: signal 6"
    * "process got signal 11"

The key question is: A "libgcc_s.so.1" lib should be installed on every Linux system nowadays, why can't it be found? The idea was that the installed one would be 64Bit and thus doesn't match that of the 32Bit application. Unfortunately this doesn't seem to be the case, as this still happens, obviously on "pure" 32Bit machines.

And I still need to verify that the 64Bit App is noticeably slower on nowadays machines. If this really is the case, I could easily change the configuration such that all machines that can run the 32Bit App will get it.

BM

Hi Bernd,
the answer is "simple"(tm): a 32 bit application searches for the 32 bit lib and if this lib is not found, the 64 bit lib will reported as "not found" even if it is installed.

find / |grep libgcc_s.so
/lib/libgcc_s.so.1
...
/usr/lib32/libgcc_s.so.1

If someone writes an application with hard coded search path (/lib/ (or /lib32/) ... where normally the common libs are located) the 32 bit libs will not be found. But I'm far away from beeing a programmer, I can only guess. The "problem" is in this case that the usual place for the 32 bit libs is /lib32/ and _not_ /usr/lib32/, but for this special library ...
Stephan

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 3,946
Credit: 201,964,363
RAC: 49,770

RE: I still need to verify

Quote:
I still need to verify that the 64Bit App is noticeably slower on nowadays machines. If this really is the case, I could easily change the configuration such that all machines that can run the 32Bit App will get it.

Just ran the same task on the same machine, the total runtime differed by less than 1% (513m vs. 509m), which is actually within measurement tolerance. So I don't think there is a need to change something one or the other way.

BM

BM

M. Schmitt
M. Schmitt
Joined: 27 Jun 05
Posts: 478
Credit: 15,872,262
RAC: 0

RE: RE: I still need to

Quote:
Quote:
I still need to verify that the 64Bit App is noticeably slower on nowadays machines. If this really is the case, I could easily change the configuration such that all machines that can run the 32Bit App will get it.

Just ran the same task on the same machine, the total runtime differed by less than 1% (513m vs. 509m), which is actually within measurement tolerance. So I don't think there is a need to change something one or the other way.

BM

I got it, it's in the the libgcc64-32bit: libgcc_s.so.1
Can this be used?

I repeat:
Windows with 32bit App: 12,001.28 CPU time: 11,861.91
Linux X64 on the same host: 13,123.66 Cpu time: 13,052.07

It's i7 .
Is that nothing? On other hosts it might be remarkable slower.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.