Newsgroups: php.internals,php.internals.win
Path: news.php.net
Xref: news.php.net php.internals:89435 php.internals.win:1133
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Matt Wilmas'" <php_lists@realplain.com>,
	<internals@lists.php.net>,
	<internals-win@lists.php.net>
Cc: "'Dmitry Stogov'" <dmitry@zend.com>,
	"'Pierre Joye'" <pierre.php@gmail.com>,
	"'Matt Tait'" <matt.tait@gmail.com>,
	"'Nikita Popov'" <nikita.ppv@gmail.com>
References: <9B23C6783EE5480CB15EAC35B9E420EA@pc1> <B72474C8C84444A8A23C9201510F37C6@pc1>
In-Reply-To: <B72474C8C84444A8A23C9201510F37C6@pc1>
Date: Thu, 26 Nov 2015 00:26:08 +0100
Message-ID: <065401d127d8$acdbf310$0693d930$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQEiQ3+JiWbokf3YDWf6nHVaJvz+MAGxpWjYn/2TbfA=
Content-Language: en-us
Subject: RE: [PHP-DEV] Windows (Visual Studio) compiler stuff
From: anatol.php@belski.net ("Anatol Belski")

Hi Matt,

I wonder really how much research you do :)

> -----Original Message-----
> From: Matt Wilmas [mailto:php_lists@realplain.com]
> Sent: Monday, November 23, 2015 2:28 AM
> To: internals@lists.php.net; internals-win@lists.php.net
> Cc: Dmitry Stogov <dmitry@zend.com>; Anatol Belski
<anatol.php@belski.net>;
> Pierre Joye <pierre.php@gmail.com>; Matt Tait <matt.tait@gmail.com>;
Nikita
> Popov <nikita.ppv@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