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. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
