Re: [Development] HEADS-UP: Q_UNLIKELY

[Thiago Macieira]

On Friday, 30 August 2019 06:31:29 PDT Mutz, Marc via Development wrote:
> 2. As a separate ELF section, barring relocations etc that might prevent
> this, these .cold sections will stay parked on disk and loaded into
> memory only on demand, which means that executing unlikely code may make
> the program actually very slow (like exceptions, which on modern ABIs
> have zero runtime overhead when not thrown but may load debug symbols to
> unwind the stack when thrown).

There are no relocations in code and there haven't been for decades. Their 
existence causes warnings in the linker and Linux distributions flag them. The 
ELF header gets a DT_TEXTREL because of that.

Position-Independent Code is achieved by having the relocations in a separate 
table, which is called the Global Offset Table (GOT). That way, all the 
relocations are dense: it's pagefuls of relocated addresses, as opposed to 
accidentally causing a page to be dirty/unsharable because of a single 
relocation.

So, no, relocations will not cause the .text.unlikely section to load.

> This is not something we can control (that I know of, other than telling
> Ville to change it), so we don't need to discuss whether that's good or
> bad. It simply _is_.

There's also the question of whether the OS would have proactively loaded that 
page. First, the OS doesn't know where the active code will be until it starts 
executing, so it may decide to load everything. Second, the .text.unlikely 
section is going to be bracketed by loaded pages (regular .text before and 
.rodata after), so the OS may decide to load that or keep it in memory.

> In turn, this means that we should no longer use Q_UNLIKELY (I don't
> know about Q_LIKELY, but am willing to be enlightened) to mark code that

#  define Q_LIKELY(expr)__builtin_expect(!!(expr), true)
#  define Q_UNLIKELY(expr)  __builtin_expect(!!(expr), false)

There's little difference between the two. Every time you use either, then one 
code path is likely and the other is unlikely.

> gets executed 0.01% of the time, but with very high chance _is_ executed
> in normal program flow once, because that causes all the error handling
> code to be paged in. We should use it only (but then we should strive to
> actually do so) for actual error code. A good indicator is if a
> qWarning/qFatal/qCritical is executed: that's error code.

Interestingly, that's one case you don't need to.

Take a look at . As you can see, GCC split 
the f() function in two, with an unlikely section ("clone .cold"), simply 
because it is calling a cold function. Our warning, critical and fatal 
functions are all marked cold. That was done in commit 
c6497e3eac1ac81497f02b40ea7f140a997b4f29 by a certain Marc Mutz :-)

Unfortunately, other compilers don't do that: https://gcc.godbolt.org/z/pXFibR
But it's not a loss because they don't have .text.unlikely sections anyway.

> doesn't work with older GCCs which claim [[unlikely]] support, so we
> will need to either add compiler version checks, or yet another macro,
> or restrict the patterns to the known-good ones:
> 
> Q_UNLIKELY_CASE case-label:

We'd need a macro anyway because of older compilers that don't support the 
attribute. The older C++11 rule was that they should complain on attributes 
they don't understand anyway.

I don't mind adding the macro now.

But I do mind littering our code with it. It's of very limited value so far 
since few compilers support it. And using the Q_LIKELY/Q_UNLIKELY macros is 
already prone to error: as you've pointed out, a since one of those getting 
executed causes a page to be loaded that wouldn't otherwise be.

The correct way to deal with that is profile-guided optimisation. Compile Qt 
with instrumentation, run some complex but representative applications, then 
feed the profile results back into GCC. That way, it will organise the code to 
optimise I-Cache usage and move actually unlikely code as well as only-used-
once code to separate pages.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal for an efficient and robust (de)serialization mechanism working with Qt-supported data

[Arnaud Clere]

-Original Message-
> From: Bogdan Vatra  
>
> It will be great if we can find a way to use it any (de)serialization 
> mechanism (e.g. proto buff, flat buffers, etc.) not only with only one (qt 
> specific).

As explained in the answer to Simon, QBind replaces .proto files with C++ 
functions to not require external tools. 
It is probable although uncertain that protobuf's binary encoding [1] can be 
read/written by QBind.
But the corresponding IBind implementation would not be trivial as it would 
need to map record's item names to unique integers and stack the current data 
structure that is implicit in the binary encoding.
It is even more probable that flatbuffers could have an IBind implementation 
since they claim to not erase any information but I did not look at the 
details[2].

