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 <tysonandre...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
