Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116082
MIME-Version: 1.0
References: <DM6PR07MB6618D41DE7680BE2BE8086DAF9DD9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <b51e40d2-0e31-4b28-ba7d-0237ed831bde@www.fastmail.com> <DM6PR07MB661871FD349540EB1CEECF35F9DE9@DM6PR07MB6618.namprd07.prod.outlook.com>
In-Reply-To: <DM6PR07MB661871FD349540EB1CEECF35F9DE9@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Sat, 18 Sep 2021 09:30:57 +0700
Message-ID: <CAEZPtU5Y5bPfSkb2Fa+XxFMSpH8YWSh_NdcuiQCoS=+mr4iO6g@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] RFC: Add `final class Vector` to PHP
From: pierre.php@gmail.com (Pierre Joye)

Good morning,

Not sure you care or read my reply but I had to jump in one more time here :)

On Sat, Sep 18, 2021 at 8:49 AM tyson andre <tysonandre775@hotmail.com> wrote:

> setSize is useful in allocating exactly the variable amount of memory needed while using less memory than a PHP array.
> `setSize($newSize, 0)` would be much more efficient and concise in initializing the value.
>
> - Or in quickly reducing the size of the array rather than repeatedly calling pop in a loop.

I would rather not reduce it at all, but use the vector_size and keep
it. User land set its max size but a realloc/free should not be
necessary and counter productive from a perf point of view. If one
uses it in a daemon, it can always be destroyed as needed.

> > To echo Pierre, a Vector needs to be of a single guaranteed type.
> > Yes, this gets us back to the generics conversation again, but I presume (perhaps naively?) there are ways to address this question without getting into full-blown generics.
>
> Yep, as you said, this type is mixed, just like the SplFixedArray, ArrayObject, values of SplObjectStorage/WeakMap, etc.
> Generic support is something that's been brought up before, investigated, then abandoned.
>
> My concerns with adding StringVector, MixedVector, IntVector, FloatVector, BoolVector, ArrayVector (confusing), ObjectVector, etc is that
>
> - I doubt many people would agree that there's a wide use case for any
>   specific one of them compared to a vector of any type.

I am lost here. This is the main usage of Vector. For linear
arithmetic like dot product, masking, add/sub/mul/div of vector etc. I
do not see any other usage per see for all the things I have
implemented or saw out there. Additionally, f.e., a string is a vector
already on its own, I am not sure a vector of vectors makes sense ;).

>   This would be even harder to argue for than just a single Vector type.
> - Mixes of null and type `T` might make sense in many cases (e.g. optional objects, statistics that failed to get computed, etc) but would be forbidden by that
> - It would be a bad choice if generic support did get added in the future.

These are special cases for general purposes of vectors. Implementing
vectors focusing on these special cases rather than the general
purpose (vectorization) would be a strategic mistake. I mentioned it
before, but please take a look at the numpy's Vector f.e., with
python's operator overload, what has been done there is simply
amazing, bringing vector processing/arithmetic a huge boost in
performance, even with millions of entries (14 to 400x speed boost
compared to classic array, even fixed).

> > But really, a non-type-guaranteed Vector/List construct is of fairly little use to me in practice, and that's before we even get into the potential performance optimizations for map() and filter() from type guarantees.
>
> See earlier comments on `vec`/Generics not being actively worked on right now and probably being a far way away from an implementation that would pass a vote.

Generics!=Vector. But I hope that's not the way we are heading here :)

> As for optimizations, opcache currently doesn't optimize individual global functions (let alone methods), it optimizes opcodes.
> Even array_map()/array_filter() aren't optimized, they call callbacks in an ordinary way.
> E.g. https://github.com/php/php-src/pull/5588 or https://externals.io/message/109847 regarding ordinary methods.
>
> Aside: In the long term, I think the opcache core team had a long-term plan of changing the intermediate representation to make these types of optimizations feasible without workarounds like the one I proposed in 5588

You are fully correct here, I see a lack of the engine devs
involvement (not complaining, just a state of the affairs :) in such
RFC where this kind of feature could greatly benefit PHP. Well
planned, this is a huge addition to PHP.

It is also why I am convinced that doing it right for Vectors (as a
start) and thinking forwards to JIT and ops overloading (internally or
userland) to allow smooth and nice vectorization (as some parts use
them already internally f.e.) will bring PHP up to speed with the
competition. If we don't, we just have something that would be similar
to what anyone could do in userland with more flexibility.

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org