Message boards : Number crunching : @Admin: Release optimised Clients?
Message board moderation

To post messages, you must log in.

1 · 2 · Next

AuthorMessage
baracutio

Send message
Joined: 17 Aug 05
Posts: 7
Credit: 85,292
RAC: 0
Message 12426 - Posted: 26 Jan 2006, 0:29:33 UTC

HI

could someone please release optimised lhc-clients (for mmx, sse, sse2 etc.)? i think it would speed up the research and save a lot of time for us and for you:)

sorry for my bad english, i'm german^^



mfg bara
ID: 12426 · Report as offensive     Reply Quote
Dirk Broer

Send message
Joined: 20 Sep 05
Posts: 31
Credit: 1,212,091
RAC: 10
Message 12430 - Posted: 26 Jan 2006, 8:57:34 UTC

Das war ganz einfach zu lesen mein Freund!

sorry for the bad German, I'm Dutch ;)
ID: 12430 · Report as offensive     Reply Quote
River~~

Send message
Joined: 13 Jul 05
Posts: 456
Credit: 75,142
RAC: 0
Message 12432 - Posted: 26 Jan 2006, 9:37:48 UTC

Sorry for the bad news, my friends.

LHC will not release optimised apps - this project needs the utmost in accuracy and tests show that the optimised apps are less accurate than the normal ones.

It is a good thought - and one that has been considered carefully by the project team in the past

River~~
ID: 12432 · Report as offensive     Reply Quote
Profile The Gas Giant

Send message
Joined: 2 Sep 04
Posts: 309
Credit: 715,258
RAC: 0
Message 12436 - Posted: 26 Jan 2006, 9:46:17 UTC

They have already used some optimisation and wu's do complete more quickly than they originally did.

Sorry for my bad English, I am Australian.

Live long and crunch.

Paul
(S@H1 8888)
BOINC/SAH BETA
ID: 12436 · Report as offensive     Reply Quote
Perle
Avatar

Send message
Joined: 25 Oct 04
Posts: 83
Credit: 77,840,929
RAC: 39,666
Message 12456 - Posted: 26 Jan 2006, 14:02:43 UTC

Doing our part, and sacrificing WU completion time for accuracy from our systems is critical.

We wouldnt want to provide erroneus data and have LHC accidently create a black hole.

Sorry for my bad English, I am American.

Keep on Crushing !!!
ID: 12456 · Report as offensive     Reply Quote
[B@H] Ray

Send message
Joined: 13 Jul 05
Posts: 82
Credit: 6,336
RAC: 0
Message 12458 - Posted: 26 Jan 2006, 14:57:14 UTC

Getting the scuence correct is more inportant than than the time.

Sorry for my bad English, I am an earthling.

Ray

Pizza@Home - Rays Place - Rays place Forums
ID: 12458 · Report as offensive     Reply Quote
Profile Mr.Pernod
Avatar

Send message
Joined: 16 Jul 05
Posts: 65
Credit: 369,728
RAC: 0
Message 12461 - Posted: 26 Jan 2006, 15:31:01 UTC - in response to Message 12456.  

Doing our part, and sacrificing WU completion time for accuracy from our systems is critical.

We wouldnt want to provide erroneus data and have LHC accidently create a black hole.

Sorry for my bad English, I am American.

Keep on Crushing !!!

good is black hole, vacuumcleaner need no more

english bad me excuse, Yoda my name is

;)
ID: 12461 · Report as offensive     Reply Quote
Travis DJ

Send message
Joined: 29 Sep 04
Posts: 196
Credit: 207,040
RAC: 0
Message 12465 - Posted: 26 Jan 2006, 17:28:55 UTC - in response to Message 12456.  
Last modified: 26 Jan 2006, 17:35:00 UTC

@Perle
We wouldnt want to provide erroneus data and have LHC accidently create a black hole.


See this thread. They DO want to create black holes even if by accident I would presume.

As for optimization, 64-bit, SSE/2/3.. the tradeoff is accuracy vs. speed. I can't find the forum post, however the LHC dev team had changed fortran compilers over time and due to just that change, performance boots had been noticed without having to add other instruction sets (i.e. major modification).

Sorry for my bad English, I am a tribble.

ID: 12465 · Report as offensive     Reply Quote
Grutte Pier [Wa oars]~GP500

