Hi Anatol, Dmitry, all,
Will reply about the original subject issues soon, but this is about new
stuff I noticed the other day... Adding Matt Tait and Nikita because of PR
#1418 and comments.
Anyway, the new Control Flow Guard (/guard:cf) is causing a big slowdown on
bench.php. :-( 14% on a Yorkfield (Q9400) and 19% on a Sandy Bridge
(Celeron G530). Ouch. Did anyone else check the performance impact? Is
this acceptable? On any other platform...?
I'll definitely remove that from my builds (Elephpant Sanctuary, coming
soon) since it's useless on all but the latest Windows versions anyway.
But if that "feature" must remain enabled otherwise, I think we can
eliminate most of the performance hit. As Nikita wondered about, I first
wanted to look at the indirect calls to the opcode handlers. I tried
separating out zend_execute.c in the Makefile and added /guard:cf- Bingo!
That restored about 98% of the speed on bench.php. It reduced
the --disable-all NTS DLL by 13.5 KB (of the 67 KB added by full CFG).
Or could maybe change back to the old SWITCH executor? I didn't try that.
It seems like it would be a good "rule" to not use any MS stuff that isn't
done on other compilers/platforms. :-)
/GS [1] is another that is/was starting to get annoying (function
prolog/epilog); luckily I was able to suppress it in most cases with changes
I'm making. It's enabled by default, of course, although I see it's
commented out in a line (old?) of confutils.js. /GS- ;-) I really hope
there aren't places where we are not doing range checks, etc. ourselves
(that the compiler can't see). So, either /GS is a waste, or it's only a
matter of time with other compilers?!
[1]
http://stackoverflow.com/questions/6607410/understanding-buffer-security-check-gs-compiler-option-in-msvc
- Matt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
