Without intending to open Pandora's Floodgate of Worms, has it been found that any operating system will number crunch BOINC any faster than any other?

Or does it just come down to your L2, core speed, etc?

---

Hi

I've got a few Thinkpad A30P machines crunching (Intel Mobile Pentium III 1200Mhz), the Fedora Core 3 Linux ones crunch at about 20% less efficiency then the Win XP Pro SP2 ones...I was quite surprised by this but the stats seem clear.

I suspect that the other main influencing factors though are the Processor itself and then the amount of onboard L2 cache (I've also got a 1.8Ghz Pentium M with 2mb L2 Cache that cranks substantially faster then a 3Ghz P4 HT with 512k L2 Cache both running XP Pro SP2).

Having a reasonable database of machines it seems to me that as SETI is primarily a cruching app memory effeciency is at least equal if not more important then processor speed and therefore the AMD Athlon 64 processors are pretty efficient as they address memory better.

Just my 2c...I'd welcome other peoples opinions.

P

---

It's not the days in your life...it's the life in your days!!

> Without intending to open Pandora's Floodgate of Worms, has it been found that
> any operating system will number crunch BOINC any faster than any other?
>
> Or does it just come down to your L2, core speed, etc?

> Without intending to open Pandora's Floodgate of Worms, has it been found that
> any operating system will number crunch BOINC any faster than any other?
>
> Or does it just come down to your L2, core speed, etc?

At the moment I am running all Win XP-SP2 and there are some conclusions that I would make based on my experience. You can see some of the numbers that make this up on my web site.

The machine architecture is important - my 5 Windows machines are running "Notrhwood" and "Prescott" cores. Taking the numbers I have collected I get slower processing times on the 3.0 GHz processors than on the 2.8 GHz processor though looking only at the Clock speed indicates that the opposite should be true. But the 2.8 GHz processor only runs 1 WU at a time when the 3.0 GHz processor runs two. So, speed is slower, throughput is higher.

The 3.2 GHz processors are even more interesting in that they have a different core ("Preescott") than the 3.0 and 2.8 GHz processors (these are "Northwood"), in that the current numbers seem to indicate that the 3.2 GHz processors are actually only slightly faster in SETI@Home than the 3.0 GHz processors.

This was because when I got the 3.2 GHz processors I could not afford two good MB, so I put one in a MB that was the "blue-light-special" and one in a good MB. My processing time for SETI@Home for these two processors was 03:46:22 where the 3.0 GHz processors have 03:49:46 average processing time.

Yet, looking at the numbers when both 3.2 GHz processors are in good MB shows a better time of 02:53:31. WHen you look at the speed differential this is a significant change, but the real reason that the time is so much better is because he cache on the 3.2 GHz processors is 1M, where it is only 512K in the 3.0 GHz processors.

So, this one test shows that Cache size is important and memory bandwidth is just about as important. When my new computer gets here, I will be able to see what increasing the Cache to 2M will do ... It is not going to be a complete "side by side" as the processors are Xeons, a higher clock speed, and a larger cache. Anyway ...

Take a look at the numbers on that page and you can see my processing times for various applications on the machines and even the number of results that comprise the data set. I have been updating it on a weekly basis so you will see about 150-200 additional results each week ...

Oh, and the best OS is obviously OS-X running on a 2.0 GHz dual G5 ... :)

[edit]
I am working on that page and trying to derive examples from the numbers so that you can try to see how I derived my conclusions. Not sure when it will be posted ...

---

> Without intending to open Pandora's Floodgate of Worms, has it been found that
> any operating system will number crunch BOINC any faster than any other?
>
> Or does it just come down to your L2, core speed, etc?
>
>
Back at Classic, and I believe it should also be true here at SetiBoinc, the Win9xes including Me crunch perhaps eight to ten percent more slowly than Win 2000 or Win Xp. It has to do with the NT core, which, I believe, crunches Seti more efficiently. Linux should do well, too. The only reason Linux did not do well at Classic was the cruncher designed for use with Linux, not Linux itself. This was remedied by using an adaptation program called Wine that allowed Linux to use the Windows cruncher. It is possible that all, some or none of the above is true with other distributed computing projects run with Boinc.

---

> Back at Classic, and I believe it should also be true here at SetiBoinc, the
> Win9xes including Me crunch perhaps eight to ten percent more slowly than Win
> 2000 or Win Xp. It has to do with the NT core, which, I believe, crunches Seti
> more efficiently. Linux should do well, too. The only reason Linux did not do
> well at Classic was the cruncher designed for use with Linux, not Linux
> itself. This was remedied by using an adaptation program called Wine that
> allowed Linux to use the Windows cruncher. It is possible that all, some or
> none of the above is true with other distributed computing projects run with
> Boinc.

