• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

FAH and BOINC?

S

Shlomo

2[H]4U
Joined
Oct 8, 2006
Messages
2,969
BOINC is a far superior client for all distributed computing networks in my opinion. I found it 500% easier to run a dual core processor on WCG than installing and setting up the SMP client. Why can't Stanford setup F@H to do all CPU work packets through BOINC?
 
Trust me a lot of us would like to see a more robust solution like that, but right now they are taking steps toward unifying clients and making peoples lives easier. Things like this can't be solved over night.



 
Shlomo said:
BOINC is a far superior client for all distributed computing networks in my opinion. I found it 500% easier to run a dual core processor on WCG than installing and setting up the SMP client. Why can't Stanford setup F@H to do all CPU work packets through BOINC?
Click to expand...

Why can't BOINC run on GPU cards ? :D

Clients have advantages and disadvantages, that's life ;)

 
Xilikon said:
Why can't BOINC run on GPU cards ? :D
Click to expand...

It actually can, just not WCG.

http://www.gpugrid.net/

Join with your Nvidia graphics card (beta)

* Read our rules and policies
* Install FROM HERE the latest Nvidia CUDA graphics driver (tested on Nvidia drivers >= 177.xx)
(Check compatible Nvidia graphics cards, recommended more than 50 stream processors)
* For Linux x64, download and install the GPU-enabled BOINC client.
* When prompted, enter http://www.gpugrid.net
 
The BOINC client, from what I understand (and I have several systems running it for WCG) doesn't work in the same way. On my systems it detects the number of cores and starts and instance for each core. In other words, it's basically the same as starting up an instance of the regular console client for each core you have. Yes, that is easier than the F@H clients, but that also has disadvantages.

SMP work units themselves I don't believe would be able to be processed using the BOINC client and that's a problem for what Stanford has in mind for the SMP work units. They want them run on at least two cores and sent back as fast as possible to keep the project moving as fast as possible. The fact that multiple cores are running on a single work unit makes this possible. I don't know if the BOINC client would be able to do something like this, especially since it autoconfigures for a client to start on each core.

Do not mistake my above comments as saying the F@H clients are better, because they definitely are not. All the different clients causes major confusion and can be huge pain in the ass. I would love to see one F@H client for each OS which can handle every type of work unit out there and have everything configurable from that single client. It would cut down on a shitload of the confusion and problems we currently have.

 
Not to derail the topic, but I have a question about the SMP software development. I may not understand correctly, but from what I see, someone that works for Nvidia is working on their GPU client, someone that works for ATI is working on their GPU client, but the SMP client is being developed in house by Stanford right?

Would there be any way to get Intel/AMD/other to help develop that client or am I too far off on this? I know if AMD/Intel helped write it, there might be some optimizations that would make it not run as fast on the other's hardware but really, that seems like it would be fine with me. As long as it is optimized period it would be better than right now. Or am I just off base completely (it happens;))

 
Wheresatom said:
Not to derail the topic, but I have a question about the SMP software development. I may not understand correctly, but from what I see, someone that works for Nvidia is working on their GPU client, someone that works for ATI is working on their GPU client, but the SMP client is being developed in house by Stanford right?

Would there be any way to get Intel/AMD/other to help develop that client or am I too far off on this? I know if AMD/Intel helped write it, there might be some optimizations that would make it not run as fast on the other's hardware but really, that seems like it would be fine with me. As long as it is optimized period it would be better than right now. Or am I just off base completely (it happens;))

Click to expand...

You are correct that ATI and NVIDIA is working on the GPU side but it's not the client (this is developed inhouse and has nothing to do with performance), it's the core. But it's a joint work with the inhouse core developer like Mark Friedrich.

For the SMP client, it's not really a core issue but a MPI issue and Intel/AMD has nothing to do with that. To break the dependency to MPI, the Gromacs core need to be rewritten for parallel computing and this is a open source software. However, it seems nobody is willing to venture that path since parallel computing programming is much more tricky since you must trash the normal programming logic and think differently. In short, the SMP core is developed inhouse but use the Gromacs code from http://www.gromacs.org/ with custom optimisations.

I already suggested to the PG to look at how the GPU2 client is working with parallel threading then port this to the SMP client in a attempt to break the MPI layer. It's a very big task so it's not easy to do this in a speedy fashion.

 
You must log in or register to reply here.
Back
Top