What's more important to faster SETI processing times? Floating point, or Integer ops? TIA!

Message boards : Number crunching : What's more important to faster SETI processing times? Floating point, or Integer ops? TIA!
Message board moderation

To post messages, you must log in.

1 · 2 · Next

AuthorMessage
Profile AlecStaar
Avatar

Send message
Joined: 16 Dec 05
Posts: 260
Credit: 44,472
RAC: 0
United States
Message 220643 - Posted: 24 Dec 2005, 1:13:24 UTC

Read the subject, thanks for the answer in advance.

My bet's with floating point, because I'd guess the nature of the data being processed is best done via that route (floating point calcs vs. integer ones).

The reason I'm asking is simple - based on the benchmark SETI's BoincMgr.exe performs!

With one build of the boinc.exe done in MSVC++ here by Trux, I can pull off these numbers from that benchmark:

Measured floating point speed 1202.20 million ops/sec
Measured integer speed 3142.24 million ops/sec

With another build of boinc.exe done in Intel C++ 9.0 with IPP 4.1 libs optimization for SSE/2 instructions on a Pentium 4 3.2ghz CPU, I can pull off these numbers:

Measured floating point speed 2193.16 million ops/sec
Measured integer speed 2279.04 million ops/sec

* Thus, my quest for the answer to my question is required, if I am going to stick by the boinc.exe build that yields me the most performance, by your guys' answering me if Floating point or Integer calcs are most important to the speed of dataprocessing by this project.

Thanks.

APK
http://torry.net/authorsmore.php?id=1781

"The object's hull is made of SOLID neutronium: A single StarShip cannot combat it!" quote Mr. Spock, Star Trek original series, episode title: "The Doomsday Machine"
ID: 220643 · Report as offensive
Profile Landroval

Send message
Joined: 7 Oct 01
Posts: 188
Credit: 2,098,881
RAC: 1
United States
Message 220645 - Posted: 24 Dec 2005, 1:19:18 UTC - in response to Message 220643.  

My bet's with floating point, because I'd guess the nature of the data being processed is best done via that route (floating point calcs vs. integer ones).


Benchmarked CPU speed bears only a tangential relationship with time to crunch. In part this is because making a benchmark that accurately predicts performance is much more difficult than it sounds, in part because there are a lot of things (L2 cache being the biggest) that affect crunch times that aren't measured by the benchmarks.

The best way to accurately determine which version produces faster crunch times on YOUR hardware is to crunch a few units under each and compare.

Cheers,
Brian
If you think education is expensive, try ignorance.
ID: 220645 · Report as offensive
Profile trux
Volunteer tester
Avatar

Send message
Joined: 6 Feb 01
Posts: 344
Credit: 1,127,051
RAC: 0
Czech Republic
Message 220655 - Posted: 24 Dec 2005, 1:59:59 UTC
Last modified: 24 Dec 2005, 2:01:23 UTC

Neither the BOINC client nor the benchmark has any impact on the speed of crunching. Only the project application has. The benchmark merely influences the claimed credit (but it has no direct impact on the granted credit) and the overall benchmark is a combination of both fpops and iops. You best run benchmarks after replacing the boinc.exe file to see how the claimed credits change. On most CPU's the binary compiled with MSVC (it means with high iops) will return better overal benchmark than the one compiled with Intel ICC.
trux
BOINC software
Freediving Team
Czech Republic
ID: 220655 · Report as offensive
Profile Tern
Volunteer tester
Avatar

Send message
Joined: 4 Dec 03
Posts: 1122
Credit: 13,376,822
RAC: 44
United States
Message 220657 - Posted: 24 Dec 2005, 2:05:32 UTC

The two client's benchmarks, once integer and floating point are added together, are 4344.44 and 4472.20... not enough difference to matter, so you can pick whichever you like better for _other_ reasons. A "cobblestone" measures _both_ values, so for credit purposes, they're just added together.

What the app _really_ does, is irrelevant to the credits. SETI is heavy on floating point, PrimeGrid is heavy on integer, and the benchmarks are equally "wrong" for both.
ID: 220657 · Report as offensive
TPR_Mojo
Volunteer tester

