PHP 8의 새로운 기능 JIT 이해

PHP 8의 JIT(Just In Time) 컴파일러는 확장으로 PHP에 통합됩니다. Opcache 확장은 런타임에 특정 opcode를 CPU 명령어로 직접 변환하는 데 사용됩니다.

즉, JIT를 사용하면 Zend VM은 특정 opcode를 해석할 필요가 없으며 이러한 명령은 CPU 수준 명령으로 직접 실행됩니다.

PHP 8의 JIT

PHP 8 JIT(Just In Time) 컴파일러의 영향은 의심할 여지가 없습니다. 그러나 지금까지 JIT가 수행해야 하는 작업에 대해 알려진 바가 거의 없다는 사실을 발견했습니다.

많은 연구와 포기 끝에 PHP 소스 코드를 직접 확인하기로 결정했습니다. C 언어에 대한 나의 지식과 지금까지 수집한 모든 정보를 결합하여 이 기사를 작성했습니다. 이 기사가 PHP의 JIT를 더 잘 이해하는 데 도움이 되기를 바랍니다.

간단히 말하면 JIT가 예상대로 작동하면 코드가 Zend VM을 통해 실행되지 않고 일련의 CPU 수준 명령으로 직접 실행됩니다.

그게 전부입니다.

하지만 더 잘 이해하려면 PHP가 내부적으로 어떻게 작동하는지 고려해야 합니다. 별로 복잡하지는 않지만 소개가 필요합니다.

PHP 코드는 어떻게 실행되나요?

우리 모두 알고 있듯이 PHP는 해석형 언어인데 이 문장 자체는 무엇을 의미할까요?

PHP 코드(명령줄 스크립트 또는 웹 애플리케이션)를 실행할 때마다 PHP 인터프리터를 거쳐야 합니다. 가장 일반적으로 사용되는 것은 PHP-FPM 및 CLI 인터프리터입니다.

인터프리터의 작업은 간단합니다. PHP 코드를 받아 해석하고 결과를 반환하는 것입니다.

일반적으로 통역되는 언어는 이 과정을 따릅니다. 일부 언어에서는 몇 가지 단계를 생략할 수 있지만 일반적인 아이디어는 동일합니다. PHP에서 프로세스는 다음과 같습니다.

PHP 코드를 읽고 이를 토큰이라는 키워드 집합으로 해석합니다. 이 프로세스를 통해 인터프리터는 각 프로그램에 어떤 코드가 작성되었는지 알 수 있습니다. 이 단계를 렉싱(Lexing) 또는 토큰화(Tokenizing)라고 합니다. 토큰 컬렉션을 얻은 후 PHP 인터프리터는 이를 구문 분석하려고 시도합니다. AST(추상 구문 트리)는 구문 분석이라는 프로세스를 통해 생성됩니다. 여기서 AST는 수행할 작업을 나타내는 노드 집합입니다. 예를 들어, "echo 1 + 1"은 실제로 "1 + 1의 결과를 인쇄합니다" 또는 더 구체적으로 "작업을 인쇄합니다. 이 작업은 1 + 1입니다"를 의미합니다. AST를 사용하면 작업과 우선순위를 더 쉽게 이해할 수 있습니다. 추상 구문 트리를 CPU에서 실행할 수 있는 작업으로 변환하려면 전환 표현식(IR)이 필요하며, PHP에서는 이를 Opcode라고 합니다. AST를 Opcode로 변환하는 프로세스를 컴파일이라고 합니다. Opcode를 사용하면 재미있는 부분이 있습니다: 코드 실행! PHP에는 일련의 Opcode를 수신하고 실행할 수 있는 Zend VM이라는 엔진이 있습니다. 모든 Opcode가 실행된 후 Zend VM은 프로그램을 종료합니다.

이 그림을 보면 더 명확해집니다.

PHP 해석 프로세스 개요의 단순화된 버전입니다.

보시다시피요. 질문이 있습니다. PHP 코드가 변경되지 않았더라도 실행될 때마다 이 프로세스를 계속 따를까요?

