Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90906
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.111 as permitted sender)
Message-ID: <BLU436-SMTP15467270C5E2F74D4B8C414E2C70@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
In-Reply-To: <56A5D921.7090800@zend.com>
Date: Mon, 25 Jan 2016 09:36:32 +0100
CC: Nikita Popov <nikita.ppv@gmail.com>,
 PHP internals list <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <BY2PR0201MB1784BD53764ED5DDD21D1DABBFC40@BY2PR0201MB1784.namprd02.prod.outlook.com> <BLU437-SMTP55816625D6C646B5E6803CE2C40@phx.gbl> <56A5D921.7090800@zend.com>
To: Dmitry Stogov <dmitry@zend.com>
Subject: Re: [PHP-DEV] Re: Reusing main VM stack for generators
From: bobwei9@hotmail.com (Bob Weinand)

> Am 25.01.2016 um 09:13 schrieb Dmitry Stogov <dmitry@zend.com>:
>> We basically need a way to properly first fetch the args (beware: =
func_arg fetches...) before instantiating the call frame, an issue which =
for example could be solved if we applied my vm_stack_restructuring =
patch (because it only installs call frames after all args were =
fetched).
>=20
> I thought about that approach, but the amount of changes doesn't worth =
the result. Doing this only for generators doesn't make a lot of sense.

After all, we still have that 2% performance improvement. And the main =
VM stack reusage for Generators.

And I believe the proposed layout is also much more close to the C =
calling convention and thus more compatible if we ever go the route down =
to compiling to assembly.
Ultimately it gives us more flexibility as we also could put point the =
return temporary/cv of some opcodes to the right place, ready to call.
We aren't that far yet with the Optimizer, but I think I see it coming, =
where we'll benefit more from fixed places. It might be just a few moves =
less, but function arg passing is very common in PHP, so the benefit =
will be more significant the more optimizations we apply.

Remember that small thing removing ZEND_SEND_VAL_SPEC_TMP_TMP_HANDLERs =
where unnecessary? When we'll be able to know which variables may hold =
references or which not, we'll suddenly be able to directly write to the =
function parameter slot in much more cases.

I still stand by the point that doing it now (which small, but =
non-negligible improvement), will bring us a bigger improvement later. =
Many small improvements built around this patch will give us a big one =
in the end.

Thanks,
Bob=