Send message
Joined: 18 Apr 00
Posts: 323
Credit: 7,001,052
RAC: 0
United Kingdom
Message 220688 - Posted: 24 Dec 2005, 3:10:37 UTC

benchmarks, benchmarks, benchmarks....

This particular weeping wound in BOINC should really have been sorted before the "exodus" of classic users.

In a nutshell, ignore them. They are wildly wrong and so easily forged that it's not true. You can take one set of hardware, install Wondoze, benchmark, record int and float performance, wipe disk, load Linux, re-benchmark, and watch in amazement as your benchmarks drop by 33% or even more depending on hardware and Linux distribution.

The above is not to support my long-running whinge about benchmarks, but just to emphasize how utterly meaningless they are.

Anyway I digress. Statistically they are equal, each having much the same effect on cobblestones claimed. But as on most projects you are granted median values, they don't matter much. At all. So take the one you fancy :)
ID: 220688 · Report as offensive
Jesse Viviano

Send message
Joined: 27 Feb 00
Posts: 100
Credit: 3,949,583
RAC: 0
United States
Message 220699 - Posted: 24 Dec 2005, 3:29:24 UTC

One big thing that the benchmarks ignore is the memory speed. My old laptop that I crunch on almost always returns the highest claimed credit per result on each work unit. Compared to the desktop machines being built today, my computer's processor speed far outstrips the available memory throughput. It has an 800MHz Pentium III, and its memory and front side buses run at 100MHz, or 800MB/s. The desktop machines being built today have a much lower processor performance to memory performance ratio. The Whetstone benchmarks and the Dhrystone benchmarks probably fit into the on-CPU cache when being run, so they do not reflect the slow memory speed on my laptop. This causes the claimed credit to be higher than what it should be for each result I turn in. I would recommend that a memory speed test be added to the suite of benchmarks used by BOINC.
ID: 220699 · Report as offensive
Profile Landroval

Send message
Joined: 7 Oct 01
Posts: 188
Credit: 2,098,881
RAC: 1
United States
Message 220702 - Posted: 24 Dec 2005, 3:34:25 UTC - in response to Message 220699.  

I would recommend that a memory speed test be added to the suite of benchmarks used by BOINC.

Or better yet, ditch them altogether and replace them with something like, say, a count of how many operations are actually being done. (This is the plan for the _enhanced client, I understand.)

Benchmarking has a long and sordid history, and the main lesson to take away from it is that if one machine has a higher benchmark than another, all it really tells you is that it runs the benchmark suite faster. The relation between Whetstone/Dhrystone scores and actual in-the-field performance is whimsical, at best. The only way to reliably estimate how long a particular hardware/OS will take to crunch a work unit is to see how long it's taken to crunch similar workunits in the past.

If you think education is expensive, try ignorance.
ID: 220702 · Report as offensive
Profile Pappa
Volunteer tester
Avatar

Send message
Joined: 9 Jan 00
Posts: 2562
Credit: 12,301,681
RAC: 0
United States
Message 220724 - Posted: 24 Dec 2005, 4:49:12 UTC
Last modified: 24 Dec 2005, 4:51:32 UTC

Evening Everyone

Even the New Program it is not perfect!

Example:
this work unit

or

this work unit

Please take a moment to go look and guess/explain what is not working with the Enhanced Beta, to help level the playing field...

I do have to admit that as far as Einstein goes I have not really lost any significant "claimed credit." Seti on the other hand with the 5.2.x and the Fpops...Still has a ways to go... So Yes, the BOINC Core Client has issues Cross Project...

I am still waiting for the PII 400 and the PII 550 to complete their 1st work units...

I will post those machine ID's as they complete...

Happy Holiday's



Please consider a Donation to the Seti Project.

ID: 220724 · Report as offensive
Profile Tern
Volunteer tester
Avatar

Send message
Joined: 4 Dec 03
Posts: 1122
Credit: 13,376,822
RAC: 44
United States
Message 220730 - Posted: 24 Dec 2005, 5:04:31 UTC - in response to Message 220724.  

Even the New Program it is not perfect!


