Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71133
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.212.177 cause and error)
MIME-Version: 1.0
In-Reply-To: <52D5CCAD.9040508@gmail.com>
References: <CA+9eiLtmUgWSZhoHgXy+UfiakGHG5RuJwP6o4txVsU76fRsDpQ@mail.gmail.com>
	<CAMUwpuSzUvsQjyRUzjd2CcEuoPfpF_iZ2dOjHOr2cScc93Httw@mail.gmail.com>
	<CA+9eiLsCpv2Lq1Kp7UqVKC=yB96NS_3r9u7QhiQ=XZSgT6UP7Q@mail.gmail.com>
	<CAMUwpuQthRJ5-NsFKShUJn9Sydd=MkXKS4k3YhYw++y=TjpVVA@mail.gmail.com>
	<52D5CCAD.9040508@gmail.com>
Date: Wed, 15 Jan 2014 11:06:48 +0400
Message-ID: <CA+9eiLtc7hsy--+jCh24HmXsYCiHieawLDK94-h=cwx_fyu4Aw@mail.gmail.com>
To: Terry Ellison <ellison.terry@gmail.com>
Cc: Julien Pauli <jpauli@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043bdfa2d6456404effcf3f6
Subject: Re: [PHP-DEV] New Memory Manager
From: dmitry@zend.com (Dmitry Stogov)

--f46d043bdfa2d6456404effcf3f6
Content-Type: text/plain; charset=UTF-8

Hi Terry,

May be I misunderstood you.

Macros must be inlined at compile-time anyway.
Inlining of "slow-paths" of zval_copy_ctor/zval_dtor would cause "code
explosion" and increase cache misses.
However on Linux it must possible to put "hot" functions in one code
section and reduce cache misses.

Anyway, it's unrelated to Memory Manager.

Thanks. Dmitry.



On Wed, Jan 15, 2014 at 3:47 AM, Terry Ellison <ellison.terry@gmail.com>wrote:

>  On 14/01/14 18:21, Julien Pauli wrote:
>
> On Tue, Jan 14, 2014 at 5:45 PM, Dmitry Stogov <dmitry@zend.com> <dmitry@zend.com> wrote:
>
>  Of course I tried to plug jemalloc and tcmalloc but they make slowdown
> instead of speedup, mainly because zend_alloc was especially designed for
> PHP and also because they suffer from multi-threading support overhead. On
> the other hand profiling PHP with oprofile I saw a lot of cache misses in
> zend_alloc.c, especially because of linked list handling. So I tried to
> combine the best from all approaches and then spend a couple of week tuning
> it.
>
> Thanks. Dmitry.
>
>
>  Yes, I was reading the great job you've done so far !
> Looking forward in testing this myself and why not fix bugs or give
> some more ideas :-)
>
> Anyway, the different pool sizes is nice.
> We already got an idea like this in ZendMM with the "small free block"
> VS "free block" linked lists, but the implementation you've done so
> far is pretty nice evolution.
>
> I think we can improve stuff by studying more accurate caches for
> frequently used C-objects such as zvals or zend_object's structures.
>
>  One of the most common macro uses for both emalloc and efree primitives
> is in the CTOR and DTOR of zval structures.  This is HOT code, yet the code
> involved is split across three main modules totalling less that 10K lines.
> As a comparison zend_vm_execute.h is over 40K lines to allow the CC
> optimizer to optimize across the entire source code.
>
> Wouldn't it make a lot more sense to combine zend_variables.c, zend_hash.c
> and zend_alloc.c into a single module (do it by #include directive as
> zend_execute.c incorporates zend_vm_execute.h) so that the CC optimizer can
> properly optimitise these CTORs and DTORs?  The DTOR for a ZVAL which
> itself a simple ZVAL hierarchy such as a an array should be executed as a
> dense code sequence that can comfortably run out of the L1Instr cache, with
> minimal cache misses and BLT failure stalls.
>
> Regards Terry
>

--f46d043bdfa2d6456404effcf3f6--