Opcode를 다시 살펴보겠습니다. 좋아요! 이것이 Opcache 확장이 존재하는 이유입니다.

Opcache 확장

Opcache 확장은 PHP와 함께 제공되며 일반적으로 비활성화할 필요가 없습니다. PHP를 사용할 때는 Opcache를 활성화하는 것이 가장 좋습니다.

그것이 하는 일은 Opcode에 메모리 공유 캐시 레이어를 추가하는 것입니다. 그 작업은 AST에서 새로 생성된 Opcode를 추출하고 실행 중에 Lexing/Tokenizing 및 Parsing 단계를 건너뛸 수 있도록 캐시하는 것입니다.

Opcache 확장을 포함한 프로세스 다이어그램입니다.

Opcache를 사용하는 PHP 프로세스를 설명합니다. 파일이 이미 구문 분석된 경우 PHP는 다시 구문 분석하는 대신 해당 파일에 대해 캐시된 Opcode를 가져옵니다.

렉싱/토큰화, 구문 분석 및 컴파일 단계를 완벽하게 건너뜁니다.

참고 사항: 이것은 멋진 PHP 7.4 사전 로딩 기능인 RFC입니다. PHP FPM이 코드 베이스를 구문 분석하고 Opcode로 변환한 후 실행하기 전에 캐시하도록 지시할 수 있습니다.

이 해석 과정에 JIT가 어떻게 참여하는지 알고 싶으십니까? 이 기사에서는 설명할 것입니다.

Just In Time 편집의 효과는 무엇인가요?

PHP Internals News에서 Zeev의 PHP 및 JIT 방송을 듣고 JIT가 실제로 무엇을 하는지 알아냈습니다.

Opcache 확장이 Opcode를 더 빠르게 가져와 Zend VM으로 직접 전송할 수 있다면 JIT를 사용하면 Zend VM을 전혀 사용하지 않고도 Opcode를 실행할 수 있습니다.

Zend VM은 Opcode와 CPU 사이의 계층 역할을 하는 C로 작성된 프로그램입니다. JIT는 런타임에 직접 컴파일된 코드를 생성하므로 PHP는 Zend VM을 건너뛰고 CPU에서 직접 실행할 수 있습니다. 이론적으로는 성능이 더 좋아질 것입니다.

이것은 기계 코드로 컴파일되기 전에 각 구조체 유형에 대해 구체적인 구현을 작성해야 하기 때문에 이상하게 들립니다. 그러나 사실 이는 타당하다.

PHP의 JIT는 특정 형식의 CPU 명령어 세트를 다양한 CPU 유형에 대한 어셈블리 코드로 매핑하는 DynaASM(Dynamic Assembler)이라는 라이브러리를 사용합니다. 따라서 컴파일러는 DynASM을 사용하여 Opcode를 특정 구조에 대한 기계어 코드로 변환하기만 하면 됩니다.

그런데 오랫동안 나를 괴롭혀온 문제가 있습니다.

미리 로드를 통해 실행 전에 PHP 코드를 Opcode로 구문 분석할 수 있고 DynASM이 Opcode를 기계어 코드(Just In Time 컴파일)로 컴파일할 수 있다면 Ahead of Time 컴파일을 사용하여 즉시 PHP를 컴파일하면 어떨까요?

Zeev의 방송을 듣고 알게 된 이유 중 하나는 PHP가 약한 유형의 언어라는 것입니다. 즉, Zend VM이 opcode를 실행하려고 시도할 때까지 PHP는 일반적으로 변수 유형을 알 수 없다는 의미입니다.

Zend_value 공용체 유형을 확인하면 많은 포인터가 다양한 유형의 변수를 가리킨다는 것을 알 수 있습니다. Zend VM은 Zend_value에서 값을 얻으려고 할 때마다 ZSTR_VAL과 같은 매크로를 사용하여 공용체 유형의 문자열에 대한 포인터를 얻습니다.

