PHP and RubixML Move From Arrays to GPUs: How the Ecosystem's Approach to ML Is Changing

The PHP ecosystem is moving steadily away from the idea that machine learning can be built seriously on ordinary arrays. The main shift is not new algorithms but a change in the role of the language itself: PHP is no longer a compute engine and increasingly becomes an orchestrator that launches pipelines, ties libraries together and hands heavy math to native extensions and GPUs. Against this backdrop, the turn by RubixML and related projects such as Tensor and NumPower is telling: for matrix operations the difference is now measured not in percentages but in orders of magnitude, from tens of seconds on arrays to fractions of a second on native structures and experimental GPU backends.

At first, PHP's path into ML looked perfectly logical. The first libraries, including PHP-ML and early versions of RubixML, stored matrices as arrays of arrays and ran every operation inside the interpreter. That was convenient for developers: nothing to compile, transparent code that is easy to debug, and basic algorithms such as k-NN, logistic regression or simple classifiers could be put together in a single evening. The approach is still useful for teaching and prototyping, because it lets you walk by hand all the way from the dot product to the forward pass of a simple neural network.

But as soon as data starts to grow, that convenience quickly becomes a bottleneck. The cause lies not in poorly written loops or in flaws of individual libraries, but in PHP's internal model itself. Numbers here do not live as compact primitives but as heavier zval structures.

Arrays are, in general, implemented as hash tables rather than dense, contiguous blocks of memory. As a result, every element access costs more, the CPU cache is used less efficiently, there is no automatic SIMD vectorization, and the copy-on-write mechanism can unexpectedly bloat memory and add extra allocations. Even useful tricks such as transposing matrices in advance or hoisting count out of loops yield only limited gains.

They make code a bit less slow, but they do not turn PHP into an environment for efficient linear algebra.

The next stage of evolution began when developers abandoned the idea of storing matrices as ordinary PHP arrays. That is how Rubix Tensor and NDArray appeared, where data sits in contiguous memory, closer to how NumPy works. NDArray uses Rust for this, which raises performance while avoiding some of the typical problems of manual memory management.

The API looks familiar from the outside, but almost everything changes inside: the per-element zval disappears, the hash-table model goes away, and the code gets closer to mathematical notation. In practical comparisons the difference is obvious: multiplying 500 by 500 matrices takes roughly 10–20 seconds on arrays, about 0.3–0.

8 seconds on Tensor on CPU, and an experimental GPU path via NumPower takes on the order of 0.05–0.2 seconds.

But native structures quickly hit a new ceiling too: even a well-optimized CPU is still a CPU. For embeddings, neural networks and large matrix operations that is no longer enough, so a turn toward GPUs became the logical next step. Around RubixML v3 and NumPower a new model is taking shape in which PHP handles orchestration, Tensor and NumPower take over the compute layer, and the GPU becomes the place where heavy math lives.

This fits well with how higher-level tools such as transformers-php, LLPhant or Neuron AI work today: PHP code there describes the pipeline, model loading, the inference call and result handling, but does not try to compute matrices and loops by hand where more suitable runtimes already exist.

This means PHP's opportunity in AI is less about catching up with Python as a compute environment and more about carving out a clear niche of its own. The language remains strong where ML or LLM features need to be built quickly into a web application, a SaaS product, an agent scenario or a corporate pipeline. But the ecosystem had to accept an unpleasant yet honest conclusion: for PHP to take part in modern ML, it does not need to compute everything itself. Its value increasingly lies in being the glue between models, data, infrastructure and interface, not a replacement for GPUs or low-level libraries.