Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87424
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <E5570C12CE404438838F1C1D3DB80653@pc1>
References: <0ABC26E371A76440A370CFC5EB1056CC2F6C9AE9@IRSMSX106.ger.corp.intel.com>
	<CA+9eiLtB2cpf2v=mX_jY+niCOst2hzW70zNf9z6omC02Es+s8w@mail.gmail.com>
	<E5570C12CE404438838F1C1D3DB80653@pc1>
Date: Fri, 31 Jul 2015 06:49:47 +0300
Message-ID: <CA+9eiLtmr1az16Ha3iPWnpez1paOS40KxshosBxxZkNg6xiO2Q@mail.gmail.com>
To: Matt Wilmas <php_lists@realplain.com>
Cc: Bogdan Andone <bogdan.andone@intel.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113fe51e0ff55e051c23b65a
Subject: Re: [PHP-DEV] Introduction and some opcache SSE related stuff
From: dmitry@zend.com (Dmitry Stogov)

--001a113fe51e0ff55e051c23b65a
Content-Type: text/plain; charset=UTF-8

On Jul 31, 2015 2:12 AM, "Matt Wilmas" <php_lists@realplain.com> wrote:
>
> Hi Dmitry, Bogdan,
>
>
> ----- Original Message -----
> From: "Dmitry Stogov"
> Sent: Thursday, July 30, 2015
>
>> Hi Bogdan,
>>
>> On Wed, Jul 29, 2015 at 5:22 PM, Andone, Bogdan <bogdan.andone@intel.com>
>> wrote:
>>
>>> Hi Guys,
>>>
>>> My name is Bogdan Andone and I work for Intel in the area of SW
>>> performance analysis and optimizations.
>>> We would like to actively contribute to Zend PHP project and to involve
>>> ourselves in finding new performance improvement opportunities based on
>>> available and/or new hardware features.
>>> I am still in the source code digesting phase but I had a look to the
>>> fast_memcpy() implementation in opcache extension which uses SSE
intrinsics:
>>>
>>> If I am not wrong fast_memcpy() function is not currently used, as I
>>> didn't find the "-msse4.2" gcc flag in the Makefile. I assume you
probably
>>> didn't see any performance benefit so you preserved generic memcpy()
usage.
>>>
>>
>> This is not SSE4.2 this is SSE2.
>> Any X86_64 target implements SSE2, so it's enabled by default on x86_64
>> systems (at least on Linux).
>> It also may be enabled on x86 targets adding "-msse2" option.
>
>
> Right, I was gonna say, I think that was a mistake, and all x86_64 should
be using it at least...
>
> Of course, using anything newer that needs special options is nearly
useless, since I guess the vast majority aren't building themselves, but
using lowest-common-denominator repos.  I had been wondering about speeding
up some other things, maybe taking advantage of SSE4.x (string stuff, I
don't know), but... like I said.  Runtime checks would be awesome, but
except for the recent GCC, the intrinsics aren't available unless the
corresponding SSE option is enabled (lame!).  So requires a separate
compilation unit. :-/
>
> Of course I guess if the intrinsic maps simply to the instruction, could
just do it with inline asm, if wanted to do runtime CPU checking.
>
>
>>> I would like to propose a slightly different implementation which uses
>>> _mm_store_si128() instead of _mm_stream_si128(). This ensures that
copied
>>> memory is preserved in data cache, which is not bad as the interpreter
will
>>> start to use this data without the need to go back one more time to
memory.
>>> _mm_stream_si128() in the current implementation is intended to be used
for
>>> stores where we want to avoid reading data into the cache and the cache
>>> pollution; in opcache scenario it seems that preserving the data in
cache
>>> has a positive impact.
>>>
>>
>> _mm_stream_si128() was used on purpose, to avoid CPU cache pollution,
>> because data copied from SHM to process memory is not necessary used
before
>> eviction.
>> By the way, I'm not completely sure. May be _mm_store_si128() can provide
>> better result.
>
>
> Interesting (that _stream was used on purpose). :-)
>
>
>>> Running php-cgi -T10000 on WordPress4.1/index.php I see ~1% performance
>>> increase for the new version of fast_memcpy() compared with the generic
>>> memcpy(). Same result using a full load test with http_load on a
Haswell EP
>>> 18 cores.
>>>
>>
>> 1% is really big improvement.
>> I'll able to check this only on next week (when back from vacation).
>
>
> Well, he talks like he was comparing to *generic* memcpy(), so...?  But
not sure how that would have been accomplished.
>
> BTW guys, I was wondering before why fast_memcpy() only in this opcache
area?  For the prefetch and/or cache pollution reasons?

Just because, in this place we may copy big blocks, and we also may align
them properly, to use compact and fast Inlined code.

>
> Because shouldn't the library functions in glibc, etc. already be using
versions optimized for the CPU at runtime?  So is generic memcpy() already
"fast?"  (Other than overhead for a function call.)

glibc already uses optimized memcpy(), but this is universal  function,
that has to check for different conditions, like allignment of source and
distination and length.

>
>
>>> Here is the proposed pull request:
>>> https://github.com/php/php-src/pull/1446
>>>
>>> Related to the SW prefetching instructions in fast_memcpy()... they are
>>> not really useful in this place. There benefit is almost negligible as
the
>>> address requested for prefetch will be needed at the next iteration (few
>>> cycles later), while the time needed to get data from RAM is >100 cycles
>>> usually.. Nevertheless... they don't heart and it seems they still have
a
>>> very small benefit so I preserved the original instruction and I added a
>>> new prefetch request for the destination pointer.
>>>
>>
>> I also didn't see significant difference from software prefetching.
>
>
> So how about prefetching "further"/more interations ahead...?

I tried, but didn't see difference as well.

Thanks. Dmitry.

>
>
>> Thanks. Dmitry.
>>
>>
>>>
>>> Hope it helps,
>>> Bogdan
>
>
> - Matt

--001a113fe51e0ff55e051c23b65a--