What? One of the examples you gave had claimed credit within a point of each other, even though the runtime for one host was MUCH longer than the other. A good example of why the new program is so much better.

The other example had one reasonable claim for credit and one outrageous one of 452 credits. The problem is obvious once you look at the "too high" result; it was done with BOINC 4.45. In other words, the benchmarks. The "New Program" requires V5.2.6(?) or above in order to use flops-counting.
ID: 220730 · Report as offensive
W-K 666 Project Donor
Volunteer tester

Send message
Joined: 18 May 99
Posts: 19012
Credit: 40,757,560
RAC: 67
United Kingdom
Message 220761 - Posted: 24 Dec 2005, 6:18:32 UTC
Last modified: 24 Dec 2005, 6:19:57 UTC

As Bill said the Enhanced works perfectly if Berkeley insists that BOINC 5.2.x is used. As shown below;
106588
112730
140489

[edit]All thet have to do is ensure the cobblestones/'time period' compared to other projects is correct[/edit]
ID: 220761 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 13720
Credit: 208,696,464
RAC: 304
Australia
Message 220772 - Posted: 24 Dec 2005, 6:45:14 UTC - in response to Message 220643.  

My bet's with floating point, because I'd guess the nature of the data being processed is best done via that route (floating point calcs vs. integer ones).

Only if all the data being crunched will fit into the CPUs cache.
Grant
Darwin NT
ID: 220772 · Report as offensive
Profile AlecStaar
Avatar

Send message
Joined: 16 Dec 05
Posts: 260
Credit: 44,472
RAC: 0
United States
Message 220967 - Posted: 24 Dec 2005, 16:49:52 UTC
Last modified: 24 Dec 2005, 17:39:00 UTC

Wow, lot of feedback!

