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