FWIU, both protobuf and flatbuffers achieve ultimate performance by mandating 
that you use their generated data structures even though you can hide them in 
your own classes (where you can also add behavior).

Although QBind may be compatible with their binary encodings, it could not 
provide the same performance, just approach it.
OTOH, the approach of QBind keeps the data format and C++ types more cleanly 
separated and requires no tool nor separately compiled data structures.

Arnaud

[1] https://developers.google.com/protocol-buffers/docs/encoding
[2] https://google.github.io/flatbuffers/flatbuffers_internals.html 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal for an efficient and robust (de)serialization mechanism working with Qt-supported data

[Arnaud Clere]

Hi Simon,

I actually plan to attend QtCS and trigger a discussion on this as the topic is 
crossing many lines.
In the meantime, in order to move forward, I will submit a codereview with just 
the core of QBind, focusing on how to offer more flexibility & efficiency in 
writing C++ data into Json+Cbor.

The question you are raising when talking about schemas is: "where do I look 
for information about the structure of the data?" (typically when reading...)
- For QDataStream, the answer is: "into the code"...  but which version of "the 
code" ? QDataStream::version() evolves at Qt's pace, so as a Qt user, it may 
not be enough to know how to read your own data from one machine to another
- For protobuf and the like: "into an external schema file" which ensures you 
cannot misinterpret the binary data and allow gradual changes to the schema... 
but you have to interpret the schema using external libs or in the case of 
protobuf compile the schema into executable code to start reading data
- For Xml: some of the structure can be guessed from markup but it is more 
"open to interpretation" and you will probably need an external schema or 
additional information to make sense of the data
- For Json, Cbor: most structure is made explicit by the standard, so even a 
third-part may be able to do a lot with your data, although its semantic may 
remain obscure if maps/objects do not use meaningful names

As a result, it is usually easier (and safer!) to deal with explicitly 
structured data as Json and Cbor, and that is what I would usually recommend.
Even though QBind cannot beat QDataStream/protobuf on raw write performance, 
QBind can be very close to them when writing Cbor.

Compared to QDataStream::operator<< and >>, QBind requires the code to be more 
descriptive about the data behind a C++ type (sequence of items or record of 
named items).
It can then translate it in explicitly structured data formats like Json, Cbor, 
Xml, Tables, etc. or just ignore it in implicitly structured data formats like 
QDataStream.

Compared to protobuf, QBind replaces external schema files + tool with a C++ 
fluent interface that is akin to an embedded DSL, just, a very trivial one.
So it does not need external tools (but does not help reading the data in other 
languages). And it allows choosing the adequate data format according to the 
requirements: binary for performance, explicit text-format for interoperability 
with other languages, XML for the toolset, what else?

Hope it helps thinking about the various pros/cons involved...

Cheers,
Arnaud

From: Simon Hausmann mailto:simon.hausm...@qt.io>>
Sent: vendredi 30 août 2019 15:43
To: Arnaud Clere 
mailto:arnaud.cl...@minmaxmedical.com>>; Edward 
Welbourne mailto:edward.welbou...@qt.io>>
Cc: development@qt-project.org
Subject: Re: Proposal for an efficient and robust (de)serialization mechanism 
working with Qt-supported data

Hi Arnaud,

I think that perhaps this is also a topic worth discussing at the Qt 
Contributor Summit, if you can attend. During a face-to-face discussion we may 
be able to find a good understanding more efficiently of what exactly it is 
that we need in Qt.

I'm interesting in discussing how we can get away from QDataStream towards 
something more schema oriented. Perhaps that involves an intermediate 
abstraction similar to what you're proposal.

Simon

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal for an efficient and robust (de)serialization mechanism working with Qt-supported data

[Bogdan Vatra via Development]

Hi,

  It will be great if we can find a way to use it any (de)serialization 
mechanism (e.g. proto buff, flat buffers, etc.) not only with only one (qt 
specific).

Cheers,
BogDan.

