[Development] QtCS 2017 QtCore sessions

[Jean-Michaël Celerier]

> (4x difference measured).

wow, good to know.



-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Tue, Oct 10, 2017 at 3:33 PM, Thiago Macieira <thiago.macieira at intel.com>
wrote:

> On Tuesday, 10 October 2017 15:04:29 CEST Jean-Michaël Celerier wrote:
> > > ** Wrapping std::{unordered_}map may be acceptable
> >
> > Hmmm... from these benchmarks, QHash seems to regularly beat
> > std::unordered_map so is it really worth it ?
> > =>  https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html
>
> The motivation for change is not performance, but security. While we don't
> think Qt applications are particularly susceptive to HashDoS attacks, our
> approach here is "we can fix this, we may as well do it".
>
> The reason I'm benchmarking and suggesting SipHash-1-2 instead of the
> standard
> SipHash-2-4 is to avoid a big performance regression.
>
> > Besides, with the Qt implementation the performance is more-or-less
> > consistent across platforms ; if it were to use
> > std containers with moderately advanced algorithms, there could be much
> > more differences depending on the various implementations
> > (the worse offender being std::regex... these damn things just don't work
> > the same on any platform).
>
> We actually have VERY different performance numbers across platforms. QHash
> currently uses the CRC32 instructions on x86 and ARM, which means the
> peformance can change significantly (4x difference measured). The same
> applies
> to the fixed version: the AES instructions are 5x faster than SipHash.
>
> > More generally, since all these containers are header-only due to their
> > templated nature, wouldn't it be interesting and benefiting to the
> greater
> > C++ community to
> > spin them off in their own small header-only utility library ?
>
> That's one big concern for a Qt6 QHash that wraps std:unordered_map. We'll
> need to see what happens.
>
> > Having an explicit choice between COW and no-COW would be valuable in
> many
> > places where people don't want to bring large stuff like whole QtCore but
> > where a few headers are OK imho;
> > offering facades to std:: types with easy, readable Qt-like APIs would
> also
> > be quite nice (ideally with a set of standard-compliant typedefs, eg
> > qt::hash_map... one can dream :p).
>
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20171010/db35fa88/attachment.html>