||To be honest, I tried to use GA in TCO01 and TCO02 marathons, and it was actually working (i.e. converging somewhere), but it worked worse than even the simplest SA. The cool thing about GA is that its process is not dependent on time (no temperature like in SA). Maybe GA requires more time to produce good results, I don't know. I would be happy if some "marathon jedi" wrote GA recipe which really showed how to make GA work better than SA.
Below you can read why this time synchronization mechanism was invented. Now it comes to my mind that instead of doing all that ugly things I can simply write:
if (!(iters & (ITERS_PER_SYNC - 1)))
done = (gettime() - starttime) / hastime;
I'll investigate how it affects the solution and edit the code=)
Synchronization with time means: temperature = F(work time). Note that the function parameter is work time instead of iteration number. So I want SA to take precisely 9.7 seconds on a marathon with 10 seconds TL=) It is quite strange if SA ends in 5 seconds and other 5 are wasted or if it doesn't have time to end properly. It is useless to restart SA from the very beginning since the first iterations effectively randomize the solution (temperature is very high).
During the first ITERS_WARMUP iterations SA works with maximal temperature (it is not greedy, but almost random). These iterations are required to estimate how much time is consumed per one iteration. Then it is assumed that all iterations spend approximately the same time. So if we did K iterations and spent T time on them, the time limit is L, then we can do about K*(L-T)/T more iterations. As you see, there is division on T. That's why this "synchronization" scheme is enabled only after several first iterations.
This modification is actually doing the start slower. The first ITERS_WARMUP are almost wasted. But I tweak this constant so that the time spent on warmup is about 0.1 - 0.5 seconds. So I do not lose much=) But I gain stability in the cooling schedule.
By the way, the assumption that all iterations take the same time is often wrong. For example, 2-opt TSP mutation takes O(1) time to generate and calculate score, but O(V) time to apply. That's why iterations with big temperature will take significantly more time that iterations with small temperature (mutation acceptance ratio is different).
But as I wrote above all this ugliness is completely unnecessary=) Thanks for a question!