(First of all, thanks for the input guys - it's a big help in aiding myself in making a determination of what boinc.exe (in particular) to stick by/with here @ this point @ least).

So, let me quote a few folks, ask a few questions & get my final set of feedback here:

Trux - Neither the BOINC client nor the benchmark has any impact on the speed of crunching. Only the project application has.


Agreed! As I say later to another poster 'real world results count the most' or something along those lines & iirc, from the last project? It IS the SETI*.exe that does the actual processing, on the older project round #1, & now on this BOINC/BoinMgr managed round #2.

I see your point there. Still, I want what will be the best "mix" of all the programs (gained via observation/experimentation here guided by work unit processing times AND the benchmarks) possible here running this project's dataprocessing.

As to the BOINCMGR.exe built-in benchmark - Well, I only use it as a 'gauge' of determining what builds of the SSE/SSE2/SSE3 cpu specific recompiles via MSVC++ (such as your model) vs. Intel C++ 9.0 (other modded client model I tested) yield for results, FPops vs. Iops, that I ought to stick with.

"Show me where they are strong vs. weak" in a nutshell.

Thus, why I asked in this posting "which is more important to the operations of this project occurring faster - Floating point or Integer ops" in my subject!

The benchmark hopefully will point out to me which client for boinc.exe is stronger in ffops vs. iops & indicate to me which to stay with - whichever one is used MORE for this project's dataprocessing (floating point calcs vs. Integer ones).

I know that each particular build, compiled & optimized by diff. compilers will have its strength (or weakness) shown via benchmarks largely in iops vs. fpops so I use the benchmark merely as a gauge here for that capacity, & will help me decide which BOINC.EXE (specifically this app) to stay with is all.

Trying to get data from you folks is all - you're WAY into it, more than I am, & exploiting experts is where it is at imo, if you are not expert on a particular subject matter (or as much as you or I would like to be on an area that is) they are your BEST reference, which you all have been for me here bigtime.

Landroval - The best way to accurately determine which version produces faster crunch times on YOUR hardware is to crunch a few units under each and compare.


I couldn't agree more - benchmarks are a ONLY really a "decent gauge" I suppose, and a fast way to make some "guided determinations", but are not the end all/be all authority.

However, I don't completely discount/disregard their results either.

Grant (SSSF) - Only if all the data being crunched will fit into the CPUs cache.


Again, agreed 110% - and, it's probably why Intel Xeon, Pentium 4 "extreme edition", & even Prescott built Intel P4 cpu's do SO well, vs. std. P4 & below level cpus (including the newer SSE/3 instruction sets).

More L2 cache onboard the CPU (vs. std. Pentium 4's like I have with only 512kb L2 cache vs. iirc, Xeon & EE's with up to 2mb L2 cache + Prescott P4's with 1mb L2 cache), direct connect, no "over the system bus" travel thru the mobo memory controller etc.. so, what you said? Does make absolute sense!

E.G. -> I've been PATIENTLY waiting for the Pentium 4 "EE" 2mb 478 i857 3.4ghz chipset CPU (to replace my std. P4 @ 3.2ghz) to drop in price (largely for aiding this project on the grounds you state in fact) but, they are STILL @ around $950 per each CPU - THAT'S STILL TOO "RICH" OF A PRICE FOR MY TASTES AND INCOME, lol!

I can definitely state that "there is no substitute for good hardware" by comparison to software, but these optimized to specific CPU platform recompiled/reoptimized clients DO make a big diff. though - in fact, so much it amazed me!

The original project had me on purely "stock" client builds of SETI 3.08 for Win32 (commandline model) & I wasn't even AWARE that folks had done recompiled/reoptimized more efficient ones for the 1st run of this project & wish I was aware of them back then!

At least I have the benefit of this forums now & being made aware of them for this round of the SETI@Home 2 project run!

Bill Michael - SETI is heavy on floating point


Aha! Now, THIS is what I suspected as well... & it's making me lean to whatever BOINC.exe yields better FPops results in its built-in boincmgr.exe benchmarking system as to the one I stick with (for now @ least).

Here, in another thread:

http://setiathome.berkeley.edu/forum_thread.php?id=26039

It seems that this thread was mentioned, & that MikeSW17 the thread starter, leans to this train-of-thought as well.

Lowfield - Anyway I digress. Statistically they are equal, each having much the same effect on cobblestones claimed.


However, lowfield (and others here) state otherwise, thus, it may be a "mixed bag" here on fpops vs. iops... so, for now, I will 'chance it' & run with the boinc.exe that yields higher fpops though.

To myself, it makes the most sense because of the nature of the data being processed by this project.

:)

* ANYHOW/ANYWAYS - thanks VERY much for the feedback guys, & to Trux + other modded client reoptimizers/recompilers!

(Down to roughly, almost to the second, 1hr. = 1 unit times, pushing 2 @ a time here concurrently according to the boincmgr.exe outputs in the WORK tab due largely to the recompiled/reoptimized seti 4.18x & boinc.exe clients that folks took the time (like Trux) to create - they truly ARE better/stronger/more efficient & it showed in the results (both benchmark & realworld work unit results here))

APK
http://torry.net/authorsmore.php?id=1781

"The object's hull is made of SOLID neutronium: A single StarShip cannot combat it!" quote Mr. Spock, Star Trek original series, episode title: "The Doomsday Machine"
ID: 220967 · Report as offensive
Profile Clyde C. Phillips, III

Send message
Joined: 2 Aug 00
Posts: 1851
Credit: 5,955,047
RAC: 0
United States
Message 221029 - Posted: 24 Dec 2005, 20:19:32 UTC

Both the floating and the integer are summed to get the official computing speed for Seti purposes. However one is considerably larger than the other and so is likely to affect the Seti speed score more than the other.

I understand that the new Seti Enhanced will count operations. I wonder how much that will degrade calculation efficiency. Hopefully no more than several percent. Maybe this will cause a more consistent number of cobblestones with the results of each unit.

I see that it may not be necessary to buy those expensive Pentium D Extremes. I see that Legacy gets over 90 units per day with his P4640. I wonder how he does it: Overclock & watercool? Just the right motherboard and memory? Just the right BIOS settings? It's too bad I've never seen these processors mounted two on a motherboard so that one machine could do perhaps 160 units per day.
ID: 221029 · Report as offensive
Profile AlecStaar
Avatar

Send message
Joined: 16 Dec 05
Posts: 260
Credit: 44,472
RAC: 0
United States
Message 221075 - Posted: 24 Dec 2005, 22:31:11 UTC - in response to Message 221029.  

Both the floating and the integer are summed to get the official computing speed for Seti purposes. However one is considerably larger than the other and so is likely to affect the Seti speed score more than the other.


Any idea which part of the dataset is larger/more prevalent?

(e.g.-> Floating Point processed OR Integer processed)

:)

