ok, as expected, you say, on normal app; i read docs again, and the only parameter bound to this expectation seems to be
the ROB expansion to 192 entry, +15% above Sandy bridge.

supposing tests are correct there, we should admit the existance of something wrong in the uop cache, i.e in its design or
in programming it from those test software.

it should be 2 loads + 1 store and 5 instructions per cycle !
or the +2 ports come to be practically unused

de facto while using vectors and FMA (where there's practically no i-caches misses) all seems running fine, as announced by Intel.
Cheers,

I have asked in clax newsgroup and got this list:
http://users.atw.hu/instlatx64/GenuineIntel00306C3_Haswell_InstLatX64.txt

Seems that situation is same as for previous generations.

thanks for the info. I was previously doing a divide BEFORE clamping to [0.25,1]. I did see some decent improvement by dividing AFTER clamping to [0.25,1], as the divpd instruction is faster on powers of 2. This improvement is good enough that the rcps+newton solution is not better.