1) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 42807) Posted 4 Nov 2004 by Chuck Lasher Post: Ben, I have some info, a discovery for me, for you and all regarding 64 bit on AMD. First, the obvious. GCC on on-modified compilers that use 'long long' for 64 bit (Even a few 64 bit OS's) do their immediate loads as 32 bit. Makes sense. Suse 9.1 uses 64bit immediate mode for a long; you get the following: int = 32; long = 64; long long = 64; (but indeed code differences).. a bug, this should be a 128. float = 32; double = 64; long double or double double = 128; Fedora FC2 64bit requires the 'long long' syntax; Regarding Cache; The A-64's use the 64k-64k Harvard I&D caches @ L1, and 512k or 1mb for L2. Cache row size is still 1024 bit and associativity is still 64 byte. The 'cache load' I'm finding is dependent on 754 (single channel) vs 939/940 (dual channel) bus. Regarding speeds, you are right, we would need to know system clocks, etc. Linux will tell us the # of ticks/clock and all that with no trouble. Cycles is indeed a good metric, ensuring the translation to a Coblestone or some equivalent may be interesting. :) Given the various FFT sizes (both bytes and # of elements), is there merit to measuring # of elements/second, adjusting for the fact that time-to-process an FFT is proportional to it's size? I want to say 'inv quadratic?', given the matrix size determines the processing time, but don't want things to get messy either. Cranking out 1000 256k x 4 byte FFTs is vastly different than processing 100 1536K x 8 byte FFTs. An Example I found is the 'Primenet' stress test. it does various FFT sizes and iterations. All seem to take about the same time for a given CPU. Somewhere there is code to figure out a fair 'processing speed. I will look for some public source code to see if there is anything we can learn from it. As for me and my 'boundary condition', i have yet completely proven where the boundaries conditions are, but 32 vs 64, alignment and chipset 'bank-switch' time are a big part of the speed since that size of FFT breaks L2 cache all the time. I am working on the 32 vs 64 bit thing as I found a condition where code, compiled for 32 bit OS's/CPU's using double-precision floats, AMD vs Intel, getting a 1 bit low-end rounding error that occurred early in the calc of a large FFT and (as you well know) rippled through that and produced an error visible only 8 significant digits down. I was running the 32 bit code on 64 bit linux at the time. I did verify the binary was a static image. I am tempted to try a 'cascaded' set of small FFTs versus 1 large FFT to see if there is a difference in error propogation. This also could help performance on the smaller cache machines but not hurt a larger cache machine at all. Final: The PC here is back to normal as of late last night.. looking good and 'feels' like 'my computer' again. I will be getting some other last-minute setup work done today for a few CVS things i am going to work on and wait for a shoot a query to AMD about the 1 bit ripple effect and how best to avoid it / handle it on large FFTs, or chained FFT series. Also catching up on email today should be interesting. ha ha. Chuck

2) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 42101) Posted 2 Nov 2004 by Chuck Lasher Post: Ben & all, Been reading and catching up.... GREAT WORK. I have some things I'm working on here where the FFT is just over 1 meg elements in size (yeah, big stuff).... I am strictly at the learning / testing / experimentation level as you know, but here are the results of my latest change which are causing me to wonder where I am wrong in my 'learning'. 64Mbyte Ram utilization for the FFT .... 147ms to process. 62Mbyte Ram utilization for the FFT .... 94ms to process. 8MByte Ram utilization for the FFT .... 6ms to process. Running on Win/XP Pro SP1 Suse 9.1 is linear in performance vs size... 7ms for 8mb and 55ms for 64MB. This is perhaps a very stupid question, but... Did I cross different boundary conditions in 32 bit XP or is that just a characteristic of my DDR-400 dual channel RAM? (AMD FX processor 2.56 Ghz, DC ECC-enabled CL2) Under Suse 9.1, I also don't have to do anywhere near the amount of FFT work because GCC 'long' is truly 64 bits (i don't have that 'long long' problem) and I actually can do boolean AND and NAND to do things as integers. What that does for the algorithms I have is permit use of -mfpmath=sse,387 and I get to use all registers when not doing any FFT work in a module. All heck still breaks loose on P4's due to cache limits, but I expect that. Chuck PS: Sorry for being away, I am just now feeling semi-comfortable after restoring from failed UPS battery that caused system crash (boot drive (C) and 'home' drive (D) only luckily). My email is kept on 'D'.... restoring that now (address book and email history included), but I do have email inbound again. Other drives were ok. I should be fully back up and running by tomorrow and feeling 'stable' again. I'll be back in the loop and hopefully catch up quick and start contributing again in a couple days.

3) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 39842) Posted 25 Oct 2004 by Chuck Lasher Post: Ben, You have my address, etc on the boinc_opt list.... would you please email me privately and we can talk about this when you have time? I have some NASTY 386 dedicated assembler that will not handle cache's greater than 8k (P4) nor will it handle FFT's greater than 131072. Also, being "Masm", won't slide into GCC very well, nor use the extended FFT or FPU capabilities of the FX class machines (which AMD has and Intel is about to have). What I need is to replace all the FFT ASM (currently done LONGHANG in C or 386 ASM) with some good code like your SIMD class and finish getting automake setup up (almost done there). It would make bringing the Altivec's into the projects a SNAP... and we both know what they will do! May we discuss and share ideas and code? I have a few things I am fixing for primes that Seti can use and You are the man to implement it. I will look at the FFT code you've referenced again.. Oourda sounds very famiiliar. I've seen so much 'brute force FPU' FFTs recently for Linux, etc that I am overwhelmed and dont remember actual equations from memory. Regarding CPDN... they are proprietary, which I do respect. I also sense in the tone of email text that the model is fragile and old.. and also respect that only a few touch it. Predictor is part public, part proprietary (NDA is all that's required). It will benefit greatly from FFT and 64 bit. Let's chat offline and see where we can help each other. I'll show you some great ones i've got already for primes that are about to hit suse 9.1 64 bit linux (as brute force in rev 1) and some wild little macros that cut out a great deal of FFT ASM. ALL of which I'm sure you've done or seen before. As of tonight, I am switching this FX-53+ to dual boot (but staying mostly in Suse 9.1 -64) and and leaving the A-64 754 pin machine in win/32. I do have Suse 9.1 Pro (32 and 64 bit versions on flip/flop dvd). Write direct when you can, (Rom can give you my email if need be... permission granted as required) Chuck

4) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 39619) Posted 24 Oct 2004 by Chuck Lasher Post: Ben, If I may add to that.. the FX class (Sledhammer and above cores, possibly more as processors are announced) is the FXSAV (?) instruction. It is a high speed special register save instruction for doing high speed context switches. I can see it being used really nicely. I can also see the use of the SSE regs for non-SSE math by simply writing macros which do __ASM directives.... That link is a good one.... I've pointed it out to a few people myself. Every time someone asks what the difference between the AMD64 and P4 is... I send tem there. I am curious if Intel has formally announced what is going to be in the P5 and P6 architectures or if those were originally slated to be the 'now-sidelined' 32 bit cores. Any idea? I ask because I am puttting together a table of processor capabilities, based on George Woltman's and Jean Penne's code for primes that taylor runtime ops based on processor features ... specifically CMOV, SSE, SSE2.. Those make a big difference in FFTs which I believe would help seti a great deal if done properly. The nice part is that it would be Intel/AMD independent detection and feature management.... totally transparent to the user. just a few runtime 'if()'s in the code at critical places. I've been working on the the 64-bit implementation of prime factoring. The math is nice and clean and gives a good opportunity to learn how to deal with a huge variety of FFT array sizes for all processors support by BOINC/Seti. I hope to bring this experience back to the project when complete. I also hope to see it put to use in the proteins & cpdn work (all fortran). Both those projects would benefit huge amounts with 64 bit math and fast 64 bit based FFT work. The error factor cuts way down and performance comes way up. Both things that we need to start preparing for as Intel gets closer (hopefully soon) to announcing & rolling out its 64 bit processors to the user community. I think we should be ready for it so AMD and Intel users can really push all boinc projects forward. Your thoughts? Chuck