* Thanks for the info., from anyone, that can answer that for me...

APK

http://torry.net/authorsmore.php?id=1781

"The object's hull is made of SOLID neutronium: A single StarShip cannot combat it!" quote Mr. Spock, Star Trek original series, episode title: "The Doomsday Machine"
ID: 221075 · Report as offensive
Profile Tern
Volunteer tester
Avatar

Send message
Joined: 4 Dec 03
Posts: 1122
Credit: 13,376,822
RAC: 44
United States
Message 221088 - Posted: 24 Dec 2005, 22:50:46 UTC

Methinks thou dost dig too deep... The best optimized SETI science application for your computer is the one that runs the fastest without errors. That may have _nothing_ to do with the compiler used, the flags set, etc. - because I can state that Crunch3r's apps are the fastest on Windows, period, and I have no idea what compiler or settings he used to create them. The improvement came from the caching mechanism introduced by the whole group of Linux folks (can't remember other names right now).

The best optimized BOINC client for your computer is NOT the one with the highest benchmarks. It is the one that most closely matches (in terms of actual speed in relation to those benchmarks) the optimized application you're running. It doesn't matter _how_ it gets the benchmarks, or which number is "higher", just that the claimed credit you ask for is within the reasonable range expected. I have actually recommended that someone use the SSE version of the BOINC client rather than the SSE2 version they _could_ have used, because the SSE2 version's benchmarks were too high.

With that having been stated, if you wind up using the caching SETI app, your times are going to be very fast, and you probably _will_ need the highest benchmarks you can get. But that means whichever one has the highest _sum_ of the two numbers, not which one has the highest in one category.

And _all_ of this assumes you crunch "SETI only", or "SETI and other projects where benchmarks don't matter"...
ID: 221088 · Report as offensive
Profile Pappa
Volunteer tester
Avatar

Send message
Joined: 9 Jan 00
Posts: 2562
Credit: 12,301,681
RAC: 0
United States
Message 221098 - Posted: 24 Dec 2005, 23:06:38 UTC - in response to Message 220730.  
Last modified: 24 Dec 2005, 23:11:12 UTC

Bill

It was nice that you picked up on this... So Quickly! It is hard to just point to "Good Examples." When everyone can drag out some many bad examples.

Even the New Program it is not perfect!


What? One of the examples you gave had claimed credit within a point of each other, even though the runtime for one host was MUCH longer than the other. A good example of why the new program is so much better.


It showed one of Tetsuji Maverick Rai's machines @2.4Ghz (40,280.89sec)189.51 Credits Claimed BOINC 5.2.14 and My AMD 64 @2.2Ghz (112,786.27sec)190.67 Credits Claimed with BOINC 5.2.13.


The other example had one reasonable claim for credit and one outrageous one of 452 credits. The problem is obvious once you look at the "too high" result; it was done with BOINC 4.45. In other words, the benchmarks. The "New Program" requires V5.2.6(?) or above in order to use flops-counting.


Once again my AMD 64 with 5.2.12 (113,151.52sec) 190.68 Claimed Credit and as you mention a 3.6Ghz Xeon (122,405.19sec) 452.17 Claimed Credit with BOINC 4.45

So as the machine is doing Einstein and Seti Ehanced Beta it has a few Seti WU's also These are 5.2.13 BOINC Core Client.

Seti Enhanced Beta

Seti

Einstein

The Einstein is producing very consistient "Claimed Credit" that was comparable to 4.45 with an optimized BOINC Core.

Al

Please consider a Donation to the Seti Project.

ID: 221098 · Report as offensive
Profile AlecStaar
Avatar

Send message
Joined: 16 Dec 05
Posts: 260
Credit: 44,472
RAC: 0
United States
Message 221102 - Posted: 24 Dec 2005, 23:15:18 UTC
Last modified: 24 Dec 2005, 23:20:27 UTC

