[Development] QtCS 2017 QtCore sessions

[Thiago Macieira]

On Friday, 1 December 2017 11:57:33 PST Marc Mutz wrote:
> > Why can't they write
> > 
> > 	QStringView(s1).compare(s2) ?
> 
> I think you owe me a bit more thought on an answer to a mail of mine
> that that :P
> A quick look at the qCompareString() overload set will answer this
> question (hint: the lhs is not always QStringView).

I understand it isn't. But can't QStringView be constructed from any 
StringLike? What overhead do you get with the solution above that you wouldn't 
by calling qCompareString directly?

> > The flaw is in the standard because it does not allow me to implement
> > an
> > optimised version using whichever tools I want to.
> 
> The standard is not obliged to publicly give you all the plumbing to
> re-implement the standard library. 

Most of it, it has to. The standard library is written in C++.

The only exceptions should be chapter 21 "Language support library".

> The lack of plumbing is _sometimes_ a
> flaw in the standard, yes (std::invoke), but not always. You are
> supposed to use the standard library functionality, not re-implement it.
> In this case, the interface is char_traits::length, it exists on all
> supported platforms and does what we'd like it to do, incl., from C++17
> on, constexpr.

Except that it's not efficient. In fact, it *used* to be efficient in libc++ 
for char (strlen) and wchar_t (wcslen), but ceased to be because of the C++17 
requirement for constexpr.

I'm not accepting a performance regression.

> >> 2. You/Intel work on the compiler vendors to get
> >> char_traits<char16_t>::length() implemented as an intrinsic, with SIMD
> >> at runtime and compiler magic at compile-time?
> > 
> > We should do that anyway, but depending on it means we'll have
> > performance in
> > 2021 or later (just look at how we have to build Linux binaries with
> > GCC 4.8).
> 
> Since char_traits::length would be called from inline code in QSV, its
> performance does not depend on how Qt was compiled, but on what the
> user's compiler is capable of. Also, presumably, the compiler was
> already optimizing char_traits::length() back when it wasn't constexpr
> (in C++11+14) and now has to implement something to not regress on
> runtime performance while still meeting constexpr restrictions. If it
> doesn't, then it's not our problem. It's SEP. And that is good. Pick
> your battles.

I have picked my battles.

As I said above, it used to be efficient in libc++ (using wcslen) then was 
made not to be so. See libcxx commit 291741 "Implement P0426: Constexpr for 
std::char_traits". Fortunately, I now see the LLVM developers applied the same 
hacky solution for libc++ that GCC devs did for libstdc++ to get performance 
back again.

Also note in both cases this applies only to char and wchar_t. char16_t is not 
fixed.

> > The flaw exists today. My choice for fixing it is to sacrifice the part
> > we
> > don't really need: the constexprness.
> 
> Fixing it in Qt is limiting both Qt and the standard library. Don't do
> that.

I wouldn't mind co-authoring a paper about this. But we cannot wait for C++20 
for it to be accepted for performance to pick back up.

> <rant>
> The same is true, btw, of QMutex. Qt takes pride in how QMutex is faster
> than std::mutex. I think it's a shame. It shows that you didn't go the
> next step and get std::mutex fixed. Having QMutex not use std::mutex
> means that tsan doesn't work correctly, for one. Here, too, the "easy"
> local "fix" is to the detriment of both the standard library
> (slower-than-necessary mutex operations) and Qt (failure to work with
> tsan).

There's nothing wrong with std::mutex's definition. It can be made as 
efficient as QMutex, more than what QMutex is today and closer to what I have 
made it for Qt 6.

It's just QoI: the libc++ and libstdc++ implementation operate on top of a 
pthread_mutex_t. If they ditch that, like we did, they can get the 
performance. It's an ABI-breaking change, though, because of 
std::mutex::native_handle_type.

> This habit of cocooning might have worked out ok when Qt was years ahead
> of the C++ standard library. But since those times in the 2000s, C++ has
> overtaken Qt in all aspects the committee decided to take on. Qt will
> have to adapt to this new reality or degrade to insignificance. Ride the
> wave or drown.

The corollary of what you're saying is that we need to continue innovating. 
That's what I believe I'm doing.

And, again, where I think the committee got it wrong, I will NOT follow suit. 
Ditto for implementations, see QRandomGenerator.

> As I said elsewhere: innovate, don't replicate. See the bigger picture
> here: Where are the patches that integrate Qt's event system and
> signal/slots mechanism with Coroutines, to name just one? Instead you
> celebrate the perceived failures of the standard and Qt's ability to
> "fix" them by writing a SIMD strlen or take the null state of a Qt value
> class to optimize QOptional size.
> 
> This pattern repeats and repeats. V8 fork, anyone? When will Qt
> _finally_ learn? :) I said in my talks about QStringView that it's
> existential for Qt to get off its own container classes. I shall in the
> future extend that statement to anything that overlaps with std.

You and I disagree.

> I explicitly do not exclude QString here, even though it's exempt for
> the time being. But people _do_ talk about a std::text_view, and it
> _will_ support utf8 strings and that, in combination, _will_ degrade
> QString to insignificance.
> 
> When Coroutines and ASIO land in C++, C++ will magically gain a
> cross-platform event loop. And more likely than not, you will have to
> integrate with it using Coroutines, futures and other awaitables, not
> the classic way of QAbstractEventDispatcher. It does not take a leap of
> imagination to assume that Coroutines TS will spark a ton of reactive
> GUI libraries for C++, incl. cross-platform ones. Qt needs to be
> prepared for that day. And the only way to prepare is to start working
> on innovative stuff and work with its various upstreams more, incl. the
> standard committee, and innovate. Stop. Fixing. Stuff. Locally. Get.
> Involved. Don't. Kodak. Qt.
> </rant>


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center