예를 들어, 이 Zend VM 핸들러는 "작거나 같음"(<=) 표현식을 처리합니다. 단지 유형 추론을 위해 else 분기가 그렇게 많이 인코딩되는 방식을 살펴보세요.

기계어 코드를 사용하여 유형 추론 논리를 수행하는 것은 불가능하며 속도가 느려질 수 있습니다.

먼저 평가한 다음 컴파일하는 것도 좋은 선택이 아닙니다. 기계어 코드로 컴파일하는 것은 CPU 집약적인 작업이기 때문입니다. 따라서 런타임에 모든 것을 컴파일하는 것도 좋지 않습니다.

그럼 Just In Time은 어떻게 컴파일되나요?

이제 우리는 유형을 미리 컴파일하기 위해 잘 추론할 수 없다는 것을 알고 있습니다. 또한 런타임 시 컴파일에는 계산 비용이 많이 든다는 것도 알고 있습니다. 그렇다면 PHP용 JIT의 이점은 무엇입니까?

균형을 찾기 위해 PHP의 JIT는 가치 있는 Opcode만 컴파일하려고 합니다. 이를 위해 JIT는 Zend VM이 실행할 Opcode를 분석하고 가능한 컴파일을 확인합니다. (구성 파일에 따라)

Opcode가 컴파일되면 Zend VM 대신 컴파일된 코드로 실행이 전달됩니다.

PHP의 JIT 해석 과정은 다음과 같습니다. 컴파일된 경우 Opcode는 Zend VM에 의해 실행되지 않습니다.

따라서 Opcache 확장에는 Opcode 컴파일 여부를 결정하는 두 가지 감지 지침이 있습니다. 그렇다면 컴파일러는 DynASM을 사용하여 이 Opcode를 기계어 코드로 변환하고 이 기계어 코드를 실행합니다.

흥미롭게도 현재 인터페이스에는 컴파일된 코드에 대한 MB 제한(구성 가능)이 있으므로 코드 실행은 JIT와 해석된 코드 간에 원활하게 전환할 수 있어야 합니다.

그런데, PHP의 JIT에 대한 Benoit Jacquemont의 이 강연은 제가 이 모든 것을 이해하는 데 도움이 되었습니다.

편집 부분이 언제 효과적으로 완료되었는지는 아직 잘 모르겠지만 지금은 별로 알고 싶지 않은 것 같습니다.

그래서 성능 향상은 그리 크지 않을 것입니다.

대부분의 PHP 애플리케이션이 JIT(Just-In-Time) 컴파일러를 사용하여 큰 성능 향상을 얻지 못하는 이유가 이제 모든 사람에게 분명해졌기를 바랍니다. 이것이 Zeev가 애플리케이션에 대해 다양한 JIT 구성을 프로파일링하고 실험하는 것이 최선의 접근 방식이라고 권장하는 이유입니다.

PHP FPM을 사용하는 경우 여러 요청에 걸쳐 컴파일된 opcode를 공유하는 것이 일반적이지만 여전히 판도를 바꿀 수는 없습니다.

이것은 JIT가 계산 집약적인 작업을 최적화하고 오늘날 대부분의 PHP 애플리케이션이 다른 어떤 것보다 I/O 바인딩이 더 많기 때문입니다. 어쨌든 디스크나 네트워크에 액세스하려는 경우 처리 작업이 컴파일되는지 여부는 중요하지 않습니다. 시기는 매우 비슷할 것입니다.

만약...

이미지 처리나 기계 학습과 같이 I/O 바인딩이 아닌 작업을 수행하고 있는 경우. I/O와 관련되지 않은 모든 것은 JIT 컴파일러의 이점을 누릴 것입니다.

이것이 바로 사람들이 C 대신 PHP로 기본 함수를 작성하는 것을 선호한다고 말하는 이유입니다. 어쨌든 이 함수를 컴파일한다면 오버헤드가 너무 커질 것입니다.

추천 튜토리얼: "PHP7"

위 내용은 PHP 8의 새로운 기능 JIT 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!