> Would you of guessed the Linux client completed in 9.5 hrs vs just 5.5 for
> Windows by relying on the benchmarks? FYI the optimized linux client at the
> pperry site was used.
I haven't been able to do a straight Linux/Windows comparison, as I don't have any dual-booting PCs. I wonder if the disparity might account for the possibility that the E@H science application itself isn't optimized? Talking about the .../projects/einstein.phys.uwm.edu/einstein_4.80_i686-pc-linux-gnu file, not the BOINC client everyone has optimized.
> Guess that's possible but for now it's clear the benchmarks are worthless for
> any meaningful cross-platform performance comparisons.
>
Indeed, but they are used to calculate your credit so getting them accurate is important.
It is correct though that the WU completion time has nothing to do with the boinc client, mainly because it's not run to work on the unit, looking in top, you'll see this:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21683 39 19 20840 11m 11m R 95.9 1.5 249:02.68 einstein_4.80_i
Note the command, einstein_4.80_i...(rest is cut by limited size of terminal), the einstein core is doing all the calculations not boinc, you're right Stevious, so us Linux users just have to wait for them to either release the source or a bunch of optimized cores for different CPUs.
> > Would you of guessed the Linux client completed in 9.5 hrs vs just 5.5
> for
> > Windows by relying on the benchmarks? FYI the optimized linux client at
> the
> > pperry site was used.
>
> I haven't been able to do a straight Linux/Windows comparison, as I don't have
> any dual-booting PCs. I wonder if the disparity might account for the
> possibility that the E@H science application itself isn't optimized? Talking
> about the .../projects/einstein.phys.uwm.edu/einstein_4.80_i686-pc-linux-gnu
> file, not the BOINC client everyone has optimized.
The Einstein team has said that their application for linux isn't optimized.
And in BOINC it's the Windows client that has higher than should Benchmarks. The next BOINC Version 4.2x has corrected the benchmark code in Windows, and the values of Linux vs Windows should be closer. I'm now imagining the people with Windows complaining that their benchmarks are lower. And I hope that "optimized" Linux clients then will not have inflated benchmarks like windows now have ;-)
Professor Desty Nova
Researching Karma the Hard Way
> > > Would you of guessed the Linux client completed in 9.5 hrs vs just
> 5.5
> > for
> > > Windows by relying on the benchmarks? FYI the optimized linux
> client at
> > the
> > > pperry site was used.
> >
> > I haven't been able to do a straight Linux/Windows comparison, as I don't
> have
> > any dual-booting PCs. I wonder if the disparity might account for the
> > possibility that the E@H science application itself isn't optimized?
> Talking
> > about the
> .../projects/einstein.phys.uwm.edu/einstein_4.80_i686-pc-linux-gnu
> > file, not the BOINC client everyone has optimized.
>
> The Einstein team has said that their application for linux isn't optimized.
Correction: we HAVE optimized. But in spite of our best efforts, gcc is not producing code that is efficient as the instruction stream emitted by the Microsoft Windows compiler. I wish it weren't true, but it is.
I hope that within the coming few days we can get back to this and try and find a better compiler or set of gcc flags for our app under Linux. We've done an awful lot of profiling and optimization work already, so we're surprised that the situation is not better. But it's clearly the case that on identical hardware our app runs significantly faster under Windows.
> Correction: we HAVE optimized. But in spite of our best efforts, gcc is not
> producing code that is efficient as the instruction stream emitted by the
> Microsoft Windows compiler. I wish it weren't true, but it is.
Forgive me if I am stating the obvious but, if the Einstein app is anything like the Seti one, it makes extensive use of libraries. If those libraries have not been optimised, optimising the app will have little effect.
Just trying to help - ignore me if I am trying to teach my grandmother to suck eggs. ;)
>
> > Correction: we HAVE optimized. But in spite of our best efforts, gcc is
> not
> > producing code that is efficient as the instruction stream emitted by
> the
> > Microsoft Windows compiler. I wish it weren't true, but it is.
>
> Forgive me if I am stating the obvious but, if the Einstein app is anything
> like the Seti one, it makes extensive use of libraries. If those libraries
> have not been optimised, optimising the app will have little effect.
>
> Just trying to help - ignore me if I am trying to teach my grandmother to suck
> eggs. ;)
>
>
>
That's quite correct but people like me who are running Gentoo Linux have already compiled all the libraries at -O3 anyway ;). Maybe I should re-emerge glibc with those other -f's...
> That's quite correct but people like me who are running Gentoo Linux have
> already compiled all the libraries at -O3 anyway ;). Maybe I should re-emerge
> glibc with those other -f's...
Gentoo here also. ;) A lot of Gentoo people are nervous about -O3 but I have two systems built from the start with -O3. One problem, though, is that Gentoo's emerge often overrides user-set compiler flags. :( I think it does with glibc and stdc++.
> > That's quite correct but people like me who are running Gentoo Linux
> have
> > already compiled all the libraries at -O3 anyway ;). Maybe I should
> re-emerge
> > glibc with those other -f's...
>
> Gentoo here also. ;) A lot of Gentoo people are nervous about -O3 but I have
> two systems built from the start with -O3. One problem, though, is that
> Gentoo's emerge often overrides user-set compiler flags. :( I think it does
> with glibc and stdc++.
>
>
Yeah, it uses the recomendations that Linux From Scratch uses, so glibc/gcc and a couple of others overide the settings. I tried doing an emerge glibc and ctrl+z'ing out of it to edit the Makefile after it had configured but it came up with some inconsistancy error or something so I'm guessing it's very carefull and picky about the flags it gets. It's already being compiled with -O2 -march=athlon-xp anyway so there's not a whole lot extra I can do.
> > The Einstein team has said that their application for linux isn't
> optimized.
>
> Correction: we HAVE optimized. But in spite of our best efforts, gcc is not
> producing code that is efficient as the instruction stream emitted by the
> Microsoft Windows compiler. I wish it weren't true, but it is.
>
> Bruce
What I really wanted to say, was "it's optimized, but not as much as the windows application". Since english isn't my primary language, sometimes things like this pass ;-)
Professor Desty Nova
Researching Karma the Hard Way
> Would you of guessed the
)
> Would you of guessed the Linux client completed in 9.5 hrs vs just 5.5 for
> Windows by relying on the benchmarks? FYI the optimized linux client at the
> pperry site was used.
I haven't been able to do a straight Linux/Windows comparison, as I don't have any dual-booting PCs. I wonder if the disparity might account for the possibility that the E@H science application itself isn't optimized? Talking about the .../projects/einstein.phys.uwm.edu/einstein_4.80_i686-pc-linux-gnu file, not the BOINC client everyone has optimized.
Guess that's possible but for
)
Guess that's possible but for now it's clear the benchmarks are worthless for any meaningful cross-platform performance comparisons.
> Guess that's possible but
)
> Guess that's possible but for now it's clear the benchmarks are worthless for
> any meaningful cross-platform performance comparisons.
>
Indeed, but they are used to calculate your credit so getting them accurate is important.
It is correct though that the WU completion time has nothing to do with the boinc client, mainly because it's not run to work on the unit, looking in top, you'll see this:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21683 39 19 20840 11m 11m R 95.9 1.5 249:02.68 einstein_4.80_i
Note the command, einstein_4.80_i...(rest is cut by limited size of terminal), the einstein core is doing all the calculations not boinc, you're right Stevious, so us Linux users just have to wait for them to either release the source or a bunch of optimized cores for different CPUs.
> > Would you of guessed the
)
> > Would you of guessed the Linux client completed in 9.5 hrs vs just 5.5
> for
> > Windows by relying on the benchmarks? FYI the optimized linux client at
> the
> > pperry site was used.
>
> I haven't been able to do a straight Linux/Windows comparison, as I don't have
> any dual-booting PCs. I wonder if the disparity might account for the
> possibility that the E@H science application itself isn't optimized? Talking
> about the .../projects/einstein.phys.uwm.edu/einstein_4.80_i686-pc-linux-gnu
> file, not the BOINC client everyone has optimized.
The Einstein team has said that their application for linux isn't optimized.
And in BOINC it's the Windows client that has higher than should Benchmarks. The next BOINC Version 4.2x has corrected the benchmark code in Windows, and the values of Linux vs Windows should be closer. I'm now imagining the people with Windows complaining that their benchmarks are lower. And I hope that "optimized" Linux clients then will not have inflated benchmarks like windows now have ;-)
Professor Desty Nova
Researching Karma the Hard Way
> > > Would you of guessed
)
> > > Would you of guessed the Linux client completed in 9.5 hrs vs just
> 5.5
> > for
> > > Windows by relying on the benchmarks? FYI the optimized linux
> client at
> > the
> > > pperry site was used.
> >
> > I haven't been able to do a straight Linux/Windows comparison, as I don't
> have
> > any dual-booting PCs. I wonder if the disparity might account for the
> > possibility that the E@H science application itself isn't optimized?
> Talking
> > about the
> .../projects/einstein.phys.uwm.edu/einstein_4.80_i686-pc-linux-gnu
> > file, not the BOINC client everyone has optimized.
>
> The Einstein team has said that their application for linux isn't optimized.
Correction: we HAVE optimized. But in spite of our best efforts, gcc is not producing code that is efficient as the instruction stream emitted by the Microsoft Windows compiler. I wish it weren't true, but it is.
I hope that within the coming few days we can get back to this and try and find a better compiler or set of gcc flags for our app under Linux. We've done an awful lot of profiling and optimization work already, so we're surprised that the situation is not better. But it's clearly the case that on identical hardware our app runs significantly faster under Windows.
Bruce
Director, Einstein@Home
> Correction: we HAVE
)
> Correction: we HAVE optimized. But in spite of our best efforts, gcc is not
> producing code that is efficient as the instruction stream emitted by the
> Microsoft Windows compiler. I wish it weren't true, but it is.
Forgive me if I am stating the obvious but, if the Einstein app is anything like the Seti one, it makes extensive use of libraries. If those libraries have not been optimised, optimising the app will have little effect.
Just trying to help - ignore me if I am trying to teach my grandmother to suck eggs. ;)
Be lucky,
Neil
> > > Correction: we HAVE
)
>
> > Correction: we HAVE optimized. But in spite of our best efforts, gcc is
> not
> > producing code that is efficient as the instruction stream emitted by
> the
> > Microsoft Windows compiler. I wish it weren't true, but it is.
>
> Forgive me if I am stating the obvious but, if the Einstein app is anything
> like the Seti one, it makes extensive use of libraries. If those libraries
> have not been optimised, optimising the app will have little effect.
>
> Just trying to help - ignore me if I am trying to teach my grandmother to suck
> eggs. ;)
>
>
>
That's quite correct but people like me who are running Gentoo Linux have already compiled all the libraries at -O3 anyway ;). Maybe I should re-emerge glibc with those other -f's...
> That's quite correct but
)
> That's quite correct but people like me who are running Gentoo Linux have
> already compiled all the libraries at -O3 anyway ;). Maybe I should re-emerge
> glibc with those other -f's...
Gentoo here also. ;) A lot of Gentoo people are nervous about -O3 but I have two systems built from the start with -O3. One problem, though, is that Gentoo's emerge often overrides user-set compiler flags. :( I think it does with glibc and stdc++.
Be lucky,
Neil
> > That's quite correct but
)
> > That's quite correct but people like me who are running Gentoo Linux
> have
> > already compiled all the libraries at -O3 anyway ;). Maybe I should
> re-emerge
> > glibc with those other -f's...
>
> Gentoo here also. ;) A lot of Gentoo people are nervous about -O3 but I have
> two systems built from the start with -O3. One problem, though, is that
> Gentoo's emerge often overrides user-set compiler flags. :( I think it does
> with glibc and stdc++.
>
>
Yeah, it uses the recomendations that Linux From Scratch uses, so glibc/gcc and a couple of others overide the settings. I tried doing an emerge glibc and ctrl+z'ing out of it to edit the Makefile after it had configured but it came up with some inconsistancy error or something so I'm guessing it's very carefull and picky about the flags it gets. It's already being compiled with -O2 -march=athlon-xp anyway so there's not a whole lot extra I can do.
> > The Einstein team has
)
> > The Einstein team has said that their application for linux isn't
> optimized.
>
> Correction: we HAVE optimized. But in spite of our best efforts, gcc is not
> producing code that is efficient as the instruction stream emitted by the
> Microsoft Windows compiler. I wish it weren't true, but it is.
>
> Bruce
What I really wanted to say, was "it's optimized, but not as much as the windows application". Since english isn't my primary language, sometimes things like this pass ;-)
Professor Desty Nova
Researching Karma the Hard Way