CR Search Benchmarks:
Equipment: typical, slightly older Intel machines: 2 GHz processor, 1 GB memory
running Maple 9.5 or 10
The current implementation calculates the combinatorics resulting from a clique replacement, checks it against a catalogue to avoid combinatorially equivalent entries, calculates the symmetry group then counts the number of different paths between selected pairs of estranged vertices.
Benchmarks:
(5,10) 11,500 complexes 3000 secs (50 mins) cpu time
(6,12) 14,750 complexes 3000 secs (50 mins) cpu time
(7,14) (near Cube) 8,701 complexes 3806 secs (1 hr, 14 mins)
(7,14) (near DC) 1,335 complexes 1235 secs (20.5 mins)
(8,16) (near Cube) 4,137 complexes 4800 secs (1 hr, 20 mins)
(8,16) (near DC) 9,881 complexes 73820 secs (25 hrs)
(9,18) (near Cube) 1,613 complexes 7679 secs (2 hrs, 8 mins)
(9,18) (near DC) 1,570 complexes 74948 secs (26.4 hrs)
Notes:
The numbers above are significantly affected by catalogue checks to ensure that combinatorially equivalent complexes are not included twice. (For example, the numbers above do not indicate the five dimensional case being significantly faster. This is the result of the catalogue being nearly complete at 11,500 entries.)
Counting the number of different paths between certain pairs of estranged vertices is by far the most time consuming operation. A higher dimensional search could selectively perform this calculation.
The current implementation runs into significant memory problems for 10 dimensions, 20 facets. These arise entirely from the path count calculation and I expect we’ll be able to work around them in order to push the dimensions a bit higher. (12 dimensions, 24 facets seems a plausible goal.)
Currently, Stage 1 is written in Maple though according to some informal time trials, a switch to Matlab -- for example -- would yield a factor (x4) speed improvement and likely an improvement in memory management.