ropensci / beastier

R package to run BEAST2
https://docs.ropensci.org/beastier
GNU General Public License v3.0
11 stars 1 forks source link

Speed up `run_beast2` calculation #64

Open richelbilderbeek opened 2 years ago

richelbilderbeek commented 2 years ago

From Wei:

[...] may I ask one more question?

As you see, my dataset is quite big. I use a powerful workstation equiped with Intel(R) Xeon(R) Gold 6230R CPU and 128G RAM. I want to shorten the BEAST2 calculation. Here are some test I did to run_beast2 function by changing n_threads: n_threads = 10, cpu use around 20%, RAM use 12% n_threads = 100, cpu use around 30%, RAM use 18% n_threads = 1000, cpu use around 20%, RAM use 18% n_threads = 10000, cpu use around 5%, RAM use 20%

Seems there is a glass ceiling for the function that whatever n_thread I set it won't increase the efficiency any more. Would you have a suggestion?

richelbilderbeek commented 2 years ago

I am unsure if this has anything to do with beastier, as beastier 'just' calls BEAST2. Asking the BEAST2 user groups is a better place for this (and it would be nice if you'd share the link :-) ).

However, there is an untested use_beagle option in beastier. BEAGLE is something for multi-threading and I don't know how it works, I only used it to get closer to the full functionality of BEAST2. If you can see differences between BEAST2 and beastier calls (i.e. my code is flawed), I'd be happy to improve!

Additionally, this may have little to do with BEAST/BEAGLE and may be a general feature of multithreading. We know that having x more threads does not mean we get x more speed, as computing power is lost by communication between the threads, as well as processes that need to wait for all threads to finish.

&TLDR: no idea, may be a general problem, unsure if it is in beastier, try asking/comparing at/with BEAST2