Am 24.01.20 um 21:53 schrieb peter green: > I still don't think -march=native is appropriate for a binary > distribution though. If you want to offer different versions of the > code built with different CPU requirements, that is fine, but please > don't let them depend on what CPU happens to be in the autobuilder.
Better ideas are welcome. Tesseract is used for mass processing of books which can take many weeks or even months. Therefore it is very important that the time critical code (dot product calculation) runs as fast as possible. For x86_64 we know the available SIMD instructions (SSE, AVX, ...) which can be used, add code for all variants and check at runtime what is supported by the CPU. For all other architectures (including ARM) there is currently no such special code, and the default code is rather slow. By using -march=native for the alternate code, hopefully the compiler will produce code which runs faster on any machine which is similar to the build machine. Users who build Tesseract on the machine which is also used for the mass production will get the best result like that. Users using a distribution can try the "native" option and either crash the program or get a possibly faster result. I see the problem of builds which depend on an autobuilder which may be different for each build. What would be the best solution for distributions? Suppress the code using a new configure option or some magic which detects that the build is for a Debian distribution? Choose compiler flags manually for the "native" option (that is already possible, see my previous answer)? Other solutions? Stefan
