Hi Matt, I wonder really how much research you do :)
> -----Original Message----- > From: Matt Wilmas [mailto:php_li...@realplain.com] > Sent: Monday, November 23, 2015 2:28 AM > To: internals@lists.php.net; internals-...@lists.php.net > Cc: Dmitry Stogov <dmi...@zend.com>; Anatol Belski <anatol....@belski.net>; > Pierre Joye <pierre....@gmail.com>; Matt Tait <matt.t...@gmail.com>; Nikita > Popov <nikita....@gmail.com> > Subject: Re: [PHP-DEV] Windows (Visual Studio) compiler stuff > > 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 > We're unlikely to remove the security options in favor of performance. But that's for one. /guard:cf is documented to have possible performance impact on systems that don't support it. However no such side effects was noticed even on win7. There was also no bug reports in this regard. We definitely can't test any possible HW, but it's more about OS, not HW. Is win7 your case? Then just upgrade :) With /GS is basically same. It's not supposed to fix the programmer mistakes, but to add protection against exploits. Stability and compatibility matters more than a performance trade off. Another thing is that just one synthetic test is unlikely to reveal the big picture. You should probably also test on some real apps, that will bring more realistic results. Thanks for your work. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
