Mateusz Charytoniuk did this first, but I’ve went a bit further and recomposed the macros for the parameter parsing system that PHP internals uses that only use C macros. Once I get the macros translate and stable I’ll move that part into it’s own repo. I am looking into moving my Raylib-PHP extension into Zig: GitHub - joseph-montanez/raylib-php: PHP 8 Bindings to raylib which is 40,000+ lines of C code, albeit its autogenerated from a system I was creating.
I did provide a very superficial benchmark, basically Zig is not as fast as C (depends) and takes a bit more memory but I’ve done nothing to optimized anything about the code base, its just Zig out of the box.
1,000,000,000 (One Billion) iterations of a string reverse
Version | Time (secs) (Linux x64) | Time (%) (Linux) | Time (secs) (macOS aarch64) | Time (%) (macOS) |
---|---|---|---|---|
PHP’s strrev | 11.95 | 0% slower | 26.61 | 11% slower |
Zig ReleaseFast | 12.36 | 3.46% slower | 24.58 | 2% slower |
C 03 Optimization | 14.14 | 18.35% slower | 23.96 | 0% |
C 02 Optimization | 14.63 | 22.45% slower | 24.24 | 1% slower |
Zig ReleaseSafe | 15.77 | 32.04% slower | 29.83 | 24% slower |
Pure PHP | 145.90 | 1120.96% slower | 280.36 | 1070% slower |
Before I’ll commit to my migration from C to Zig for my PHP extension, I have to get this compiling on Windows as well, since that’s my core usage. Linux and macOS work fine.
Now I’ve had a lot of problem getting even Zig’s C-Interop to work, in fact I have a patch file to patch the php-src
because Zig runs into indefinite loops and conditionals causes problems with double returns (it creates invalid zig code itself). That excludes code that crashes as its trying to convert C into Zig and there are edge cases. This should not be Zig’s issue, it’s just php-src
inlines so much source code in header files!
I started this Friday night… its 2am Monday, sooOoOo lets just say I am intrigued…