I'm now wondering if the coders here can go with John Carmacks' version of the FLOAT function!

IIRC, it is not as accurate as math.h FLOAT function from what I understand (not out to as many decimal places of precision) but, it is TRULY many orders of magnitude faster than the 'stock/oem' version of the float function in most C/C++ compiler's math.h file!

I've seen the code for it on Slashdot, & although incredibly small (sub 20 line function) it's fast!

Much faster than most native math.h headers have for a floating point calc function!

By the way - That Quake III sourcecode with that function's also now publicly available and free.

Thus, so is that version of the FLOAT function!

* To those who have seen the sourcecode &/or work with it:

Do you know if using that version of float might help speed this up yet more, w/out adversely affecting the data calculation accuracy?

(TIA for the answer!)

APK

P.S.=>
Bill Michael - Methinks thou dost dig too deep...


Heh, never... I can't dig deep enough, in pursuit of higher performance!

Bill Michael - But that means whichever one has the highest _sum_ of the two numbers, not which one has the highest in one category.


Are you sure? Read my last posting, & what I asked the user there... it appears that either Integer ops, or Floating Point ops, compose MORE of what is used on the processing of the dataset by SETI 4.18x from his statement, & I need to find out if it is more of Integer, or of Floating Point calculated data.

This matters!

Because, imo, whatever is used more in the dataset processing process? I will optimize for (integer vs. float)... it only makes sense! apk
http://torry.net/authorsmore.php?id=1781

"The object's hull is made of SOLID neutronium: A single StarShip cannot combat it!" quote Mr. Spock, Star Trek original series, episode title: "The Doomsday Machine"
ID: 221102 · Report as offensive
Profile Tern
Volunteer tester
Avatar

Send message
Joined: 4 Dec 03
Posts: 1122
Credit: 13,376,822
RAC: 44
United States
Message 221118 - Posted: 25 Dec 2005, 0:14:45 UTC - in response to Message 221102.  

Bill Michael - But that means whichever one has the highest _sum_ of the two numbers, not which one has the highest in one category.


Are you sure? Read my last posting, & what I asked the user there... it appears that either Integer ops, or Floating Point ops, compose MORE of what is used on the processing of the dataset by SETI 4.18x from his statement, & I need to find out if it is more of Integer, or of Floating Point calculated data.


You are still confusing SETI and BOINC. SETI uses far more floating point math than integer math, but this has nothing to do with the BOINC benchmarks. The benchmark value used for calculating credit is simply the sum of the two numbers.

It _should_ be weighted towards the floating point value for SETI, just as PrimeGrid _should_ be weighted to the integer value. But that's not how it actually _is_ done. To me, it is misleading that BOINC even _reports_ two separate values, because they are not used separately, anywhere. (At present.)
ID: 221118 · Report as offensive
Profile AlecStaar
Avatar

Send message
Joined: 16 Dec 05
Posts: 260
Credit: 44,472
RAC: 0
United States
Message 221125 - Posted: 25 Dec 2005, 0:33:20 UTC
Last modified: 25 Dec 2005, 1:04:53 UTC

Bill Michael - You are still confusing SETI and BOINC. SETI uses far more floating point math than integer math, but this has nothing to do with the BOINC benchmarks. The benchmark value used for calculating credit is simply the sum of the two numbers.


Hmmm, am I?

You see, my seeing a higher floating point calculation from the BoingMgr.exe benchmark results, tells me that the particular build of boinc.exe seems to do better with floating-point calculation IF built & optimized using the Intel compiler vs. the Microsoft one.

(I draw this conclusion based on facts, for a reason (more on that below) - because that is the ONLY thing I change when testing is the boinc.exe portion (intel compiler optimized version vs. ms compiler optimized version), that's true, but NOT my real motivation here... it's only telling me that one does better on floating point math calc optimization, hence all my questions below about the nature & amounts of calcs used for integer, vs. floating point, while this app set processes said data!)

Then, using the Intel compiler optimized build of boinc.exe, I seem to pull off far larger numbers in floating point tests using "Crunch3rs" build optimized in Intel C++ 9.0 w/ IPP 4.1 libs, vs. Trux's build using MSVC++!

