TypePHP Nedir? AOT Derleyici, Hız Testleri ve Ne Zaman Kullanılır

TypePHP, Swoole’un ahead-of-time (AOT) derleyicisidir: tipli PHP yazarsınız, program C++17’ye indirilir, ardından yerel ikili, PHP eklentisi veya paylaşımlı kütüphane üretilir. Bu yol “daha hızlı OPcache” değildir; uzun ömürlü Swoole worker’ları veya FrankenPHP ile de aynı ürün değildir. Dinamik PHP esnekliğini, sıcak yolda yerel makine kodu için takas eden bir derleme adımıdır.

Bu rehber TypePHP’nin ne olduğunu, OPcache ve JIT’ten farkını, proje README’sindeki resmi dil benchmark sayılarını, pratik Linux kurulumunu, üç derleme modunu, kimin benimsemesi gerektiğini (ve kimin gerekmediğini), uyumluluk sınırlarını ve kendi toolkit ölçümlerimizden Cloud VPS boyutlandırmasını kapsar. Resmi belgeler swoole.com/aot altındadır; derleyici için kaynak github.com/swoole/typephp. Yalnızca çalışma zamanı tip notları anlatan başka “TypePHP” sayfalarıyla karıştırmayın.

TypePHP nedir?

Klasik PHP Zend motorundan geçer: ayrıştır → opcode → (isteğe bağlı OPcache) → (isteğe bağlı JIT) → çalıştır. TypePHP teslim modelini değiştirir. Uyumlu tipli PHP bir kez optimize C++17’ye çevrilir; PHPX ve (moda göre) libphp / Embed SAPI parçalarıyla bağlanır. Çıktı, ayrı bir php yorumlayıcı süreci olmadan başlayan bağımsız çalıştırılabilir, yüklenebilir eklenti veya başka projelerin çağırdığı kütüphane olabilir.

Proje PHP 8.4–8.5 hedefler; C++17 araç zinciri (GCC 9+ / Clang veya Windows’ta MSVC), CMake 3.24+, Composer 2 ve yüksek hassasiyetli matematik kütüphaneleri (GMP, MPFR) ister. Unix’te binary mod eşleşen Embed kütüphanesi (libphp.so / libphp.dylib) bekler; yoksa derleme, php-src’den özel çalışma zamanı için php-builder önerebilir. Bu otomatik derleme RAM ve disk açısından ağır yoldur.

TypePHP, FPM WordPress barındırmaya göre hâlâ yenidir. CPU-bound CLI araçları, tipli sıcak yollar, yerel paketleme ve kaynak koruma için bir derleyici gibi düşünün — “CMS’imi 8× hızlandır” anahtarı gibi değil.

TypePHP vs OPcache vs JIT vs Swoole / FrankenPHP

Bu araçlar farklı sorunları çözer. Pazarlama sloganlarını karıştırmak sprint kaybettirir.

OPcache opcode’ları paylaşılmış bellekte tutar. JIT aynı Zend süreci içinde sıcak izler için makine kodu üretebilir. İkisi de bağımsız yerel ürün ikilisi üretmez. Swoole ve FrankenPHP PHP’yi bellekte tutar ve I/O / eşzamanlılığı değiştirir; uygulamayı C++’a AOT derlemezler. TypePHP’nin işi AOT yerel çıktıdır.

Resmi benchmark sayıları (ve neyi kanıtlamazlar)

TypePHP README, php-src’deki bench.php ve micro_bench.php dil benchmark’larını -O3 ile yayınlar:

• bench.php toplam: 5.034 s (yorumlanan PHP) → 0.603 s (TypePHP AOT) — yaklaşık ~8×
• micro_bench.php toplam: 13.045 s → 2.021 s — yaklaşık ~6.5×

Bu yükler fonksiyon çağrıları, nesne özellikleri, dizi/hash erişimi, string ve kontrol akışını zorlar. WordPress sayfa üretimi, Laravel HTTP throughput veya “hafta sonu migrasyonundan sonra aynı çarpan” vaadi değildir. README tabloyu proje ölçüm anlık görüntüsü diye etiketler: PHP sürümü, CPU, bayraklar ve eklentiler sonucu kaydırır. Kapasite planlamadan önce aynı makinede karşılaştırın.

Aynı README’deki std-container mikrobench’inde JIT altında PHP dizileri 67.6 s, TypePHP std::array 6.4 s (elle yazılmış C++ std::vector 6.2 s) gösterir. Sayısal/kapsayıcı iş için ilginçtir; CMS TTFB iddiası değildir. “ZendVM’den >10×” ifadelerini pazarlama diline yakın tutun; bu yazıda birincil rakamlar README tablosudur.

Linux’ta kurulum

İki pratik yol: Composer paketi veya GitHub’dan önceden derlenmiş tpc sürüm ikilisi.

Sistem paketleri

sudo apt update
sudo apt install -y build-essential cmake pkg-config libgmp-dev libmpfr-dev
# PHP 8.4 veya 8.5 CLI + geliştirme başlıkları + php-config
# Composer 2

RHEL/Fedora: dnf install gcc gcc-c++ cmake pkgconf-pkg-config gmp-devel mpfr-devel. CMake ≥ 3.24 gerekir.

Composer

composer require --dev swoole/typephp
vendor/bin/tpc.php project.yml
# veya: vendor/bin/tpc.php hello.php

Sürüm ikilisi ve PHPX / libphp

