Компиляторы
Cranelift и альтернативные backends
Cloudflare Workers запускают Wasm модули за 5ms. Если бы использовался LLVM -O2, компиляция занимала бы секунды - serverless не работал бы. Cranelift решает: компилирует в 10x быстрее при 90% производительности. А QBE показывает: весь production-quality компиляторный backend может уместиться в 15,000 строк C, которые один человек способен прочитать полностью. Разные задачи требуют разных backend'ов.
- **Wasmtime + Cranelift**: Cloudflare Workers, Fastly Compute@Edge, ByteDance - все используют Cranelift для Wasm JIT с cold start < 10ms против минут для Docker контейнеров
- **rustc_codegen_cranelift** (экспериментально): debug builds Rust проектов компилируются в 2-3x быстрее чем с LLVM backend - значимое улучшение цикла разработки для крупных Rust проектов
- **Python 3.13 copy-and-patch JIT**: ~5% speedup на реальных benchmark'ах при minimal overhead на compile time - первый JIT в CPython после 30 лет чистой интерпретации
Cranelift IR и архитектура
Cranelift - компиляторный backend написанный на Rust, разработанный Bytecode Alliance для Wasmtime. Архитектура: Cranelift IR (SSA + sea-of-nodes inspired), ISLE (instruction selection DSL), register allocator regalloc2, machine code emitters для x86-64, ARM64, RISC-V, s390x. Цель - безопасность и скорость компиляции, не максимальный throughput.
Cranelift используется в Wasmtime (основной Wasm runtime Bytecode Alliance), Wasmer (через cranelift feature), и rustc_codegen_cranelift (экспериментальный backend для rustc). Cranelift написан на Rust и проходит формальную верификацию части code gen через ISLE + SMT solver. Это делает его более безопасным backend чем LLVM для security-critical workloads.
Какова главная цель Cranelift по сравнению с LLVM?
Быстрая компиляция: tradeoffs
Cranelift оптимизирован для JIT-сценариев где время компиляции критично. На уровне `opt_level=speed_and_size` генерирует код ~90% производительности LLVM за ~10% времени компиляции. Wasmtime компилирует ~100MB/s Wasm байткода (Cranelift) vs ~10MB/s (LLVM). Это разница между 100ms и 1s cold start для serverless.
Python 3.13 добавил copy-and-patch JIT использующий LLVM и шаблоны: копирует pre-compiled шаблон инструкции и патчит операнды. Это даёт ~5% speedup при minimal compile time. Python 3.14+ рассматривает более агрессивный JIT. JavaScript V8 Sparkplug использует схожий подход: baseline JIT без оптимизаций, только маппинг байткода в нативный.
Почему Cranelift выбран для Wasmtime вместо LLVM?
QBE: минималистичный backend
QBE (Quick Backend) - минималистичный компиляторный backend в ~15000 строк C. Поддерживает x86-64, ARM64, RISC-V. Достаточен для production-quality языков: Cproc (C compiler), cQube (Hare language backend), cc (simple C compiler). QBE IR простой и читаемый. Цель проекта: показать что backend не обязан быть монстром 7+ миллионов строк.
QBE разработал Quentin Carbonneaud как альтернативу для авторов языков, которым не нужен весь LLVM. Hare language (системный язык от sircmpwn/Drew DeVault) использует QBE как основной backend. QBE поддерживает базовые оптимизации: SSA-based DCE, copy elision, basic register allocation. Для исследовательских компиляторов QBE - идеальный баланс между сложностью и возможностями.
Для какого типа проектов QBE является лучшим выбором backend?
GCC Backend и libgccjit
GCC backend (RTL - Register Transfer Language) - зрелая альтернатива LLVM с 40+ лет оптимизаций. GCC генерирует лучший код для некоторых паттернов: FORTRAN HPC, auto-vectorization через Graphite (полиэдральные преобразования). libgccjit - публичный API для встраивания GCC как JIT backend.
Python 3.13 использует copy-and-patch JIT который внутри использует LLVM для генерации шаблонов (не для JIT-компиляции в рантайме). GCC Graphite (полиэдральные циклы) иногда даёт лучшую векторизацию чем LLVM Polly для Fortran/HPC кода. GFortran (Fortran compiler в GCC) до сих пор генерирует более оптимальный код для некоторых BLAS-like операций чем Flang (LLVM Fortran).
LLVM всегда генерирует лучший код чем GCC
GCC и LLVM конкурируют: GCC лидирует для Fortran HPC и некоторых автовекторизационных паттернов, LLVM лидирует для C++/Rust и имеет лучший toolchain экосистему
GCC Graphite (полиэдральные преобразования циклов) в ряде HPC benchmark'ов даёт 5-15% лучший throughput для числовых вычислений. Разные компиляторы используют разные алгоритмы и эвристики - сравнение зависит от конкретного кода
Что такое GCC RTL (Register Transfer Language)?
Итоги
- Cranelift: Rust-backend для Wasmtime, 10x быстрее компиляция чем LLVM -O2 при 90% производительности; идеален для JIT и serverless
- QBE: 15k строк C backend поддерживающий x86-64/ARM64/RISC-V; для исследовательских компиляторов где читаемость важнее максимальных оптимизаций
- Backend выбор - tradeoff: LLVM (максимальная оптимизация), Cranelift (быстрая JIT компиляция), QBE (простота), GCC (зрелость + Fortran)
Связанные темы
Cranelift и альтернативные backends связаны с JIT и WebAssembly:
- LLVM инфраструктура — Cranelift и QBE - альтернативы LLVM backend; LLVM остаётся стандартом для maximum optimization
- WebAssembly — Cranelift - основной backend Wasmtime для компиляции Wasm в нативный код
- JIT-компиляция основы — Cranelift используется как backend для JIT компиляторов где latency компиляции критична
Вопросы для размышления
- Cranelift компилирует в 10x быстрее LLVM за 90% производительности. Для каких production workloads эти 10% производительности критичны и стоят медленной компиляции?
- QBE показывает что backend можно написать в 15k строк. Почему же большинство новых языков (Rust, Zig, Swift) выбирают LLVM несмотря на его сложность?
- Python 3.13 copy-and-patch JIT даёт ~5% speedup. Почему не 50%? Какие характеристики Python делают агрессивный JIT сложным по сравнению с JavaScript?