Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Marc Mutz]

On Wednesday 20 January 2016 08:19:04 Thiago Macieira wrote:
> On Wednesday 20 January 2016 08:12:58 André Somers wrote:
> > Where is this qAsConst coming from? When was it introduced? Where is it
> > documented?
> 
> Commit 264c72837d6ff717a248dd180c2dfb45391c6aab, in dev. No api docs.

It was intended as private API for use within Qt. If the sentiment is that it 
should be public, I'll add proper docs.

If the sentiment is also that we should start to discourage the use of 
Q_FOREACH, then I'll add a \note to its docs pointing at qAsConst + range-for.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Smith Martin]

Here is a JIRA task for it:
https://bugreports.qt.io/browse/QTBUG-50548


From: Development <development-boun...@qt-project.org> on behalf of Marc Mutz 
<marc.m...@kdab.com>
Sent: Wednesday, January 20, 2016 11:58 AM
To: development@qt-project.org
Subject: Re: [Development] QStringLiteral vs QLatin1String ,    foreach vs for 
range

On Wednesday 20 January 2016 08:19:04 Thiago Macieira wrote:
> On Wednesday 20 January 2016 08:12:58 André Somers wrote:
> > Where is this qAsConst coming from? When was it introduced? Where is it
> > documented?
>
> Commit 264c72837d6ff717a248dd180c2dfb45391c6aab, in dev. No api docs.

It was intended as private API for use within Qt. If the sentiment is that it
should be public, I'll add proper docs.

If the sentiment is also that we should start to discourage the use of
Q_FOREACH, then I'll add a \note to its docs pointing at qAsConst + range-for.

Thanks,
Marc

--
Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Knoll Lars]

On 20/01/16 11:58, "Development on behalf of Marc Mutz" 
 wrote:

>On Wednesday 20 January 2016 08:19:04 Thiago Macieira wrote:
>> On Wednesday 20 January 2016 08:12:58 André Somers wrote:
>> > Where is this qAsConst coming from? When was it introduced? Where is it
>> > documented?
>> 
>> Commit 264c72837d6ff717a248dd180c2dfb45391c6aab, in dev. No api docs.
>
>It was intended as private API for use within Qt. If the sentiment is that it 
>should be public, I'll add proper docs.
>
>If the sentiment is also that we should start to discourage the use of 
>Q_FOREACH, then I'll add a \note to its docs pointing at qAsConst + range-for.

+1 to both. Let's encourage people to use range-for and qAsConst instead of 
foreach.

Cheers,
Lars

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

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Gunnar Roth]

Thank you Thiago.

 


Actually I meant ucomparing a QString with a QStringLiteral when i said " both
strings being uft16 seems to be faster ".

So what i learned now on an x85 with avx support is should be no performance problem.

But what about a wec2013 with arm, as qt does not support neon for wec2013.

Qt does not even support sse2 for wec because configureap.cpp does always reset sse2 to no, even if i pass it to configure.

Same as the openssl problem, which was solved in dev branch. https://codereview.qt-project.org/#/c/122437/

 

Regards

Gunnar Roth


Gesendet: Montag, 18. Januar 2016 um 00:28 Uhr
Von: "Thiago Macieira" <thiago.macie...@intel.com>
An: development@qt-project.org
Betreff: Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

On Sunday 17 January 2016 22:22:39 Gunnar Roth wrote:
> why is QLatin1String more efficient than QLiteralString in this case? both
> strings being uft16 seems to be faster for, you could use size_t chunks
> for comparison for example.

Your premise is wrong. The QLatin1String is not stored as UTF-16. It's stored
as Latin1.

If you're asking about runtime performance, it's because we have algorithms to
perform the operation without converting in the common case scenario.

Take the equality operator and QString::compare: sure it's more efficient to do
binary compares of two QChars, especially if you can unroll the loop and do
SIMD (like we do, see [1]). But if your initial data is Latin1, you'd need to
incur a performance penalty to allocate memory and then convert from Latin1 to
UTF-16 before doing the comparison. So QString has a UTF-16-to-Latin1
comparison, which is quite efficient (and also SIMD-enabled, see [2]).

