Boost perf tests?
Hi Boost devs, Does Boost have any runtime perf tests? We (MSVC) are looking for something that uses modern C++, which would reveal areas where our optimizer and libraries could be improved. I looked around briefly, but didn't find anything. Thanks, STL
On 17.09.2015 20:00, Stephan T. Lavavej wrote:
Hi Boost devs,
Does Boost have any runtime perf tests? We (MSVC) are looking for something that uses modern C++, which would reveal areas where our optimizer and libraries could be improved.
I looked around briefly, but didn't find anything.
I have a few tests in libs/log/test/performance. I also have a perf test for different versions of operators on boost::uuid locally, although it's more about low level optimizations.
Does Boost have any runtime perf tests? We (MSVC) are looking for something that uses modern C++, which would reveal areas where our optimizer and libraries could be improved.
I've just recently reworked the Math lib performance tests - all floating point stuff of course so may or may not be what you're looking for ;) See the libs/math/reporting/performance directory in develop, can produce reports such as: https://rawgit.com/boostorg/math/develop/reporting/performance/html/index.ht..., you may wish to investigate ::tgamma by the looks of things (see https://rawgit.com/boostorg/math/develop/reporting/performance/html/index.ht...), on the other hand, congratulations on yn ;) There are also performance tests for multiprecision under libs/multiprecision/performance. No nice tables this time :( However, the library does use noexcept and constexpr quite a bit. Whether the differences those make are detectable compared to the algorithmic overheads is debatable. HTH, John.
Hi Stephan, Stephan T. Lavavej wrote:
Hi Boost devs,
Does Boost have any runtime perf tests? We (MSVC) are looking for something that uses modern C++, which would reveal areas where our optimizer and libraries could be improved.
I looked around briefly, but didn't find anything.
Boost.Container https://github.com/boostorg/container/tree/develop/bench Boost.Geometry: https://github.com/boostorg/geometry/blob/develop/index/example/ Try benchmark_experimental.cpp Also here are some: https://svn.osgeo.org/osgeo/foss4g/benchmarking/geometry_libraries/compariso... https://svn.osgeo.org/osgeo/foss4g/benchmarking/geometry_libraries/compariso... Boost.Polygon: http://www.boost.org/doc/libs/1_59_0/libs/polygon/doc/voronoi_benchmark.htm Regards, Adam
[Andrey Semashev]
I have a few tests in libs/log/test/performance. [...]
[John Maddock]
I've just recently reworked the Math lib performance tests [...]
[Adam Wulkiewicz]
Boost.Container [...]
Thanks! And if you run into any specific perf issues, either in the libraries or the optimizer, please let me know. (I should mention in advance that we're aware of the iostreams floating-point parsing issue.) STL
On 17.9.2015. 20:53, Stephan T. Lavavej wrote:
Thanks! And if you run into any specific perf issues, either in the libraries or the optimizer, please let me know.
IMO, the #1 place you should start with is the NT2 library (https://github.com/jfalcou/nt2), it really tortures both the frontend (metaprograming/compiletimes) and the backend/optimiser (you seriously lag there behind GCC and Clang). The guys behind NT2 are just extracting the core of their lib to submit it as Boost.SIMD. You might want to 'check in' with Eric Brumer from the backend team (if he still works with MS) as we had lengthy exchanges about MSVC codegen deficiencies (even, still not fixed, regressions actually) and how to fix them primarly WRT NT2. In the process I've created quite a few related Microsoft Connect tickets, I guess you can find them by my name (+ their names are all prefixed with "[MSVC]") but the central one is: [MSVC] Serious SSE codegen regression https://connect.microsoft.com/VisualStudio/Feedback/Details/804579 In short, IMHO MSVC codegen deficiencies WRT C++ abstractions primarily come from the lack of the SRA optimisation, lousy ABI/calling conventions (MS x64? you can't be serious ;P) 'poor' alias analysis, tracking/elimination of temporaries and register allocation/stack thrashing, inlining heuristic (AFAICT 2015 still does not "always inline" functions with a single call site)... Boost.Spirit would be my next choice - you don't actually need any benchmarks there (as in most other situations) - just look at the codegen - usually it's a facepalm moment, i.e. you don't need to measure to see that there are 5 times more instructions than there need to be ;) For ABI/calling convention improvements specifically I'd use Boost.Units - seriously, 'the world finally wants' to be able to write foo( 4.3kHz ) without compilers passing that through the stack :P (comments/issues pointed out by Niall Douglas WRT his monad library, very similar to ones I experienced with my 'upcoming' Boost.Err library, also come into play here)...
(I should mention in advance that we're aware of the iostreams floating-point parsing issue.)
Considering how broken (performance-wise) iostreams are by-design, I don't expect tuning the fp parser will make anyone measurably happier ":)" Looking forward to VS2015 u1 ;-D -- Domagoj Saric Software Architect www.LittleEndian.com
On 21/09/2015 16:32, Domagoj Saric wrote:
On 17.9.2015. 20:53, Stephan T. Lavavej wrote:
Thanks! And if you run into any specific perf issues, either in the libraries or the optimizer, please let me know.
IMO, the #1 place you should start with is the NT2 library (https://github.com/jfalcou/nt2), it really tortures both the frontend (metaprograming/compiletimes) and the backend/optimiser (you seriously lag there behind GCC and Clang). The guys behind NT2 are just extracting the core of their lib to submit it as Boost.SIMD.
We'll more than happy to help on this front, Stephan. If you're interested, you can contact me off-list.
participants (6)
-
Adam Wulkiewicz -
Andrey Semashev -
Domagoj Saric -
Joel FALCOU -
John Maddock -
Stephan T. Lavavej