I believe the documentation already states (emphatically) a health warning that --enable-dummy is only for scientific reproducibility of sorts. It is our best attempt to provide a platform-independent version of the code for reproduction purposes. It is 100x or more slower than the production version, and should never be used in real-world analysis. (We also use it as a reference implementation, testing the vectorized production code against it.) There is no way that any Linux production distro should be using a ./configure --enable-dummy, please.
In retrospect I've realized that --enable-dummy is in fact more problematic than helpful, because it's a catch-22; we cannot maintain and test on platforms we do not have. We believe that the test failures can be ignored (caused by minor numerical issues) and that the example "dummy" code is portable and functional, but still. I expect we will remove the "dummy" implementation option altogether in the next major release; it will still be there, but only used in our tests. > On Dec 3, 2015, at 11:12 AM, Edmund Grimley Evans > <edmund.grimley.ev...@gmail.com> wrote: > >> Travis, the issue is that they want ARM and PPC64le support > > Yes, that would be very nice. But there's also the issue that > "--enable-dummy" doesn't work even on Intel. Perhaps you don't > consider that to be a major issue, but it might be as easy to fix it > as to modify the documentation to explain that it is not expected to > work. > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806675