Send message
Joined: 22 Jan 06
Posts: 21
Credit: 125,903
RAC: 0
Message 12475 - Posted: 26 Jan 2006, 22:09:24 UTC - in response to Message 12430.  

I can understand but aren't there fale safes.
If you see at d.net they have made there clients go many times faster.
last update was 40% increase, even for p3's :DDDDD

Sorry for my bad english, i'm Frisian.

Das war ganz einfach zu lesen mein Freund!

sorry for the bad German, I'm Dutch ;)


Hallo niederlander, bij welk team zit jij ook DPC.
GP500 subteam Grutte Pier.

ID: 12475 · Report as offensive     Reply Quote
Travis DJ

Send message
Joined: 29 Sep 04
Posts: 196
Credit: 207,040
RAC: 0
Message 12476 - Posted: 27 Jan 2006, 1:20:48 UTC - in response to Message 12475.  
Last modified: 27 Jan 2006, 1:21:46 UTC

I can understand but aren't there fale safes.
If you see at d.net they have made there clients go many times faster.
last update was 40% increase, even for p3's :DDDDD


d.net uses integer math in their RC5 & OGR calculations. Fixed-size numbers, no floating point, IIRC. All the RC5 cores basically do bitshifting routines to compare keycodes in sequence from one to .. however many billions of billions of combinations for the 72-bit contest. Some of their cores use SSE/2 on supported platforms because of their register size (128-bit SSE registers) making it faster to do the math .. general purpose registers are 8 or 16 bit. So, you can see the advantage of storing the data in a SSE register vs several smaller ones.

The difference is LHC is highly floating-point intensive. Yes, SSE does do floating point calculations "better" (depending on point of view) however they've experienced variation in the results amongst various CPUs when SSE was used, which is a no-no for scientific work.
ID: 12476 · Report as offensive     Reply Quote
Profile Paul D. Buck

Send message
Joined: 2 Sep 04
Posts: 545
Credit: 148,912
RAC: 0
Message 12484 - Posted: 27 Jan 2006, 5:17:38 UTC - in response to Message 12475.  

I can understand but aren't there fale safes.
If you see at d.net they have made there clients go many times faster.
last update was 40% increase, even for p3's

For a project like SETI@Home, 6-7 digits of precision in the answer are "close enough". And even there, the comparisons are "fuzzy" so that slightly different answers do not invalidate the work.

In LHC@Home, the litterally have to have identical digits out to the 16th decimal place. This is why they give partial credit even for failures. It may be that your result is "off" by just a little, but too much for a validation.

Optimization for speed will always trade off some accuracy for the increase in speed.

For LHC@Home that is unacceptable. Lots of inaccurate work fast is worse than accurate work done the first time through, even if it takes "longer". It is the concept of doing it right the first time.
ID: 12484 · Report as offensive     Reply Quote
Gaspode the UnDressed

Send message
Joined: 1 Sep 04
Posts: 506
Credit: 118,619
RAC: 0
Message 12490 - Posted: 27 Jan 2006, 9:31:49 UTC - in response to Message 12426.  

HI

could someone please release optimised lhc-clients (for mmx, sse, sse2 etc.)? i think it would speed up the research and save a lot of time for us and for you:)

sorry for my bad english, i'm german^^



mfg bara


Here we go again...

SixTrack is one of the applications routinely used by Fortran compiler writers to test performance of their compilers. It is, by default, an 'optimised' client, since the compiler writers themselves have optimised it. Any further 'optimisation' will add little to the performance, and is likely to affect the accuracy adversely.


Gaspode the UnDressed
http://www.littlevale.co.uk
ID: 12490 · Report as offensive     Reply Quote
Profile Fuzzy Hollynoodles
Avatar

Send message
Joined: 13 Jul 05
Posts: 51
Credit: 10,626
RAC: 0
Message 12492 - Posted: 27 Jan 2006, 10:24:13 UTC

And no optimized clients will help anything in the periods, where there's no work to get.

Excuse me for my good English, I'm Danish. :-P


"I'm trying to maintain a shred of dignity in this world" - Me
ID: 12492 · Report as offensive     Reply Quote
[B@H] Ray