It is the same code actually, but different compilers. For Windows the compiler is the the Microsoft standard, and for the Linuc it is bcc (I think).

There is a whole group working with the compilers and the SETI@Home code and when they get done we should have much more effective code because it will be compiled with the most effective compiler "switches" for a given processor, and will also use the most efficient instructions to do the work. For example, the G5 processors have a high performance vector unit (Altivec) and that is not being used at the current time (Even so, my SETI@Home times on the G5 are pretty darn nice).

For this Ned Slider (If memory serves) is the guy to look for ... here is another place to look for Linux stuff http://www.pperry.f2s.com/.

---

gcc is the compiler.

---

>
> For this Ned Slider (If memory serves) is the guy to look for ... here is
> another place to look for Linux stuff <a> href="http://www.pperry.f2s.com/">http://www.pperry.f2s.com/[/url].
>

Hi Paul /waves/

LOL - Thanks for the plug!

I must admit, I'm sorely tempted by Apple's georgous iMac G5 :-)

To answer the question in hand - for most people, if your building machines purely to crunch, I'd recommend sticking with the OS which you are familiar. WinNT2K/XP is probably faster out of the box, but Linux just about has the edge if you compile your own optimized seti app from source (not for beginners). Overall, there's really nothing in it.

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

If you're going to dedicate a box, I'd recommend against the Mac Mini.

[Gasps from the Mac Addicts upon reading the heretical statement]

Apple's hardware is quirky - very quirky, actually - and is very difficult to support if you're not Apple. Even Apple's "Sanctioned" Yellow Dog Linux isn't able to keep up with the nooks and crannies of the hardware (Just ask anyone whose Mac won't sleep or beep).

If you want a really good reason, it's because the best and most effective part of the G4 and G5 (it's AltiVec unit) is not taken advantage of during the execution of SETI. This may be because gcc isn't SIMD savvy, but it does put a crimp in the performance.

And even if you did get a Mac - Any Mac - you'd either have to learn OS X (Which is pretty easy, but leaves you relatively powerless) or learn Linux (Which is a steep learning curve, but provides the right kind of power). Linux isn't easy, and that goes doubly so on a PPC box.

