The Applications section says there's an application for Android running on ARM, but when I attach my phone (5.1.1) and my tablet (4.4) it says Rosetta Mini is not available for my type of computer. Is there no Android work, or are my devices not running ARM?

---

Your device list shows that it reported in with ARM:
https://boinc.bakerlab.org/rosetta/hosts_user.php?userid=576954

The researchers that were using the ARM application have not produced any tasks for some time.

---

Rosetta Moderator: Mod.Sense

The researchers that were using the ARM application have not produced any tasks for some time.

I think they've abandoned Android because of these results:

There's a 11x performance loss when running the standard abinitio-relax folding protocol on a 96 residue protein sequence, compared to our in house machines. The average float and int ops BOINC cpu benchmark values of active hosts compared to Windows is around 2.4x and 1.7x less, respectively.

---

The researchers that were using the ARM application have not produced any tasks for some time.

I think they've abandoned Android because of these results:

There's a 11x performance loss when running the standard abinitio-relax folding protocol on a 96 residue protein sequence, compared to our in house machines. The average float and int ops BOINC cpu benchmark values of active hosts compared to Windows is around 2.4x and 1.7x less, respectively.

Well duh. Smartphones are never going to be as fast as computers, at least not for a long time. If every project abandoned android because it was slower, there wouldn't be any android projects like Seti or WCG.

Smartphones are never going to be as fast as computers, at least not for a long time. If every project abandoned android because it was slower, there wouldn't be any android projects like Seti or WCG.

I'd say they never will be as fast, a CPU allowed to burn 100+ Watts will always be a lot faster than one with only 1-2 Watts. And they are not only slower, they also have less RAM per core (and AFAIK no pagefile) and Rosetta likes/needs lots of RAM. SETI for example doesn't need much RAM, so better suitable for Smartphones/Tablets.

---

.

We may start sending small peptide modeling jobs to android devices which will require less memory but it may take some time to develop and test.

We may start sending small peptide modeling jobs to android devices which will require less memory but it may take some time to develop and test.

Is that something you could have some of the community members help with? Presumably it would require starting with source code and known good results from the x86 software as a benchmark, and some test tasks to run.

---

Is that something you could have some of the community members help with?

I hope that some of the community members help with cpu code optimization....

---

We may start sending small peptide modeling jobs to android devices which will require less memory but it may take some time to develop and test.

Is that something you could have some of the community members help with? Presumably it would require starting with source code and known good results from the x86 software as a benchmark, and some test tasks to run.

I don't expect significant differences in the results compared to standard platforms but we'll surely run and compare benchmarks. It will require an app update which will happen soon.

Is that something you could have some of the community members help with?

I hope that some of the community members help with cpu code optimization....

There is a volunteer who has been helping with compiler optimizations. His tests suggest that the largest gain worth pursuing would be from using icc. He did not see sufficient performance increases with sse3, sse4.1, and avx simd.

Is that something you could have some of the community members help with?

I hope that some of the community members help with cpu code optimization....

There is a volunteer who has been helping with compiler optimizations. His tests suggest that the largest gain worth pursuing would be from using icc. He did not see sufficient performance increases with sse3, sse4.1, and avx simd.

Did your volunteer try Profile Guided optimization and how much improvement did he see?

Since you link statically -fPIC is a waste, did your volunteer try building with the -fPIC turned off and how much did improvement did you see? Indirect branches through the GOT tables is fairly expensive.

Did your volunteer try Profile Guided optimization and how much improvement did he see?

I hope that this volunteer is doing something deeper than "recompile with flags"

---

originally thinking if i'd venture to 'volunteer' on that optimization challenge, but considering my own poor skills meddling in codes and a perpetual lack of time, decided to leave the challenge to the more competent hackers :o :p lol

hacking rosetta is a true and real brave effort, for the hackers looking for a cheap thrill on the credits, u could actually hack the boinc client codes which is an illegitimate way to spoof quite a lot of things :o :p lol

hacking rosetta is a true and real brave effort, for the hackers looking for a cheap thrill on the credits, u could actually hack the boinc client codes which is an 'illegitimate' way to spoof quite a lot of things :o :p lol

As per the other thread, increasing the BOINC benchmark wouldn't get you very far on Rosetta - it would increase the claimed credit, but the granted credit wouldn't be affected much at all.

---

got a little too curious & did some googling

found an interesting article/paper which seemed to describe rosetta (not sure if this is the same s/w & how recent/relevant does that reflect today's codes)
http://biochem218.stanford.edu/Projects%202012/Wang.pdf

the described algorithms are indeed innovative/elaborate/complex for after all we are solving *real* world problems which presents itself in all its native complexity.

it'd look pretty complex (it won't be easy) to optimise given descriptions e.g. of the scoring functions: "Two scoring functions are available. One is more coarse-grained but faster to compute whereas the second function is all-atomic and more accurate but also slower. The coarse-grained function takes into account the torsion angles of the backbone with the side chains described by a centroid located at the center of mass. In contrast, the all-atomic description considers all side-chain atoms, van der waals packing, hydrogen bonds and manifestations of water. The complete scoring function can be found in Rohl et. al., 2004"

and apparently it seem to suggest the algorithms (e.g. scoring functions?) are continually being enhanced continually to solve more difficult problems or different problems. i.e. there is apparently the scientific goals to address unresolved problems/models hence probably a need to keep the code clean /maintainable vs simply trying to do it the fastest, which may make maintaining codes / enhancing algorithms difficult.

i'm not too sure if simple matrix multiplication is involved if it is simple matrix multiplication it can be accelerated with widely available matrix libraries e.g.
https://www.tacc.utexas.edu/research-development/tacc-software/gotoblas2,
http://www.openblas.net/ and perhaps many more say from Intel / AMD etc.

but those vector/parallel SIMD computations apparently suffer from a 'matrix size' problem, tiny matrices derives very little benefit using the SIMD codes, only large sized square matrices actually see the significant improvements
https://boinc.bakerlab.org/rosetta/forum_thread.php?id=6683&nowrap=true#79077

but i'd like to wish would be optimizing challenge takers well / good progress in making better/faster rosetta s/w while keeping the scientific goals of solving the unresolved problems even further enhanced

seasons greetings,:D lol

but i'd like to wish would be optimizing challenge takers well / good progress in making better/faster rosetta s/w while keeping the scientific goals of solving the unresolved problems even further enhanced

This is the point.
The code optimization, for me, is NOT a request for a better rac/points, but for faster/better science!
Our cpus can use cores and extensions.
Our gpus can use computational power.

---

but i'd like to wish would be optimizing challenge takers well / good progress in making better/faster rosetta s/w while keeping the scientific goals of solving the unresolved problems even further enhanced

This is the point.
The code optimization, for me, is NOT a request for a better rac/points, but for faster/better science!
Our cpus can use cores and extensions.
Our gpus can use computational power.

this would seem a little overlap to the 'science' forum, but it's still more number crunching

did a little more googling and reading out of curiosity found this:

https://www.rosettacommons.org/docs/latest/rosetta_basics/scoring/score-types

apparently the codes has evolved and today those 'scoring functions' at the least is elaborate/sophisticated (perhaps somewhat complicated).
those 'scoring functions' seemed to involve various combinations some of terms multiplied ans summed over an entire molecular structure. e.g. as described/explained in a very simplified way :

http://www.rosettadesigngroup.com/workshops/RCW2007/presentations/GlennRosettacon2007.ppt

Rosetta Energy Function:

Weighted linear combination

Energy = w1*term1 + w2*term2 +

if there are many of such terms it may well be possible to accelerate that quite a bit (or even significantly) using those fused multiply and add and vector instructions available in the Intel Haswell & above CPUs especially if it can be made into a vectorized algorithm.

i'd guess the bigger is the structure (e.g. big proteins having large number of atoms) in which vector algorithms can be written, the bigger is the acceleration that could possibly benefit those calculations

only thing would be that it'd take someone effort to understand various aspects of rosetta and codes and just as importantly to learn those cpu specifics e,g. AVX intrinsics https://software.intel.com/sites/landingpage/IntrinsicsGuide/

start fiddling, optimizing and testing, could be an interesting but not easy challenge.

i'd like to wish would be optimizing challenge takers well / good progress in making better/faster rosetta s/w while keeping the scientific goals of solving the unresolved problems even further enhanced

seasons greetings,:D lol

apparently the codes has evolved and today those 'scoring functions' at the least is elaborate/sophisticated (perhaps somewhat complicated). Those 'scoring functions' seemed to involve various combinations some of terms multiplied ans summed over an entire molecular structure.

We know that the code is very complex and heterogeneous and this is why is difficult to optimize. As i proposed time ago, a solution may be to create one (or more) little "sub-project" with specialized code. In user profile, a volunteer may accept to participate. Some projects use this way.
Obviously I do not know the resources available to the team, so i do not know if it is feasible.

---

We know that the code is very complex and heterogeneous and this is why is difficult to optimize. As i proposed time ago, a solution may be to create one (or more) little "sub-project" with specialized code. In user profile, a volunteer may accept to participate. Some projects use this way.
Obviously I do not know the resources available to the team, so i do not know if it is feasible.

that appear quite possible as it seem boinc has some native support for this
https://boinc.berkeley.edu/trac/wiki/AppFiltering

one trouble though is that jobs/work units are linked to apps
https://boinc.berkeley.edu/trac/wiki/JobIn
this may lead to no work units being distributed to those apps
it may take some customizations or clever configs / setup to make those apps 'compatible apps' it'd seem such a feature don't exist today for boinc

[quote]
We know that the code is very complex and heterogeneous and this is why is difficult to optimize. As i proposed time ago, a solution may be to create one (or more) little "sub-project" with specialized code. In user profile, a volunteer may accept to participate. Some projects use this way.
Obviously I do not know the resources available to the team, so i do not know if it is feasible.

the other way apparently is to use platforms and in particular app planning

https://boinc.berkeley.edu/trac/wiki/BoincPlatforms
https://boinc.berkeley.edu/trac/wiki/AppPlan

You may have executables that exploit specific architectural features at a finer granularity than that of platform. For example, you may have an executable that uses AMD 3DNow instructions. There are two ways to arrange this:

Use the application planning mechanism to specify a class of app versions that can be sent only to hosts with particular CPU features;

this would be natively supported by boinc, using appplans would allow different versions targeting different cpu / gpu features to be used.

perhaps these schemes could be all tested out on ralph@home and researchers who volunteer to try out the 'bleeding edge' 'extreme performance' apps can send their jobs to the ralph@home pool (who know someone may volunteer their entire garage of petaflops gpu clusters in that pool) :D lol

http://www.forbes.com/sites/reuvencohen/2013/11/28/global-bitcoin-computing-power-now-256-times-faster-than-top-500-supercomputers-combined/