Linux sürüm arşivleri derleyiciyi (ve README’leri) taşır; üretim Composer bağımlılıkları tpc içine gömülüdür. Arşivin PHP ZTS ABI’sini host PHP ile eşleştirin. Binary/shared çıktılar için PHP_HOME içinde bin/php-config, başlıklar ve lib/libphp.so olsun. Embed libphp yoksa TypePHP php-src üzerinden php-builder önerebilir — RAM ve disk planlayın (aşağıdaki boyutlandırma).

Resmi belgeler: Kurulum, Composer, Derleme, Çalıştırma.

Windows notu

Windows x64 toolkit’leri eşleşen PHP/PHPX çalışma zamanlarını içerir. Yine de desteklenen bir C++ derleyicisi (MSVC) gerekir. PHP_HOME, PHPX_HOME ve PATH için toolkit içindeki WINDOWS-SETUP.txt’ye uyun. Çoğu ekip için birincil derleme ortamı Linux’tur.

Hello world ve üç derleme modu

<?php

function main(): void
{
    echo "Hello World!\n";
    var_dump(PHP_VERSION);
}

bin/tpc.php hello.php
./hello

Binary mod küresel main() ister (parametresiz veya main(int $argc, array $argv), dönüş void). Üst düzey çalıştırılabilir ifadeler yok; iş fonksiyon veya metot içinde olmalı.

--nano ile libphp bağlamayan, eval / dinamik include’ları reddeden VM’siz Nano derlemeleri de vardır. Bilmiyorsanız normal bin ile başlayın.

Kimler için — ve ne zaman migrate etmeyin

Uygun: CPU-bound CLI yardımcıları, toplu işleyiciler, tipli sayısal boru hatları, yerel ikili olarak dağıtmak istediğiniz araçlar, C++ araç zinciri ve PHP 8.4+ ile rahat ekipler, kaynağı kontrol edip dinamik kalıpları yeniden yazabileceğiniz deneyler.

Uygun değil: Klasik FPM WordPress veya “yarın tüm Laravel’i derle”, kök/araç zinciri olmayan paylaşımlı hosting, eval, ağır çalışma zamanı sınıf üretimi veya TypePHP’nin bilinçli reddettiği reflection hileleri. TypePHP, değişmemiş CMS önüne bırakılan sihirli hızlandırıcı değildir.

Tek cümlelik karar: kazanç tipli sıcak yollara ve AOT kısıtlarını kabul etmeye bağlıysa küçük bir CLI ikilisi prototipleyin; kazanç HTTP eklentilerine ve dinamik WordPress filtrelerine bağlıysa OPcache/JIT’te kalın (eşzamanlılık için Swoole/FrankenPHP ayrı konu — AOT yerine geçmez).

Uyumluluk sınırları

TypePHP, AOT ile uyumlu olduğu yerde PHP sözdizimini izler; bilinçli kısıtlar vardır. Küresel kapsam yalnızca bildirimdir. Çıkarılan int/float/bool varsayılan olarak sabit yerel depolama kullanır. Bazı dinamik referans, bildirim, closure ve reflection kalıpları desteklenmez. Yeniden yazım vaat etmeden önce uyumsuz özellik listesini ve uyumluluk belgelerini kontrol edin. Denetimsiz “mevcut CMS’i TypePHP yapacağız” satışı migrasyonu ortada bırakır.

EuroVDC Cloud VPS’te deneyin (ölçülmüş minimumlar)

Resmi Windows TypePHP v0.9.4 toolkit’ini bir derleme makinesinde ölçtük (o makinede Docker/WSL yoktu; Linux php-src otomatik derlemesi orada çalıştırılmadı). Kaydedilen sayılar:

• Windows toolkit zip: 56.77 MB; diskte açılmış boyut: 171.24 MB
• Linux sürüm tarball’ı (derleyici odaklı varlık): 12.53 MB
• hello.php derleme denemesi sırasında tpc.exe tepe working set: 34.6 MB (derleme MSVC cl olmadığı için durdu — tepe RSS yine de derleyici başlangıç maliyetini yansıtır)

Sistem paketleri, önceden derlenmiş tpc ve C++ araç zinciriyle gerçek bir Linux deneyi için en az:

• ≥ 4 GB RAM, 2+ vCPU, ≥ 20 GB boş disk → EuroVDC Cloud VPS Medium (4 vCPU / 4 GB) pratik alt sınır
• php-builder / Embed libphp otomatik derlemesi ve rahat -j için: ≥ 8 GB RAM → Cloud VPS Medium Plus (4 vCPU / 8 GB)
• Paylaşımlı hosting: uygun değil

Avrupa düğümü için Cloud Server sipariş edin, yukarıdaki paketleri kurun, ürün yeniden yazımına bağlanmadan önce hello ikilisini derleyin. Sofya veri merkezinden yumuşak yol kontrolü: Looking Glass.

Kaynaklar

• swoole/typephp — README, gereksinimler, benchmark tablosu
• TypePHP kurulumu (swoole.com/aot)
• Composer entegrasyonu
• Derleme belgesi
• Performans belgesi
• Uyumluluk belgesi
• Çalıştırma belgesi
• ITNEXT — TypePHP wants to make PHP faster
• Codex — Getting to Know TypePHP

Denemeye hazır mısınız? Cloud VPS Medium veya Medium Plus alın, araç zincirini kurun, hello.php derleyin; ardından sıcak yolunuzun AOT TypePHP’ye mi yoksa OPcache/JIT’te mi kalacağına karar verin.