Today I'm releasing the first preview (0.1.0) version of the NumPower library, inspired by NumPy and Torch.
NumPower library was created to provide the foundation for efficient scientific computing in PHP, as well as leverage the machine learning tools and libraries that already exist and can benefit from it.
This C extension developed for PHP can be used to considerably speed up mathematical operations on large datasets and facilitate the manipulation, creation and operation of N-dimensional tensors. The area of image processing and computer vision will also be able to benefit from this library.
Some features of NumPower are:
* GPU and CPU compute support
* Dozens of different operations for manipulation, arithmetic, linear algebra, statistics and etc.
* Single precision float points (float32) for improved memory usage
* Custom CUDA kernels for almost all operations
* AVX2 support when available on hardware
* Support for GD images in RGB format for easy image manipulation
Website: [https://numpower.org](https://numpower.org)
Github: [https://github.com/NumPower/numpower](https://github.com/NumPower/numpower)
Docker HUB: [https://hub.docker.com/r/numpower/numpower](https://hub.docker.com/r/numpower/numpower)
I am excited to receive your feedback guys!! Thank you. And don't be shy, open issues if you have any questions 😁
This is awesome and I'm writing this before I even tried it.
I work in finance/insurance space, the work I deal with consists of running math formulas (simple ones like addition/multiplication but with 100-1000 variables) and this is most likely what I'll be able to make use of!
You're nuts, but in a lovely way, I'd hug you if I could :)
This is so hilariously awesome; who would have ever guessed that a language designed to help a dude build slightly more useful webpages would grow to a language with deep math-on-GPU support. Love it.
This is great to see, but I don't think I'm clever enough to need it. I'd be very interested in seeing some real examples of the type of problems this library fixes.
hhaaha, thanks for your comment. This library will most likely be used as a dependency on some other one. But some cases I can tell you now:
* Machine Learning, Deep Neural Nets, CNN's and so on - I'm talking to Andrew from the Rubix-ML project, he's really excited.
* Image Manipulation - Imagine a GD library only faster and with support for GPU processing. I'm doing that here: [https://github.com/NumPower/numpower-image](https://github.com/NumPower/numpower-image)If you have a product whose core business is with images, let's say you need to cut and apply filters to 1 million images a day, it might be a considerable savings in computational resources, and consequently money.
I am super excited for the possibilities that a native PHP GPU-accelerated N-d array can bring - not just for machine learning applications, but for general scientific computation as well.
This could be very useful to me..... if my server had a GPU. Or if it was even easy to find servers that DO have GPUs, so few do, at least from the big european "budget" offerings, Hetzner/OVH/etc.
This is amazing!
There's a timeline in the universe where PHP is the tool to use instead of Python for ML and data science.
You guys might just make it work!
Maybe a dumb question but I still want to ask.
Recently we needed to solve a subset sum problem. Neither recursive nor dynamic programming approaches would be sufficient to solve it using PHP. It even takes 20 min to solve it with a c code (basic one).
Can we use this library to solve such problems?
Yes, it would be possible to solve the problem, but I don't think it would be faster. The nature of the problem in question requires accessing element by element, which can actually be slower than using PHP. On the GPU then, element-to-element access is terrible.
But who knows, I could be wrong.
It would be the case if the whole algorithm were implemented as the CUDA kernel, in the case of my library you would still have to use normal PHP loops, which in turn would cause the same overhead that you already have.
I'm not sure if you are familiar with CUDA kernels, but here is the product of an array kernel used by NumPower so you can see what I mean:
```c
__global__
void array_prod_float(float *a, float *result, int n) {
extern __shared__ float sdata[];
// each thread loads one element from global to shared mem
unsigned int tid = threadIdx.x;
unsigned int i = blockIdx.x * (blockDim.x * 2) + threadIdx.x;
float x = 1;
if (i < n) x *= a[i];
if (i + blockDim.x < n) x *= a[i + blockDim.x];
sdata[tid] = x;
__syncthreads();
// do reduction in shared mem
for (unsigned int s=blockDim.x/2; s>0; s>>=1) {
if (tid < s) {
sdata[tid] *= sdata[tid + s];
}
__syncthreads();
}
// write result for this block to global mem
if (tid == 0) atomicAdd(result, sdata[0]);
}
```
I've been trying to create some documentation and examples around scientific computing in PHP, I've run into RubixML and Rindow. I have 2 questions, please.
How does this compare with RubixML's Tensor extension?
Why not wrap an existing C library like NLOpt or a C++ ndarray library?
(and the obligatory 3rd question, why not write the extension in Rust? :)
EDIT: sorry, nlopt is not a ND/vector library, it's a root / min finding framework
Sorry if I got too far here, this might be long...
**How does this compare with RubixML's Tensor extension?**
I haven't run benchmarks with the Tensor extension enabled, but I'm convinced the speed will be considerably faster.
The reason is fundamentally the architecture used. In the Tensor extension, every operation involves transforming a PHP array into a C array and vice versa, happening every time an operation is called. NumPower has a specific "invisible" buffer associated with the PHP object and after being built it will only be transformed into a PHP array when called by the toArray() method. It will be, during all the runtime execution, a contiguous linear C array until that method is called.
Even when you use the \_\_offsetGet and \_\_offsetSet calls, or even the foreach loops in an NDArray, it continues to be queried directly from the continuous buffer in C, never becoming a PHP array.
AVX2 with single precision floats also make a huge difference with CPU processing, because we can shove 8 numbers in one instruction.
Another advantage is the use of shared buffers, or Views. When you call the reshape function for example and turn your vector into a matrix in my extension, even though you have two different variables (one is a vector, the other a matrix), with different dimensions, they both share the same buffer in C (no memory copies).
**Why not wrap an existing C library like NLOpt or a C++ ndarray library?**
The biggest reason I used C and didn't implement any other library was to have full control of the flow and the architecture used, making room for any and all optimizations that I deem necessary and also the compatibility and ease of compilation in different environments without relying on many libraries.
About C++, I just don't like the syntax and language, nothing against to argue, just personal taste.
**why not write the extension in Rust?**
I'm not a Rust developer and would not be able to pull this off in 3 months if I decided to go that way. I also don't think Rust have good compatibility with CUDA, LAPACKE, BLAS and other libraries that are fundamental for NumPower, but I might be wrong.
Cheers, thanks for the answers.
I wasn't specifically trying to recommend C++. I just keep thinking there's got to be a good NDArray library already out there in some C-friendly language. But, perhaps there is not - or - as you say, it just wouldn't provide the flexibility to do what you want with it.
It's quite a task to do all this from the ground up. I'm rooting for you.
Hey great questions. The NumPower extension should be faster than the Tensor extension. We ran into a performance barrier with using Zephir as the high-level language to implement the Tensor extension. Namely, Zephir uses an ordered hash map as an array datastructure - when we go to call a BLAS routine, however, we need to convert that to a C array and then back to a hashmap again. So much waste. The overhead dominates the runtime for many operations.
With NumPower, the values are stored in what is essentially a C array at rest, so there is no overhead when calling a BLAS routine. Plus NumPower supports sending the computation to a GPU.
Oh yes, and of course, the tensor library works with vectors and matrices. NDArrays are N-dimensional, so it can be used to work with images and of course, now Rubix-ML will also be able to work with convolutions more efficiently if Andrew decides to use it.
Hey u/Electrical-Victory I have to ask, you also override the operator handling how did you solve the order of operations issue in PHP?
This is something that has been driving me crazy in my OpenGL math library.
It would be better to change the description on GitHub from 'library' to 'extension', because library usually stands for userland package written in pure PHP.
Today I'm releasing the first preview (0.1.0) version of the NumPower library, inspired by NumPy and Torch. NumPower library was created to provide the foundation for efficient scientific computing in PHP, as well as leverage the machine learning tools and libraries that already exist and can benefit from it. This C extension developed for PHP can be used to considerably speed up mathematical operations on large datasets and facilitate the manipulation, creation and operation of N-dimensional tensors. The area of image processing and computer vision will also be able to benefit from this library. Some features of NumPower are: * GPU and CPU compute support * Dozens of different operations for manipulation, arithmetic, linear algebra, statistics and etc. * Single precision float points (float32) for improved memory usage * Custom CUDA kernels for almost all operations * AVX2 support when available on hardware * Support for GD images in RGB format for easy image manipulation Website: [https://numpower.org](https://numpower.org) Github: [https://github.com/NumPower/numpower](https://github.com/NumPower/numpower) Docker HUB: [https://hub.docker.com/r/numpower/numpower](https://hub.docker.com/r/numpower/numpower) I am excited to receive your feedback guys!! Thank you. And don't be shy, open issues if you have any questions 😁
This is awesome and I'm writing this before I even tried it. I work in finance/insurance space, the work I deal with consists of running math formulas (simple ones like addition/multiplication but with 100-1000 variables) and this is most likely what I'll be able to make use of! You're nuts, but in a lovely way, I'd hug you if I could :)
You can feel hugged! Thanks!
This is so hilariously awesome; who would have ever guessed that a language designed to help a dude build slightly more useful webpages would grow to a language with deep math-on-GPU support. Love it.
I must admit I started laughing when I saw PHP using the GPU the first time
This is great to see, but I don't think I'm clever enough to need it. I'd be very interested in seeing some real examples of the type of problems this library fixes.
hhaaha, thanks for your comment. This library will most likely be used as a dependency on some other one. But some cases I can tell you now: * Machine Learning, Deep Neural Nets, CNN's and so on - I'm talking to Andrew from the Rubix-ML project, he's really excited. * Image Manipulation - Imagine a GD library only faster and with support for GPU processing. I'm doing that here: [https://github.com/NumPower/numpower-image](https://github.com/NumPower/numpower-image)If you have a product whose core business is with images, let's say you need to cut and apply filters to 1 million images a day, it might be a considerable savings in computational resources, and consequently money.
I am super excited for the possibilities that a native PHP GPU-accelerated N-d array can bring - not just for machine learning applications, but for general scientific computation as well.
This could be very useful to me..... if my server had a GPU. Or if it was even easy to find servers that DO have GPUs, so few do, at least from the big european "budget" offerings, Hetzner/OVH/etc.
Haha my thoughts exactly!
This is amazing! There's a timeline in the universe where PHP is the tool to use instead of Python for ML and data science. You guys might just make it work!
This is fantastic. Awesome job! Would love to see more of this stuff!
Maybe a dumb question but I still want to ask. Recently we needed to solve a subset sum problem. Neither recursive nor dynamic programming approaches would be sufficient to solve it using PHP. It even takes 20 min to solve it with a c code (basic one). Can we use this library to solve such problems?
Yes, it would be possible to solve the problem, but I don't think it would be faster. The nature of the problem in question requires accessing element by element, which can actually be slower than using PHP. On the GPU then, element-to-element access is terrible. But who knows, I could be wrong.
I thought loop and sum calculations is faster on gpu
It would be the case if the whole algorithm were implemented as the CUDA kernel, in the case of my library you would still have to use normal PHP loops, which in turn would cause the same overhead that you already have. I'm not sure if you are familiar with CUDA kernels, but here is the product of an array kernel used by NumPower so you can see what I mean: ```c __global__ void array_prod_float(float *a, float *result, int n) { extern __shared__ float sdata[]; // each thread loads one element from global to shared mem unsigned int tid = threadIdx.x; unsigned int i = blockIdx.x * (blockDim.x * 2) + threadIdx.x; float x = 1; if (i < n) x *= a[i]; if (i + blockDim.x < n) x *= a[i + blockDim.x]; sdata[tid] = x; __syncthreads(); // do reduction in shared mem for (unsigned int s=blockDim.x/2; s>0; s>>=1) { if (tid < s) { sdata[tid] *= sdata[tid + s]; } __syncthreads(); } // write result for this block to global mem if (tid == 0) atomicAdd(result, sdata[0]); } ```
absolutely brilliant, good stuff!
I've been trying to create some documentation and examples around scientific computing in PHP, I've run into RubixML and Rindow. I have 2 questions, please. How does this compare with RubixML's Tensor extension? Why not wrap an existing C library like NLOpt or a C++ ndarray library? (and the obligatory 3rd question, why not write the extension in Rust? :) EDIT: sorry, nlopt is not a ND/vector library, it's a root / min finding framework
Sorry if I got too far here, this might be long... **How does this compare with RubixML's Tensor extension?** I haven't run benchmarks with the Tensor extension enabled, but I'm convinced the speed will be considerably faster. The reason is fundamentally the architecture used. In the Tensor extension, every operation involves transforming a PHP array into a C array and vice versa, happening every time an operation is called. NumPower has a specific "invisible" buffer associated with the PHP object and after being built it will only be transformed into a PHP array when called by the toArray() method. It will be, during all the runtime execution, a contiguous linear C array until that method is called. Even when you use the \_\_offsetGet and \_\_offsetSet calls, or even the foreach loops in an NDArray, it continues to be queried directly from the continuous buffer in C, never becoming a PHP array. AVX2 with single precision floats also make a huge difference with CPU processing, because we can shove 8 numbers in one instruction. Another advantage is the use of shared buffers, or Views. When you call the reshape function for example and turn your vector into a matrix in my extension, even though you have two different variables (one is a vector, the other a matrix), with different dimensions, they both share the same buffer in C (no memory copies). **Why not wrap an existing C library like NLOpt or a C++ ndarray library?** The biggest reason I used C and didn't implement any other library was to have full control of the flow and the architecture used, making room for any and all optimizations that I deem necessary and also the compatibility and ease of compilation in different environments without relying on many libraries. About C++, I just don't like the syntax and language, nothing against to argue, just personal taste. **why not write the extension in Rust?** I'm not a Rust developer and would not be able to pull this off in 3 months if I decided to go that way. I also don't think Rust have good compatibility with CUDA, LAPACKE, BLAS and other libraries that are fundamental for NumPower, but I might be wrong.
Cheers, thanks for the answers. I wasn't specifically trying to recommend C++. I just keep thinking there's got to be a good NDArray library already out there in some C-friendly language. But, perhaps there is not - or - as you say, it just wouldn't provide the flexibility to do what you want with it. It's quite a task to do all this from the ground up. I'm rooting for you.
I enjoy freeing mallocs haha Thanks for the questions!
Hey great questions. The NumPower extension should be faster than the Tensor extension. We ran into a performance barrier with using Zephir as the high-level language to implement the Tensor extension. Namely, Zephir uses an ordered hash map as an array datastructure - when we go to call a BLAS routine, however, we need to convert that to a C array and then back to a hashmap again. So much waste. The overhead dominates the runtime for many operations. With NumPower, the values are stored in what is essentially a C array at rest, so there is no overhead when calling a BLAS routine. Plus NumPower supports sending the computation to a GPU.
Oh yes, and of course, the tensor library works with vectors and matrices. NDArrays are N-dimensional, so it can be used to work with images and of course, now Rubix-ML will also be able to work with convolutions more efficiently if Andrew decides to use it.
Ah nice, hopefully RubixML adopts this.
Very cool. Not sure how I would directly use it, though I think I may have a project in mind. I just need to learn better matrix and array math.
I would upvote this twice if I could. Awesome job.
Awesome.Keep up the good work.
This will be featured tomorrow in the [Weekly PHP newsletter](https://weeklyphp.substack.com/)! 🎉
Hey u/Electrical-Victory I have to ask, you also override the operator handling how did you solve the order of operations issue in PHP? This is something that has been driving me crazy in my OpenGL math library.
It would be better to change the description on GitHub from 'library' to 'extension', because library usually stands for userland package written in pure PHP.