Larger is better. It's stated above the table. It appears to be scaled so that mt19937 is 100. I'll change the entries to match the Performance section, which has the heading "relative speed compared to fastest [percent]." Is that clearer?
Maybe ;-) I always get confused by these kinds of performance comparisons. My preference is for the fasted to be given a fixed score (say 1 or whatever), and everything else then listed as relative to that. But there's no easy way.
Table 1.6 could use updating with more modern machines/compilers.
I'm working on generating quickbook automatically from the output of random_speed.cpp.
FYI Boost.Math does something similar in libs/math/tools/process_perf_results.cpp.
In "Header <boost/random/additive_combine.hpp>" the synopsis flows off the page, some of the others are probably too wide as well. I find generating a PDF and then checking all the "No space for an element, trying to recover" messages a good way to track these down. Might need some changes to the code formatting to make these readable if they're Doxygen generated? Let me know if you need help in PDF generation.
Fixing this will probably require changes to the BoostBook stylesheets. The original code is split onto multiple lines.
Oh :-( I suspect this is Doxygen messing things up then, because there's nothing in quickbook/boostbook/docbook that will change code formatting like this that I know of. Cheers, John.