Yes, Linux is surely the way to go if validation is OK, its crunching a little faster i think, Boinc in Linux seem to show less processing time used compared to how long it really takes but still an improvement over Windows.
Matt_lo, I tested some flash games using Firefox, no problems when boinc is running. Btw, a really good flash-game: http://mirror2.cgdc3.fizzlebot.com/?gameID=2
Gimme friction baby.
I just attached my Linux box to Einstein and the first wu to arrive looks like it will take a lot longer on it then on either of my Windows boxes that run E@H. Yet others say it runs faster, ah the vagaries of life.
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.
I just attached my Linux box to Einstein and the first wu to arrive looks like it will take a lot longer on it then on either of my Windows boxes that run E@H. Yet others say it runs faster, ah the vagaries of life.
If it's a brand new BOINC installation, then it will take some time to "calibrate" the runtime estimation mechanism to your PC. Basically BOINC has two sources to estimate runtime : the benchmarks it runs periodically on your PC and actual crunching performance. BOINC will gradually correct the performance estimation from the benchmark as it crunches along and sees how fast your PC really is.
I just attached my Linux box to Einstein and the first wu to arrive looks like it will take a lot longer on it then on either of my Windows boxes that run E@H. Yet others say it runs faster, ah the vagaries of life.
Your computers aren't using the same data packs either, though the differences are small: 0514.05, 0516.05 and 0504.05.
You are a long time participant so I know you know all about DCF, data pack frequencies and their relationship to runtime.
Yes, I've been around for ages. The Linux box has been running with SIMAP, Rosetta, MCDN and Tanpaku for about 6 weeks, but it was today it got itøs first Einstein wu.
The original estimate was way out of course, I was basing my run time estimate on % complete against elapsed time so far, which indicated, if reasonably linear a 50+ hour run time.
The Linux stuff is all new to me. I started with it 1st July with the Linux PC as a workstation for developing embedded Linux stuff. Figured it should do something useful while I wonder what the embedded systems latest error message means!
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.
Yes, Linux is surely the way to go if validation is OK, its crunching a little faster i think, Boinc in Linux seem to show less processing time used compared to how long it really takes but still an improvement over Windows.
Is there really evidence at this time that it is worth switching from WIN to LINUX to get faster running of E@H?
I recall some of the early remarks by akos that the code generated by Gnu C was not very amenable to speed-up by the methods he used.
Then later I read that a team effort was being made to get the Linux speed up to the WIN speed.
But where does this competition stand now? Does one OS consistently beat the other as far as E@H is concerned? (I am interested in Intel Core 2 processors if that affects the answer.]
I recall some of the early remarks by akos that the code generated by Gnu C was not very amenable to speed-up by the methods he used.
The problem was only with Akos's attempts to hack the exe and insert new code into the binary. Once he was an official part of the team and could have is tweaked asm embedded into the c++ source it became a moot point and all x86 platforms were eligable for the speedup.
But where does this competition stand now? Does one OS consistently beat the other as far as E@H is concerned? (I am interested in Intel Core 2 processors if that affects the answer
Dont think theres any proof about one being faster than the other, Linux seem to report fewer seconds of CPU time used, thats all there is to it maybe. Hard for me to compare since i didnt go directly from WinXp to Linux, the little stop-over in VMware kind of destroyed my baseline for comparing.
Is there really evidence at this time that it is worth switching from WIN to LINUX to get faster running of E@H?
...
But where does this competition stand now? Does one OS consistently beat the other as far as E@H is concerned? (I am interested in Intel Core 2 processors if that affects the answer.]
ADDMP.
I think Linux and Windows apps show roughly comparable performance now, which is the goal to achieve after all. I would not recommend switching OS just for E@H if you are otherwise happy with your installation. The question that started this thread was if it still makes sense to run E@H in a virtual Windows PC on a Linux host (to avoid cross platform validation problems) and the answer to that is no: you can safely switch to native Linux clients now. Whether Linux or Win apps are a bit faster may actually depend on the CPU. But if you look at the list of top computers for E@H, you can see that both Windows and Linux have entries there.
The one platform that seems to be a bit faster than others is Intel on Macs (OSX/Darwin), but that's probably because the compiler can optimize the code more aggressively: OSX on Intel is relatively young, you don't have to support any CPU prior to Core Solo, so you can optimize exclusively for Core's and Core 2s. For example the compiler has a free choice from the x87,SSE, SSE2 and SSE3 instruction sets for floating point number processing.
" Linux seem to report fewer seconds of CPU time used, thats all there is to it maybe."
The most obvious method of comparing two computers or two OSes is to look at the "stones" awarded vs the seconds reported & calculate "stones"/day per cpu.
But are you saying here that you just don't trust the cpu seconds reported for a work unit by WIN vs LINUX?
If the cpu seconds cannot be trusted, what would you think of getting the wall clock time at some very low %completion & another wallclock time at some high %completion for a computer doing nothing but E@H? One could then calculate the stones awarded divided by the wall clock time corrected to 100% completion.
Yes, Linux is surely the way
)
Yes, Linux is surely the way to go if validation is OK, its crunching a little faster i think, Boinc in Linux seem to show less processing time used compared to how long it really takes but still an improvement over Windows.
Matt_lo, I tested some flash games using Firefox, no problems when boinc is running. Btw, a really good flash-game: http://mirror2.cgdc3.fizzlebot.com/?gameID=2
Gimme friction baby.
Team Philippines
I just attached my Linux box
)
I just attached my Linux box to Einstein and the first wu to arrive looks like it will take a lot longer on it then on either of my Windows boxes that run E@H. Yet others say it runs faster, ah the vagaries of life.
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.
RE: I just attached my
)
If it's a brand new BOINC installation, then it will take some time to "calibrate" the runtime estimation mechanism to your PC. Basically BOINC has two sources to estimate runtime : the benchmarks it runs periodically on your PC and actual crunching performance. BOINC will gradually correct the performance estimation from the benchmark as it crunches along and sees how fast your PC really is.
CU
BRM
RE: I just attached my
)
Your computers aren't using the same data packs either, though the differences are small: 0514.05, 0516.05 and 0504.05.
You are a long time participant so I know you know all about DCF, data pack frequencies and their relationship to runtime.
Yes, I've been around for
)
Yes, I've been around for ages. The Linux box has been running with SIMAP, Rosetta, MCDN and Tanpaku for about 6 weeks, but it was today it got itøs first Einstein wu.
The original estimate was way out of course, I was basing my run time estimate on % complete against elapsed time so far, which indicated, if reasonably linear a 50+ hour run time.
The Linux stuff is all new to me. I started with it 1st July with the Linux PC as a workstation for developing embedded Linux stuff. Figured it should do something useful while I wonder what the embedded systems latest error message means!
Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.
RE: Yes, Linux is surely
)
RE: I recall some of the
)
The problem was only with Akos's attempts to hack the exe and insert new code into the binary. Once he was an official part of the team and could have is tweaked asm embedded into the c++ source it became a moot point and all x86 platforms were eligable for the speedup.
RE: But where does this
)
Dont think theres any proof about one being faster than the other, Linux seem to report fewer seconds of CPU time used, thats all there is to it maybe. Hard for me to compare since i didnt go directly from WinXp to Linux, the little stop-over in VMware kind of destroyed my baseline for comparing.
Team Philippines
RE: Is there really
)
I think Linux and Windows apps show roughly comparable performance now, which is the goal to achieve after all. I would not recommend switching OS just for E@H if you are otherwise happy with your installation. The question that started this thread was if it still makes sense to run E@H in a virtual Windows PC on a Linux host (to avoid cross platform validation problems) and the answer to that is no: you can safely switch to native Linux clients now. Whether Linux or Win apps are a bit faster may actually depend on the CPU. But if you look at the list of top computers for E@H, you can see that both Windows and Linux have entries there.
The one platform that seems to be a bit faster than others is Intel on Macs (OSX/Darwin), but that's probably because the compiler can optimize the code more aggressively: OSX on Intel is relatively young, you don't have to support any CPU prior to Core Solo, so you can optimize exclusively for Core's and Core 2s. For example the compiler has a free choice from the x87,SSE, SSE2 and SSE3 instruction sets for floating point number processing.
CU
BRM
Thanks to all who replied
)
Thanks to all who replied here
ted3 wrote: