BOINC-for-wine??
23 Jan 2006 17:16:13 UTC
Topic 190662
(moderation:
I know that E@H has tried to develop a version of einstein that will run fast under Linux. I appreciate that effort. But I suppose they are limited by compiler availability, & it seems that Linux compilers are still not as highly optimized for speed as Win compilers.
But I would like to ask here whether anyone has done any work on the problem from the opposite end. Has anyone tried to develop a version of BOINC that was specifically tuned to run smoothly & reliably on wine [wine under Linux]? If yes, where might I find that version? If no, does anyone know whether such wine-tuning would be feasible? Is it possible that there are BOINC developers who could do that?
I know that some versions of BOINC will run under wine & I have been doing that for many months. But the BOINCs I have gotten to run are sometimes erratic, & I have not gotten some of the newer versions to run at all under wine. I don't know, but I suspect that is merely because the developers (of the Windows versions of BOINC) did not have wine compatibility on their priority list at all.
Thanks for listening,
ADDMP
BOINC-for-wine??
)
Please don't be fooled by recent post indicating that. I'd like you to point
to this WU.
As you can see host 387863 a P4 CPU 2.80GHz running XP did the WU in 9,414.56 seconds. Host 229468 a
P4 CPU 2.80GHz too, but running Linux, did the WU in 8,877.12 seconds.
Took me some time to find two identical host :)
Michael
Team Linux Users Everywhere
ADDMP, Another person
)
ADDMP,
Another person noted that he'd found the new Linux app crunched faster than the current Win app on his rig, after he'd run out of re-install licenses on WinXP and switched to, if I recall correctly, Ubuntu.
Regards,
Michael
microcraft
"The arc of history is long, but it bends toward justice" - MLK
RE: RE: it seems that
)
Thanks for the reply.
I have done some testing of wine vs native linux on hardware that I happen to have installed myself. This consists of two older P4 socket 778s and three athlons of various speeds & types. On my hardware, the new native linux E@H came pretty close on the P4s (but did not quite reach the wine speed), but was still clearly slower on the Athlons. Enough slower that I decided to stay with wine, at least on the Athlons. I think it might be the case that the compiler that was used to improve the performance of the native Linux E@H was an Intel compiler. [Can anyone confirm the use of an Intel compiler??? If E@H was tuned using an Intel complier, then it would probably surprise no one that the speedup would be greater on Intel chips.]
So the answer as to how using the native Linux compiler compares to using wine depends on the hardware one happens to be using.
Anyway, I am still interested in whether there is any possibility of a BOINC version that is tuned to be stable when running wine. Has anyone already done that? Would anyone besides me use such a BOINC (if it existed) , or am I am voice crying in the wilderness?
ADDMP
RE: ADDMP, Another person
)
Thanks for your reply. But as I mentioned in my previous reply, I have done this comparison myself on my own hardware. I think the comparison is hardware dependent. And I think that Athlons come out on the short end. At least MY Athlons did.
If anyone has a head-to-head comparison of the two compilers on an athlon computer, please point me to that.
ADDMP
RE: RE: I know that E@H
)
hi Michael,
but that wu illustrates the *other* linux problem very well. The XP box claims 14 cobblestones for the work, the linux box 9 - that is around 2/3rds the credit very roughly.
The problem seem to be that the linux benchmakrs are less optimised than the windows one, so that a given number of seconds cpu time on linux is deemed to be less work than the same number on windoze.
Of course, to avoid cheating the degree of optimisation on benchmarks and on the app should be identical. That is an impossible goal in practice: the effect of optimisation varies a lot beteeen apps (some apps are slowed down more in a long pipeline than others, for example).
To the first degree this is fair as the averaging process sorts it all out.
In this example the win box pulls the average up - but in other cases (like where there are two linux boxes in the same wu) the average will be pulled down.
To the second degree of unfairness the unfairness remains - a linux box is more likely than a windoze box to find itself in a low scoring quorum.
The issue has not gone away, just been muted a little in my opinion.
River~~
~~gravywavy