[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