Re: [boost] Boost perf tests?

Subject: Re: [boost] Boost perf tests?
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2015-09-21 10:32:33

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