Discontinuation of V8 support for Intel chips without SSE2/CMOV

[Yang Guo]

To reduce code complexity of the IA32 port of V8, we decided to drop support for Intel chips with no SSE2/CMOV support. This does not affect the X64 port, as it always includes SSE2/CMOV. This starts with the 3.26 release. Upcoming changes to the code base will reflect this change by removing non-SSE2/CMOV specific code from the V8 code base.

Yang

[Yang Guo]

I made a mistake. What I meant to say is that we are going to drop support starting with the 3.27 release.

Yang

[Ben Noordhuis]

You mean I won't be able to run V8 on my P3 anymore? Outrageous! I
want my money back!

Jokes aside, a while ago I did some non-scientific benchmarks on cmov
vs. cmp + a conditional jump (trying to speed up polymorphic functions
in OCaml) and cmov was always slower on an i7. Maybe it performs
better on older CPUs, I didn't test that.

I'm not 100% sure why that is but Linus Torvalds puts forth some
hypotheses here[1] that sound plausible: the branch predictor
speculates that the branch last taken will be taken again. Most
branches are not perfectly equally distributed so branch prediction is
a win on average. Whereas cmov always has a data dependency and
therefore isn't amenable to that kind of speculative execution.

[1] http://yarchive.net/comp/linux/cmov.html

[Louis Santillan]

Intel [1] and DM&P [2] are still producing non-SSE (let alone SSE2) x86-32 chips.  You may wish to reconsider.

[1] http://linuxgizmos.com/intel-launches-arduino-compatible-galileo-board/

[2] http://linuxgizmos.com/arduino-compatible-boardset-runs-linux-on-x86/​

[Sven Panne]

On Fri, May 9, 2014 at 2:50 PM, Ben Noordhuis <in...@bnoordhuis.nl> wrote:

[...] Jokes aside, a while ago I did some non-scientific benchmarks on cmov

vs. cmp + a conditional jump (trying to speed up polymorphic functions
in OCaml) and cmov was always slower on an i7.  Maybe it performs
better on older CPUs, I didn't test that.

I'm not sure that CMOV is really a win, either. Perhaps we should try to kick out CMOV completely and have a look at the performance numbers. Unless there is a clear win on some platform we care about, I strongly propose to kick CMOV out completely, it would nicely simplify things further.

 

I'm not 100% sure why that is but Linus Torvalds puts forth some
hypotheses here[1] that sound plausible: the branch predictor
speculates that the branch last taken will be taken again.  Most
branches are not perfectly equally distributed so branch prediction is
a win on average.  Whereas cmov always has a data dependency and
therefore isn't amenable to that kind of speculative execution.

[1] http://yarchive.net/comp/linux/cmov.html

I know that article, but it's 7 years old and from the weird performance characteristics of modern processors I've seen so far I am highly reluctant to predict anything (although I have a gut feeling that CMOV is a bad idea nowadays). :-) Separate instructions on the assembler level get merged into single microcode operations and vice versa, OOO execution, register renaming, pipelines, varying number of shifting units, branch prediction, ... make things basically unpredictable if you just look at the machine code. So let's measure...

[Sven Panne]

We are aware that there is some non-SSE HW out in the wild, but we think that this is sufficiently esoteric to make our lives as V8 developers much easier by kicking out the support. If one cares strongly enough about such HW, there is always the option to fork M36 and create a separate platform port for non-SSE2. This would make it possible to track upstream changes to the rest, but one should not underestimate the amount of work involved to keep such a port alive (I would guess almost 1 person working full-time on it).

[Yang Guo]

The change has landed in r21223 and r21279.

On Friday, May 9, 2014 10:19:26 AM UTC+2, Yang Guo wrote: