Posts by robertmiles

1) Message boards : Number crunching : Ralph support OpenCL ? (Message 7270)
Posted 5 Nov 2022 by Profile robertmiles
Post:
You could look for online introductory courses in OpenCL. I'm interested in such a course so I can start doing an OpenCL version for another BOINC project. Ralph@Home and Rosetta@Home look like very difficult first projects, though.

The online OpenCL courses I've found so far all appear to either be long and expensive, or be basically addons for someone who is already using OpenCL.
2) Message boards : RALPH@home bug list : Web site bugs (Message 7079)
Posted 1 Nov 2021 by Profile robertmiles
Post:
Robert

Hopefully you posted this on Rosetta as well as this site gets very little maintenance.

Thanks
Bill F

Already done.
3) Message boards : RALPH@home bug list : Web site bugs (Message 7072)
Posted 29 Oct 2021 by Profile robertmiles
Post:
There's a problem with the way to recover from a lost password. The way to enter an email address to send recovery link to is quite hard to find.

I finally found it though. First, click as far right as you can in the area for entering this address. The box you enter it in should then appear. Entering it to the left of this box does nothing.

Rosetta@Home has this same problem.

Due to a failed computer, I could not use the alternate method based on information from the previous account.
4) Message boards : Number crunching : Ralph support OpenCL ? (Message 7071)
Posted 29 Oct 2021 by Profile robertmiles
Post:
You might accomplish more with your efforts to start OpenCL use if you look for online classes for OpenCL and mention here those that are both cheap and suitable for people with no previous OpenCL experience,


This could be an interesting course


It looks interesting - but not enough information to determine if SYCL is BOINC-compatible. Thanks, though.

No information on how to register fir the online classes without also registering for the not-so-cheap on-site events.
5) Message boards : Number crunching : Ralph support OpenCL ? (Message 7062)
Posted 15 Sep 2021 by Profile robertmiles
Post:
You might accomplish more with your efforts to start OpenCL use if you look for online classes for OpenCL and mention here those that are both cheap and suitable for people with no previous OpenCL experience,
6) Message boards : Number crunching : Ralph support OpenCL ? (Message 6977)
Posted 11 Mar 2021 by Profile robertmiles
Post:
We know there is a LOT of problems to "adapt" cpu app to gpu.
But, for example, they use gpu to "train" AI on Rosetta, so i think it's not impossible to produce gpu app for this project

It's not impossible. After all, it was tried previously, perhaps 9 years ago. The important point is whether it is worthwhile. The previous GPU version ran at roughly the same speed as the CPU version, so that was decided to be not worth continuing.


But, as we said before, some projects run both cpu and gpu apps, so it's not impossible.

PS. I'm much more optimist about cpu optimizations...

For Ralph and Rosetta, CPU optimizations look more worthwhile. For many other BOINC projects, trying GPU versions looks worthwhile.[/quote]
7) Message boards : Number crunching : Ralph support OpenCL ? (Message 6976)
Posted 11 Mar 2021 by Profile robertmiles
Post:
duplicate
8) Message boards : Number crunching : Ralph support OpenCL ? (Message 6971)
Posted 8 Mar 2021 by Profile robertmiles
Post:
Most of the alternate software packages mentioned here for GPU use under BOINC look usable if you want BOINC to start a task, and then have no control of that task until it finishes. But how many BOINC users want to allow that?

?
These "alternative softwares" are only compilers/library/tools that permit to compile sw to runs on gpu.
A lot of boinc projects run code on gpu automatically: gpugrid (CUDA), Einstein/Milkyway (OpenCl), MLC (Rocm)

I've run GPUGRID, Einstein, and Milkyway applications before. I haven't looked at MLC.

Years ago, a major section was added to BOINC to allow running CUDA applications. Another major section was then added to allow running OpenCL applications. I'd expect this to be required for adding capability to run applications using any other GPU computer language, although it is possible that other GPU computer compilers could translate their requirements into using either the CUDA section or the OpenCL section instead, or have a library that can do these translations.

Some of the things that must be handled :

1. Which GPU to use, if the computer has more than one.
2. Any pauses or slowdowns needed to allow the user to do something else on the computer before the application finishes,
3. A way to abort the application if the current task appears to be trying to run forever.
4. Reporting the application's progress to BOINC.

[snip]

Do you feel it is reasonable to pay that much money to produce GPU versions that, so far, seem likely to run at roughly the same speed as the CPU versions?

We don't know how gpu version could be faster than cpu version, cause we don't have gpu version.
Maybe 10%, maybe 70%, maybe 350%. We don't know.

Since the clocks for GPUs on graphics boards are typically about a quarter of the speeds of CPU clocks, the GPU version could be as slow as a quarter of the speed of the CPU version if it had no two operations that could run simultaneously. But in that case, no BOINC project would be likely to offer that GPU version.

However if the maximum possible number of operations that could run simultaneously on that graphics board were compatible with the program, the GPU version could run as fast as a fourth of the CPU application multiplied by the number of GPU cores in the GPU. For some of the latest graphics boards, that could be a thousand times as fast as the CPU version.

Ten times as fast as the CPU version is more typical for GPU versions released by BOINC projects, though.

Intel GPUs are occasionally able to run faster than graphics board versions, since Intel GPUs is inside the CPU package and can therefore have very high bandwidth paths to the CPU. Graphics board GPUs have slower paths through the PCIe slots and can only transfer fewer bits at a time.

The solution, maybe, will be to fork the code and run only one specific kind of simulation on gpu.

I've read that the Ralph@Home and Rosetta@Home applications have large collections of different software paths, many of which are not used in most tasks.

However, it should be possible to identify paths that are used the most and have the most possible speedup, and produce a forked version that uses only those paths, with GPU use where it is reasonable.

I've also read that the Rosetta developers do not want to deal with interpreting dumps from more versions of their applications, so I'd expect them not to want to do this.

Also, this would require the developers to produce a way to sort all of the tasks into those that can run on the GPU version and those that cannot.
9) Message boards : Number crunching : Ralph support OpenCL ? (Message 6969)
Posted 6 Mar 2021 by Profile robertmiles
Post:
Most of the alternate software packages mentioned here for GPU use under BOINC look usable if you want BOINC to start a task, and then have no control of that task until it finishes. But how many BOINC users want to allow that?

I've looked into getting the source code for the Ralph@Home and Rosetta@Home applications. It is allowed, but only for those who pay a fairly high price for it (several thousand dollars).

Do you feel it is reasonable to pay that much money to produce GPU versions that, so far, seem likely to run at roughly the same speed as the CPU versions?
10) Message boards : Number crunching : Ralph support OpenCL ? (Message 6960)
Posted 24 Feb 2021 by Profile robertmiles
Post:
You might post more information on how to learn some of the GPU computer languages compatible with BOINC.

I've already had online classes in C++ and CUDA, so I'm most interested in online classes for OpenCL.

I'm not to the point where I can check if the various other GPU computer languages you post about are compatible with BOINC.
11) Message boards : Number crunching : Ralph support OpenCL ? (Message 6888)
Posted 11 Sep 2020 by Profile robertmiles
Post:
I'd expect both Ralph@home and Rosetta@home to use only OpenCL compilers that can run under Linux but produce code to run under either Linux or Windows.

Also, remember that the last time they tried, the GPU code would run only at approximately at the same speed as the CPU code, rather than ten times the speed of the CPU code which is usually the minimum accepted for BOINC projects.
12) Message boards : RALPH@home bug list : Rosetta 4.12+ (Message 6860)
Posted 10 Aug 2020 by Profile robertmiles
Post:
A minor problem with the last batch of tasks - they arrive showing an estimated runtime of about 1 hour, but are now approaching an actual 6 hours.
13) Message boards : RALPH@home bug list : Rosetta 4.12+ (Message 6831)
Posted 30 May 2020 by Profile robertmiles
Post:
This seems like to be the same problems affecting several BOINC projects which have switched to SSL uploads and downloads.

Rosetta@home is one of those affected.

It's caused by an expired entry in the ca-bundle.crt file that's part of BOINC.

If that's the cause, it will take an update to that file to fix the problem by removing the expired entry.

That may, in turn, require a new version of BOINC for those users who don't know how to modify the files that are part of BOINC by any means other than updating BOINC.

https://boinc.bakerlab.org/rosetta/forum_thread.php?id=14006

https://boinc.berkeley.edu/forum_thread.php?id=13758&sort=5
14) Message boards : RALPH@home bug list : Rosetta 4.12+ (Message 6742)
Posted 27 Apr 2020 by Profile robertmiles
Post:
[snip]

robertmiles wrote:

I looked at TN-Grid. They are currently not accepting new users.
This is not correct. New users can join any time. They only need to create the account via the web site and need to enter the invitation code from the main page. AFAIK this is a measure to reduce spam, not to hinder new contributors to join. That said, it is true that their work generator always had and still has a limited pace. But my experience during the last few days was that my hosts remained saturated.

[snip]

I created the account, and have started running tasks.

They have finished creating all of the workunits for their planned COVID-19 work, and expect to have the rest of them downloaded soon.
15) Message boards : RALPH@home bug list : Rosetta 4.12+ (Message 6718)
Posted 11 Apr 2020 by Profile robertmiles
Post:
@robertmiles, I can't respond to your Ralph@home/ Rosetta@home related points, because I am new to Ralph and lack the insight. But a quick response to this unrelated item:
robertmiles wrote:

I looked at TN-Grid. They are currently not accepting new users.
This is not correct. New users can join any time. They only need to create the account via the web site and need to enter the invitation code from the main page. AFAIK this is a measure to reduce spam, not to hinder new contributors to join. That said, it is true that their work generator always had and still has a limited pace. But my experience during the last few days was that my hosts remained saturated.
/end-offtopic

[snip]
I think I was able to create an account. I'll finally try to add the project in a few hours, after I upgrade BOINC to 7.16.5. Thank you.
16) Message boards : RALPH@home bug list : Rosetta 4.12+ (Message 6716)
Posted 10 Apr 2020 by Profile robertmiles
Post:
I just increased the resource share for Rosetta@Home on my computer. Too soon to see the results from that yet.

My Ralph account shows no 4.15 tasks yet. Can you tell which if any of these possible causes does this?

1. They aren't testing 4.15 for Windows yet.

2. The tasks they show don't include any from the last few days, probably because the list was read from a rather obsolete copy of their database.

3. Their list of tasks for a user show them only for a day or so.

For one decoy tasks, note that the first decoy is usually only for testing how well your computer runs the software. That means that its output is seldom useful for any other purpose, and it may might not even be sent back.

I looked at TN-Grid. They are currently not accepting new users. They are thinking of starting some COVID-19 work, which would probably start a flood of new users if they don't keep limiting them.


On another subject, can't the wrapper for 32-bit tasks be recompiled or rewritten so that it runs in 32-bits, at least under 32-bit operating systems? Or maybe a script that tries the 64-bit wrapper first, and if that fails quickly with certain errors, tries the 32-bit wrapper instead? Does this need extra testing to handle a 32-bit version of BOINC running under a 64-bit operating system?
17) Message boards : RALPH@home bug list : Rosetta 4.12+ (Message 6705)
Posted 7 Apr 2020 by Profile robertmiles
Post:
I hope they will try widely 4.15 version before release it on production in Rosetta@Home.


Posts from the admin give me hope - but they'll need more volunteers here in order to ensure that, from what I understand.

That's what Ralph@home is for - testing new versions before they are released on Rosetta@home.
18) Message boards : RALPH@home bug list : Rosetta 4.12+ (Message 6678)
Posted 5 Apr 2020 by Profile robertmiles
Post:
Starting to see some rosetta 4.13 work on one of my Ubuntu servers since this afternoon.
So far all showing success.

I'm guessing 4.12 did not make it to prod then.

Rosetta work seems to have been depleted

4,12 made it over on Rosetta@home, even if it was not tested first on Ralph@home.

New users over on Rosetta@home are trying to download more tasks much faster than new tasks are created. Work over there WILL be depleted until they work out ways to generate new tasks faster.
19) Message boards : RALPH@home bug list : Rosetta_beta 4.0+ (Message 6565)
Posted 25 May 2018 by Profile robertmiles
Post:
More Error while computing, for v4.07 windows_intelx86:

http://ralph.bakerlab.org/result.php?resultid=4828008
Reason: Access Violation (0xc0000005) at address 0x00B1C0E8 write attempt to address 0x0FC2512C

http://ralph.bakerlab.org/result.php?resultid=4834727
ERROR: HybridizeFoldtreeDynamic: failed to build fold tree from cuts and jumps

http://ralph.bakerlab.org/result.php?resultid=4838682
ERROR: HybridizeFoldtreeDynamic: failed to build fold tree from cuts and jumps

http://ralph.bakerlab.org/result.php?resultid=4839839
Reason: Access Violation (0xc0000005) at address 0x00B1C0E8 write attempt to address 0x1614B12C

http://ralph.bakerlab.org/result.php?resultid=4839899
ERROR: HybridizeFoldtreeDynamic: failed to build fold tree from cuts and jumps

http://ralph.bakerlab.org/result.php?resultid=4839875
ERROR: HybridizeFoldtreeDynamic: failed to build fold tree from cuts and jumps


Also a few for v4.07 windows_x86_64:

http://ralph.bakerlab.org/result.php?resultid=4837014
ERROR: HybridizeFoldtreeDynamic: failed to build fold tree from cuts and jumps

http://ralph.bakerlab.org/result.php?resultid=4838794
ERROR: HybridizeFoldtreeDynamic: failed to build fold tree from cuts and jumps

http://ralph.bakerlab.org/result.php?resultid=4838713
Reason: Access Violation (0xc0000005) at address 0x00007FF744AEA206 read attempt to address 0xFFFFFFFF

http://ralph.bakerlab.org/result.php?resultid=4838711
Reason: Access Violation (0xc0000005) at address 0x000001F42FECB1C0

http://ralph.bakerlab.org/result.php?resultid=4841528
ERROR: HybridizeFoldtreeDynamic: failed to build fold tree from cuts and jumps


And a v4.07 windows_x86_84 Validate error:

http://ralph.bakerlab.org/result.php?resultid=4838714
ERROR: HybridizeFoldtreeDynamic: failed to build fold tree from cuts and jumps


But some of these same error messages occur for tasks that are Completed and validated, for example:

http://ralph.bakerlab.org/result.php?resultid=4838712
ERROR: HybridizeFoldtreeDynamic: failed to build fold tree from cuts and jumps

http://ralph.bakerlab.org/result.php?resultid=4839930
ERROR: HybridizeFoldtreeDynamic: failed to build fold tree from cuts and jumps


64-bit Windows
Microsoft Windows 10 Pro
10.0.17134 Build 17134
20) Message boards : RALPH@home bug list : Rosetta_beta 4.0+ (Message 6563)
Posted 25 May 2018 by Profile robertmiles
Post:
Looks like whoever wrote the message on 24/4/18 is still waiting for information on which versions of Windows were used for the 32 bit failures. If so, there's no point in complaining about lack of another message or fix until more people supply this information.

I just had a failure for Rosetta v4.07 windows_intelx86 under 64-bit Windows.

http://ralph.bakerlab.org/result.php?resultid=4826810

Microsoft Windows 10 Pro
10.0.17134 Build 17134


Next 20



©2024 University of Washington
http://www.bakerlab.org