Thank you Thiago.
Actually I meant ucomparing a QString with a QStringLiteral when i said " both
strings being uft16 seems to be faster ".
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
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
> 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
