Какво е TypePHP? AOT компилатор, бенчмаркове и кога да го ползвате

Какво е TypePHP? AOT компилатор, бенчмаркове и кога да го ползвате
Блог 2 мин. четене

Какво е TypePHP: Swoole AOT, срещу OPcache/JIT, официални benches, инсталация, съвместимост и измерени Cloud VPS минимуми.

TypePHP е ahead-of-time (AOT) компилаторът на Swoole: пишете типизиран PHP, програмата се свежда до C++17 и се получава нативен бинарен файл, PHP разширение или споделена библиотека. Това не е „по-бърз OPcache“ и не е същият продукт като дългоживеещи Swoole worker-и или FrankenPHP. Това е стъпка на компилация, която разменя динамичната гъвкавост на PHP срещу нативен машинен код по горещия път.

Това ръководство обхваща какво е TypePHP, как се различава от OPcache и JIT, официалните езикови benchmark числа от README на проекта, практичен Linux инсталационен път, трите режима на компилация, за кого е подходящ (и за кого не), границите на съвместимост и измерени минимуми за Cloud VPS от нашите toolkit измервания. Официалните документи са на swoole.com/aot; източникът за компилатора е github.com/swoole/typephp. Не бъркайте с други „TypePHP“ страници, които обсъждат само runtime типизация.

Какво е TypePHP

Класическият PHP минава през Zend: parse → opcodes → (по избор OPcache) → (по избор JIT) → изпълнение. TypePHP променя модела на доставка. Съвместим типизиран PHP се превежда веднъж в оптимизиран C++17 и се свързва с PHPX и (според режима) libphp / Embed SAPI. Резултатът може да е самостоятелен изпълним файл без отделен php интерпретатор процес, зареждаемо разширение или библиотека за други проекти.

Проектът цели PHP 8.4–8.5, изисква C++17 toolchain (GCC 9+ / Clang или MSVC на Windows), CMake 3.24+, Composer 2 и библиотеки за висока точност (GMP, MPFR). Binary режимът на Unix очаква съответна Embed библиотека (libphp.so / libphp.dylib); ако липсва, build-ът може да предложи php-builder от php-src. Този auto-build е тежкият път за RAM и диск.

TypePHP е все още млад спрямо FPM WordPress хостинг. Третирайте го като компилатор за CPU-bound CLI инструменти, типизирани горещи пътища, нативно пакетиране и защита на кода — не като ключ „направи CMS-а ми 8× по-бърз“.

TypePHP срещу OPcache срещу JIT срещу Swoole / FrankenPHP

Тези инструменти решават различни проблеми. Смесването на маркетингови лозунги губи спринтове.

TypePHP AOTOPcacheJIT (PHP 8+)Swoole / FrankenPHP
Цел на компилациятаНативен машинен код (през C++17)BytecodeМашинен код (trace)Все още Zend/runtime; дългоживеещ процес
ЗагряванеНяма при runtime (вече компилирано)На процесJIT загряванеСтарт на worker + reuse на връзки
Нативен изпълним файлДа (bin)НеНеНе (освен ако го обвиете сами)
Типична ползаЧислови / типизирани hot paths, пакетиранеБез повторно парсване на заявкаНякои CPU циклиConcurrency, постоянни връзки

OPcache държи opcodes в споделена памет. JIT може да генерира машинен код за горещи следи в същия Zend процес. Нито едното не доставя самостоятелен нативен продуктов бинарен файл. Swoole и FrankenPHP държат PHP резидентен и променят I/O и concurrency; те не AOT-компилират приложението към C++. Работата на TypePHP е AOT нативен изход.

Официални benchmark числа (и какво не доказват)

README на TypePHP публикува езикови бенчмаркове от php-src bench.php и micro_bench.php, компилирани с -O3:

  • bench.php общо: 5.034 s (интерпретиран PHP) → 0.603 s (TypePHP AOT) — около ~8×
  • micro_bench.php общо: 13.045 s → 2.021 s — около ~6.5×

Тези натоварвания натоварват извиквания на функции, достъп до свойства на обекти, масиви/hash, низове и control flow. Не са WordPress page-generation benches, не са Laravel HTTP throughput и не обещават същия множител за вашия CMS след уикенд миграция. README етикетира таблицата като snapshot от измерване на проекта: версия на PHP, CPU, флагове и разширения местят резултата. Сравнявайте на същата машина преди да планирате капацитет.

Отделен std-container микробенч в същото README показва PHP масиви под JIT при 67.6 s срещу TypePHP std::array при 6.4 s (близо до ръчно написан C++ std::vector 6.2 s) за голям update цикъл. Интересно за числова/контейнерна работа — не е CMS TTFB твърдение. Твърдения като „>10× срещу ZendVM“ четете като близки до маркетинг; основните цитирани числа тук са таблицата от README.

Инсталация на Linux

Два практични пътя: Composer пакет или предварително сглобен tpc release от GitHub.

Системни пакети

sudo apt update
sudo apt install -y build-essential cmake pkg-config libgmp-dev libmpfr-dev
# PHP 8.4 или 8.5 CLI + development headers + php-config
# Composer 2

