Hard to tell without seeing the actual definition.
But Galapagos is simply running over and over your definition.
Galapagos itself is not using much of the cpu (probably its math is really inexpensive).
so…
Is your definition multithreaded?
Most of Rhino and Grasshopper components run single-threaded.
If you manually move around the sliders, how many cpu cores are being used?
It’s strange that your definition run single-threaded on Windows but Multi-threaded on Mac.
Too strange.
Does it actually run quicker on Mac than on Windows? Time-wise.
… are you using Karamba?
Maybe some Karamba setting have it being multithreaded on Mac, but the same setting is single-threaded on Windows?
Maybe this setting exist outside Rhino… (never used karamba…)
No. That’s not how Galapagos solver works.
Galapagos is not brute-forcing any possible input combination, but instead it is making attempts heuristically checking the resulting “fitness” at each attempt. It have to be sequential in a way or another.
Please turn on the profiler and check the karamba component alone: is it using a single thread? Win? Mac?
Again my guess is that you have to look for karamba setting outside Rhino. I think they are set up differently from win to Mac.
As the solver starts it has no idea about the actual shape of the fitness landscape. Indeed, if we knew the shape we wouldn’t need to bother with all this messy evolutionary stuff in the first place. So the initial step of the solver is to populate the landscape (or “model-space”) with a random collection of individuals (or “genomes”). A genome is nothing more than a specific value for each and every gene. In the above case, a genome could for example be {A=0.2 B=0.5}.
I am a complete beginner in this topic, but couldn’t Galapagos hand the computation of each genome to a core? And say compute 16 genomes at once?
This is going OT.
(Have you solved the mistery why in one of your system it is going multithreaded and in another one not? Report please, this might be handy if someone else have the same problem…)
… current Galapagos implementation on Grasshopper do not do that. But I may be wrong.
From what I understand, Galapagos operate “externally” to normal grasshopper flow:
Normally GH data flow left to right. But galapagos isn’t inside that flow.
It’s like an external guy that:
move sliders (genome) to make a new attempt
take note of the results (fitness)
consider the past results and evaluate which new attempt to do
repeat
Any attempt is a single attempt.
Your best option is to optimize your code so it is run faster, so Galapagos make new attempts faster… or to look for another solver, alternative to Galapagos…
Although a few native components in GH1 are multi-threaded, the GH1 solver and Galapagos are not. So unless that file uses plug-in components which behave different on Mac than on Windows I don’t see where the multi-threading could possibly come from.
And yes, running the solver simultaneously during a Galapagos run would be quite possible in theory, GH1 is not threadsafe in any way and plug-ins are not expected to be thread-safe either. So running multiple gh documents at the same time in the same instance of Rhino is a recipe for disaster.
GH2 is fundamentally more multithreaded on a component level, but hopefully that just means that all cores will be occupied speeding up individual iterations, rather than running multiple ones simultaneously.
There’s no Galapagos equivalent yet for GH2 though…