Maybe in some cases the UTF16-to-Latin1 operation is slower than pure UTF-16,
but is almost always faster than the combined malloc+convert+operate+free. In
this particular case, the ucstrncmp for uchar is either as fast as the QChar
one, or in the case of AVX2, possibly even faster in longer strings (less
memory being read).

[1]
https://code.woboq.org/qt5/qtbase/src/corelib/tools/qstring.cpp.html#_ZL9ucstrncmpPK5QCharS1_i
[2]
https://code.woboq.org/qt5/qtbase/src/corelib/tools/qstring.cpp.html#_ZL9ucstrncmpPK5QCharPKhi
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

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


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

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[André Somers]

Op 20/01/2016 om 06:47 schreef Thiago Macieira:

On Wednesday 20 January 2016 05:20:36 Kevin Kofler wrote:

Thiago Macieira wrote:

foreach copies; ranged for doesn't.

… unless you try to use it on a non-const Qt container with usage count >1,
then it will even deep-copy (detach) it! (I know you know this, but you
should warn people about it.) So you need to be very careful about what you
pass to ranged for.

Indeed.

But his is the argument that convinced me: with foreach and Qt containers, you
usually get the runtime performance you want, but it costs in dead code since
the deep-copy code will be present (at least until we can get rid of the
unsharable flag). With ranged for plus qAsConst, there's no copy code
generated.

So instead of:

foreach (auto x, container)

You'll write:

for (auto x : qAsConst(container))

or if you know it's already const, you can skip the qAsConst part.

This is no more and no less readable, but is more explicit about what it does.
Where is this qAsConst coming from? When was it introduced? Where is it 
documented?


I can't find it in my Qt documentation.

André

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

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Kevin Kofler]

Thiago Macieira wrote:
> foreach copies; ranged for doesn't.

… unless you try to use it on a non-const Qt container with usage count >1, 
then it will even deep-copy (detach) it! (I know you know this, but you 
should warn people about it.) So you need to be very careful about what you 
pass to ranged for.

Kevin Kofler

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

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Thiago Macieira]

On Wednesday 20 January 2016 08:12:58 André Somers wrote:
> Where is this qAsConst coming from? When was it introduced? Where is it 
> documented?

Commit 264c72837d6ff717a248dd180c2dfb45391c6aab, in dev. No api docs.

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

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

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Knoll Lars]

On 20/01/16 08:12, "Development on behalf of André Somers" 
 wrote:



>
>
>Op 20/01/2016 om 06:47 schreef Thiago Macieira:
>> On Wednesday 20 January 2016 05:20:36 Kevin Kofler wrote:
>>> Thiago Macieira wrote:
 foreach copies; ranged for doesn't.
>>> … unless you try to use it on a non-const Qt container with usage count >1,
>>> then it will even deep-copy (detach) it! (I know you know this, but you
>>> should warn people about it.) So you need to be very careful about what you
>>> pass to ranged for.
>> Indeed.
>>
>> But his is the argument that convinced me: with foreach and Qt containers, 
>> you
>> usually get the runtime performance you want, but it costs in dead code since
>> the deep-copy code will be present (at least until we can get rid of the
>> unsharable flag). With ranged for plus qAsConst, there's no copy code
>> generated.
>>
>> So instead of:
>>
>>  foreach (auto x, container)
>>
>> You'll write:
>>
>>  for (auto x : qAsConst(container))
>>
>> or if you know it's already const, you can skip the qAsConst part.
>>
>> This is no more and no less readable, but is more explicit about what it 
>> does.
>Where is this qAsConst coming from? When was it introduced? Where is it 
>documented?
>
>I can't find it in my Qt documentation.

It just got added some weeks ago, after we realised that range-for would lead 
to our containers detaching. So it'll be in 5.7.

In general, I'm very much in favour of getting rid of foreach in favour of 
range-for.

Cheers,
Lars

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

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Thiago Macieira]

On Wednesday 20 January 2016 05:20:36 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > foreach copies; ranged for doesn't.
> 
> … unless you try to use it on a non-const Qt container with usage count >1,
> then it will even deep-copy (detach) it! (I know you know this, but you
> should warn people about it.) So you need to be very careful about what you
> pass to ranged for.

Indeed.