RHEL/Fedora: dnf install gcc gcc-c++ cmake pkgconf-pkg-config gmp-devel mpfr-devel. Нужен е CMake ≥ 3.24.

Composer

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

Release бинарен файл и PHPX / libphp

Linux release архивите носят компилатора (и README); production Composer зависимостите са вградени в tpc. Съпоставете PHP ZTS ABI на архива с host PHP. За binary/shared изходи PHP_HOME трябва да съдържа bin/php-config, headers и lib/libphp.so. Ако липсва Embed libphp, TypePHP може да предложи php-builder от php-src — планирайте RAM и диск (вижте оразмеряването по-долу).

Официални документи: Install, Composer, Compile, Execution.

Бележка за Windows

Windows x64 toolkit-ите включват съответните PHP/PHPX runtime-и. Все пак ви трябва поддържан C++ компилатор (MSVC). Задайте PHP_HOME, PHPX_HOME и PATH според WINDOWS-SETUP.txt. За повечето екипи Linux остава основният compile host.

Hello world и три режима на компилация

<?php

function main(): void
{
    echo "Hello World!\n";
    var_dump(PHP_VERSION);
}
bin/tpc.php hello.php
./hello

Binary режимът изисква глобална main() (без параметри или main(int $argc, array $argv), връща void). Няма изпълними top-level statements; работата е във функции или методи.

РежимФлагИзходТрябва main()Типична употреба
Binary-m bin (по подразбиране)Изпълним файлДаCLI инструменти, услуги, standalone приложения
Extension-m extPHP .so / .dllНеЗареждане на компилирани API в PHP SAPI
Library-m libСподелена библиотека + stubsНеПовторна употреба от друг проект

Има и --nano за VM-free Nano build-и без libphp, които отхвърлят eval / динамични include. Започнете с нормален bin, освен ако съзнателно ви трябва Nano.

За кого — и кога да не мигрирате

Подходящо: CPU-bound CLI помощни програми, batch процесори, типизирани числови pipeline-и, инструменти като нативен бинарен файл, екипи с C++ toolchain и PHP 8.4+, експерименти с контролируем код.

Неподходящо: класически FPM WordPress или „утре цялото Laravel приложение“, shared hosting без root/toolchain, код с eval, тежка runtime генерация на класове или reflection трикове, които TypePHP съзнателно отхвърля. TypePHP не е магически ускорител пред непроменен CMS.

Решение в едно изречение: ако ползата зависи от типизирани hot paths и приемате AOT ограниченията, прототипирайте малък CLI бинарен файл; ако зависи от HTTP плъгини и динамични WordPress филтри, останете на OPcache/JIT (Swoole/FrankenPHP само за concurrency — не заместител на AOT).

Граници на съвместимост

TypePHP следва PHP синтаксиса там, където е съвместим с AOT, с умишлени ограничения. Глобалният scope е само декларации. Изводените int/float/bool по подразбиране ползват фиксирано нативно хранилище. Някои силно динамични reference, declaration, closure и reflection модели остават неподдържани. Проверете списъка с несъвместими функции и документацията за съвместимост, преди да обещаете rewrite. „Ще направим TypePHP на съществуващия CMS“ без одит оставя миграцията наполовина.

Опитайте на EuroVDC Cloud VPS (измерени минимуми)

Измерихме официалния Windows TypePHP v0.9.4 toolkit на build хост (Docker/WSL там липсваха; Linux auto-build на php-src не беше изпълнен там). Записани числа:

  • Windows toolkit zip: 56.77 MB; разархивиран на диск: 171.24 MB
  • Linux release tarball (ориентиран към компилатора): 12.53 MB
  • Peak working set на tpc.exe при опит за компилация на hello.php: 34.6 MB (компилацията спря, защото липсваше MSVC cl — peak RSS все пак отразява старта на компилатора)

За реален Linux експеримент със системни пакети, предварително сглобен tpc и C++ toolchain планирайте поне:

  • ≥ 4 GB RAM, 2+ vCPU, ≥ 20 GB свободно дисково пространство → EuroVDC Cloud VPS Medium (4 vCPU / 4 GB) като практичен под
  • При php-builder / Embed libphp auto-build с удобен -j: ≥ 8 GB RAM → Cloud VPS Medium Plus (4 vCPU / 8 GB)
  • Shared hosting: не е подходящ

Поръчайте възел в София на Cloud Server, инсталирайте пакетите по-горе и компилирайте hello бинарен файл, преди да се ангажирате с продуктов rewrite. Мека проверка на пътя от нашия datacenter в София: Looking Glass.

Източници

Готови за експеримент? Поръчайте Cloud VPS Medium или Medium Plus, инсталирайте toolchain-а, компилирайте hello.php и тогава решете дали горещият ви път принадлежи на AOT TypePHP или остава на OPcache/JIT.

typephp aot swoole php opcache jit kompilator

EuroVDC

Открийте силата на Cloud

KVM виртуализация · Мигновено мащабиране · 24/7

Наемете Cloud сървър

Bu içeriği faydalı buldunuz mu?

– kişi faydalı buldu

Sosyal Medyada Paylaş

Какво е TypePHP? AOT компилатор, бенчмаркове и кога да го ползвате