Linux vs. Windows
10 Jun 2005 21:05:22 UTC
Topic 189324
(moderation:
Hi,
I added two computers to my E@H cluster early this month just to see if what I thought I was seeing is true. The machines are identical P4 boxes (2.6GHz, HT, 512MB) but one is running Windows 2000 and the other runs Linux 2.6.9-1.667smp. The Linux box is much slower than the windows box. Any ideas as to why??
Linux: Measured FP 355.07, Interger 644.78
Last 5 work units:
CPS claim grant
Over Success Done 114,603.87 66.31 72.75
Over Success Done 103,363.96 59.81 72.78
Over Success Done 115,757.43 66.98 67.71
Over Success Done 98,435.62 56.96 72.80
Over Success Done 101,199.79 58.56 69.06
Win2K: Measured FP 1071.13, Interger 959.95
Last 5 work units:
CPS claim grant
Over Success Done 48,109.14 56.55 pending
Over Success Done 47,934.58 56.34 74.90
Over Success Done 48,194.14 56.65 72.88
Over Success Done 48,134.44 56.58 72.70
Over Success Done 47,992.80 56.41 75.54
Thanks,
Pat
Linux vs. Windows
)
There are loads of messages of this problem in these forums.
Just write "linux" in search. ;)
As I understand it Einstein-app isn't compiled as good as the windows-app.
Some guys/gals running the windows version under wine in linux with
better performance.
As I understand it
)
As I understand it Einstein-app isn't compiled as good as the windows-app.
Change to: As I understand it, gcc does not create so good floating point instructions as the Microsoft compiler.
Why can't they compile it
)
Why can't they compile it under Linux with the Microsoft compiler? There's a Linux version, right?
RE: As I understand it
)
Well that's the one point. Intel's compiler do much better. But look into older threads. Thers another reason. Linux does more accurate computation, which in turn takes longer to compute.
RE: RE: As I understand
)
No! I tried. No measurable difference with traditional floating point. And that is needed because of a lot of old CPUs hanging around.
RE: Why can't they compile
)
Is there? Can you point me to it? I don't know nothing about it (yet)...
BM
BM
RE: RE: Why can't they
)
Microsoft suport Linux. Not going to happen. Linux is the biggest threat that Microsoft is currently facing. Linux is being developed and deployed on everything from home computers to supercomputers.
License cost is 0, support costs are roughly equivelent to Windows, and the source is available so that it can be examined if needed to solve a problem with the system.
Long term support costs is a huge battleground right now with studies supporting one side or the other in the marketing wars ...
There was a marvelous letter from a minister for a south american country where he debated Microsofts value proposition and diced them up pretty badly ... I wish I could find my copy again ... it was so sweet ... maybe someone else will remember the link ...
{edit}
here and here
RE: RE: RE: Why can't
)
Well, I don't really expect this to be officially supported, but there is a small possibility that someone internal from MS has successfully tried this and it may have slipped out of the labs...
But I think the most likely explanation is that capobian just confused Intel's and Microsoft's compilers.
BM
BM
RE: Well, I don't really
)
Today I found out that M$ seems to cheat.
Look at this small example:
double foo(double a, double b, double c) {
return a + a * b + a * c + b + b * c + c;
}
And this is the corresponding assembler output from Microsoft compiled with /O2 (I think I used version 6.x), the comments are mine ...
fld QWORD PTR _c$[esp-4]
; load c into st(0)
fld QWORD PTR _b$[esp-4]
; load b into st(0); c is in st(1)
fadd ST(0), ST(1)
; add b+c; c still in st(1)
; do you see? In the original code there is no a+b
fmul QWORD PTR _a$[esp-4]
; multiply (b+c) with a; c still in st(1)
; Hey! So they change the term a*b + a*c to a*(b+c).
; This is mathematically correct when you have an infinite
; precision, but may lead to problems otherwise.
fld QWORD PTR _b$[esp-4]
; load b into st(0); (b+c)*a is in st(1); c in st(2)
fmul ST(0), ST(2)
; multiply b with c; (b+c)*a is in st(1); c in st(2)
faddp ST(1), ST(0)
; add b*c to (b+c)*a; c is in st(1)
fadd QWORD PTR _a$[esp-4]
; add a to it ...
fadd QWORD PTR _b$[esp-4]
; add b to it ...
faddp ST(1), ST(0)
; finally add c to it.
So, the original statement
a + a * b + a * c + b + b * c + c
was transformed to
(b + c)*a + b*c + a + b + c
And depending on the value this may lead to very different results.
Bernd, what options do you use with the M$ compiler?
RE: RE: RE: As I
)
Hallo Wurgl !
I keep peeking into the Linux/Windows and 64 bit threads, but haven't seen a conclusive explanation of why the Einstein version for Linux (EfL) should be so much worse than the Einstein version for Windows (EfW).
I'm still dreaming that if a reason could be named, the problem would be (almost) solved.
Like many others Linux users, I have boxed EfW into Wine, and run BOINC 4.19. With the nice benefit - so I read - of unduly high credits claims.
This setup is fine, as long as BOINC 4.19 is available or tolerated. I've tried to install higher BOINC versions for Windows - without success. The installation cannot take place in an environment where IExplorer isn't available. Installing IExplorer is not a thing I am going to impose on myself ...
A few days ago, I installed the new Debian AMD64 release on my system, and run now E@H in a chroot-ed ia32/ix386 environment. Which brings up the recurring question : 64-bit Einstein - when, or why not ?
I keep asking ...
-rg-