Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

GTOP: single-threaded CMA-ES through parallel retry

The primary experiment asks a user-facing question: how much better is the solution distribution when the same wall-time allowance can use all physical cores? Every external cmaes optimizer instance is serial. Because CMA-ES can terminate protectively before the deadline, each lane immediately starts a new CMA-ES run and retains its best result. The serial arm uses one restart lane; the retry arm coordinates one lane per worker through fcmaes_core::retry. Both arms use the same lane deadline, objective, bounds, population, sigma, and deterministic root-seed scheme.

Equal-wall-time solution quality

Each retry pair includes the serial seed stream as lane zero plus additional independent streams in the parallel arm. Mean and population standard deviation (Sdev) of the best objective are the primary outcomes; smaller is better. Retry W/T/L is the paired win/tie/loss count for parallel retry. Measured wall time audits deadline comparability in the separate work table.

ProblemWorkersPairsSerial successRetry successSerial best meanSerial best sdevRetry best meanRetry best sdevRetry W/T/L
cassini11610038/100100/1005.1667780.1913084.9307090.00000286/12/2
cassini2161000/1000/10020.3950342.58588715.1405161.97976096/3/1
gtoc1161000/1000/100-1034840.688556140299.400512-1295551.114110104974.26905794/6/0
messenger161000/1000/10013.9507561.49258511.3004580.69451995/5/0
rosetta161000/1000/1006.7796102.2634462.8164240.80056293/4/3
sagas161000/1000/100171.74298235.723425120.59337548.15267692/7/1
tandem161000/1000/100-201.495632206.305874-598.689263216.83126993/7/0

The paired win count is primarily a scheduler check. Mean-start ratios range from 14.75× to 15.00×. Under iid independent restarts with no information sharing, a k-to-one ratio predicts a retry win probability of k/(k+1), or 93.7%–93.8% here. The observed W/T/L values are consistent with that baseline; the mean and sdev columns quantify the returned solution distribution.

Equal-wall work audit

The arms intentionally do not use equal CPU work. These counts document how parallel retry converts otherwise idle cores into more independent search within the same elapsed allowance.

ProblemWorkersDeadlineSerial wall meanSerial wall sdevRetry wall meanRetry wall sdevSerial starts meanRetry starts meanSerial evaluations meanRetry evaluations meanSerial active coresRetry active cores
cassini1164000 ms4.000109s0.000112s4.000491s0.000468s141.92114.41115347165981621.0016.00
cassini2164000 ms4.000150s0.000039s4.000503s0.000139s10.1151.2819929121772241.0016.00
gtoc1164000 ms4.000147s0.000140s4.000440s0.000125s74.71106.4789225117112011.0015.99
messenger164000 ms4.000135s0.000091s4.000469s0.000257s16.9252.0974569145121971.0016.00
rosetta164000 ms4.000140s0.000071s4.000523s0.000195s9.0133.1800001119027921.0016.00
sagas164000 ms4.000114s0.000090s4.000479s0.000269s67.41005.61702941253836631.0016.00
tandem164000 ms4.000146s0.000083s4.000510s0.000423s14.8221.6850532127745241.0016.00

Interpretation boundary

The equal-wall experiment intentionally spends more aggregate CPU in order to reduce user waiting time and improve the returned solution distribution. It is not an equal-CPU or algorithm-efficiency claim. The fixed-work comparison only isolates fcmaes_core::retry scheduling. The fcmaes-core CMA-ES row additionally changes the optimizer implementation and is not a pure core-count comparison. The coordinated DE→CMA results in the parent GTOP report use adaptive budgets and crossover, so they are a system-level reference rather than another equal-work arm.