lmi
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]