So I'd recommend that if you're already into x86, stay there. Get a decent mobo, a sizeable cache (a low CPU:FSB ratio if you can't), two sticks of 256MB, an 8gB HD, a copy of W98, and relax. You'll have saved around $50 and an additional $50 in aspirin from the headaches you would have had.<p align="center">Follow-ups set to FotD2</p>

---

> If you're going to dedicate a box, I'd recommend against the Mac Mini.
>
> [Gasps from the Mac Addicts upon reading the heretical statement]
>
> Apple's hardware is quirky - very quirky, actually - and is very difficult to
> support if you're not Apple. Even Apple's "Sanctioned" Yellow Dog Linux isn't
> able to keep up with the nooks and crannies of the hardware (Just ask anyone
> whose Mac won't sleep or beep).
>
> If you want a really good reason, it's because the best and most
> effective part of the G4 and G5 (it's AltiVec unit) is not taken advantage of
> during the execution of SETI. This may be because gcc isn't SIMD savvy, but
> it does put a crimp in the performance.
>
> And even if you did get a Mac - Any Mac - you'd either have to learn OS
> X (Which is pretty easy, but leaves you relatively powerless) or learn Linux
> (Which is a steep learning curve, but provides the right kind of power).
> Linux isn't easy, and that goes doubly so on a PPC box.
>
> So I'd recommend that if you're already into x86, stay there. Get a decent
> mobo, a sizeable cache (a low CPU:FSB ratio if you can't), two sticks of
> 256MB, an 8gB HD, a copy of W98, and relax. You'll have saved around $50 and
> an additional $50 in aspirin from the headaches you would have had.<p> align="center"><a> href="http://setiweb.ssl.berkeley.edu/forum_reply.php?thread=12118&post=93622#input">Follow-ups
> set to FotD2[/url]</p>
>

Ok, this answers a question I had, actualy. I was always under the impression that my G5 would out strip my aging Athlon XP 2000. Are there any plans to have the altivec unit used in boinc on OSX in the future? I mean, I got nearly double the score with my Athlon box.

What also is sad is that my 900mhz G3 ibook, which is over a year and a half old, gets only 300 points less on the Floating Point benchmark than this spiffy new iMac with a g5 in it.

I will note though, that the BOINC score for INT was higher on the imac than my Athlon, by about 200 points.

One more thing... I've noticed a drop in performance on the Athlon machine since moving from SP1 to SP2 of XP. Odd, no?

---

Meddle not in the affairs of dragons, for you are crunchy and good with ketchup!

I was always under the impression that my G5 would out strip my aging Athlon XP 2000.
It will, given the right condition(s).

Are there any plans to have the altivec unit used in boinc on OSX in the future? I mean, I got nearly double the score with my Athlon box.
Off the top of my head (or from out of my behind, depending on your POV), it's easier to develop for a standardized platform where all functions, procedures, etc., will be supported. This simplicity for the devs means that the hardware-specific calls and routines that could speed up for one platform have to be sacrificed for the greater good of cross-platform operability.

I'm sure that there's an AltiVec-ified version out there...

What also is sad is that my 900mhz G3 ibook, which is over a year and a half old, gets only 300 points less on the Floating Point benchmark than this spiffy new iMac with a g5 in it.
According to your CPU stats, your iBook is faster than my 867MHz TiBook! [scratches head, shrugs shoulders] Dunno what to say.

---

> I mean, I got nearly double the score with my Athlon box.

Are you refering to the benchmarks?
If so, they're not a good reference for actual crunching times. According to the benchmarks even the slower P4s should beat the higher end Athlons by a significant margin, the reverse is actually the case.

---

Grant
Darwin NT

Does anyone know if there are any plans to compile BOINC & SETI Client
for WIN XP 64-Bit Edition, to make full use out of the 64-Bit CPU's such
as the Opterons and the new P4's with EMT64? I would be anxious to test
AMD's claim that the Opterons can run 32-Bit and 64-Bit applications
simultaneously without taking a performance hit, so I should be able to run
a 32-Bit SETI WU and a 64-Bit SETI WU on EACH CPU, in the same time it
currently takes to run ONE WU. This would, at least theoretically, double
the thruput of my Opteron and FX53 machines...

Regards, Daniel.

---

> Hi Paul /waves/

Hi ... Waves back ...

> LOL - Thanks for the plug!

You are welcome ... I am just waiting for you optimization guys to get it all in one sack ... :)

> I must admit, I'm sorely tempted by Apple's georgous iMac G5 :-)

I am waiting to see if Apple announces today (as some expect) new G5 ... runors are it is going to be a dual-dual core machine based on the IBM G5 (just to pass along the confusion the IBM G4 is Apples G5 and if the new CPU is based on IBM's G5 it will probably be called the G6 by Apple).

All I know is that the G5 returns the fastest results in almost all cases. I have a new computer on order and I will be seeing if that can beat the processing times of the G5 or not (Xeon 3.4, 2M cache), it will likely be more productive, but slower in processing times.


> To answer the question in hand - for most people, if your building machines
> purely to crunch, I'd recommend sticking with the OS which you are familiar.
> WinNT2K/XP is probably faster out of the box, but Linux just about has the
> edge if you compile your own optimized seti app from source (not for
> beginners). Overall, there's really nothing in it.

I agree. There are also people that are reporting that overall, and at this time, WIndows has the edge. I don't think that is going to be the case when the optimization team starts to move their work into the common code baselines. And when that happens we should see AMD optimized clients that use the AMD instruction extensions for the AMD chips, and Intel extensions for their chips, and maybe the Altevic for the Apples.

---

> I am waiting to see if Apple announces today (as some expect) new G5 ...
> runors are it is going to be a dual-dual core machine based on the IBM G5
> (just to pass along the confusion the IBM G4 is Apples G5 and if the new CPU
> is based on IBM's G5 it will probably be called the G6 by Apple).

Small correction to this. The G5 is a subset of the IBM Power5 super processor. IBM's newest Processor breakthrough is the Cell, but there are no announced plans by Apple to utilize this technology as of yet in their CPU cores.

---

Meddle not in the affairs of dragons, for you are crunchy and good with ketchup!

> I am waiting to see if Apple announces today (as some expect) new G5 ...
> runors are it is going to be a dual-dual core machine based on the IBM G5
> (just to pass along the confusion the IBM G4 is Apples G5 and if the new CPU
> is based on IBM's G5 it will probably be called the G6 by Apple).

Sounds like a beautiful piece of hardware. (Perhaps it is about time to replace my Quadra 650...) I just wouldn't put much faith in *any* product anouncements or technical specs released today. You never know when somebody's trying to have some fun on April Fool's. :)

---

Here my 2c:

Hardware:
High Memory bandwith, Large cache and as much Clockspeed as you can afford... ;-)

OS:
Whatever you like..
If you want top performance you need to recompile the seti client for your own machine. To do that, my favorite solution is to run Linux and use GCC to compile the sources.

Is a self compiled Linux Seti client really faster than the original Windows Seti client?

After some tests and a good base for comparsion I can say that my average completion times are 10% faster on Linux than they used to be on Windows.
I am currently running clients on an Athlon 64 and a Pentium-M both show the above mentioned improvements...

Chris

---

Chris Bosshard
Visit my homepage
astroinfo SETI page

(Perhaps it is about time to replace my Quadra 650...
It has a full-fledged 68040, and therefore can run a Linux or A/UX, which in turn means that it can run SETI (given enough RAM, of course).

I'm about to try for SETI's slowest cruncher with a IIcx...

---

Just a thought:

The boinc client isn't what's actualy running the process, right?
It downloads a client for each project process and runs that under it.

For example on a Windows machine, look at the running processes. One of em should be 'setiathome_4.09_windows_intelx86.exe' while on the Mac you get 'setiathome_4.02_darwin_ppc' as the client.

Which begs to me the question: Why the Power PC, /made/ for mac OSX, which at the very lowest runs on a G3, and the majority of which runs on G4 and higher with the AltiVec Engine... doesn't use that AltiVec engine for floating point to gain the power increase it affords?

It's just my train of thought. Who knows, the next version of the OSX client might have been coded for the AltiVec.

---

Meddle not in the affairs of dragons, for you are crunchy and good with ketchup!

Which begs to me the question: Why the Power PC... doesn't use that AltiVec engine for floating point to gain the power increase it affords?
AltiVec is G4 and G5... the G3 and PPC60x wouldn't be able to take advantage of it, let alone run it.

I think the real reason is for cross-platform portability. In order to keep the code runnable on as many machines as possible, you have to code in a very hardware-independent and restricted way. Therefore, you can't make calls to hardware that might not exist.

Heaven forbid a PowerPC's vector unit should be considered an unfair advantage over HyperThreading and the like...

---

> Which begs to me the question: Why the Power PC... doesn't use that AltiVec
> engine for floating point to gain the power increase it affords?
> AltiVec is G4 and G5... the G3 and PPC60x wouldn't be able to take advantage
> of it, let alone run it.

You have to pick a point and then build systems for that. Because of limits on resources, the development team picked OS-X v10.3 as the minimum (or was it 10.2? whatever). To do OS-9, for example would drain resources for potentially little gain. Later, assuming enough demand, someone may make a prot to other platforms. But reality today is that it is mostly a Windows world (and I will not begin to descripe all the ways that holds us back ...) and this is where the largest potential group of host computers resides ...

SETI@Home Classic was available on a wide variety of platforms, most of which were only a small contribution to the science. If you look you will see that after a few repititions of x86 class machines and some Macintosh versions, that the rest of the contributions for all the remaining platforms is, um, not that significant.

> I think the real reason is for cross-platform portability. In order to keep
> the code runnable on as many machines as possible, you have to code in a very
> hardware-independent and restricted way. Therefore, you can't make calls to
> hardware that might not exist.

There is a team working right now on adding optimizations to the Science Application. One of the things being looked at is the use of the extensions to the instruction set and how that might benefit the speed of the applications. This is a complex and tricky task as the increases in speed cannot be allowed to compromise the accuracy of the analysis.

> Heaven forbid a PowerPC's vector unit should be considered an unfair advantage
> over HyperThreading and the like...

This has nothing to do with what is going on. One of the many issues with a vector processing unit is that most of these hardware accellerators sacrafice accuracy and precision for speed. For most of the operations this is an acceptable trade-off that does not alter the outcome.

For example the early Cray computers were very, very fast ... in some there was no divide operation, and in most of the ones that did have one it was an approximation ... but in many models "slide-rule" accuracy is close enough (3 digits of precision) to make the models acceptable.

In LHC@Home this type of accuracy is totally un-acceptable. The models are unstable by their very nature, and accuracy and stability are so necessary that they are restricted to a specific compiler and only two of the 4 current BOINC Platforms. Even now, they are in down-time working on making the models more accurate and attempting to eliminate more sources of problems.

---