5) Message boards : Number crunching : BOINC 4 and Win98 (Message 32221) Posted 2 Oct 2004 by Chuck Lasher Post: I am a beta tester for Boinc, albeit seldom. version 4.09 (official release) and CPDN do have a small lockup problem on Win/XP. I believe this is part of the CPDN graphic and BOINC miscommunicating since the CPDN version upgrade. This is the ONLY 4.09 issue I have seen. 4.10/4.11 have similar issues and again, in my option are related. It does require a specific sequence of keystrokes to lockup both the graphic and the CC, however the CC resumes normal processing as soon as the graphic is closed. This information has been reported to the appropriate people for further examination. Chuck Lasher > Thank you for the information regarding the Official Release......I was not > aware of it and will give it a shot. > > Kurt Christie > > > > With the inactivity on this board one would think all is now well. > > > I have tried version 4.11 and all went well for a few days. Today, > > however, I > > > am back to screen lockup, strange monitor patterns, and a hard > reboot. > > > Maybe I can find 4.10 somewhere and go back to it since it was fine > for > > > numerous days. Kurt Christie > > > > At http://setiweb.ssl.berkeley.edu/download.php you can download the > OFFICIAL > > RELEASED Windows/x86 4.09 BOINC software ! > > > > If you continue to use ß-versions, it is your own fault if your system > behaves > > strange :P > > > > IF you still have problems with BOINC 4.09, the chances are high that > your > > problems are not caused by BOINC but by another component of your > system. > > > > MfG, MEX > > > > > >

6) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 27265) Posted 17 Sep 2004 by Chuck Lasher Post: > Ok updates. > > There is now an official optimization group mailing list from boinc (seti). > Go to the home page for the link. > > If you are a programmer, I think this is where you want to be. > --- > Verification: Write the code - Compare the output to original routine's > output. Determine margin of error. > > Verifying a compiled client's output. > 1. Put the original seti client .exe in a directory with a given WU. > 2. Rename the wu to "work_unit.sah". > 3. Start the original client. > 4. Let it finish. Now there is a new file in the folder called "result.sah". > 5. Copy this file away and save it. > 6. Put new client in same directory. > 7. Erase any "result.sah" stderr.txt state.sah files > 8. Run new client. > 9. Let it finish. > 10. Use a file compare or 'diff' program to compare the new output to the > original. > > ----- > > 64 bit code. The 64 bits applies to integers, as in standard registers. > The rest of the code around the floating point parts will go somewhat > quicker. > > When working with floats you still have the FPU's 32 bit single, 64 bit double > stored in 80 bit internal floating registers. > > When working with SIMD, you have 3DNow and SSE for 32 bit floats, SSE2 and > SSE3 for 64 bit floats. > > Altivec is 32 bit float SIMD. > --- > The conversions I've performed in able to make the SSE code work will be of > benefit to Altivec and other SIMD programmers, but I haven't written Altivec > routines yet (nor have access to Mac for testing). > > Brad Anderson (Mr. Anderson to you all ;) has written Altivec routines for > the most active floating point routines in seti_boinc. He has compiled the > application for 3 flavors of Mac and released them on his website. > > This is covereed in another thread here in "crunch" started by him. > > Thank you for the input. I shall relay the information to the team Mr Herndon. :) Sincerely, Chuck Lasher

7) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 26718) Posted 15 Sep 2004 by Chuck Lasher Post: > Chuck et al, > > While you're doing this magnificent work, are you comparing the run times on > code compiled by different compilers? > > I saw the Intel compiler mentioned together with the MS one... > > The Weasel > > > > > > Yes, and I am even looking at the generated code and comparing as much as possible... but I question whether that is a rather moot point now or not. There have been changes submitted to Boinc-dev and implemented into 4.09 (or 4.10) now. Until our team discusses all this, we won't be making any further posts. Chuck Team Phoenix Rising.

8) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 26341) Posted 14 Sep 2004 by Chuck Lasher Post: > > > Let's skip all the the computer geek speak, and get right down to > it. > > When > > > will the software be available for all 64 bit users? > > > > > > > > > > Please forgive my 'non-geek, standard answer'......"When we know it's > ready... > > I've started testing on my stuff on 32bit and 64 bit machines. I'm sure > Ben > > is testing his. Next step is to put it together and give it to the > appropriate > > folks to test more, bless, and then distribute when they are happy with > it." > > Chuck, > > Is this going to be a windows only 64-bit version? If not, that is fine, but > if it is, you should state that... I know the Team MacNN has optimized > compiles for the Mac, though I have not used them yet because of where we are > I have no way to really see if it is working correctly... I know it is > possible, but, I am waiting until the GUI comes out and I can "watch" ... > <p> > For BOINC Documentaion: Click Me! > > > > Paul, It is our team's intention to make this applicable to all platforms. I assume (but can't speak for Ben) that that Ben's SSE optimizations also translate to Altivec instructions for Macs and he's also intending (if I remember earlier posts correctly) other CPU support. As for the number of significant digits, I find that 12-13 is as far as we can really push it. Given Ben's statements about sampling and BioScience (P@H) starting with high-def data, I think we're in good shape if we can pull in 32 bit for now, operate in 64 or 80 bit resolution (using 128 bit to store the 80 bit interim results), and then output 32 bit again with significantly reduced roundoff error(s). This is where I believe the science (as a whole) takes the greatest leap forward. If Team MacNN has optimizations for Altivec, etc... can we somehow find a way to get all this integrated? We now have Ben's work, our work, Francophone's work, and MacNN's work.... and I am sure COUNTLESS others working on the same thing. How do we pull this together for the good of the science as a whole??? I am open to direct email (you have my address), so please... let's make this happen. We are about to start final testing on Win32/Win64/Linux32/Linux64... cpus Pentium, P2, P3, P4, and all the AMDs available on in all possible configurations possile because they are simply the most readily available to us from all the volunteers of the team. If we have some Macs, then it will be tested there, but I don't know of any of of yet. Our goal when we started this was to bring everything up to 64 bit. I personally am working on getting a couple SGIs and SUNs loaned to me as well just to ensure that big and little endian machines all behave the same. These will be added insurance for portability and adherence to the Cobblestone model. I personally would like us (TPR) to present to SSL software that is solid and easily integratable into the main stream (integrated with Ben's if possible), tested to their standards, and then released per their license and GPL requirements. It makes the most sense to let BOINC-Dev be the focal point for final integration and release to the general public through their standard channels. They are afterall fundamentally responsible for the project. Does this answer your questions? Chuck Team Phoenix Rising. PS: Yes, it's 5am... I had an idea on the benchmarks and it was easier to code than write it down, and it does fix an issue I had with register allocations on the difference processor families... :)

9) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 26198) Posted 14 Sep 2004 by Chuck Lasher Post: > > > Let's skip all the the computer geek speak, and get right down to > it. > > When > > > will the software be available for all 64 bit users? > > > > > > > > > > Please forgive my 'non-geek, standard answer'......"When we know it's > ready... > > I've started testing on my stuff on 32bit and 64 bit machines. I'm sure > Ben > > is testing his. Next step is to put it together and give it to the > appropriate > > folks to test more, bless, and then distribute when they are happy with > it." > > > > > > Chuck > > Team Phoenix Rising > > > > Thank you for your time and answer. I do and will look forward to the new > software. > > > > > > We *ALL* anxiously await the formal ok to use it.... a big step for science, performance, and fairness to all.. I will do my best to see how quickly the appropriate folks (a few hours drive from me if they ever needed any help) can work it into their schedule... I'm sure both Ben's and my work will be welcome.... It's been a nagging issue to them for a long time. I'm sure they will be happy to get this off their plate as it will permit them to remove all those 'fudge factors' from the system (which you see as the differences between estimated completion and how long it actually takes you to run it). Chuck, Team Phoenix Rising

10) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 26157) Posted 14 Sep 2004 by Chuck Lasher Post: > Let's skip all the the computer geek speak, and get right down to it. When > will the software be available for all 64 bit users? > > Please forgive my 'non-geek, standard answer'......"When we know it's ready... I've started testing on my stuff on 32bit and 64 bit machines. I'm sure Ben is testing his. Next step is to put it together and give it to the appropriate folks to test more, bless, and then distribute when they are happy with it." Chuck Team Phoenix Rising

11) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 25809) Posted 13 Sep 2004 by Chuck Lasher Post: > > Hi all, > > > > My SSE conversion of the FFT seem to be approx 125% faster than the > Oourda > > code. Still testing, seeing if they produce substantially identical > results > > to FPU code. Errors seem to be on numbers 5th digit or so. > > > > Almost all of the current seti calculations, including the buffer of data > from > > the telescope is currently in a single precision floating point format. > > (32 bits) > > > > We could use double precision, double the size of the buffers, read the > data > > from the WU file as doubles, but I don't know if that would generate > more > > accurate results. > > > > As I recall reading the data is gathered from the telescope in a 2 bits > per > > sample format. So I don't know if the precision is there to enhance > > detection. > > > > Regarding AMD 64bit, the AMD 64 has some interesting features here for > greater > > accuracy in computations. > > > > It has 16 SSE2 registers vs 8 in Intel P4. (each 128bits long) > > It still has only 8 FPU registers (as in orignal 80386 each is 80 bits > long) > > > > > > > Your question about reading and operating in double precision would gain us a > lot... remember, we lose bits with each calc. Single precision is good for > only 6.8 digits of precision. Once you start operating on that... you start > losing due to roundoff. The longer we can keep out the roundoff errors, the > better. This is known from direct experience with orbital work I now do. > > > Have you seen the additional registers in the FX (Sledgehammer and above) class > machines for AMD? They have more registers. > > Also, would you like some verification of operation on Linux? I have some > BSD/SYSV runtime corrections for code that I think should be integrated and am > intersted in puttting our works together. (I'm mostly working on CC and a > benchmark that is balanced with Integer, FP, direct & indirect addressing > for a better 'cross-prject' benchmark.) I think the 1988-based benchmarks > have outlived their usefullness. So far, I've compiled on VS, and GCC and > gotten almost identical results. I am curious how it behaves on HT p4s. > I've also put in a memory test (from code I wrote 3 years ago) that stresses > and does a balanced intermix of byte, word, dword, and qword r/w. If you > plot the results for each 'segment' (4k, 8k, 16k, .... 4M), you can see where > a processor and it's caches 'break', and where bandwidth goes flatline max. > > How do we put this all together? > > Chuck > > > >

12) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 25805) Posted 13 Sep 2004 by Chuck Lasher Post: > Hi all, > > My SSE conversion of the FFT seem to be approx 125% faster than the Oourda > code. Still testing, seeing if they produce substantially identical results > to FPU code. Errors seem to be on numbers 5th digit or so. > > Almost all of the current seti calculations, including the buffer of data from > the telescope is currently in a single precision floating point format. > (32 bits) > > We could use double precision, double the size of the buffers, read the data > from the WU file as doubles, but I don't know if that would generate more > accurate results. > > As I recall reading the data is gathered from the telescope in a 2 bits per > sample format. So I don't know if the precision is there to enhance > detection. > > Regarding AMD 64bit, the AMD 64 has some interesting features here for greater > accuracy in computations. > > It has 16 SSE2 registers vs 8 in Intel P4. (each 128bits long) > It still has only 8 FPU registers (as in orignal 80386 each is 80 bits long) > > Your question about reading and operating in double precision would gain us a lot... remember, we lose bits with each calc. Single precision is good for only 6.8 digits of precision. Once you start operating on that... you start losing due to roundoff. The longer we can keep out the roundoff errors, the better. Have you seen the addition registers in the FX (Sledgehammer and above) class machines for AMD? They have more registers. Also, would you like some verification of operation on Linux? I have some BSD/SYSV runtime corrections for code that I think should be integrated and am intersted in puttting our works together. (I'm mostly working on CC and a benchmark that is balanced with Integer, FP, direct & indirect addressing for a better 'cross-prject' benchmark.) I think the 1988-based benchmarks have outlived their usefullness. So far, I've compiled on VS, and GCC and gotten almost identical results. I am curious how it behaves on HT p4s. I've also put in a memory test (from code I wrote 3 years ago) that stresses and does a balanced intermix of byte, word, dword, and qword r/w. If you plot the results for each 'segment' (4k, 8k, 16k, .... 4M), you can see where a processor and it's caches 'break', and where bandwidth goes flatline max. How do we put this all together? Chuck

13) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 25405) Posted 12 Sep 2004 by Chuck Lasher Post: > Hey all, > > Another item to consider... > > Faster computation doesn't equal more credit as things are now. > > Right now the credit you claim for a WU is > * > (algorithm is somewhat more complex). > > So for science faster = better, but for credit no go. > > Also, your claimed credit for that WU will be compared to 2 other > crunchers claimed credits...and the lowest value will be granted > to all 3 users. > > =Ben > > Ben, I do not speak for all of us, but for those that I am permitted to speak for.... the purpose of going to 64 bit is to both improve the science and improve the performance. We don't expect more credit. We do expect the science now to be higher quality because we have reduced the rounding errors and given our scientists more finished / processed data to work with. I honestly expect credt to be the same... or more correctly stated.. to be properly calculated (which has been a problem since the beginning). Now we can be fair, fast, and accurate. What more can we ask for? true? Chuck

14) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 25274) Posted 11 Sep 2004 by Chuck Lasher Post: > Hi all, > > I have compiled versions of seti and seti_boinc for linux and > visual C++. > > There are bugs in the benchmark code. I have forwarded the changes to > the devel community and they are being added, though probably not > released to public for a bit yet. > > The bugs are overoptimization by VC and other compilers. > The optimization process had been omitting code in the benchmark > as the results of those portions of the benchmark were not used > elsewhere (compiler says, don't use...don't bother to compute). > Note: I tried Intel C++ 8.0 and it figured out almost none > of the benchmark results were used. The result was 7x higher > benchmark results. > > So, if you are using a newer VC, your results might look great > but the actual crunching code might remain the same speed. > > Bottom line, benchmark wasn't doing stuff it should have been. > Now that it will be doing the stuff, the numbers will be lower. > > In addition I have also profiled the code to find the most used > functions. Mostly they are the Fast Fourier Transform code > routines. I have rewritten them in SSE and am now working on > 3Dnow. My code determines CPU type and capabilities at > startup and uses appropriate SIMD subroutines. > Is anyone out there good with Altivec, and CPU identification > on Mac/Power PC? > > =Ben > > Ben, THANK YOU! you just did where I am headed... and the same place others have gone... May I ask you to consider one more thing? BSD vs SYSV on socket/io calls and set flags? Thanks CHuck

15) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 25273) Posted 11 Sep 2004 by Chuck Lasher Post: A few comments as I am getting the Linux side about running... First, you do need the environment variables set. Whether in your Cygwin, Linux, or Win environment.... Also, you have to make sure you've 'configured' the makefile for the appropriate flags. Looks like your compile does not have the correct INCLUDE_PATH or INCLUDE, or -I/include-dir1 -I/include-dir2 etc... to manually override it.... you're close.. REAL CLOSE. as for the 3com... I have two 3com cards and it works just fine. The only thing that doesn't work is my Marvell Yukon adapter (Mobo) on my 3rd machine), so I stuck in an old 3c905tx and it found it just fine. You should be running pure/real ethernet to the cable modem. If they have you running any special drivers (like poet, etc, you are in trouble even in 32 bit mode and time to get a new cable modem).. the modem HAS to be free-standing. If you can't put a hub or switch between you and the cable modem then things are hosed right there. Earthlink DSL runs poet in the PC (like a win modem)... I think they even have the gaul to call it winpoet (sp?).... please check that out. If your modem doesn't have an 'internal IP address' you are hosed and should give up or get a new modem (like a nice moto)..... Please forgive me if I am sounding harsh, I do not mean to sound harsh... but cable companies and DSL providers are trying to give us 'software modems' just like 'win modems' for dialup and it won't work no matter what you do. If all goes well here... I will have a working CC and Seti client (linux) shortly. I'm #ifdef'ing the differences around '0' vs 'null' pointers where the OS developers did not understand the posix spec. I'll post it all with my first download. I do have a few library updates for GCC to get yet... I found a bug of my own here and am resolving that now. I hope this answers everyones posts / questions in one shot..... I will take a look at the code errors (compile, runtime) posted and see what I think needs to be looked at... but we ARE close. please just remember 1) zero versus NULL pointer 2) lockboxes that are NOT thread safe.... and 3) SIGNAL (process level) versus thread signals.... These are the keys. our AMD_64 POSIX is thread-level signal and lockbox safe... so watch for code to change.... 0 vs null is why there are hangs.. (I got that one solved). I'll be back in a little bit. Wish we had a better forum. Chuck.

16) Message boards : Number crunching : BOINC 4 and Win98 (Message 24990) Posted 11 Sep 2004 by Chuck Lasher Post: Just an FYI: Running 4.07 here... it is the most stable for me.... I hear 4.09 is coming shortly and should fix some/all of the hang problems... but have no confirmation of that. The 'hang' is a known issue. I am sticking w/ 4.07 for now... it is most reliable I've used and read reports on. I am about to try and see what happens with Linux 64.

17) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 24586) Posted 10 Sep 2004 by Chuck Lasher Post: > > > I get modem working from 64bit Windows ... I planed to try to > compile it > > > during the weekend but seems like I have to be with my family ;o) > > > > Gee, Slavko - I usually look forward to spending time with my folks > > hey this whole SETI/BOINC-64 thing sounds really cool but don't worry - > ET > > will be waiting patiently. It's Humanity that's in danger of expiring, > not the > > Cosmos... > > > > > > If I may, my twist on this is not just ET, but P@H, CPDN, and all that use > BOINC. Given the user base for Seti is well established, P@H and all its > down-stream elements stand to benefit the most IMHO. I feel the more P@H or > CP can do, the better chance we have of saving ourselves. This is my > personal driving force behind my efforts. I agree ET is important, but I > think we must balance looking around at ourselves as much, arguably possibly > more, than looking skyward for some things. I'm sure "ET" will be more > impressed if we prove we can do something for ourselves as well. true? So, yes, I agree "ET will be waiting patiently". > > As for the whole Boinc-64 effort, I see this as the foundation for the next > generation of computers which is now upon us. AMD is there, Intel is a few > months behind. Soon all will have 64 bit machines and the ability to be more > accurate AND faster should be taken advantage of as quickly and efficiently as > possible without losing ANY of our 32 bit roots since well over 90% of the > contributors are still using 32 bit P4s and AMDs. Many users will wait for > the 64 bit world to stabilize (as I am about to do) before buying the next set > of CPUs... I have enough now to help us take the step, that is all I wanted. > That is my humble offering back to the world community for all it has given > me. > > > > > Chuck > Team Phoenix Rising. > >

18) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 24584) Posted 10 Sep 2004 by Chuck Lasher Post: > > I get modem working from 64bit Windows ... I planed to try to compile it > > during the weekend but seems like I have to be with my family ;o) > > Gee, Slavko - I usually look forward to spending time with my folks > hey this whole SETI/BOINC-64 thing sounds really cool but don't worry - ET > will be waiting patiently. It's Humanity that's in danger of expiring, not the > Cosmos... > > If I may, my twist on this is not just ET, but P@H, CPDN, and all that use BOINC. Given the user base for Seti is well established, P@H and all its down-stream elements stand to benefit the most IMHO. I feel the more P@H or CP can do, the better chance we have of saving ourselves. This is my personal driving force behind my efforts. I agree ET is important, but I think we must balance looking around at ourselves as much, arguably possibly more, than looking skyward for some things. I'm sure "ET" will be more impressed if we prove we can do something for ourselves as well. true? As for the whole Boinc-64 effort, I see this as the foundation for the next generation of computers which is now upon us. AMD is there, Intel is a few months behind. Soon all will have 64 bit machines and the ability to be more accurate AND faster should be taken advantage of as quickly and efficiently as possible without losing ANY of our 32 bit roots since well over 90% of the contributors are still using 32 bit P4s and AMDs. Many users will wait for the 64 bit world to stabilize (as I am about to do) before buying the next set of CPUs... I have enough now to help us take the step, that is all I wanted. That is my humble offering back to the world community for all it has given me. Chuck Team Phoenix Rising.

19) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 24427) Posted 10 Sep 2004 by Chuck Lasher Post: > Great idea! > I started developing on Windows 3.0 ... also have experiences with System V > for 1 year (CLIX OS on Intergraph Graphic Workstations, Huntsville, Alabama), > 1 year for Linux and last 5 years Windows, .NET, C#, MSSQL, Oracle ... > > To put our world wide effort together, would be a great and I believe we will > do a real difference. > > <a> href="http://setiweb.ssl.berkeley.edu/forum_thread.php?id=3067">S@h Berkeley's > Staff Friends Club © member > Then we have a common ground, and other things also ... my customer is in Huntsville, Al. :) My job emphasis right now is distributed simulation for on heterogeneous platforms in both WAN/LAN configs in real-time (DIS) protocol using real-time data & interaction. I think that says enough. Let's get more people involved.... Also please email me direct and we can talk. Anyone else who's serious is welcome... Let's do this folks... Let's give back something to Rom and Dave that they started. Let's make it BIG and what I am sure they will enjoy seeing take life! Chuck Team Phoenix Rising

20) Message boards : Number crunching : Contributing code? Amd64 build for Windows (Message 24419) Posted 10 Sep 2004 by Chuck Lasher Post: > Sure, we should cooperate in this area. I'm developer by profession and would > like cooperate or do a native 64bit compile BOINC and SETI@home app. I prefer > Windows enviroments, that's the reason why I installed Windows x86 beta, build > 1218. > > > I do think that all of us who are working on pieces of 64 bit should > come > > together and work together as a complimentary team to Boinc-dev & > Alpha > > and feed our work through them. > > <a> href="http://setiweb.ssl.berkeley.edu/forum_thread.php?id=3067">S@h Berkeley's > Staff Friends Club © member > This is perfect... Most of the team I work with is all Unix/Linux people. I have been working in Unix/X since 1982 (Sun-1/Sun-2 days with tape drives).. and work in mixed mode 32/64 bit all the time now SysV and BSD Unix / Linux. Please We are making a big effort to help with the solaris / linux issues to help Boinc deal with the Windows/Seti problem (where they are most needed) as well as future development (where they are best). Let us all find a way to have a common forum. Our team has a test server being build (I started up FC2 AMD_64 yesterday) We are hoping to get linux for Seti and P@H first and help CPDN make the transition. We have a schedule, resources starting to come together. The more that WE, the users, work together, the better Boinc and it's applications will be for all. That is our goal. Let's make this a world-wide effort and make a real difference. Shall we? Chuck, Team Phoenix Rising.

Next 20

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