-
Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!
News From Pande Group (Stanford)
- Thread starter ChasR
- Start date
- Joined
- Sep 14, 2009
- Location
- Switzerland
That sounds pretty promising
- Joined
- Mar 31, 2005
- Location
- Stealing your megahurtz at night
It sounds like we will be able to expect better performance and reliability out of the clients. This is good news for all of us. 
for Pande Group!!
for Pande Group!!
- Joined
- Sep 20, 2007
Sounds Pretty promising,
- Joined
- Sep 22, 2004
Very interesting indeed... sounds like the landscape is going to change once again. 
I especially find the SMP2 upgrades interesting... I recall on several occasions pointing out that the SMP client was multi-process and not multi-threaded. Each core process is within itself running more than one thread, but not for scientific calculations... I suspect the other 3 out of the 4 threads an SMP core process are used for MPI (message passing interface), leaving the last thread for the actual calculations. In other words, there's the overhead with the current implementation.
From the standpoint of someone who writes log parsing code... I'll be happy to see the erratic log writes in the SMP client logs go away. I believe this truly multi-threaded approach will facilitate that.
Guess I need to get back on the (oh yeah, don't talk about ...) to get HFM ready for these new goodies.
I especially find the SMP2 upgrades interesting... I recall on several occasions pointing out that the SMP client was multi-process and not multi-threaded. Each core process is within itself running more than one thread, but not for scientific calculations... I suspect the other 3 out of the 4 threads an SMP core process are used for MPI (message passing interface), leaving the last thread for the actual calculations. In other words, there's the overhead with the current implementation.
From the standpoint of someone who writes log parsing code... I'll be happy to see the erratic log writes in the SMP client logs go away. I believe this truly multi-threaded approach will facilitate that.
Guess I need to get back on the (oh yeah, don't talk about ...) to get HFM ready for these new goodies.
- Joined
- Feb 25, 2004
- Location
- N of splat W of Torin
Always thought the old GPU2 client has been plenty stable... Out of 1908 GPU2 wu's completed I only have 6 failed. With at least 4 coming from power outages. This has been the best year ever for folding and forgetting. It may be my avoidance of SMP has helped as well.
If the GPU3 is more stable then that, that will be impressive.failed.jpg
If the GPU3 is more stable then that, that will be impressive.
failed.jpgAttachments
Last edited:
- Joined
- Jan 25, 2008
- Location
- Los Angeles, CA
I'm liking the sound of GPU3 being backward compatible. 
I hope that works well with current hardware.
Oh, and does that mean ATI will make use of all it's SP cores? ;-)
I hope that works well with current hardware.
Oh, and does that mean ATI will make use of all it's SP cores? ;-)
- Joined
- May 17, 2005
- Location
- High Desert, Calif.
Hmmm, OpenMM looks to be promising:
- Joined
- Dec 16, 2007
- Location
- Chicago, IL
Can't wait to see the next gen GPU's on GPU3.
I do not like going from multi-process to multi-threaded. I always liked the idea of multi-process, although it is slightly more overhead, I don't think it's that much. With each "thread" having it's own process it means that there is an individual PID, memory map. We don't have to worry about IPC, RPC or piping.
In the end this just makes my dream of a kerrighed cluster go from lack of a farm, to impossible without thread suppose in kerrighed, which 99.9% won't happen (too much work for little benefit/no one needs it)
In the end this just makes my dream of a kerrighed cluster go from lack of a farm, to impossible without thread suppose in kerrighed, which 99.9% won't happen (too much work for little benefit/no one needs it)
- Joined
- Aug 13, 2001
- Location
- Deep Blue Sea (Maryland)
does that apply to new/faster Window client too.......
- Joined
- Aug 13, 2001
- Location
- Deep Blue Sea (Maryland)
still wishing for a faster (efficient) window client (A2 core? 8 thread superbig WU?) one day.......
- Joined
- Oct 12, 2001
- Location
- Folding in Barbados
I'm definitely looking forward to the GPU3 client.
- Joined
- Mar 12, 2007
So does this mean we will have a native Linux and Mac GPU client? Maybe this is why they never had them for GPU2, partly because of the Wine wrapper and maybe because they dove in to this right after getting GPU2 stable. Why spend the time to get this running on another platform when they are just going to improve the core (all cores) and have what looks like built in portability.
Similar threads