But his is the argument that convinced me: with foreach and Qt containers, you 
usually get the runtime performance you want, but it costs in dead code since 
the deep-copy code will be present (at least until we can get rid of the 
unsharable flag). With ranged for plus qAsConst, there's no copy code 
generated.

So instead of:

foreach (auto x, container)

You'll write:

for (auto x : qAsConst(container))

or if you know it's already const, you can skip the qAsConst part.

This is no more and no less readable, but is more explicit about what it does.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[André Somers]

Op 20/01/2016 om 08:18 schreef Knoll Lars:

Where is this qAsConst coming from? When was it introduced? Where is it
documented?

I can't find it in my Qt documentation.

It just got added some weeks ago, after we realised that range-for would lead 
to our containers detaching. So it'll be in 5.7.

In general, I'm very much in favour of getting rid of foreach in favour of 
range-for.
Perhaps in the meantime the foreach macro could just be changed to 
actually expand to a range-for?


André

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

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Thiago Macieira]

On Wednesday 20 January 2016 08:37:45 André Somers wrote:
> Op 20/01/2016 om 08:18 schreef Knoll Lars:
> >> Where is this qAsConst coming from? When was it introduced? Where is it
> >> documented?
> >> 
> >> I can't find it in my Qt documentation.
> > 
> > It just got added some weeks ago, after we realised that range-for would
> > lead to our containers detaching. So it'll be in 5.7.
> > 
> > In general, I'm very much in favour of getting rid of foreach in favour of
> > range-for.
> Perhaps in the meantime the foreach macro could just be changed to
> actually expand to a range-for?

It can't. I tried a few years ago and it's not compatible.

Ranged for requires that the first part (before the colon) be a declaration. 
Foreach allows an existing variable.

Foreach also requires creating a copy and that causes the dangling reference 
issue we discussed before.

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

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

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Thiago Macieira]

On Tuesday 19 January 2016 09:50:37 Gunnar Roth wrote:
> Thank you Thiago.
>  
> Actually I meant ucomparing a QString with a QStringLiteral when i said
> " both strings being uft16 seems to be faster ".
> So what i learned now on an x85 with avx support is should be no performance
> problem. 

We also have SSE2 code which should provide similar performance, but not 
better since the unpacking code is more expensive than the one AVX2 
instruction that loads and zero-extends.

> But what about a wec2013 with arm, as qt does not support neon for
> wec2013.

I don't do benchmarks for ARM. That said, Erik and Allan have been re-writing 
some of my vector code from SSE2 to Neon and are contributing the code to the 
dev branch. Some of the functionality is possible only in AArch64 due to the 
lack of one single instruction corresponding to SSE2's PMOVMSKB in 32-bit 
mode. That includes the string-compare code.

> Qt does not even support sse2 for wec because configureap.cpp does
> always reset sse2 to no, even if i pass it to configure. 

Probably because whoever wrote that part of configureapp.cpp assumed that it 
would always be ARM.

> Same as the
> openssl problem, which was solved in dev
> branch. https://codereview.qt-project.org/#/c/122437/ 

Right.

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

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

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Gunnar Roth]

Hi, thanks for answering, but

> Am 17.01.2016 um 20:36 schrieb Thiago Macieira :
> 
> On Sunday 17 January 2016 19:13:44 Gunnar Roth wrote:
>> Hi,
>> I saw quite some changes like https://codereview.qt-project.org/#/c/145961/
>>   Replace QStringLiteral
>> with QLatin1String in QFileSelector. I also read about the problem of
>> QStringLiteral concerning plugins, but what is the idea behind these
>> changes ?
> 
> QLatin1String is more efficient if you're calling a method that has a 
> QLatin1String overload, like most methods in QString itself.
> 
why is QLatin1String more efficient than QLiteralString in this case? both 
strings  being uft16 seems to be faster for, you could use size_t chunks for 
comparison for example.

Regards,
Gunnar


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

[Development] QStringLiteral vs QLatin1String , foreach vs for range

[Gunnar Roth]

Hi,
I saw quite some changes like https://codereview.qt-project.org/#/c/145961/ 
  Replace QStringLiteral with 
QLatin1String in QFileSelector.
I also read about the problem of QStringLiteral concerning plugins, but what is 
the idea behind these changes ? 

There is also a lot of replacing foreach with range for loops? What is the idea 
behind this? Any links to read?


