pgrust 개발자, copy-and-patch JIT로 SQL 쿼리당 약 5μs 컴파일 주장

pgrust JIT 컴파일러가 코드를 약 5μs에 컴파일한다고 주장하며, 일부만 골라 처리하지 않고 모든 SQL 쿼리를 JIT 컴파일할 수 있다고 설명함
작성자는 LLVM 사용이나 C/C++ 코드 생성은 컴파일 시간이 길어 적용 범위를 제한한다고 보고, 직접 어셈블리를 대상으로 생성하는 방식을 택했음
글의 예제는 리터럴 문자열, 연결, 반복만 지원하는 Rust 정규식 엔진이며, 인터프리터 구현과 JIT 구현 방식을 단계적으로 비교하려는 구성임
JIT는 실행 시점에 얻는 정보가 프로그램 동작을 크게 바꿀 때 유용하며, 언어 인터프리터뿐 아니라 런타임에 스키마를 알게 되는 데이터 파싱에도 쓸 수 있다고 설명함
작성자는 AI 보조로 JIT 구현 난도가 예상보다 낮았다고 말하며, pgrust 성능의 한 이유로 이 컴파일러를 듦

Hacker News opinions

pgrust는 흥미롭지만 PostgreSQL에 올릴 길이 없다면, 결국 널리 쓸 만큼 견고한 독립 프로젝트가 목표인지 궁금함

솔직히 흥미롭다는 말에는 동의 못 함. 데이터베이스나 컴파일러 경험이 없는 사람이 AI로 대충 만든 코드처럼 보임

JIT 컴파일 자체가 보안에 안전하지 않음

ClickHouse는 수년째 JIT를 핵심으로 쓰는데, 그 정도면 충분히 안전하다고 봐야 하는 것 아닌가

JIT는 Write xor Execute 정책을 깨야 해서 문제가 맞음. iOS가 Apple 제공 소프트웨어에만 제한하는 이유도 W^X 때문임

Rust에서 JIT를 쓰는 건 사실상 unsafe 블록을 쓰는 것과 비슷한지 궁금함

보안을 극단까지 밀면 검증된 인터프리터만 돌리거나, 암호 서명된 정적 링크 바이너리만 실행해야 할 것임

Apple도 JavaScriptCore에서는 JIT를 씀. 다만 App Store 정책이 앱의 JIT나 실행 권한 메모리 mmap, mprotect를 막는 식임

Common Lisp에서는 JIT 대상을 프로그래머가 고를 수 있고, 실행 시점뿐 아니라 컴파일이나 로드 시점에도 네이티브 코드로 만들 수 있음

SBCL의 일반적인 빌드는 그런 의미의 JIT가 아님. 평가 전에 코드를 전부 컴파일함

PostgreSQL의 LLVM JIT가 느리다는 불만은 새 얘기가 아님. JIT가 드문 게 아니라 LLVM 같은 프레임워크를 많이 쓸 뿐이고, Cranelift, GNU Lightning, Mir처럼 LLVM보다 생성이 빠른 도구도 있음

SLJIT, asmjit, WebKit의 B3 JIT 같은 작고 빠른 JIT도 이미 있음. 직접 만든 copy-and-patch JIT보다는 느릴 수 있어도 LLVM보다는 빠를 가능성이 큼

이 방식은 copy-and-patch 컴파일을 써서 5μs를 낸 것임

AI가 어려운 도메인 코드를 잘 쓴다는 주장에는 회의적임. UI나 단순 CRUD를 넘으면 결과물이 엉망인 경우가 많아서, 낯선 도메인에서 AI로 시작할 때 특히 조심하게 됨

이건 엄밀한 JIT라기보다 어셈블리 템플릿에 기본 치환을 하는 방식임. LLVM를 빼면 LLVM가 해주는 최적화도 포기하는 셈임

정규식 엔진 구현은 Russ Cox의 글을 먼저 읽어볼 만함. 이 글의 예제와 직접 맞닿아 있음