Gurobi 4.0.1 を用いて以下の問題を解く際にスレッド数を１から４８まで変えながら実行してみた。スレッド数が１変わっただけで実行時間も大きく変動し、スレッド数が多い方が良いとは限らない。
○問題 rol3000.mps (MPILIB2003)
スレッド数：実行時間(秒)
1 160.07
2 96.21
3 387.94
4 76.65
5 80.21
6 58.03
7 145.86
8 96.12
9 423.78
10 168.45
11 77.31
12 90.14
13 200.47
14 91.95
15 78.93
16 157.72
17 100.14
18 58.24
19 87.61
20 47.40
21 215.34
22 42.41
23 49.83
24 43.28
25 57.90
26 31.32
27 39.26
28 33.24
29 72.17
30 80.95
31 94.45
32 40.92
33 70.12
34 63.03
35 41.29
36 170.97
37 99.80
38 63.68
39 59.51
40 87.69
41 1109.85
42 27.78
43 48.02
44 81.63
45 31.08
46 33.40
47 43.11
48 63.69
○計算サーバ : (4 CPU x 12 コア = 48 コア)
CPU : AMD Opteron 6174 (2.20GHz / 12MB L3) x 4個
メモリ : 256GB (16 x 16GB / 1066MHz)
OS : Fedora 14 for x86_64
○問題 rol3000.mps (MPILIB2003)
スレッド数：実行時間(秒)
1 160.07
2 96.21
3 387.94
4 76.65
5 80.21
6 58.03
7 145.86
8 96.12
9 423.78
10 168.45
11 77.31
12 90.14
13 200.47
14 91.95
15 78.93
16 157.72
17 100.14
18 58.24
19 87.61
20 47.40
21 215.34
22 42.41
23 49.83
24 43.28
25 57.90
26 31.32
27 39.26
28 33.24
29 72.17
30 80.95
31 94.45
32 40.92
33 70.12
34 63.03
35 41.29
36 170.97
37 99.80
38 63.68
39 59.51
40 87.69
41 1109.85
42 27.78
43 48.02
44 81.63
45 31.08
46 33.40
47 43.11
48 63.69
○計算サーバ : (4 CPU x 12 コア = 48 コア)
CPU : AMD Opteron 6174 (2.20GHz / 12MB L3) x 4個
メモリ : 256GB (16 x 16GB / 1066MHz)
OS : Fedora 14 for x86_64
アクセス
トータル
一般的に，最適解発見の早さによって，全体の処理時間は大きく変わります．roll3000は，この傾向が特に顕著です．このインスタンスは4,5年前まで，open instanceでしたが，「最良下界値優先で探索したらCPLEXで解けた」というのが最初です．41スレッドでは，たまたま最適解の発見が遅れたのだと思います．
前日のブログにある某整数計画ソルバに関しては，nondeterministicでしか動作しない上，１nodeの処理時間も大きくばらつき，投機的実行も何種類かあって状況はさらに複雑です．この結果を見ると，nondeterministicで良い気がしてきました．「Deterministicを開発する目的はデバッグのためだけ」と言う人がいました．商用では，実行毎に計算時間が変わるのは説明に困るのでしょうが，スレッド数を変えてこれだけ変わると，結局，ある程度理解して使ってもらうしかない気がします．
もし，可能なら最適解を与えて計算を開始（つまり，最適性の保証のための計算のみ）して，同様の実験を行って見て頂けないでしょうか？ それでも，安定的に高速になるとは限らないと思うのですが，商用ソルバは，ここはミスらないのかな．