Posts by garyn

1) Message boards : Number crunching : WU's named 'test' seemed to just stop (Message 66218) Posted 19 May 2010 by garyn_87048 Post: Thanks!
2) Message boards : Number crunching : WU's named 'test' seemed to just stop (Message 66200) Posted 18 May 2010 by garyn_87048 Post: I have several computers running boinc applications. On Sunday, May 16, (two days ago) I noticed at least two of the computers "idling out". They were running Rosetta tasks that either “test” or “test2” embedded in the name and the cpu load on those cores dropped to zero and the percent completed was not increasing. I aborted one of the jobs if happens to be visible on my account. This happened on an XP machine and a Vista64 machine. I apologize for the vague details. Any idea if this was a fluke specific to my setup or if there was a glitch in a recent application? Thanks! Gary
3) Message boards : Number crunching : CPU Optimization, GPU utilization: so sad! (Message 60379) Posted 30 Mar 2009 by garyn_87048 Post: Thank you for considering these options! Please consider using volunteers! I think there are several ‘safe’ ways (see below) to engage outside participation and make these changes happen quickly and effectively. Personally, I am very interested in seeing you succeed! I’m guessing this represents a much larger sentiment or the current CPU power directed your way would have gone elsewhere. Svincent, I read your post and I read your link. I agree with, embrace, and understand your concern. I think you can have both a faster project and generate dependable results. My Proposal: Admittedly, I have zero protein experience. However, I have extensive software experience and both a CS and CE background. I think your project may benefit from a three pronged approach, where each prong is nearly independent and each prong can be supported by various levels of volunteer hours and expertise. Prong 1: Each of your software releases represents a milestone which, at least temporarily, R@H believes to be stable and to generate reliable and useful results. I believe the easiest and quickest performance improvement is to compile this software in 32bit and 64bit native formats and then sub-divide these two branches into targeted CPU math libraries. This ‘multiple recompile’ could be an (almost) entirely a volunteer driven effort. The default R@H BOINC client gets the 32 bit version (the POR version, equivalent to no volunteer effort). Initially, only interested users download the specialized versions. Later, it may be possible to auto-detect the client host’s configuration. There is some chance that the various compiler optimizations may generate code that produces (hopefully only ‘slightly’ at worst case) different results. The combined R@H and volunteer effort (mostly volunteer) would be responsible for running these versions head to head (possibly even relying partially on BOINC client muscle) and begin building a library of ‘known’ tough proteins to test against all software releases. Prong 2: Get portions of the existing, stable, seldom changed, calculation-important software rewritten into an optimized format. For this task, I’m guessing that you can tap some very experienced volunteers - this area maybe particularly enticing to knowledgeable experienced volunteers with only limited extra bandwidth to donate. Modifications would be subject to the same (or even more rigorous) testing as prong 1. Again, the original POR code can be retained. Prong 3: Review the current design and processing flow and attempt to identify the best scheme for utilizing GPU power. The GPU approach is likely much more parallel than the current design. This analysis will help define R@H’s longer term roadmap and may possibly even lead to short-term unanticipated processing gains. Using mostly higher-level process flows, the volunteer community may provide some surprisingly innovative suggestions. Testing and implementation as in prong 1 and 2. Hope there is a useful nugget somewhere in this!
4) Message boards : Number crunching : CPU Optimization, GPU utilization: so sad! (Message 60352) Posted 28 Mar 2009 by garyn_87048 Post: Please provide a link to the CUDA enabled versions. I looked and didn't find them. And, this message board's responses to CPU/GPU inquiries has been (or appears to me to have been) "nope, and no such plans". It is possible that I may have misread the 2008-2009 posts. Yes, I think this is a great project! But, I don't seen CUDA enabled and CPU optimized applications available or in the pipeline. Generally, when these questions were posted they were referred to a list of reasons neither path is doable (see yesterday's post, message 60322). These guys/gals are no doubt very clever and I apologize if my wording obscures my primary point: I'm hoping to see recent CPU and GPU advances actively considered/embraced. If needed, consider recruiting volunteer to help. I think there are a lot of people interested in seeing this project succeed!
5) Message boards : Number crunching : CPU Optimization, GPU utilization: so sad! (Message 60349) Posted 27 Mar 2009 by garyn_87048 Post: I just finished reading threads 3879, “Number crunching: CPU Optimization” and 4042, “Number crunching: does GPU upgrade help for R@H”. The threads are both about a year old and both threads are a bit depressing. If I correctly captured the gist of these threads: no, R@H is not going to try and optimize, and no, R@H is not going to try and use GPU’s. It just seemed sad - R@H is such an appealing project. Yet, R@H development appears to be focused on the current software fires and oblivious to a long-term processing strategy. I think “The Bad Penguin” has some good suggestions. CPU optimization would appear to be the simplest, quickest, and easiest first step. R@H might be stuck in a paradigm that the software has to be re-written in order to achieve optimization. That may be ultimate solution, but I think there is a less costly initial step. At each release point, there is at least some group of code which is deemed to be at least momentarily stable. I believe the project would benefit by making native 32 bit, 64 bit editions and within each group having specific AMD and Intel math libraries. Being optimistic, I think it would also be beneficial to possibly extend the sub-groupings to SSE2 and prior, SSE3, and SSE4 (I’m not sure how the AMD processors divide out). Savvy R@H participants can find their best match. Those who either don’t care or don’t feel comfortable attempting would keep the stock version. CPU optimization part 2: From “Paul D. Buck” comments in the threads, it appears that there are some sections of R@H code that are more long term stable. It would seem like this would be an area to apply some amount of modest software re-write efforts. As group, BOINC projects seem to attract an at least a somewhat technically savvy audience (just look at the detail in some of the user questions). My naïve suggestion – would R@H consider engaging volunteers at release time to help generate the various CPU optimized flavors? Or, engage volunteers to help re-write the stable portions of the application? Maybe these efforts are already underway (awesome!), but if not, it feels like an untapped talent pool. GPU (the CUDA’s) utilization: it just seems short sighted not devote some effort into figuring out how to utilize these powerful processors within R@H. If I’ve missed the current CPU and GPU efforts, I apologize for my misdirected post. I did read the “Number crunching: Rosetta Application Version Release Log” for 2008/2009 and did not see any specific mention of CPU/GPU efforts.
6) Message boards : Number crunching : 64 bit version and/or processor optimized versions (Message 60318) Posted 25 Mar 2009 by garyn_87048 Post: Thanks Pete! Ooops, I posted too fast. I'll go look for the source code now. Gary Does rosetta@stone have a 64 bit version? Is there a FAQ? Are there optimized versions by operating system or CPU type? Thanks! Gary Hi Gary. No on both counts, only 32bit from what i can remember. anyone else got a better answer. Plenty of F.A.Q.'s around you just have to look. pete.
7) Message boards : Number crunching : 64 bit version and/or processor optimized versions (Message 60305) Posted 25 Mar 2009 by garyn_87048 Post: Does rosetta@stone have a 64 bit version? Is there a FAQ? Are there optimized versions by operating system or CPU type? Thanks! Gary

Posts by garyn_87048