În ziua de vineri, 30 august 2019, la 16:42:54 EEST, Simon Hausmann a scris:
> Hi Arnaud,
> 
> I think that perhaps this is also a topic worth discussing at the Qt
> Contributor Summit, if you can attend. During a face-to-face discussion we
> may be able to find a good understanding more efficiently of what exactly
> it is that we need in Qt.
> 
> I'm interesting in discussing how we can get away from QDataStream towards
> something more schema oriented. Perhaps that involves an intermediate
> abstraction similar to what you're proposal.
> 
> Simon
> 
> From: Development  on behalf of Arnaud
> Clere  Sent: Friday, August 30, 2019 15:37
> To: Edward Welbourne 
> Cc: development@qt-project.org 
> Subject: Re: [Development] Proposal for an efficient and robust
> (de)serialization mechanism working with Qt-supported data
> 
> Thank you,
> I will then submit a patch with the core of QBind and ask for reviewers.
> Arnaud
> 
> -Original Message-
> From: Edward Welbourne 
> Sent: jeudi 29 août 2019 17:39
> To: Arnaud Clere 
> Subject: Re: Proposal for an efficient and robust (de)serialization
> mechanism working with Qt-supported data
> 
> Hi Arnaud,
> 
> > I only received feedback from users in private, so I guess this is not
> > the right mailing list to ask for feedback on new features.
> 
> The development@ list is entirely apt as a place for this discussion.
> It's just that we're all rather busy (we just passed a feature freeze for a
> release we'll be polishing for the near future) and the Qt community
> generally works by "if no-one objects, go for it".  FWIW (not much, as this
> is outside my field of expertise) what you describe sounded interesting and
> worth turning into a code review on https://codereview.qt-project.org/
> 
> Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal for an efficient and robust (de)serialization mechanism working with Qt-supported data

[Simon Hausmann]

Hi Arnaud,

I think that perhaps this is also a topic worth discussing at the Qt 
Contributor Summit, if you can attend. During a face-to-face discussion we may 
be able to find a good understanding more efficiently of what exactly it is 
that we need in Qt.

I'm interesting in discussing how we can get away from QDataStream towards 
something more schema oriented. Perhaps that involves an intermediate 
abstraction similar to what you're proposal.

Simon

From: Development  on behalf of Arnaud 
Clere 
Sent: Friday, August 30, 2019 15:37
To: Edward Welbourne 
Cc: development@qt-project.org 
Subject: Re: [Development] Proposal for an efficient and robust 
(de)serialization mechanism working with Qt-supported data

Thank you,
I will then submit a patch with the core of QBind and ask for reviewers.
Arnaud

-Original Message-
From: Edward Welbourne 
Sent: jeudi 29 août 2019 17:39
To: Arnaud Clere 
Subject: Re: Proposal for an efficient and robust (de)serialization mechanism 
working with Qt-supported data

Hi Arnaud,

> I only received feedback from users in private, so I guess this is not
> the right mailing list to ask for feedback on new features.

The development@ list is entirely apt as a place for this discussion.
It's just that we're all rather busy (we just passed a feature freeze for a 
release we'll be polishing for the near future) and the Qt community generally 
works by "if no-one objects, go for it".  FWIW (not much, as this is outside my 
field of expertise) what you describe sounded interesting and worth turning 
into a code review on https://codereview.qt-project.org/

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal for an efficient and robust (de)serialization mechanism working with Qt-supported data

[Arnaud Clere]

Thank you,
I will then submit a patch with the core of QBind and ask for reviewers.
Arnaud

-Original Message-
From: Edward Welbourne  
Sent: jeudi 29 août 2019 17:39
To: Arnaud Clere 
Subject: Re: Proposal for an efficient and robust (de)serialization mechanism 
working with Qt-supported data

Hi Arnaud,

> I only received feedback from users in private, so I guess this is not 
> the right mailing list to ask for feedback on new features.

The development@ list is entirely apt as a place for this discussion.
It's just that we're all rather busy (we just passed a feature freeze for a 
release we'll be polishing for the near future) and the Qt community generally 
works by "if no-one objects, go for it".  FWIW (not much, as this is outside my 
field of expertise) what you describe sounded interesting and worth turning 
into a code review on https://codereview.qt-project.org/

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] HEADS-UP: Q_UNLIKELY

[Mutz, Marc via Development]

Hi,

Over the years, compilers (at least GCC) have started to interpret 
Q_UNLIKELY not only as a way to encode information for the branch 
predictor, but more and more to move code marked as such into a 
completely different (.cold) ELF section, which is where the exception 
tables and stack unwinding code also goes. This means two things:


1. Such code is placed far away from the non-unlikely code, which means 
that the normal flow of execution can be more compact, which results in 
an increased effective I-cache size (and, presumably, faster execution).


This we all expect from Q_UNLIKELY and Q_LIKELY.

2. As a separate ELF section, barring relocations etc that might prevent 
this, these .cold sections will stay parked on disk and loaded into 
memory only on demand, which means that executing unlikely code may make 
the program actually very slow (like exceptions, which on modern ABIs 
have zero runtime overhead when not thrown but may load debug symbols to 
unwind the stack when thrown).


This is not something we can control (that I know of, other than telling 
Ville to change it), so we don't need to discuss whether that's good or 
bad. It simply _is_.


In turn, this means that we should no longer use Q_UNLIKELY (I don't 
know about Q_LIKELY, but am willing to be enlightened) to mark code that 
gets executed 0.01% of the time, but with very high chance _is_ executed 
in normal program flow once, because that causes all the error handling 
code to be paged in. We should use it only (but then we should strive to 
actually do so) for actual error code. A good indicator is if a 
qWarning/qFatal/qCritical is executed: that's error code.


Example: https://codereview.qt-project.org/c/qt/qtbase/+/141519

Q_UNLIKELY however, doesn't work on the following code pattern:

case X: qWarning(...)



if (foo) {

} else {
   qWarning(...);
}



if (foo) {

return;
}

qWarning(...);

because it requires an expression that then is assumed to unlikely be 
true.


Before C++20, we could reformat the code to invert 'foo' and mark is 
Q_UNLIKELY, and the 141519 change did that in some places. C++20 adds 
[[unlikely]], which doesn't take a condition, so it can be used in the 
above situations. I've proposed it here: 
https://codereview.qt-project.org/c/qt/qtbase/+/272244 This also shows 
some patterns that at least work with GCC. We also know that


if (foo) [[unlikely]] {}

doesn't work with older GCCs which claim [[unlikely]] support, so we 
will need to either add compiler version checks, or yet another macro, 
or restrict the patterns to the known-good ones:


   Q_UNLIKELY_CASE case-label:

or simply in the flow of execution:

   if (foo) {

   } else {
   Q_UNLIKELY_CASE
   qWarning(...);
   }

   if (foo) {
   return;
   }

   Q_UNLIKELY_CASE
   qWarning(...);

The references patch opts for the latter.

Flame away :)

Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Kirill Burtsev as Approver

[Jüri Valdmann]

+1

From: Development  on behalf of Alexandru 
Croitor 
Sent: Thursday, August 29, 2019 4:08 PM
To: Allan Sandfeld Jensen 
Cc: Qt development mailing list 
Subject: Re: [Development] Nominating Kirill Burtsev as Approver

+1

> On 29. Aug 2019, at 15:29, Allan Sandfeld Jensen  wrote:
>
> On Thursday, 29 August 2019 14:54:45 CEST Michael Bruning wrote:
>> Hi all,
>>
>> I would like to nominate Kirill Burtsev as approver for the Qt Project.
>> Kirill joined the Qt WebEngine team about a year ago and has been mainly
>> contributing to the web engine module, but also to qtbase and
>> qtdeclarative. I trust that he will follow Qt guidelines and will use the
>> approver rights responsibly.
>>
>> Here is his list of changes:
>> https://codereview.qt-project.org/q/owner:kirill.burtsev%2540qt.io> odereview.qt-project.org/q/owner:kirill.burtsev%40qt.io>
>>
>> and reviews:
>> https://codereview.qt-project.org/q/reviewer:kirill.burtsev%2540qt.io> //codereview.qt-project.org/q/reviewer:kirill.burtsev%40qt.io>
>>
>> Disclaimer: we are working in the same company and the same team.
>>
>
> +1 :)
>
> 'Allan
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development