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)
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.
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.
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.
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.
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 ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
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.
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.
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
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.
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.
Windows 64bit, Boinc64bit
)
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
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.
RE: My Linux host is fully
)
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.
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
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?
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 ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
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.
* "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
RE: Well, recent versions
)
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
RE: I still need to verify
)
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
RE: RE: I still need to
)
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.