[Interest] SIMD accelerated wrappers for relevant Qt container classes (QVector, ...) or QByteArray?
René J. V. Bertin
rjvbertin at gmail.com
Wed May 10 10:57:42 CEST 2017
Thiago Macieira wrote:
> No, but you convert to and from Latin1 with it, you search for characters in
> it, etc. That's optimised.
And that's already something :)
> True, but "simpler operations" also describes the extent of the operations
> available in QVector. Comparing ranges, clearing them, finding an element,
> etc. are all operations that the compiler can easily autovectorise for you.
I'd hope indeed that the underlying implementation is written in such a way that
the compiler doesn't find too many pretexts not to auto-vectorise it :)
I was thinking a bit beyond those simple operations available in QVector and the
like. QVector may not be the best example, but it does come to mind when you
think vector calculus and being able to write its common operations as vector
operations and not in loops (or calls to external library functions with cryptic
names hailing back only "real programmers" understand ;) )
> You ought to consider always compiling your code with -march=sandybridge (2011
> CPU) or -march=haswell (2013). You should do that for Qt too, as it enables
> most of the optimisations in QString I was talking about.
I do, at least on Mac I always configure everything with "-O3 -march=native" or
even "-Ofast -march=native" (there's apparently a difference for clang's auto-
vectorisation, beyond using "fast math").
For my Linux builds I usually don't use -march because I also deploy to an old
notebook where I think even -march=core2 is risky (-march=btver or amdfam10 do
work but I doubt they're of much interest).
It'd be nice if Qt could be built with support for runtime-selection of the most
efficient available implementation :)
R.
More information about the Interest
mailing list