[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Parallel blues
From: |
Vadim Zeitlin |
Subject: |
Re: [lmi] Parallel blues |
Date: |
Sat, 30 Jul 2016 22:46:16 +0200 |
On Sun, 24 Jul 2016 15:11:14 +0000 Greg Chicares <address@hidden> wrote:
GC> I feel like we're in the back old days when C++ compilers provided either
GC> no STL or a wretched one, so we used the objectspace or roguewave
GC> implementation, hacking it as necessary to overcome incompatibilities
GC> between it and our compilers. These newly-standardized libraries don't
GC> seem to be ready for production, at least not with MinGW-w64. Maybe other
GC> libraries are production-ready, but not <regex> and obviously not <thread>.
Unfortunately it's hard to disagree with this, but I feel that at least
the latter is really the problem of this particular compiler, as C++11
threading library works just fine with gcc under Unix as well as with MSVC
and clang under their corresponding platforms. And, of course, it also
works with TDM-GCC or nuwen MinGW distributions.
GC> This is a dead end. Threading turns out not to be a silver bullet.
I think this is slightly unfair as it does exactly what we expected, i.e.
achieves a slightly better speed up than using GNU parallel under Linux. It
just doesn't compensate for the awful performance of std::regex.
GC> I think we should just put this back on the shelf and reconsider it
GC> when the new standard libraries have matured.
I'm afraid we might be waiting for quite some time. If one of the
explanations of Boost.Regex performance advantage is its MT-unsafety, then
std::regex will never catch up with it.
So IMO the only realistic alternative is to switch to PCRE, although this,
of course, just replaces one third party library with another (albeit C
one).
Regards,
VZ