(Both tests were for the SSE/2 optimized for Pentium 4 CPU's models of boinc.exe AND seti 4.18x).

That ONLY tells me that the intel compiler produces better/more efficient floating point code is all.

That's "step #1" in my research here on the software end - hence, some of my questions below to others, mainly the one regarding the dataset used here (if it is primarily composed mostly of data that is floating point calculated).

Secondly, it would be good to know if the folks doing the optimizations here can actually use John Carmack's version (from the Quake III sourcecode base, since that one is far faster, albeit not as precise to the right of the decimal point) of the FLOAT function, rather than the math.h header file version... again, to gain speed of operations during their optimizations, hopefully, w/out affecting the accuracy of calculations used, adversely, thru a superior (speed-wise) float function being used.

Also, I DO realize, as I stated below a couple times now, that SETI 4.18x is what does the actual "dataprocessing" of the units...

Again though: Since optimized builds of BOINC.exe seem to gain when optimized using Intel's C++ 9.0 FAR MORE in FLOATING POINT calcs?

That tells me that the SETI 4.18x client that does the actual work will be faster if optimized via Intel's compiler, vs. Microsoft's...

:)

* What I am basically trying to determine here, is 2 things:

1.) The dataset used by SETI 4.18x during processing - is the greater majority/bulk of its data processed via floating point calculations, or integer?

&

2.) What compiler tends to seem to optimize ANY program better for floating point OR integer...

What I hope to find out, in the quest for greater performance (hence, some of my questions earlier, such as the one from 2 posts back from myself):

A.) IF the Intel compiler proves superior in floating point (and it is, I know this much already looking @ the numbers from my tests here)

&

B.) That said, additionally - If what I suspect is true (that the majority of what SETI 4.18x uses is floating point calculations)?

Then I will lean towards the builds optimized using Intel's C++ 9.0 compiler using IPP 4.1 libs + SSE/2 instruction set optimization, in the quest for greater processing speeds from the apps this application set for this project uses while it runs...

APK
http://torry.net/authorsmore.php?id=1781

"The object's hull is made of SOLID neutronium: A single StarShip cannot combat it!" quote Mr. Spock, Star Trek original series, episode title: "The Doomsday Machine"
ID: 221125 · Report as offensive
Profile Tern
Volunteer tester
Avatar

Send message
Joined: 4 Dec 03
Posts: 1122
Credit: 13,376,822
RAC: 44
United States
Message 221129 - Posted: 25 Dec 2005, 0:59:50 UTC - in response to Message 221125.  

* What I am basically trying to determine here, is 2 things:

1.) The dataset used by SETI 4.18x during processing - is the greater majority/bulk of its data processed via floating point calculations, or integer?


I haven't counted, but I think at least three people have told you floating point... I know _I_ have.

2.) What compiler tends to seem to optimize ANY program better for floating point OR integer...

What I hope to find out, in the quest for greater performance (hence, some of my questions earlier, such as the one from 2 posts back from myself):

A.) IF the Intel compiler proves superior in floating point (and it is, I know this much already looking @ the numbers from my tests here)

&

B.) That said, additionally - If what I suspect is true (that the majority of what SETI 4.18x uses is floating point calculations)?

Then I will lean towards the builds optimized using Intel's C++ 9.0 compiler using IPP 4.1 libs + SSE/2 instruction set optimization, in the quest for greater processing speeds from the apps this application set for this project uses while it runs...


And, if the _only_ difference between two SETI builds is the compiler, you'll be fine, and you'll have the fastest one. But if the optimizer has done "other things" besides choose a compiler and flip compiler switches, the "fastest version" for your computer could be one written in VB, for all I know. (I'm a Mac person.) Today, _the_ fastest are Crunch3r's. (For Windows.) Period. Doesn't matter what compiler he used, his are faster. Look at the reference times, and see for yourself. This isn't a theoretical exercise, we _know_ the answer!
ID: 221129 · Report as offensive
1 · 2 · Next

Message boards : Number crunching : What's more important to faster SETI processing times? Floating point, or Integer ops? TIA!


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.