The problem is that often the compiler can't automatically vectorize because some preconditions are not met. The knowledge about those preconditions is mostly limited to compiler people and so far, by what I know, there's no static analysis tool that tells you why the compiler couldn't vectorize a loop.

Clang can tell you why a loop wasn't vectorized with a couple of compiler flags:

-Rpass-analysis=loop-vectorize -Rpass-missed=loop-vectorized

http://llvm.org/docs/Vectorizers.html#diagnostics

The Intel compiler has various options to report autovectorisation success. You still have to go through them and follow the advice, of course, but by and large they are not entirely useless.

MSVC also will report whether vectorization succeeded, and why it didn't if it failed.

do a profile run and I'll bet you it will insert as many runtime checks necessary to get around those precondition checks.

Do you want to help out with LuaJIT? We are looking for people...

Do you mean that you want to hire people as LuaJIT maintainers? That would be exciting news. If you have any details to share I would be happy to start pointing good people in your direction.

Yes. If someone is qualified and wants to do that we would be interested in hiring them in London or San Francisco.

I would love to, but I'm probably severely under-qualified (apart from having used LuaJIT extensively). I'd probably get lost pretty fast while delving further into the inner workings of the compiler, a domain in which I only have superficial knowledge. I can learn, of course, but it looks pretty steep. (And no, I do not have a CS degree, which seems like one of those useful things to have when working on a compiler.)

You should apply anyways. There's really only two possible outcomes:

* They say "no": you go on with your life, no biggie.

* They say "yes": you move to SF/London and start learning :)

Those two possibilities vary hugely in their time consideration! 1 considers the far future outcome ("you go on with your life") but 2 only considers the next few months. 2a you find out you can do it and enjoy it, great career path for the next n years, 2b you find out you can't hack it and either quit or get fired, 2bi you then do what you would have done in 1, not a huge opportunity cost, 2bii your ego suffers a huge blow and you fall into a pit of depression and drunkenness and self-doubt about ever learning anything again and you: 2biiα eventually get out and do 1 (larger opportunity cost and potential permanent damage), or: 2biiβ die soon after...

A lot of people really want to avoid the 2bii tree and will shrink away from any action that seems to have a chance of leading from the bearable status quo to there.

>I sort of expect a top-notch compiler to perform this automatically

Based on the N-Body portion of the Bench Mark game it only seems like the ICC does this.

U can also use something like openMP (Newer versions has pragma's for SIMDs) to help the compiler expose parallelism in your code. (Hard fore a compiler to figure out the intent of the programmers. So be nice and give the the poor compiler some hints ;) ). Also many consumer grade chips have GPUs integrated, this can also be used for speeding things up.

I'd hope that at least the branches would be turned into cmovs.

Depends on how predictable the branches are. LLVM used to use CMOVs whenever possible but I believe this was changed a few years back to generally improve performance.

See a related bug in GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56309

"conditional moves instead of compare and branch result in almost 2x slower code"

Yeah, easy to predict branches are really cheap. Very non-deterministic, hard-to-predict ones on the other hand are still surprisingly expensive. In such a case, conditional moves might make sense, or sometimes you can also use the result of a comparison in arithmetic operations, something like:

  idx = 2*idx + (key > table[idx])

(to move a key down an implicitly-stored binary tree)

I remember Linus making much the same point: http://yarchive.net/comp/linux/cmov.html

It generally lines up with what I've observed. Surprisingly, I've found that even arithmetic comparisons like you mentioned ran a bit faster with branches instead of conditional moves. The one case where I have seen comparisons benefit is with SSE code where the comparison results go straight to a register instead of a flag.