Long Term Roadmap?

[wuffy68]

The other day I posted about homunculi in-silico and the hypothetical scenario of simulating every protein in the human body simultaneously.
While this may be far-out, and elicit zero response, I thought I'd focus on my final question in the post regarding long-term roadmaps.

Given the current trends and advances in science, AI and computing, what is the vision for Folding@home (and distributed computing in the realm of protein folding science) over the next:

• * 5 years?
  * 10 years?
  * 25 years? (FAH has already been around for ~22 years)
  * 50 years?
  * even 100 years!?

While anything beyond five years will be speculative - perhaps discussing multiple paths to meet "some" grand end-goal would be beneficial to attracting more people to join the fold "today". We know that recent advances in mobile technology and cloud computing (like AWS) combined with low-latency networks (5G+ and Starlink) will disrupt PC workstation and PC gaming markets going forward, but how will those changes affect citizen science, distributed computing and philanthropy in the future? Will the same number of people+ be willing to pay to contribute their cloud time to the cause (outside of simply having bragging-rights to demonstrate it can be done)?

Thank you...

[Jonazz]

The researchers posted something like this, but it's 9 years old:

https://folding.typepad.com/news/2012/0 ... -come.html

[JimboPalmer]

There are many ways to view these forums, I tend to view them as help forums, If I have insights that can improve your folding experience, I share that. If I know less than you do, I try to stay out of the way and let others help.

There is a gotcha coming that I hope the development team is preparing for.

Years ago Sony wrote an Android port for F@H and just after that development, ARM invented a new technology that maimed their project.

In an architecture called big.LITTLE some number of simple, power frugal cores are included with some advanced power hungry cores on the same CPU.

https://en.wikipedia.org/wiki/ARM_big.LITTLE

There are actually 3 different versions and the rules change for each. F@H works with some but others were particularly difficult to code for.

1. You have some number of LITTLE cores and the same number of big cores, and if any program needs a big core, all the big cores replace all the LITTLE cores.

2 You have some number of LITTLE cores and the same number of big cores, and if any program needs a big core, that one LITTLE core is replaced by a big core.

3. You have some number of LITTLE cores and some number of big cores, if any program needs a big core, it is shifted to that big core, but all LITTLE cores remain active.

3 is a particular problem for F@H as the number of active cores varies over time and some cores are wildly faster than others. F@H is not currently written to cope with either issue.

Sadly for F@H, Windows 11 includes a scheduler that allows big.LITTLE, both in ARM and in x86. This will bite F@H code that has worked well for decades.

The simple, least appealing solution is to quit CPU folding. It would be far better to program F@H to only fold on big cores. Ideally, you would run one slot of LITTLE cores and another slot of BIG cores, so each WU only sees equally fast cores.

[wuffy68]

The researchers posted something like this, but it's 9 years old:

https://folding.typepad.com/news/2012/0 ... -come.html

Thank you - that would be a good basis to build upon starting in 2021 (along with adding a little more sci-fi factor for projections farther out). Unfortunately "villin", Aß aggregation of 4 chains, and proteins with 160 amino acids folding on multi-millisecond timescales don't necessarily inspire people in this world of "instant gratification" , but being a part of something huge in a not too distant future, might. No real immediate need, as COVID-19 seems to have brought in enough folks to keep the current work servers busy, but it would be a nice-to-have.

[wuffy68]

There are actually 3 different versions and the rules change for each. F@H works with some but others were particularly difficult to code for.

Interesting ... what is the range of performance one can expect (best, worst, average - given an identical WU), and are there BIOS-level settings that would enable users to chose which profile their system runs? My newest system is 5 years old
Most of us know, that the client warns any time there's a change in number of cores being used for any given CPU work unit (like adding a new GPU in the middle of a running CPU job, etc.) Even with BIOS-level control, without either having core-configuration specific FAH builds, or building the client with flags capable of toggling run level based on hardware configuration, it would add extra onerous steps for both developers AND for those wanting to get their feet wet with low-power folding (and perhaps make their shiny new equipment run less efficiently overall than what they bargained for).

I know FAH announced they will have NIH funding to update the client and control interface - not sure if big.LITTLE architecture support is included in that roadmap?

[JimboPalmer]

My understanding is that AMD has announced their intent to do big.LITTLE in x86, but I do not think any exist yet. Microsoft claims Windows 11 is big.LITTLE capable.

https://hothardware.com/news/amd-patent ... 8000-zen-5

https://wccftech.com/microsoft-windows- ... rformance/