Bruce,
Can you give us the latest on the possibilities of getting the Albert application in optimized forms? WIth the Altivec version I see super performance and know that this is also (based on SETI@Home experience) potentially possible with the PC type CPUs. I know that to have decent coverage there would have to be about 7 different "flavors"
1) Standard
2) AMD SSE2
3) AMD SSE3
4) Intel SSE2
5) Intel SSE3
6) I forget
7) I forget #2
Is it this complexity and the difficulty of ensuring the download brings the correct version down?
Or something else?
Or, the check is in the mail?
Enquiring minds want to know! :)
____________
I think I read somewhere that Albert was basically automatically optimized. When it detects that SSE3 or whatever is available it automatically runs code better suited for that instruction set.
____________
BOINC WIKI
BOINCing since 2002/12/8
Hmmm,
I don't think it is doing a very good job then. If it was, I would expect closer concurrence between the G5 and the Xeons and I am not seeing that at all ...
____________
Even if it is too difficult to have boinc d/l the appropriate app it could be left as is. Then have a seperate d/l page where we can d/l the one we need and manually install the app. A lot of us are quite familiar with this proceedure because we have done so with our seti apps.
____________
98SE XP2500+ @ 2.1 GHz Boinc v5.8.8
@Paul:
Make that
1) Standard
2) AMD SSE2
3) AMD SSE3
4) Intel SSE
5) Intel SSE2
6) Intel SSE3
7) I forget
____________
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
Douglas Adams (1952 - 2001)
If you're at this, make it that:
1) Standard
2) MMX
3) MMX + 3Dnow
4) MMX + SSE
5) MMX + 3Dnow2 + iSSE
6) MMX + SSE + SSE2
7) MMX + 3Dnow2 + SSE
8) MMX + 3Dnow2 + SSE + SSE2
9) MMX + SSE + SSE2 + SSE3
10) MMX + SSE + SSE2 + SSE3 + iA64
11) MMX + SSE + SSE2 + SSE3 + VT
...
... you see a complexity in this pattern? ;)
____________
greetz, Uli
Bernd MachenschalkForum moderator
Project administrator
Project developer
Send message
Joined: Oct 15 04
Posts: 3005
Credit: 77,468,235
RAC: 31,282
During the last weeks and months we have been mainly busy with getting the Albert setup working, so I had not much time to spend on further optimization.
- The AltiVec-version of code is hancoded, explicitely using vector instructions where possible (at least in the very core of the program).
- On Linux, if SSE is detected the App switches to a part of the program that has been optimized for SSE by the compiler (gcc 3.4 or 4.0).
- On Windows we use the stock MSC compiler (7.1) on the generic version of the code.
I played with compiler options, compiler versions and modifications to the code for quite some time, but found the following measurements not to give any significant improvement in the calculation times compared to the Apps we currently deliver:
- prefer SSE2 over SSE when available (Linux)
- use hand-coded vector code (for SSE2) instad of leaving the optimization to the compiler (Linux)
- use SSE(2) optimization of the MSC compiler (Windows)
- use icc (the Intel compiler, version 8) instead of gcc or MSC
So my preliminary conclusions are that
- The MSC compiler does a suprisingly good job, at least on our code
- The SSE optimization of gcc seems to give results that are (nearly) as good as hand-written code
- The AltiVec Unit is simply better (and somewhat easier to program) than the SSE stuff; thats why I desperately regret the decision of Apple ragarding CPUs.
I began to play with the auto-vectorization of gcc-4 and icc-9, but without a usable result yet. It's something I'm still working on.
BM
____________
BM
- The AltiVec Unit is simply better (and somewhat easier to program) than the SSE stuff; thats why I desperately regret the decision of Apple ragarding CPUs.
Jobs did it to me with the Lisa, now I have a G5 he is at it again. Sorry, it is all my fault. I was thinking to go all PowerMac over windows.
I guess I will have to rethink that one. Though, I would like to get a Quad this year.
____________
Hello Bernd,
thx for sharing that information! It's good to hear that devs are looking into this. When I compare this to the optimization process of the seti application, several things come to my mind:
- I think the largest single contribution in s@h was the caching of FFT results.. anything like that possible here?
- 2nd was the usage of a special FFT library, can't remember the name but it was hand coded for different CPUs and instruction sets
-> since e@h searches for periodic signals I suspect you're using FFT as the main algorithm as well?
- 3rd was the impact of using the icc 8 or 9, with different flags for p3, p4, p-m and with some tricks the p3 version worked for AXP as well and they made a A64 version
-> would it be useful to talk with the seti guys about their optimization experiences with the icc? (thinking of TMR, crunch3r, Harold Naparst)
MrS
____________
Scanning for our furry friends since Jan 2002
Hello Bernd,
thx for sharing that information! It's good to hear that devs are looking into this. When I compare this to the optimization process of the seti application, several things come to my mind:
- I think the largest single contribution in s@h was the caching of FFT results.. anything like that possible here?
- 2nd was the usage of a special FFT library, can't remember the name but it was hand coded for different CPUs and instruction sets
-> since e@h searches for periodic signals I suspect you're using FFT as the main algorithm as well?
- 3rd was the impact of using the icc 8 or 9, with different flags for p3, p4, p-m and with some tricks the p3 version worked for AXP as well and they made a A64 version
-> would it be useful to talk with the seti guys about their optimization experiences with the icc? (thinking of TMR, crunch3r, Harold Naparst)
MrS
Here is what I use on my Pentium II, SuSE Linux 9.3:
Optimized SETI client V4.07.3a for i686 with FFTW3 by Ned Slider
Tollio
____________
Hi!
I did a hand-optimized version of the albert code. (windows, no SSE)
It produces absolutely correct results, but at least two times faster.
Can I use it without any kickback?
____________
Hi!
I did a hand-optimized version of the albert code. (windows, no SSE)
It produces absolutely correct results, but at least two times faster.
Can I use it without any kickback?
I do not work here or anything, but speaking in general, I think it would be best to submit your changes to the E@H staff, so 1. they can validate your claims, and 2. they can possibly use those changes in their main albert client
Having a 2x improvement in windows would be a huge help if the results are really just as accurate.
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
I second that one: a 2x speed-up would be huge. May I ask how you got the source code?
MrS
____________
Scanning for our furry friends since Jan 2002
Who's to say he did. Hand optimizing asm isn't much less difficult than running a disassembler on an executable to get (undocumented) asm out. Farthermore, running the app under a debugger would allow you to profile the execution and determine where the code was spending most of it's time, and thus where to concentrate the optimzation.
____________
Bruce AllenForum moderator
Project administrator
Project developer
Project scientist
Send message
Joined: Oct 15 04
Posts: 1094
Credit: 171,459,074
RAC: 493
Hi!
I did a hand-optimized version of the albert code. (windows, no SSE)
It produces absolutely correct results, but at least two times faster.
Can I use it without any kickback?
I'm very interested in this. I'll send you an email off list.
Cheers,
Bruce
____________
I'm very interested in this. I'll send you an email off list.
Ok. I'm waiting for your email.
Akos
Any results on this so far? Any beta-testers needed? :)
MrS
____________
Scanning for our furry friends since Jan 2002
Any results on this so far? Any beta-testers needed? :)I would like to help on speed optimization, but i don't know what is the way of it. Probably i can put my code on a webpage, but i think it would be not legal. I didn't get any e-mails in connection with legitimacy.
Any results on this so far? Any beta-testers needed? :)I would like to help on speed optimization, but i don't know what is the way of it. Probably i can put my code on a webpage, but i think it would be not legal. I didn't get any e-mails in connection with legitimacy.
Try emailing Bruce directly. You can find his email at the bottom of his personal page. http://www.lsc-group.phys.uwm.edu/~ballen/
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
Are you currently using your modified binaries? Because wow, 345.38 RAC is pretty good for an athlon 1700
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
I seems so. He's crunching 1.5 times faster than my 2.5GHz X2 (for one WU)! That's damn impressive, even if the 1700+ may be OC'ed :)
MrS
____________
Scanning for our furry friends since Jan 2002
Bruce AllenForum moderator
Project administrator
Project developer
Project scientist
Send message
Joined: Oct 15 04
Posts: 1094
Credit: 171,459,074
RAC: 493
Any results on this so far? Any beta-testers needed? :)I would like to help on speed optimization, but i don't know what is the way of it. Probably i can put my code on a webpage, but i think it would be not legal. I didn't get any e-mails in connection with legitimacy.
This is my fault -- I got caught up in some urgent things at this end. I've just written to you off-list.
Cheers,
Bruce
____________
Any News?
Bruce AllenForum moderator
Project administrator
Project developer
Project scientist
Send message
Joined: Oct 15 04
Posts: 1094
Credit: 171,459,074
RAC: 493
Any News?
Yes. Akosf has done three things to speed up our executable. One of these optimizations is very clever: it eliminates large numbers of (slow) divisions. We're in the process of building and testing new executables (for all platforms) that incorporate these changes. They should result in very substantial speed-ups.
Bruce
____________
Sounds excellent!
That's the spirit and why I like this Project alot :o)
____________
Scientific Network : 44800 MHz - 77824 MB - 1970 GB
One of these optimizations is very clever: it eliminates large numbers of (slow) divisions. We're in the process of building and testing new executables (for all platforms) that incorporate these changes. They should result in very substantial speed-ups.
That's great news guys :)
I'll be running 100% Einstein for some time now, because I'm running out of network traffic (wtf) .. so this may be just in time.
MrS
____________
Scanning for our furry friends since Jan 2002
Any News?
Yes. Akosf has done three things to speed up our executable. One of these optimizations is very clever: it eliminates large numbers of (slow) divisions. We're in the process of building and testing new executables (for all platforms) that incorporate these changes. They should result in very substantial speed-ups.
Bruce
If you need someone to help test in Linux, just give a shout!
I am really looking forward to this.
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
Any News?
Yes. Akosf has done three things to speed up our executable. One of these optimizations is very clever: it eliminates large numbers of (slow) divisions. We're in the process of building and testing new executables (for all platforms) that incorporate these changes. They should result in very substantial speed-ups.
Bruce
If you need someone to help test in Linux, just give a shout!
I am really looking forward to this.
I'm also running Einstein exclusively in Linux and would love to help.
BORG
____________
Any News?
Yes. Akosf has done three things to speed up our executable. One of these optimizations is very clever: it eliminates large numbers of (slow) divisions. We're in the process of building and testing new executables (for all platforms) that incorporate these changes. They should result in very substantial speed-ups.
Bruce
Sounds really, really great. Looking forward to the new bins
____________
We're in the process of building and testing new executables (for all platforms) that incorporate these changes. They should result in very substantial speed-ups.
Any news? Are new binaries arriving?
I'd like to suggest to make anyway an SSE2 optimized version of the albert application (expecially for Win).
For Seti, I saw that the best boost is done with SSE2 optimization, and a lot of people own an SSE2 enabled CPU.
It shouldn't be too time-expensive to build only one optimized version...
____________
I'd like to suggest to make anyway an SSE2 optimized version of the albert application (expecially for Win).
For Seti, I saw that the best boost is done with SSE2 optimization, and a lot of people own an SSE2 enabled CPU.
Read below, in the same thread we are now, a post from Bernd Machenschalk. He has tested it, to find that SSE2 does not give a significant improvement over SSE in Linux compiling with gcc.
And for Windows, he says there is no significant improvement when using SSE or SSE2 over the default optimizations from MSVC compiler.
Read below, in the same thread we are now, a post from Bernd Machenschalk. He has tested it, to find that SSE2 does not give a significant improvement over SSE in Linux compiling with gcc.
Yes, but if they've to decide which set of instruction to use for improvements, I think SSE2 is the best one, because every fast CPU have it.
And for Windows, he says there is no significant improvement when using SSE or SSE2 over the default optimizations from MSVC compiler.
Ok, but it's only automatic recompiling. I think that if the "core code" is optimized by hand to support SSE or SSE2, it should be possible to get boost in performance.
Surely, it's not possible to handcode a lot of different versions, but if they chose one (such as SSE2 in example) I think it's quite easy to maintain that optimized version up-to-date.
Anyway... it's only a suggestion! ;-)
____________
While we are at it how about a client that can tap the power of my GPU? I saw an article some time in the past that with PCI-e video cards that it should be possible to use the CPU power of the GPU's.
Or is this too far fetched. I dont understand that much about coding just know many of us have a very powerfull videocard or 2 that is not being used when this client is running.
Add it to the wish list...
Troy
____________
While we are at it how about a client that can tap the power of my GPU? I saw an article some time in the past that with PCI-e video cards that it should be possible to use the CPU power of the GPU's.
How many different GPUs are in the wild? Who will test the application?
I think this is the biggest problem.
Yes, but if they've to decide which set of instruction to use for improvements, I think SSE2 is the best one, because every fast CPU have it.
Ok, but it's only automatic recompiling. I think that if the "core code" is optimized by hand to support SSE or SSE2, it should be possible to get boost in performance. Surely, it's not possible to handcode a lot of different versions, but if they chose one (such as SSE2 in example) I think it's quite easy to maintain that optimized version up-to-date.
I tried out a SSE2 versions on my Pentium-M. It was slower.
While we are at it how about a client that can tap the power of my GPU? I saw an article some time in the past that with PCI-e video cards that it should be possible to use the CPU power of the GPU's.
How many different GPUs are in the wild? Who will test the application?
I think this is the biggest problem.
I heard from someone over at SIMAP that there are two major flavors of GPUs. ATI and Nvidia. There are also some integrated intel gpus.
Apparently they have already been using gpus in Folding@home. One guy has a link to a gpu compiler, looks like it will definetly work for newer gpus of both flavors, and it might work for older ones.
At the bottom of his post he said
"Above readings may enable u to mount u 2 teraflops desktop at low cost
that is: about $20K
ps: 1 teraflop == 1000 gigaflops
Happy crunching :D"
I am a little skeptical of 2 TFLOPS, but if he is right then gpus could help a lot.
Here is the link to the SIMAP page about it. The gpu posts are at the bottom of the page.
EDIT: Sorry, I forgot to give you the link to download it incase you are interested.
____________
How many different GPUs are in the wild? Who will test the application?
I think this is the biggest problem.
There is currently only one line of GPUs (ATI) and only one family within that line (the 1600, 1800, 1900, etc) that is designed from scratch to be used for General Computing purposes, and AFAIK ATI has not yet released the specs for the General Computing API. According to the articles that I read at the time, their schedule called for releasing those API specs in late-1st qtr - early-2nd qtr of 2006, so any time soon...
This family of GPUs covers a broad cost range, from moderate to very expensive, and has now been out for about 4 months, so there are probably several already installed in some of our crunching rigs. I'm quite sure that those of you who have them would be happy to test.
Michael
____________
microcraft
"The arc of history is long, but it bends toward justice" - MLK
I agree: ATIs X1000 series is currently the most suitable for GPGPU (general purpose GPU). I know ATI wants to push this, however, I don't know how this will look specifically. It would be great if they'd provide highly optimized math libraries.
I think the biggest problem with GPGPU today is the 32bit precision (fp).
MrS
____________
Scanning for our furry friends since Jan 2002
I agree: ATIs X1000 series is currently the most suitable for GPGPU (general purpose GPU). I know ATI wants to push this, however, I don't know how this will look specifically. It would be great if they'd provide highly optimized math libraries.
I think the biggest problem with GPGPU today is the 32bit precision (fp).
MrS
I think I'll try to contact them (ATI) to see how they're coming along toward releasing developers' specs. I'm not a dev by any stretch of the imagination, but if we could get something more solid to work with ...
____________
microcraft
"The arc of history is long, but it bends toward justice" - MLK
A36
whats the link for??
____________
Join us in Chat (see the forum) Click the Sig
Join UBT
A36
Thanks!
____________
A36
If this is what I think it is, thanks a bunch! I've been waiting.
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
Akosf, that's really, really great: an speed improvement of 2.3x for my Athlon XP. The completion time is reduced from 4h to be only 1h 45min now.
I hope E@H team will release soon this new applications for all platforms, the "200 days to completion" will be hugely reduced.
But it will be necessary to increase again the maximum number of WU's per day a host can download. Faster machines will process now much more WU's per day.
Or, in the future, I suppose the WU's size should be increased, to avoid overloading the data server.
Akosf, that's really, really great: an speed improvement of 2.3x for my Athlon XP. The completion time is reduced from 4h to be only 1h 45min now.
I am thinking I will have to switch my Linux clients back to using wine again..
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
A36
Thank you for your hard work and generousity! :)
I do feel a little strange using an unauthorized client version, but I guess the proof is in the pudding as they say, meaning that if the results are accurate, then presumably there is no downside to using the application.
____________
Regards,
Bob P.
A36
VERY fast app! Outstanding work, akosh! WU completed in 41.5% of CPU time under official app. Now, just to wait and see if it validates, and as josep said, Bruce will have to up the daily quota again.
@ Bruce - Just a suggestion - when you multiplied the quota, it might have been a good idea to also multiply the penalty for errored results. When working with a quota of 32, putting a 1 WU penalty on a serial-error host is going to take forever to limit the damage. When the daily "q" was 8, a penalty of 1 was significant, a fast-working deterent.
Respects,
Michael
____________
microcraft
"The arc of history is long, but it bends toward justice" - MLK
Now, just to wait and see if it validates...
Michael
The amazing thing is, it does validate!
____________
Regards,
Bob P.
And temperature of CPU is less than using official albert.exe.
Thanks
____________
Akosf, that's really, really great: an speed improvement of 2.3x for my Athlon XP. The completion time is reduced from 4h to be only 1h 45min now.
I am thinking I will have to switch my Linux clients back to using wine again..
I have put two of my linux machines back into wine mode running the new windows binary from Akosf, so far it appears they are also enjoying the same speed increase. I will know for sure once they are done computing.
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
Thanks,
I'll test the App on my test box and if it works I will turn up a few cruncher boxes using this app!!!
Troy
____________
A36
Thank you very much!
3 Win-Hosts, Athlon T-Bird, Athlon XP 2400+ and Athlon 64 X2 4400+ all need less than half of the time for a wu now, as before.
All results are valid so far.
CPU-temperature seems to be 1 to 2 °C lower too.
I hardly dare to ask if it would be much work to compile albert II as a linux-app?
cu,
Michael
____________
VERY fast app! Outstanding work, akosh! WU completed in 41.5% of CPU time under official app. Now, just to wait and see if it validates, and as josep said, Bruce will have to up the daily quota again.
I can only agree.
Only needed 40.6% of the time on a sempron3000.
____________
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
Now I know what this is, a little advice I assume I just put the file in the Einstein folder and just rename the old EXE in there similar to when doing it for SETI??
____________
Join us in Chat (see the forum) Click the Sig
Join UBT
Now I know what this is, a little advice I assume I just put the file in the Einstein folder and just rename the old EXE in there similar to when doing it for SETI??
1. Download file.
2. Unzip file
3. Move the file to the C:/Program Files/BOINC/projects/einstein.phys.uwm.edu/ directory
4. Restart boinc
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
Now I know what this is, a little advice I assume I just put the file in the Einstein folder and just rename the old EXE in there similar to when doing it for SETI??
1. Download file.
2. Unzip file
3. Move the file to the C:/Program Files/BOINC/projects/einstein.phys.uwm.edu/ directory
4. Restart boinc
Thanks thought that would be the answer
____________
Join us in Chat (see the forum) Click the Sig
Join UBT
Thanks thought that would be the answer
Not a problem! ;)
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
I would like to know how Dr. Bruce feels about the optimized app before installing. I know it is validating and things, but getting a better official word makes me feel better.
So, is it good for us to use?
____________
According to general purpose computation on gpus the following page might be interesting:
http://www.gpgpu.org/
@akos
How did you optimize the application without having the source code present? Do you use some tools analysing the app while calculating?
btw: Well done! :-D
____________
Greetings, Santas little helper
I would like to know how Dr. Bruce feels about the optimized app before installing. I know it is validating and things, but getting a better official word makes me feel better.
So, is it good for us to use?
I would like to know, too, although I suspect an "official" endorsement by a project official may not be immediately possible. If for no other reason, there may be some legal agreements that may need to be put into place before an application "from the wild" can be accepted by this very large and publically (governmentally) funded project.
But anyway, we hope Bruce responds in some manner as this software will most likely continue to spread by "unofficial" word of mouth. :)
____________
Regards,
Bob P.
I would like to know how Dr. Bruce feels about the optimized app before installing. I know it is validating and things, but getting a better official word makes me feel better.
So, is it good for us to use?
I would like to know, too, although I suspect an "official" endorsement by a project official may not be immediately possible. If for no other reason, there may be some legal agreements that may need to be put into place before an application "from the wild" can be accepted by this very large and publically (governmentally) funded project.
But anyway, we hope Bruce responds in some manner as this software will most likely continue to spread by "unofficial" word of mouth. :)
Too late now the cat is out of the bag!! lol!!
____________
Join us in Chat (see the forum) Click the Sig
Join UBT
Well, I can tell you it doesn't work for a K6-2 running 9x.
Moral of story:
1.) Make sure you exercise some caution before you slipstream it to all your hosts. Related to this, since this opti is essentially an RE hack, that might explain why Dr. Allen wanted to run it through the testing loop before releasing it as an "official" EAH app, because of problems like that.
2.) To announce to the EAH community with a potential CAYS link, with no explanation or even a link to a site to allow anyone to see what's up about it is irresponsible, regardless of how clever the work is.
3.) My gut feeling is Dr. Allen is not going to be too thrilled about this development.
Alinator
Moral of story:.....
2.) To announce to the EAH community with a potential CAYS link, with no explanation or even a link to a site to allow anyone to see what's up about it is irresponsible, regardless of how clever the work is.
Alinator
Perhaps a low level link was intentional to limit access to only the most "savvy" users who would be able to deal with any problems, but nonetheless, I am just as irresponsible in using the application. No one is forcing me to use it....
____________
Regards,
Bob P.
Moral of story:.....
2.) To announce to the EAH community with a potential CAYS link, with no explanation or even a link to a site to allow anyone to see what's up about it is irresponsible, regardless of how clever the work is.
Alinator
Perhaps a low level link was intententional to limit access to only the most "savvy" users who would be able to deal with any problems, but nonetheless, I am just as irresponsible in using the application. No one is forcing me to use it....
exactly as with any optimised client there is always risk and most users know that
____________
Join us in Chat (see the forum) Click the Sig
Join UBT
I would like to know how Dr. Bruce feels about the optimized app before installing. I know it is validating and things, but getting a better official word makes me feel better.
So, is it good for us to use?
I don't know about you, but it feels damn good to me :)
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
A36
I tested the very fast application on my Intel P4 3.2 GHz with active HT.
Crunching times nearly the half of the original Albert.
But, the temperature (copper-core oft the cooling unit, checked with Digital Voltmeter and VCR ) will be nearly 10 Degrees lower!
Many Thanks to You. You have done an excellent work!
Chris
---
SpecialOffTopic-Team - FileBase
http://www.cmds.tk
Bruce's looked over the code changes for the optimization, praised them and promised new apps for all platforms using them, so I think any objection would be pro forma at worst.
The drop in cpu temp's probably related to the fact that the biggest algorithm change removed most of the slow division ops, so you're not using that part of your FPU much.
____________
Akosf wrote earlier in this tread:
Any results on this so far? Any beta-testers needed? :)I would like to help on speed optimization, but i don't know what is the way of it. Probably i can put my code on a webpage, but i think it would be not legal. I didn't get any e-mails in connection with legitimacy.
Something made him change his mind. We know from earlier in this thread that he has shown his optimized client to Bruce. His post only contained the link to the application. No installation instructions, so you need some familiarity with BOINC file structure to be wiling to install it. Look at the timestamp of his post.
Posted 7 Mar 2006 6:59:08 UTC
If you wanted to release a test application, isn’t just before work Tuesday morning an excellent time to do so, if you want to keep an eye on things. (just before 8 in Germany)
The sent back result contains this massage:
�Optimized by akosf (A-36) --> 'projects/einstein.phys.uwm.edu/albert_4.37_windows_intelx86.exe'�
If Bruce made a post wanting us for some reason to stop using this client, wouldn’t most of us reading this thread uninstall it so fast it would make a gravitational wave even SETI could detect. :)
Is that the X-files theme I hear in the background? :)
____________
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
PS has anyone tested it on an amd platform? I've got it running on my a64x2 and it hasn't crashed, but it'l lbe afew hours before I've got validatable results.
____________
Akosf wrote earlier in this tread:
Any results on this so far? Any beta-testers needed? :)I would like to help on speed optimization, but i don't know what is the way of it. Probably i can put my code on a webpage, but i think it would be not legal. I didn't get any e-mails in connection with legitimacy.
Something made him change his mind. We know from earlier in this thread that he has shown his optimized client to Bruce. His post only contained the link to the application. No installation instructions, so you need some familiarity with BOINC file structure to be wiling to install it. Look at the timestamp of his post.
Posted 7 Mar 2006 6:59:08 UTC
If you wanted to release a test application, isn’t just before work Tuesday morning an excellent time to do so, if you want to keep an eye on things. (just before 8 in Germany)
The sent back result contains this massage:
�Optimized by akosf (A-36) --> 'projects/einstein.phys.uwm.edu/albert_4.37_windows_intelx86.exe'�
If Bruce made a post wanting us for some reason to stop using this client, wouldn’t most of us reading this thread uninstall it so fast it would make a gravitational wave even SETI could detect. :)
Is that the X-files theme I hear in the background? :)
Be that as it may, and I am implying no malfeasance on Akosf's part in reverse engineering Albert, or malintent in his "obscure" test release. The fact remains that if EAH wanted to have app version variety in the wild they would have made the source code freely available and encouraged folks to have at it, like SAH does.
I took Dr. Allen's prompt and positive responses as an indicator he found the proof-of-concept app had merit, but we would have to wait until as many of the ramifications of full scale release could be evaluated and addressed.
Alinator
PS has anyone tested it on an amd platform? I've got it running on my a64x2 and it hasn't crashed, but it'l lbe afew hours before I've got validatable results.
I've completed two and two halfs (units started under old finished under new). One and two halfs have validated successfully, the 4th WU is waiting on someone else, and won't be validated for annother day or two.
I've gone from 3:45+-15 per large WU to 1:40/WU.
CPU temp hasn't deltaed more than a degree or three at most (I didn't check beforehand), but a64s aren't blastfurnaces to begin with.
____________
Akosf, that's really, really great: an speed improvement of 2.3x for my Athlon XP. The completion time is reduced from 4h to be only 1h 45min now.
I hope E@H team will release soon this new applications for all platforms, the "200 days to completion" will be hugely reduced.
But it will be necessary to increase again the maximum number of WU's per day a host can download. Faster machines will process now much more WU's per day.
Or, in the future, I suppose the WU's size should be increased, to avoid overloading the data server.
I wound up getting a bunch of small WUs right after I installed this on my XP 1600 system and slammed into the max quota per day within 12 hours. :-P
If I had gotten the big WUs instead of the small ones I would have been fine. Oh well, crunch Seti for a while.
____________
Seti Classic Final Total: 11446 WU.
I have put two of my linux machines back into wine mode running the new windows binary from Akosf, so far it appears they are also enjoying the same speed increase. I will know for sure once they are done computing.
There is definitely the same speed increase using the windows binary under wine(as to be expected). So for those brave few, time to bust out wine again to make Linux match up to the new and improved windows binary.
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
I wound up getting a bunch of small WUs right after I installed this on my XP 1600 system and slammed into the max quota per day within 12 hours. :-P
If I had gotten the big WUs instead of the small ones I would have been fine. Oh well, crunch Seti for a while.
Randy,
That SUX!
BTW, What does the "tx36" mean on your BOINC client? Nice FP benchies!
Michael
____________
microcraft
"The arc of history is long, but it bends toward justice" - MLK
BTW, What does the "tx36" mean on your BOINC client? Nice FP benchies!
That's one of those "optimized" clients by Trux.
A link to a S@H thread.
Michael
____________
Team Linux Users Everywhere
One little problem I noticed, I am claiming 0 cpu time, and 0 credits for some of my machines that are running the windows binary under linux with wine.
Example: http://einstein.phys.uwm.edu/results.php?hostid=564143
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
A36
Can I say WOW! Between 39.5-40.5% decrease in crunch times on my 2 fastest machines. A couple of results have successfully validated.
Great Job!
I wound up getting a bunch of small WUs right after I installed this on my XP 1600 system and slammed into the max quota per day within 12 hours. :-P
If I had gotten the big WUs instead of the small ones I would have been fine. Oh well, crunch Seti for a while.
Yeah, we really do need the quota increased again now..
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
Akosf's app is running fine on all of my machines. It's kind of a hoot to see a 1.2 Gig P3 beat an Athlon 64 3000+. Great work!!!
____________
Ive been running his app on my 600mhz p3 which is overclocked to 800, increasing the fsb from 100 to 133 mhz and it is fine with it. For some reason it cant handle seti optimized 4.11 but this it does fine with
____________
Akosf's app is running fine on all of my machines. It's kind of a hoot to see a 1.2 Gig P3 beat an Athlon 64 3000+. Great work!!!
Well I just implemented it on one so ...;-) :-)
____________
I got a quota hit warning too, but that had more to do with my having a 3 day quota and each new result taking a bite out of the eta for each of the others. At 80-100m per big WU unless I get a swarm of little ones at once I should be ok.
____________
Noticed something interesting. The optimized app's benefitting small WUs alot more than big ones. My time on big WU's has gone from 210-240m to 80-100m or a ~2.5x speedup. I had a handfull of small WUs as well. They went from ~60m to 11-12m a 5x gain.
____________
I got a quota hit warning too, but that had more to do with my having a 3 day quota and each new result taking a bite out of the eta for each of the others. At 80-100m per big WU unless I get a swarm of little ones at once I should be ok.
Now THIS is REALLY disappointing. At 8 min. after midnight (UTC) my XP 1600 system downloaded two .DAT files and immediately parsed them out to 32 WUs. It then flagged that system as at Max Quota for the day...this was at 12 min. past midnight (UTC).
According to BoincView, all 32 WUs are short ones that my system will burn thru in about 21 min. each. That gives me just under 12 hrs of crunching on that system before they're all gone. Looks like I'm getting the swarm of little ones you were worried about. Well, Seti will get more crunching when I'm out of Einstein WUs.
I downloaded the optimized app so I could do MORE work for Einstein and chop down that 200 days number a bit. I guess if I do work more efficiently for Einstein, I can contribute more to DC as a whole once I hit my E@H quota.
387 (win app. for older processors)
387 (win app. for older processors)
Could you give a breakdown of what procs will be able to use the first app, and which'll need this one instead?
____________
Could you give a breakdown of what procs will be able to use the first app, and which'll need this one instead?
387: 387 compatible
Axx: Pentium Pro compatible
Ixx: Pentium Pro compatible (but it uses fsincos instruction instead of taylor-series, because the fpu of netburst based processors not so strong)
387 (win app. for older processors)
Hi akosf
What type of "optimized Client" do you use? I see Boinc 4.45 at your hostlist.
Is this the old Standard Boinc version?
I use your A36 and the Boinc 5.3.6(tx), but I´ll never reached your Benchmarks.
Give us a tip, please.
Thanks for your good work.
Chris
Could you give a breakdown of what procs will be able to use the first app, and which'll need this one instead?
387: 387 compatible
Axx: Pentium Pro compatible
Ixx: Pentium Pro compatible (but it uses fsincos instruction instead of taylor-series, because the fpu of netburst based processors not so strong)
Your meens is that new than Pentium Pro should use A36,and the older use 387.
Is it?
____________
Wish you can understand my English:)
What type of "optimized Client" do you use? I see Boinc 4.45 at your hostlist. Is this the old Standard Boinc version?
I use your A36 and the Boinc 5.3.6(tx), but I?ll never reached your Benchmarks.
Give us a tip, please.
I use a modified 4.45 client. It's enough to me.
Oh, yes... the current benchmark system is funny, because usage of higher benchmark values realizes higher granted credit average. You can download officially "revised" clients from here.
Ixx: Pentium Pro compatible (but it uses fsincos instruction instead of taylor-series, because the fpu of netburst based processors not so strong)
So, is the Ixx version better for Pentium IV?
I'm testing your A36 in a Pentim IV Northwood 2.4Ghz with good results, but if there is a better specific version, could you link this one here, as the two previous ones?.
Thank you very much for your effort, Akosf
387: 387 compatible
Axx: Pentium Pro compatible
Your meens is that new than Pentium Pro should use A36,and the older use 387.
Is it?
Not exactly.
"Pentium Pro compatible" means that the target processor has to be able to execute all instructions of Pentium Pro processor to run this code.
Example: Pentium Pro was introduced in 1995, but AMD K6-III is not compatible with it. K6-III was released in second half of 1999.
So, is the Ixx version better for Pentium IV?
Yes, it is faster but just with some percentages.
A36 running on 2xXeon4 (S603, HT), 2xPIIIs Tualatin, XP T-Bread and 2xMP T-bread now, no trouble so far.
Those results that I switched to A36 in the middle of the calculation have survived it (as it isn't using anonymous platform and doesn't need app_info.xml), one of them already validated OK.
Good work, thanks !
This is wierd.. I've tried the A36 on four different machines and I'm not seeing any difference in performance at all. As far as I can tell, I've got it installed properly - I'm just not seeing any difference in speeds.
*Edit: Okay.. perhaps I was going by the wrong thing.. benchmarks don't seem to change any, but after watching the client for a while it seemed to be going a little faster than the expected time for similar workunits. I guess I'll just leave it on a machine for a while and check back after work when I get home.
____________
"Beer is proof that God loves us and wants us to be happy." -- Benjamin Franklin
---
Installed on all 4 pc's today.
The first 1 that crunched a whole wu, went from 1.36 hours to 40 mins (an XP2000), and validated 100% ok.
Great job akosf.
Keep up the good work.
Thx from 1 happy camper
____________
387 (win app. for older processors)
Thanks for your continued efforts. Seems to be running fine on a K6-2, and hopefully I'll be back in around 100 Ksecs. or so with a positive report! :-)
Also, apologies if you were offended by my initial criticism of the test release. None was intended.
Alinator
Thanks for your continued efforts. Seems to be running fine on a K6-2, and hopefully I'll be back in around 100 Ksecs. or so with a positive report! :-)
Probably this code isn't the best for K6-2, but I hope that it will be faster than original.
*Edit: Okay.. perhaps I was going by the wrong thing.. benchmarks don't seem to change any,
You are of course correct, the benchmarks refer to the fundamental operating characteristics of your machine, and are not related to any software that the machine is running.
____________
Regards,
Bob P.
Noted, but at around 200K for stock Albert I'll take anything I can get!
Thanks again for the updated apps and further guideline info.
Alinator
"It's all so clear to me now." - David Bowman(2010)
Yes, my initial misunderstanding was in thinking that this A36 file would affect the benchmarks -- obviously incorrect.
I'm pleased to report that the P4 2.66 I have at work is now completing work in roughly 35 to 40 percent less time than before.
Thank you akosf for your programming talent and interest in sharing! :)
____________
"Beer is proof that God loves us and wants us to be happy." -- Benjamin Franklin
---
A36 running on a Barton 3000+ (Boinc 4.32)
Absolutely amazing :
wu 5565823 : 7,039.09 sec
wu 5570033 : 2,100.00 sec
I think that time is 50 % percent less than before.
____________
[
A36 running on a Barton 3000+ (Boinc 4.32)
Absolutely amazing :
wu 5565823 : 7,039.09 sec
wu 5570033 : 2,100.00 sec
I think that time is 50 % percent less time than before.
Mine is also 50% quicker than it used to be. I love it
____________
Join us in Chat (see the forum) Click the Sig
Join UBT
Can't thank you enough Akosf. Using standard app time was 4hrs 20min on my xp2500+ @ 2.1 Ghz. Now using for two days your A36 and times dropped to 1hr 45min. THat makes it almost 2.5 times faster, amazing! And the short wu only take 30min.
:)
____________
98SE XP2500+ @ 2.1 GHz Boinc v5.8.8
Can't thank you enough Akosf. Using standard app time was 4hrs 20min on my xp2500+ @ 2.1 Ghz. Now using for two days your A36 and times dropped to 1hr 45min. THat makes it almost 2.5 times faster, amazing! And the short wu only take 30min.
:)
The really short WUs will be faster still. I went from ~60m eta on some using the old app, to 11-12m using A36, on my 2.4gig A64x2.
____________
Can't thank you enough Akosf. Using standard app time was 4hrs 20min on my xp2500+ @ 2.1 Ghz. Now using for two days your A36 and times dropped to 1hr 45min. THat makes it almost 2.5 times faster, amazing! And the short wu only take 30min.
:)
Hmmm. Curious as to why your 'short' WUs are taking so 'long'. My XP 1600 is cranking them out at 21-25 min. each.
OTOH, maybe your 'short' WUs are longer than mine.
[EDIT to fix link]
____________
Seti Classic Final Total: 11446 WU.
They probably are longer. My machines about the same speed as his, and I've got a clutch with 25-30m etas about 2.5days down the queue.
____________
387: 387 compatible
Axx: Pentium Pro compatible
Ixx: Pentium Pro compatible (but it uses fsincos instruction instead of taylor-series, because the fpu of netburst based processors not so strong)
Sorry, but having little experience with recent* computers other than Macs I find all the different kinds of processors out there very confusing. Can anyone tell me with which of the above an AMD "Athlon XP 2000+" and an Intel "x86 Family 15 Model 2 Stepping 9" would be considered compatible—or point me to a good reference?
(* Meaning less than a couple of decades old.)
____________
netburst is p4. and would use A37.
I think pentium-M is based on p3 and would use A36. As would athlons.
The 387 client is only needed for P1s and K6s. Possibly the very lower power/performance cpu that from Cyrex currently owned by Via(??) might be equally neutered.
____________
387 -> 386, Family 4 (486,5x86,MediaGX), Family 5 (Pentium,PentiumMMX,K5,K6(all),6x86,MediaGX-MMX) and some others oldies.
A36 -> Family 6 (AMD K7 core processors,PentiumPro,PentiumII,PentiumIII,6x86MX,M2), Family 7 (Itanium), Family 15 (Athlon64,Pentium4 and so...)
I don't have enough info about the newer Cyrix-VIA processors, probably the 0.25u and 0.35u size processors are not compatible with Pentium Pro.
387 -> 386, Family 4 (486,5x86,MediaGX), Family 5 (Pentium,PentiumMMX,K5,K6(all),6x86,MediaGX-MMX) and some others oldies.
A36 -> Family 6 (AMD K7 core processors,PentiumPro,PentiumII,PentiumIII,6x86MX,M2), Family 7 (Itanium), Family 15 (Athlon64,Pentium4 and so...)
For those who don't know which family their CPU belongs to, grab a copy of CPU-Z. It will tell you.
387 -> 386, Family 4 (486,5x86,MediaGX), Family 5 (Pentium,PentiumMMX,K5,K6(all),6x86,MediaGX-MMX) and some others oldies.
A36 -> Family 6 (AMD K7 core processors,PentiumPro,PentiumII,PentiumIII,6x86MX,M2), Family 7 (Itanium), Family 15 (Athlon64,Pentium4 and so...)
For those who don't know which family their CPU belongs to, grab a copy of CPU-Z. It will tell you.
I ran the cpu-z program but it says family F, though the model is 4. It is a p4(ht) 630, 3.0G prescott, sse3 (em64t). I've been using the A36, that is correct i hope? Thank you very much akosf for the optimization, it has helped this computer out immensely. :)
____________
They probably are longer. My machines about the same speed as his, and I've got a clutch with 25-30m etas about 2.5days down the queue.
The ones that I was getting at the time of the switch and crunched with std app took ~75 min. Then the others done with A36 finished in 32 min. That is still the same rate of increase I saw with the longer wu's.
:)
____________
98SE XP2500+ @ 2.1 GHz Boinc v5.8.8
Umm, *cough* My processor knowledge isn't "top of the pops" exactly. It seems that the A36 best for the Pentium M 745, is that correct?
/S
Umm, *cough* My processor knowledge isn't "top of the pops" exactly. It seems that the A36 best for the Pentium M 745, is that correct?
Pentium M -> Family 15 -> A36 will be good.
I just want to say wow.
A WU averige went from 3,6H to 1,6 H. :)
Thanks akosf
____________
A36 works well on old Celeron 1.1GHz, cut times of units that used to take 34+ksecs to under 15ksecs.
So akosf, any chance of making an optimized Linux client? If you need access to a Linux machine, I can give it to you.
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
So akosf, any chance of making an optimized Linux client? If you need access to a Linux machine, I can give it to you.
Well, I'm to be accustomed to windows, but if somebody give me a linux executable code than I can do a try to modify it by a hexadecimal editor.
Well, I'm to be accustomed to windows, but if somebody give me a linux executable code than I can do a try to modify it by a hexadecimal editor.
Here't is:
http://homepage.hispeed.ch/einstein/albert_4.40_i686-pc-linux-gnu.zip
____________
Since installing A36 my times have fallen by more than half. Going from 75k+ seconds to around 28k seconds is a huge drop in compute time. Puts new life back in these old cpu's and will save me both time and money. I can do more work, in less time, on the same hardware, for the same cost!
All I can say is "THANKS"!!!!!!!!!!! Now it's time to install A36 on the last 4 'puters.
____________
Thanks for your continued efforts. Seems to be running fine on a K6-2, and hopefully I'll be back in around 100 Ksecs. or so with a positive report! :-)
Probably this code isn't the best for K6-2, but I hope that it will be faster than original.
Roger that, but even though it may not be optimum for the K6 family, it's looking at this point like it's still going to be about twice as fast as stock Albert! Sweet! :-)
Alinator
...it's looking at this point like it's still going to be about twice as fast as stock Albert! Sweet! :-)Alinator
This "unofficial" Beta test of ours seems to be going quite well! :)
One hopes the official powers that be will release this as an official release so that the entire project can benefit from this wonderful optimization!
____________
Regards,
Bob P.
...it's looking at this point like it's still going to be about twice as fast as stock Albert! Sweet! :-)Alinator
This "unofficial" Beta test of ours seems to be going quite well! :)
One hopes the official powers that be will release this as an official release so that the entire project can benefit from this wonderful optimization!
The feeling I get is that it will happen rather quickly, though there may be some delay while they try to massage the code for our folks on Linux and older, non-Altivec Macs. Shouldn't forget the Solaris, either.
I expect there will be a scramble to upgrade the servers, too, to handle the vastly increased throughput.
____________
microcraft
"The arc of history is long, but it bends toward justice" - MLK
...it's looking at this point like it's still going to be about twice as fast as stock Albert! Sweet! :-)Alinator
This "unofficial" Beta test of ours seems to be going quite well! :)
One hopes the official powers that be will release this as an official release so that the entire project can benefit from this wonderful optimization!
The feeling I get is that it will happen rather quickly, though there may be some delay while they try to massage the code for our folks on Linux and older, non-Altivec Macs. Shouldn't forget the Solaris, either.
I expect there will be a scramble to upgrade the servers, too, to handle the vastly increased throughput.
Hope they increase the daily quota too. I've got one system that runs out of WUs (the small ones) in less than 12 hrs. (That's all it's been getting since I switched to the optimized app.)
A36 runs perfectly on my Barton 3000+.
No crash, wus validated OK
It's time now to install A36 on a Barton 2500+ and an Athlon64 3200+
Definitively, a superb application
Thanks to you and kudos Akosf.
____________
[
Hope they increase the daily quota too. I've got one system that runs out of WUs (the small ones) in less than 12 hrs. (That's all it's been getting since I switched to the optimized app.)
I just got a batch that's running around 14 minutes each. At that rate, I'll be out in less than 8 hours. I don't run anything but einstein now, so if they don't increase the quota, my cpus will get some well deserved rest.
Terry
Currently testing the new app and its really nice :-)
Going like 1 minute = 1 % on my Athlon 64 3000+ :D
____________
I examined the linux code closely. It's horrible.
The 'blind flying' type optimization is hopeless. I'm sorry...
Probably a better compiler would be able to increase its performance significantly.
I examined the linux code closely. It's horrible.
The 'blind flying' type optimization is hopeless. I'm sorry...
Probably a better compiler would be able to increase its performance significantly.
Thanks for looking anyway. Nobody can do everything (and do a good job of it, that is).
The feeling I get is that it will happen rather quickly, though there may be some delay while they try to massage the code for our folks on Linux and older, non-Altivec Macs. Shouldn't forget the Solaris, either.
I expect there will be a scramble to upgrade the servers, too, to handle the vastly increased throughput.
IT depends. Judging from comments Bruce's made earlier the gains from hand optimization vs letting the compiler do all the work are very minimal outside of altivec macs. Which means that first he'll have to convert aksof's enhancements (improvment's in the fundamental algorithm) back into C(++?) and build executables for all the various platforms before releasing anything.
____________
I´m going to test this optimized version on this: Opteron 144@2,2GHz@DFI nForce IV ultra infinity, 1024 MB RAM@400MHz@dualchannel. Now, a time for one "normal" wu is about 4,350 seconds. Just wait and you will know it too...
____________
First result in for K6-2/500:
28:59:10, Not too shabby for a slug.
WOW, previous run times with Albert were in the 55-60 hr ballpark.
VERY Sweet!
Alinator
I´m going to test this optimized version on this: Opteron 144@2,2GHz@DFI nForce IV ultra infinity, 1024 MB RAM@400MHz@dualchannel. Now, a time for one "short" wu is about 4,350 seconds and for the "normal" about 15,450. Just wait and you will know it too...[
____________
I´m going to test this optimized version on this: Opteron 144@2,2GHz@DFI nForce IV ultra infinity, 1024 MB RAM@400MHz@dualchannel. Now, a time for one "short" wu is about 4,350 seconds and for the "normal" about 15,450. Just wait and you will know it too...[
First "short" WU - 1,907.97seconds.
____________
This is all quite amazing!
May I propose a hearty round of applause to akosf?
for( int i = 1; i < SOME_BIG_NUMBER; ++i )
{
Clap();
Grin();
Print( 'This guy rocks!' );
++kudos;
}
Cheers, Mike. :-)
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
ECS K7sem Mainbord
on-board AMD Duron 892MHz CPU (8.5 x 105) Codename:Spitfire, Athlon lite
on-board Graphics
VIA chip set
256MB SDRAM PC133 (Kingstone)
OS: Win98SE
Boinc app. ver.4.19
Standard average performance 40,324.00 sec.
Average performance with A387 24,943.14 sec.
Average performance with A36 15,122.16 sec.
Units validated with both clients
Cheap configuration with great output thanks to Akosf.
If you cant upgrade the CPU call Akosf :-)
With respect
Screbilde
____________
"The FUTURE is only a PARTICLE away from the PRESENT and the PAST."
Just ran 2 on my p4 3.2ghz with 512mb ram
time..taken---------claimed credit
8,198.38-------------17.82
8,049.83--------------17.50
____________
I´m going to test this optimized version on this: Opteron 144@2,2GHz@DFI nForce IV ultra infinity, 1024 MB RAM@400MHz@dualchannel. Now, a time for one "short" wu is about 4,350 seconds and for the "normal" about 15,450. Just wait and you will know it too...[
"normal" is about 6,600seconds. Great job!
____________
Puts new life back in these old cpu's and will save me both time and money.
Erm, no. Related just to credit, the new boostapp will do nothing. The only one who's getting use out of it is the project itself and science intended crunchers (like me) ;-). AFAIK simply because your credit is just referred to your crunching speed (FLOPS/IOPS) and time (crunching 10k seconds on 2 wus instead of 1 does't change the total time spent for the project, it just cuts the credit in half per wu).
I can do more work, in less time, on the same hardware, for the same cost!
Yes, more work units are done :-)
____________
Greetings, Santas little helper
Puts new life back in these old cpu's and will save me both time and money.
Erm, no. Related just to credit, the new boostapp will do nothing. The only one who's getting use out of it is the project itself and science intended crunchers (like me) ;-). AFAIK simply because your credit is just referred to your crunching speed (FLOPS/IOPS) and time (crunching 10k seconds on 2 wus instead of 1 does't change the total time spent for the project, it just cuts the credit in half per wu).
I can do more work, in less time, on the same hardware, for the same cost!
Yes, more work units are done :-)
Did I say anything about credit? It saves time because it does more WU's in the same amount of time and I don't have to think about upgrading the systems. That's pretty simple isn't it?
____________
Did I say anything about credit? It saves time because it does more WU's in the same amount of time and I don't have to think about upgrading the systems. That's pretty simple isn't it?
How will it save money and time to you? If you're counting wus(useless for yourself(!), just useful for the project itself) then ok. Nothing related to BOINC recuires an upgrade so you are not forced to do so. If the app gets faster and all use it your system is relatively as slow as before so if you want to speed up relative to the others the need of new hardware is clear independent of the software ...
btw: this is no attack on your person, k? I just wanted to illustrate the situation for credit hunters ... chill out :)
____________
Greetings, Santas little helper
Puts new life back in these old cpu's and will save me both time and money.
Erm, no. Related just to credit, the new boostapp will do nothing. The only one who's getting use out of it is the project itself and science intended crunchers (like me) ;-). AFAIK simply because your credit is just referred to your crunching speed (FLOPS/IOPS) and time (crunching 10k seconds on 2 wus instead of 1 does't change the total time spent for the project, it just cuts the credit in half per wu).
Unless the other 2 people working on the same unit don't have the optimized albert app, in which case you get their credit for the WU instead of your own, and double your credit!
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
Unless the other 2 people working on the same unit don't have the optimized albert app, in which case you get their credit for the WU instead of your own, and double your credit!
OK you're right, but it's not the aim of the project that everyone uses a different app ... I hope that all ppl will use a faster software soon
____________
Greetings, Santas little helper
Unless the other 2 people working on the same unit don't have the optimized albert app, in which case you get their credit for the WU instead of your own, and double your credit!
OK you're right, but it's not the aim of the project that everyone uses a different app ... I hope that all ppl will use a faster software soon
Completely agreed. Maybe we should just get rid of credit to avoid half of the posts in this forum ;)
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
How will it save money and time to you? If you're counting wus(useless for yourself(!), just useful for the project itself) then ok. Nothing related to BOINC recuires an upgrade so you are not forced to do so. If the app gets faster and all use it your system is relatively as slow as before so if you want to speed up relative to the others the need of new hardware is clear independent of the software ...
btw: this is no attack on your person, k? I just wanted to illustrate the situation for credit hunters ... chill out :)
OK, I'll make this simple for you: I have 2 P4's, one is a 2.8e and the other is a socket 423 @ 1.5Ghz, everything else is either dual or quad PIII Xeons at 500-700Mhz. Since the changes to the app allow each cpu to do more work in a give length of time, that makes the cost per WU go down. We are talking cost of the power to keep the farm running. Overall cost stays the same but the cost per WU is reduced.
Run time for the old Xeons was in the range of 75k-95k per WU, depending on the speed of the cpu in question. Time per WU has dropped to 25-30k. The only other way to increase output would be to replace the systems I already have since they are all running the fastest cpu's they will support. Or, I could add another 6-7 machines of the same speed. Hence, it saves me money because I don't need to replace the systems, or add new ones to increase the amount of work done. And, it saves me time because I don't have to spend the time, and money, looking for the parts I need nor do I have to spend the time to build new systems. It saves me time and money, with the added benefit to the project of getting more WU's done in a given length of time with the resources they have available to them.
____________
At any time independent of the used app you could buy new hardware and increase the work done. This is not the point we are talking about. You write that the money/wu is reduced. Absolutely correct but wus are crucial for the project not for your person.
"it saves me money because I don't need to replace the systems"
-> You would save time and money if you want to reach a certain crunching speed related to wus done but this is weird. There is no "need" from the project side.
"it saves me time because I don't have to spend the time, and money, looking for the parts I need nor do I have to spend the time to build new systems"
-> you dont "have to" spend the time and money, who is forcing you to do so? Maybe you force yourself? This is independent of the software. I can force myself too to build another system, yes, now, tomorrow, yesterday ...
"I could add another 6-7 machines"
-> I could too, at any time, whether the app speeds up or not that not the point ...
Lets think about the theoretical case the S4 analysis is done and you worked until the end. If you now stop crunching anything, then you have saved money and time because you are finished earlier, ok. But I guess you will search for another task for your cpus (S5 or something completely different) and if they are finished you are again searching and so on ... so your cpus are used all the time, indepently to what project they contribute. So money and time is the same.
So we see, we all could but nobody has to upgrade. Just if you want to enlarge your contribution to the project there is a need to buy new hardware if the app doesn't change. Maybe you are so noble-minded and still want to increase working speed then it's a break for you and you would save money and time for a certain moment ... :-)
OK, let's finish with that, I think it's getting boring ^^
____________
Greetings, Santas little helper
Santas little helper:
You have missed the point completely, three times!
____________
for Info, with the new optimized Client
Albert WUs about 1:30
with my Athlon64 3.200+
Greetings from Germany NRW
Ulli 
for Info, with the new optimized Client
Albert WUs about 1:30
with my Athlon64 3.200+
Greetings from Germany NRW
Ulli
My Athlon XP 2800+ on Windows XP Home went from 15380 sec to 6598 sec. Claiming about half the credit, but I was rarely getting what I claimed before anyway, with the optimized BOINC client.
____________
I've tried to run akosfs code on a linux box by using wine, but i've got a strange effect, look at this:
http://einstein.phys.uwm.edu/results.php?hostid=566983
Time reportet is almost everywhere zero, but it took always about 13000s to complete. But luckily the workunits get validated though.
Is there anything i can do to fix the time reported?
I've tried to run akosfs code on a linux box by using wine, but i've got a strange effect, look at this:
http://einstein.phys.uwm.edu/results.php?hostid=566983
Time reportet is almost everywhere zero, but it took always about 13000s to complete. But luckily the workunits get validated though.
Is there anything i can do to fix the time reported?
Yeah, I posted about his too farther down. All my machines just went into a forced CPU benchmark, so I am going to see if that fixes it for some reason.
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
If you're going to pin this thread, wouldn't it make more sense to instead have a single post thread listing where to download the two or three versions aksof(he's mentioned an I36 executable for P4's but not provided a link) has provided and which platforms they support, and then only allow moderators to post. As choked up as this thread is, actaully finding the needed information is easier said than done.
____________
If you're going to pin this thread, wouldn't it make more sense to instead have a single post thread listing where to download the two or three versions aksof(he's mentioned an I36 executable for P4's but not provided a link) has provided and which platforms they support, and then only allow moderators to post. As choked up as this thread is, actaully finding the needed information is easier said than done.
Fair enough, it has been quite a whirlwind.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
On my Athlon XP2800+ it's running at around 0.96% per minute!!!!!!!!
____________
www.chris-kent.co.uk aka Chief.com
gabberattack (johnny, eriq, segfault, r2k4, bully, sifon)
Send message
Joined: Feb 16 05
Posts: 10
Credit: 8,917,900
RAC: 11,701
I examined the linux code closely. It's horrible.
The 'blind flying' type optimization is hopeless. I'm sorry...
Probably a better compiler would be able to increase its performance significantly.
Hello, Akosf. Your application is gret, my crunching times are half. Would you be able to send me, or post a link to linux binary code for albert application? Or your binary for windows ? Maybe we would be able to make something with Linux and OSX version. Thanx, gabberattack
____________
Just like to say congrats to Akosf for his great work. Do we know what the 'official' view of these new apps is at the moment? (sorry if this is posted elsewhere but I couldn't find it)
Cheers
Stwato
____________
akosf said he looked at the disassembly of the linux binaries, but they were different enough he wasn't able to figure out what was going on.
Bruce's promised new, official applications based on akosf's algorithm improvements, but they haven't done so yet. Mainly I suspect the delay is in translating the assembly back into C to allow crossplatform development.
____________
Bruce AllenForum moderator
Project administrator
Project developer
Project scientist
Send message
Joined: Oct 15 04
Posts: 1094
Credit: 171,459,074
RAC: 493
akosf said he looked at the disassembly of the linux binaries, but they were different enough he wasn't able to figure out what was going on.
Bruce's promised new, official applications based on akosf's algorithm improvements, but they haven't done so yet. Mainly I suspect the delay is in translating the assembly back into C to allow crossplatform development.
Here's an update.
We've now incorporated Akosf's improvements into our source code. But we haven't started distributing this faster application yet, for a simple reason. We are worried that our project server might break with the increased upload/validation disk load since the work will be getting done faster when we begin distributing new apps to all users. So we're upgrading the disk controllers and should be ready for this increased load soon.
____________
We are worried that our project server might break with the increased upload/validation disk load since the work will be getting done faster when we begin distributing new apps to all users.
I can certainly understand why! The S38 optimized Windows SSE application does a workunit in about 0.30 the time of the current science application. That is like getting all at once over 3 times as many crunchers! At least that is a happy problem for you! :)
____________
Regards,
Bob P.
At least that is a happy problem for you! :)
Definitely, hehe ;) what a problem! Would be interesting which app is faster, akosf's S-38 or the officially optimized one. Maybe the new official app will get another speed-up since Akos's further development may be not implemented yet.
Live long and crunch ;-)
____________
Greetings, Santas little helper
Here's an update.
We've now incorporated Akosf's improvements into our source code. But we haven't started distributing this faster application yet, for a simple reason. We are worried that our project server might break with the increased upload/validation disk load since the work will be getting done faster when we begin distributing new apps to all users. So we're upgrading the disk controllers and should be ready for this increased load soon.
Maybe you could just release the new linux binaries immediately. That way people like me aren't having to run wine to take advantage of the improvements in the new binary, and also, Linux is a relatively small share of the E@H computer base, so I doubt the increased WU's from the Linux machines would break anything.
This would also allow for testing out the code before a widespread release.
Just wishful thinking :)
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
We are worried that our project server might break with the increased upload/validation disk load since the work will be getting done faster when we begin distributing new apps to all users.
how about making the workunits say 2x or 4x longer with the new app? those z.... named workunits are much too short even without optimation anyway.
greetz, pe.
____________
how about making the workunits say 2x or 4x longer with the new app? those z.... named workunits are much too short even without optimation anyway.
greetz, pe.
IMHO they would have to restart the S4 run then. It would only make sense if _all_ workunits have (e.g.) a longer integral time. But ok. They might merge several workunits to a single one.
For my P200 is NO workunit too short :)
____________
What about new source optimized FreeBSD binary, too? That's so tiny market share that it will absolutely not overload your servers, Bruce :)
____________
Dear Bruce,
We've now incorporated Akosf's improvements into our source code. But we haven't started distributing this faster application yet, for a simple reason. We are worried that our project server might break with the increased upload/validation disk load since the work will be getting done faster when we begin distributing new apps to all users. So we're upgrading the disk controllers and should be ready for this increased load soon.
with all due respect, this problem is easy to solve. Rather than having 25+% CPU time waisted while running a known-to-underperform binary, I suggest to ask everybody to pay credit to other Hungarian's work (as I understood that Akosf is from Hungary) and thus run SZTAKI (http://szdg.lpds.sztaki.hu/szdg/) for a while. E@H updates its server in the meantime and we all will be back once you give the thumbs-up signal for it.
All the best
Steffen (who needs his CPU power himself since a few days)
I guess any DC programm can be optimized furher so this is no reason to leave Einstein@home and come back ... Even if we "waist" cpu time now we'll finish earlier.
____________
Greetings, Santas little helper
I suggest to ask everybody to pay credit to other Hungarian's work (as I understood that Akosf is from Hungary) and thus run SZTAKI (http://szdg.lpds.sztaki.hu/szdg/) for a while.It is a very grandiose attitude.
At least that is a happy problem for you! :)
Definitely, hehe ;) what a problem! Would be interesting which app is faster, akosf's S-38 or the officially optimized one. Maybe the new official app will get another speed-up since Akos's further development may be not implemented yet.
Live long and crunch ;-)
Same here. We know akosf's gained very large improvements by changing the actual algorithm used. I'd be very interested in seeing if he's outdone the compiler in producing asm code as well. Excepting cases where the compiler doesn't know about new instruction sets (and special purpose processors without a good compiler) it's supposed to be very hard to do now.
____________
[quote][quote]Excepting cases where the compiler doesn't know about new instruction sets (and special purpose processors without a good compiler) it's supposed to be very hard to do now.
Alot of the times it comes down to compilers needing to make sure the code stays 100% accurate according to the logic the coder explicitly, whereas looking at the code often times reveals that moving a few calcuations around to take advantage of pipelining and so on is actually "ok" for the code. The code can only be as good as you allow it to be. Alot of times people use variables in a way that makes them dependent on earlier calculations, and decreases the utilization of the CPU being able to do things in the pipeline.
I'm not saying this is what akosf did for sure, but it is one major area where a compiler will never be perfect.
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
I suggest to ask everybody to pay credit to other Hungarian's work (as I understood that Akosf is from Hungary) and thus run SZTAKI (http://szdg.lpds.sztaki.hu/szdg/) for a while.It is a very grandiose attitude.
Also give akosf the Volunteer Developer title.
____________
seriously...he cuts 5-10% computation time off of each go and posts improvements so fast that i had to write a script to update the farm!
____________
Send message
Joined: Oct 6 05
Posts: 56
Credit: 11,538,300
RAC: 14,336
Going directly from the stock Albert 4.37 today to the S39 has given me a 5X increase in speed. I've gone from around 5 hours to 1 hr 15 min.
So..are we gonna be able to keep up with the data collection now?
____________
Here's an update.
We've now incorporated Akosf's improvements into our source code. But we haven't started distributing this faster application yet, for a simple reason. We are worried that our project server might break with the increased upload/validation disk load since the work will be getting done faster when we begin distributing new apps to all users. So we're upgrading the disk controllers and should be ready for this increased load soon.
Would you be willing to post the new official clients as beta clients until the new disk controllers are installed. That way, those interested (who I suspect are merely the same people using the unofficial clients) could try them out now, and everyone else gets them with the official roll-out.
Thanks,
Greg
Has anyone reported trying Akosf's windows versions under wine?
Thanks,
ADDMP.
____________
Has anyone reported trying Akosf's windows versions under wine?
Thanks,
ADDMP.
Yes.
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
Has anyone reported trying Akosf's windows versions under wine?
Thanks,
ADDMP.
Yes.
And is it faster?
And how much?
____________
Has anyone reported trying Akosf's windows versions under wine?
Thanks,
ADDMP.
Yes.
And is it faster?
And how much?
Seems to be about the same that the windows people are claiming.
____________
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
[/quote]
Would you be willing to post the new official clients as beta clients until the new disk controllers are installed. That way, those interested (who I suspect are merely the same people using the unofficial clients) could try them out now, and everyone else gets them with the official roll-out.
Thanks,
Greg[/quote]
I´m for this one.
Anders n
____________
From http://bugs.winehq.org/show_bug.cgi?id=4006
BOINC installs fine with the current GIT tree
Will 3DNow! optimizations also make it into the next offical client? Akosf's S39L worked great on my machine, but his D40 version with the 3DNow! optimizations was even better! I just hope we Athlon XP users aren't forgotten. :-)
____________
Will 3DNow! optimizations also make it into the next offical client? Akosf's S39L worked great on my machine, but his D40 version with the 3DNow! optimizations was even better! I just hope we Athlon XP users aren't forgotten. :-)
Kerwin,
Who knows? Would be nice, though. If I ever get the OK to use the electricity to bring my old rig online, I'll probably use my backup XP_Mobile Barton in it, but if and when I get a place of my own, with no power restrictions, I have on or two old XP 2500 T'breds that may again see the light of electron flow. :-) For my Barton core (with SSE), the 3DNow! app is only about 1-2% faster than the SSE app.
Michael R.
____________
microcraft
"The arc of history is long, but it bends toward justice" - MLK
Kerwin,
Who knows? Would be nice, though. If I ever get the OK to use the electricity to bring my old rig online, I'll probably use my backup XP_Mobile Barton in it, but if and when I get a place of my own, with no power restrictions, I have on or two old XP 2500 T'breds that may again see the light of electron flow. :-) For my Barton core (with SSE), the 3DNow! app is only about 1-2% faster than the SSE app.
Michael R.
Yes it would be nice! If the only changes to the next official app are the optimizations, then there should be no reason why us AMD folks can't continue using the D40 app...probably with an app_info.xml file of course.
[Edit]
Then again, there's nothing stopping akosf from taking the next official app and optimizing the hell out of that. ;-)
____________
Yes it would be nice! If the only changes to the next official app are the optimizations, then there should be no reason why us AMD folks can't continue using the D40 app...probably with an app_info.xml file of course.
[Edit]
Then again, there's nothing stopping akosf from taking the next official app and optimizing the hell out of that. ;-)
Well, that's the thing, though - what is being talked about here is the next official app incorporating Akos' opts, and (if everyone gets their wish) there being several official versions, each tailored for extensions. As you've probably noticed, the last few have been relatively tiny "tweaks", amounting to 1-5%, compared to the mighty leaps (20-30%) of the first 3 or 4 Akos Miracles. If the next official app(s) do come out this way, I wouldn't expect that there will be much more optimization possible on top of what he's already accomplished. We're getting pretty demanding, aren't we? Geez, give the guy a break :-) They're already going to go through hell, just trying to get Linux and Mac into the same neighborhood, or at least get them into the same TimeZone.
____________
microcraft
"The arc of history is long, but it bends toward justice" - MLK
(edited for length) We're getting pretty demanding, aren't we? Geez, give the guy a break :-) They're already going to go through hell, just trying to get Linux and Mac into the same neighborhood, or at least get them into the same TimeZone.
While reading this post, a rather amusing but terrifing thought occured to me.
That being
"They could implement daylight saving to try and bring the mac's and lunix into line."
I know its a scarey thought, those who know about daylight saving will I hope understand while those who have never heard about this abomination should thank their lucky stars.
akosf said he looked at the disassembly of the linux binaries, but they were different enough he wasn't able to figure out what was going on.
Bruce's promised new, official applications based on akosf's algorithm improvements, but they haven't done so yet. Mainly I suspect the delay is in translating the assembly back into C to allow crossplatform development.
Here's an update.
We've now incorporated Akosf's improvements into our source code. But we haven't started distributing this faster application yet, for a simple reason. We are worried that our project server might break with the increased upload/validation disk load since the work will be getting done faster when we begin distributing new apps to all users. So we're upgrading the disk controllers and should be ready for this increased load soon.
Alright there,
I will now cease calculations on my linux machines, since my one win latop now is able to outnumber the entire RAC I used to have before. This removes the strain on the project server's disk controller at least a little.
From a discussion in our team board, voices suggested handing over the source code to akosf since he has done so much great work. This would enable him to have his optimizations running on all platforms, to my understanding. Would that be at all feasible?
____________
:
your thoughts - the ways :: the knowledge - your space
:
As you've probably noticed, the last few have been relatively tiny "tweaks", amounting to 1-5%, compared to the mighty leaps (20-30%) of the first 3 or 4 Akos Miracles.
On my machine there was not a 20-30% increase, not even 200% but more like a whopping 350%! I was cruising at ~180 RAC, now I am well beyond 520 RAC and counting.
Bear in mind that there has been a LSC ( Ligo Scientific Collaboration ) meeting in recent weeks ( see here ), so I'd guess that our fearless leaders may well have been distracted/busy with that....
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Bear in mind that there has been a LSC ( Ligo Scientific Collaboration ) meeting in recent weeks ( see here ), so I'd guess that our fearless leaders may well have been distracted/busy with that....
Cheers, Mike.
Lousy excuses, while we are in the trench of the frontline! :-D
No, I know they work as hard as they can and there are many more obligations to follow, so I just hang in there and wait.
Lousy excuses, while we are in the trench of the frontline! :-D
No, I know they work as hard as they can and there are many more obligations to follow, so I just hang in there and wait.
Actually I'll share some interesting stuff I found while browsing the presentations:
Up to Mar 20 2006 01:31:02 UTC Elapsed run time = 3249.5 hours Sample Hours Percent ------- -------- ------- H1 2075.2 63.9 since Nov 4, 2005 8:00 PST H2 2356.7 72.5 since Nov 4, 2005 8:00 PST L1 1658.2 55.1 since Nov 14, 2005 12:00 CST H1+H2 1897.6 58.4 since Nov 4, 2005 8:00 PST H1+L1 1261.4 41.9 since Nov 14, 2005 12:00 CST H2+L1 1316.5 43.8 since Nov 14, 2005 12:00 CST H1+H2+L1 1154.3 38.4 since Nov 14, 2005 12:00 CST One or more 2768.9 85.2 since Nov 4, 2005 8:00 PST Two or more 2166.8 66.7 since Nov 4, 2005 8:00 PST (H1orH2)+L1 1423.6 47.3 since Nov 14, 2005 12:00 CST
These are the 'locked' hours for the interferometers - thus producing the 'good' data for further signal analysis (H1 and H2 are Hanford big & small, L1 is Livingstone). The triple co-incidence time (H1+H2+L1) is already at about 1200hrs - twice the length of the 600hrs we are analysing now for the S4 run. Someone here recently asked 'what next' - well it's coming! Also akosf's ( or any other ) optimisations are going to flow for S5 too and be very bloody useful!
Another table relates to increased detector sensitivity:
Before break After break (best) L1 ~10 Mpc ~12 Mpc H1 ~11 Mpc ~14.5 Mpc H2 ~5 Mpc ~7 Mpc
(The 'break' is the period between the S4 and S5 runs ).
These are distance estimates ( in Megaparsecs or Mpc ) to detection limit on current sensitivity for a 'standard' binary inspiral event - discovery of which is keenly sought. Because volume goes as cube of distance, a 20% increase in radius, say, gives about a 70% increase in the sphere of space enclosed ( 30% gives about another 120%, 40% gives about another 170% ).
The upshot is that S5, as we speak, has collected significantly longer times on considerably larger volumes of space. So who wants their computer(s) to host the calculations that reveal some real breakthrough for science?!
Pick me... pick me... pick me... pick me... pick me... :-)
( .....hand upstretched in classroom.... )
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
Actually I'll share some interesting stuff I found while browsing the presentations....
Cheers, Mike.
Thanks for taking the time to review the presentations, this is very interesting information! I was wondering how much "good" triple-coincidence time data they were collecting, because the intruments are so incredibly sensitive they pick up the very least bit of earthly background noise. In fact, imho, the sensitivity is such and the planet is so noisey that a space-based instrument seems probably best (and I know one is planned eventually).
Updates like yours are encouraging, and certainly keep up my interest in the project! :)
____________
Regards,
Bob P.
Actually I'll share some interesting stuff I found while browsing the presentations....
Cheers, Mike.
Thanks for taking the time to review the presentations, this is very interesting information! I was wondering how much "good" triple-coincidence time data they were collecting, because the intruments are so incredibly sensitive they pick up the very least bit of earthly background noise. In fact, imho, the sensitivity is such and the planet is so noisey that a space-based instrument seems probably best (and I know one is planned eventually).
Updates like yours are encouraging, and certainly keep up my interest in the project! :)
Quite right! Ultimately space is the place to be!
( What 'good' really means is that the 'dark port' of the interferometer has been held at an interference fringe minimum by the active use of the incredible control system of the whole array. One then takes the signals used in that system to perhaps deduce the flexing/distortion of spacetime induced by a passing gravitational wave propagating through the entire LIGO. The poorer alternative is to not do that control effort, but measure the light fluctuation at that port..... )
Anyhows, what makes the project not entirely hopeless here on Earth - given that we are looking for alterations in spacetime of the order of 10 to the power of minus 21 while using instruments, wavelengths, noises etc all far larger than that - is that most 'background' is incoherent. This means that many non-astronomical influences like the 'shot noise' of a laser, or thermal movements of the atoms in the mirrors do not have a preference with respect to the direction of the effect of scientific interest. A good analogy is the seaside where there is a lot of slosh, froth, wind, waves and spray etc.... but if you watch for long enough ( much, much longer than these 'obvious' disturbances ) the tide comes and goes. In other words averaging smears away such temporary upsets and allows trends to be observed. Another helpful method is to 'park' the noise in less critical parts of the observed data. So if you have some noise component that blurs a region of particular interest ( technically in the power vs. frequency spectrum ) then one can cleverly design widgets to interact physically with the detector parts to channel energy away into other 'modes'. So you ask the tenor to sing just as hard but in the baritone range! In addition, if you can't do that, then make the noise well defined, 'narrow', well studied, and understood - hence you can confidently subtract it away from the data. Another expectation is that widely separated detectors ought not suffer identical patterns of incidental noise - like a tree being felled in the Louisiana woods, or a brushfire in Washington State - so comparison between sites ( with simultaneously locked interferometers ) is quite valuable. Another trick is to get the chalk and pencil out and make a well educated guess as to what sort of signal ought to be heard for some given astronomical phenomenon, and then search for that in all the hubbub.
Cheers, Mike.
____________
"I have made this letter longer than usual, because I lack the time to make it short." - Blaise Pascal
...and then search for that in all the hubbub.
Cheers, Mike.
Thanks for the wonderful explanation! I guess our computers are searching for the faint gravitational wave "song" in amongst the furious noise of the hurricane...
Again, I really appreciate your time in making these clear explanations. :)
____________
Regards,
Bob P.
Back to the original name of this thread.
Albert v.4.50 has shown up.
Bruce, could you kindly explain what level of optimization did you implement? This might be quite important for akosf.
The new 4.50 Albert is in beta test currently. Akosf said he is starting to "work some black magic" on it. :)
____________
Regards,
Bob P.
The new 4.50 Albert is in beta test currently. Akosf said he is starting to "work some black magic" on it. :)
Personally I prefer white magic, but Hungary may have a different tradition :-)
Hey! White magic is boring,The new 4.50 Albert is in beta test currently. Akosf said he is starting to "work some black magic" on it. :)Personally I prefer white magic, but Hungary may have a different tradition :-)
but I have some magic words for you... ;-)