Send message
Joined: 13 Jul 05
Posts: 82
Credit: 6,336
RAC: 0
Message 12509 - Posted: 27 Jan 2006, 16:51:19 UTC - in response to Message 12492.  

And no optimized clients will help anything in the periods, where there's no work to get.

P
But you have to think of those who like to sit around looking at that nice optomized client when it is not working. As long as they use the one we are using now when there is work. Have to make them feel good.
Ray


Excuse me for my good English, I'm Danish. :-P


Excuse me for my good English, I'm from planet Earth.

Pizza@Home - Rays Place - Rays place Forums
ID: 12509 · Report as offensive     Reply Quote
Profile Fuzzy Hollynoodles
Avatar

Send message
Joined: 13 Jul 05
Posts: 51
Credit: 10,626
RAC: 0
Message 12513 - Posted: 27 Jan 2006, 19:26:11 UTC - in response to Message 12509.  
Last modified: 27 Jan 2006, 19:26:56 UTC


P
But you have to think of those who like to sit around looking at that nice optomized client when it is not working. As long as they use the one we are using now when there is work. Have to make them feel good.
Ray


Ohhhh yeah, I spend hours every day sitting and watching my Seti optimized science client! ;-D



"I'm trying to maintain a shred of dignity in this world" - Me
ID: 12513 · Report as offensive     Reply Quote
Profile [B^S] Molzahn

Send message
Joined: 21 Jan 06
Posts: 46
Credit: 174,756
RAC: 0
Message 12527 - Posted: 28 Jan 2006, 0:04:21 UTC

Hello my fellow LHC crunchers,
LHC and Einstein are my primary concerns with BOINC at the moment, I also run Seti, and was/am planning on installing an optimized BOINC client tonight (http://www.guntec.de/Crunch3r/boincx86.html )...

Since LHC is my primary concern: is it a bad idea to install an optimized client? or are we just discussing the optimized project application?

Sorry to ask a question that most likely has an obvious answer; hopefully someone can clarify my misunderstanding with the difference here.

Thanks a ton,
ACLUguy

Post Script: Thank you in advance for taking the time to humor my "newbie" question.

blog pictures
ID: 12527 · Report as offensive     Reply Quote
Profile [B^S] Molzahn

Send message
Joined: 21 Jan 06
Posts: 46
Credit: 174,756
RAC: 0
Message 12530 - Posted: 28 Jan 2006, 1:48:51 UTC
Last modified: 28 Jan 2006, 1:49:55 UTC

Ok I re-read this thread and as i know, LHC is already "optimized"; I was just curious if an optimized BOINC client would give less accurate LHC results. It seems as if this is so. Sorry, I should have read this thread more carefully.

Thank you, and if this assertion is incorrect please correct me,
ACLUguy
Post Script: No need to respond unless i am incorrect. :) thanks again

blog pictures
ID: 12530 · Report as offensive     Reply Quote
Profile Fuzzy Hollynoodles
Avatar

Send message
Joined: 13 Jul 05
Posts: 51
Credit: 10,626
RAC: 0
Message 12531 - Posted: 28 Jan 2006, 2:57:39 UTC - in response to Message 12530.  

Ok I re-read this thread and as i know, LHC is already "optimized"; I was just curious if an optimized BOINC client would give less accurate LHC results. It seems as if this is so. Sorry, I should have read this thread more carefully.

Thank you, and if this assertion is incorrect please correct me,
ACLUguy
Post Script: No need to respond unless i am incorrect. :) thanks again


I don't know if I understand you correct, do you think an optimized Seti client will corrupt your LHC results?

I don't have the optimized client but I have the optimized science application installed, so when I start my BOINC manager, the log starts with these lines:

1/27/2006 10:10:22 AM||Starting BOINC client version 5.3.2 for windows_intelx86
1/27/2006 10:10:22 AM||libcurl/7.14.0 OpenSSL/0.9.8 zlib/1.2.3
1/27/2006 10:10:22 AM||Data directory: C:\\Programmer\\BOINC
1/27/2006 10:10:22 AM|SETI@home|Found app_info.xml; using anonymous platform
1/27/2006 10:10:22 AM||Processor: 1 GenuineIntel Intel(R) Pentium(R) 4 CPU 2.80GHz
1/27/2006 10:10:22 AM||Memory: 503.36 MB physical, 1.20 GB virtual
1/27/2006 10:10:22 AM||Disk: 37.25 GB total, 23.61 GB free