Regards,
Gunnar Roth

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

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Thiago Macieira]

On Sunday 17 January 2016 19:13:44 Gunnar Roth wrote:
> Hi,
> I saw quite some changes like https://codereview.qt-project.org/#/c/145961/
>   Replace QStringLiteral
> with QLatin1String in QFileSelector. I also read about the problem of
> QStringLiteral concerning plugins, but what is the idea behind these
> changes ?

QLatin1String is more efficient if you're calling a method that has a 
QLatin1String overload, like most methods in QString itself.

As for the plugin problem, it's what happens when you refer to global 
variables in plugins that get unloded.

> There is also a lot of replacing foreach with range for loops? What is the
> idea behind this? Any links to read?

foreach copies; ranged for doesn't.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Thiago Macieira]

On Sunday 17 January 2016 19:31:54 Olivier Goffart wrote:
> As explained here: https://woboq.com/blog/qstringliteral.html
> QStringLiteral can avoid malloc and conversion to QString. But there is an 
> operator==(const QString&,QLatin1String) which also don't do allocations or 
> conversion.  In that case QLatin1String is slightly better because it takes
> twice as less space in the binary (UTF-16 vs. ASCII)

Technically, it's "less than half the space".

For any string of N Latin-1 characters, QLatin1String occupies N+1 bytes and 
QStringLiteral occupies 2*(N+1)+24. 

And this is assuming the compiler didn't do common tail merging of strings 
(most don't). If that happens, then the size of two QLatin1Strings of M and N 
characters could be less than M+N+2.

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

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

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Olivier Goffart]

On Sonntag, 17. Januar 2016 19:13:44 CET Gunnar Roth wrote:
> Hi,
> I saw quite some changes like https://codereview.qt-project.org/#/c/145961/
> Replace QStringLiteral with QLatin1String in QFileSelector. I also read
> about the problem of QStringLiteral concerning plugins, but what is the idea
> behind these changes ?
> 
> There is also a lot of replacing foreach with range for loops? What is the
> idea behind this? Any links to read?

About QStringLiteral: 
As explained here: https://woboq.com/blog/qstringliteral.html
QStringLiteral can avoid malloc and conversion to QString. But there is an 
operator==(const QString&,QLatin1String) which also don't do allocations or 
conversion.  In that case QLatin1String is slightly better because it takes 
twice as less space in the binary (UTF-16 vs. ASCII)


As for foreach and range for loops: the foreach macro does a bit more by doing 
a copy of the container and call the non const begin and end functions. That's 
a very small costs for qt containers (a few atomic operations) but it saves 
code space.

All of this is probably negligible, but it helps reducing the size of the 
library.

-- 
Olivier 

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Thiago Macieira]

On Sunday 17 January 2016 22:22:39 Gunnar Roth wrote:
> why is QLatin1String more efficient than QLiteralString in this case? both
> strings  being uft16 seems to be faster for, you could use size_t chunks
> for comparison for example.

Your premise is wrong. The QLatin1String is not stored as UTF-16. It's stored 
as Latin1.

If you're asking about runtime performance, it's because we have algorithms to 
perform the operation without converting in the common case scenario.

Take the equality operator and QString::compare: sure it's more efficient to do 
binary compares of two QChars, especially if you can unroll the loop and do 
SIMD (like we do, see [1]). But if your initial data is Latin1, you'd need to 
incur a performance penalty to allocate memory and then convert from Latin1 to 
UTF-16 before doing the comparison. So QString has a UTF-16-to-Latin1 
comparison, which is quite efficient (and also SIMD-enabled, see [2]).

Maybe in some cases the UTF16-to-Latin1 operation is slower than pure UTF-16, 
but is almost always faster than the combined malloc+convert+operate+free. In 
this particular case, the ucstrncmp for uchar is either as fast as the QChar 
one, or in the case of AVX2, possibly even faster in longer strings (less 
memory being read).

[1] 
https://code.woboq.org/qt5/qtbase/src/corelib/tools/qstring.cpp.html#_ZL9ucstrncmpPK5QCharS1_i
[2] 
https://code.woboq.org/qt5/qtbase/src/corelib/tools/qstring.cpp.html#_ZL9ucstrncmpPK5QCharPKhi
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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