What this means is that when I crunch Seti WU's, it uses Crunch3rs client, and when I crunch other WU's, it uses my "normal" BOINC client, and my returned results are totally kosher in the other projects.


"I'm trying to maintain a shred of dignity in this world" - Me
ID: 12531 · Report as offensive     Reply Quote
Profile [B^S] Molzahn

Send message
Joined: 21 Jan 06
Posts: 46
Credit: 174,756
RAC: 0
Message 12532 - Posted: 28 Jan 2006, 3:47:26 UTC
Last modified: 28 Jan 2006, 4:16:27 UTC

Thank you for responding, i will try to make this (slightly) more clear,
Yeah I understand the difference between the SETI optimization & BOINC optimization; at least i think so, perhaps i'm not understanding the BOINC optimization and that's why my post was misleading.

I was just wondering if using a optimized BOINC client would corrupt/reduce the quality of LHC results; something I don't wish to do.

I assumed the BOINC optimization exe was just optimizing BOINC for my processor, and did not sacrifice quality for speed (in every project, including LHC). The consensus (, if i understand correctly,) seems to be that an optimized BOINC client would compromise LHC results...

Does that sound right? Or are we just discussing the addition/creation of a new science application to optimize LHC? On the contrary, if an optimized BOINC client will not harm LHC results: I will install it post haste.

Thank you for responding,
ACLUguy

Post Script: I assume, since I wont be installing the optimized BOINC client (it seems like it does corrupt LHC results, from what i can understand): I will install the optimized SETI science program; as you have suggested, and use (instead of the BOINC optimization). Thanks for your response to my redundant, rambling, indecipherable posts. :) (I wish i was adept at communicating with the English language; it seems as if a few of us have this problem...)

blog pictures
ID: 12532 · Report as offensive     Reply Quote
Profile Paul D. Buck

Send message
Joined: 2 Sep 04
Posts: 545
Credit: 148,912
RAC: 0
Message 12537 - Posted: 28 Jan 2006, 5:56:33 UTC

An optimezed BOINC Client, the thing with version 5.2.13 will not affect science results. It *MIGHT* reduce your total run times, but, *MY* expectation is that the gain will be lost in the noise of the work unit run time variance. In other words, it is too small to measure correctly.

The PRIMARY effect of optimizing the BOINC client software is to alter the results of the benchmarks. Thus raising claims to "where they belong". Though how anyone truly knows what that figure is, is beyond me. The idea that the "standard" work unit is worth 32.0x Cobblestones is the only metric used, and it is not official by any means. And, with the 400% variation on speeds by computers and the benchmark driven claim, I have to ask myself, on which system was the 32 CS actually measured? One that we would now believe underclaims? Or one we now believe overclaims? But I digress...

The CRUCIAL quesion is the optimization of the science application. All other optimizations are essentially meaningless. OUR interest is in optimization for speed (though it is equally valid to optimize for size - like Apple is rumored to have done for OS-X). In this case, the trade off is usually, as I said before, some accuracy for speed. In LHC@Home that is unacceptable. And, if the compilers are in fact tested against sixtrack then the "generic" code is likely to be pretty good.

Though, a "good" optimizing compiler with appropriate directives can still improve on that when a program is compiled to a particular ISA, or CPU, or even better still the CPU/Cache/Chipset combination.

Of course, as has been shown by Einstein@Home, nothing beats writing critical sections by had in a target machine's assembly code. That is why my G5 which is usually comparable to the Xeons I have beats them by a factor of 3 with EAH work. Heck, i regularly get work shorter than one hour on the G5, and I don't even have the fastest model ... mine is ONLY a dual 2.0 GHz ... I sure would like a quad 2.5 ... :)

I hope this helps, there is some more in the Wiki under optimization including I believe a paper by HP that demonstrates a "run-time" streaming optimizer that, even though it is software, allows programs run via the interperative software to run faster than if it ran on the raw hardware. Very much contrary to expectations ... :)
ID: 12537 · Report as offensive     Reply Quote
1 · 2 · Next

Message boards : Number crunching : @Admin: Release optimised Clients?


©2024 CERN