実際、2013 年に、Niao 兄弟と Dmitry (PHP 言語コア開発者の 1 人) は、PHP5.5 バージョン (未リリース) で JIT を試みたことがあります。 PHP5.5 の本来の実行プロセスは、字句解析および構文解析を通じて PHP コードをオペコード バイトコードにコンパイルし (形式はアセンブリに似ています)、その後、Zend エンジンがこれらのオペコード命令を読み取り、1 つずつ解析して実行します。

そして、オペコードリンクの後に型推論 (TypeInf) を導入し、JIT を通じて ByteCode を生成して実行しました。

その結果、ベンチマーク(テストプログラム)ではJIT導入後、PHP5.5と比較して8倍のパフォーマンス向上という素晴らしい結果が得られました。しかし、この最適化を実際のプロジェクト WordPress (オープンソース ブログ プロジェクト) に導入したところ、パフォーマンスの向上はほとんど見られず、不可解なテスト結果が得られました。

そこで、彼らは Linux でプロファイル タイプ ツールを使用して、プログラム実行の CPU 時間消費を分析しました。

WordPress を 100 回実行したときの CPU 消費量の分布:

CPU 時間の 21% がメモリ管理に費やされます。

CPU 時間の 12% は、主に PHP 配列の追加、削除、変更、チェックなどのハッシュ テーブル操作に費やされます。

CPU 時間の 30% が strlen などの組み込み関数に費やされます。

CPU 時間の 25% が VM (Zend Engine) に費やされます。

分析後、次の 2 つの結論が導き出されました:

(1) JIT によって生成された ByteCode が大きすぎる場合、CPU キャッシュ ヒット率が低下します (CPU キャッシュ ミス)

PHP5.5 コードでは、明らかな型定義がないため、型推論は頼りました。可能な限り推論できる変数の型を定義し、型推論と組み合わせて、その型以外の分岐コードを削除し、直接実行可能な機械語コードを生成します。ただし、型推論ではすべての型を推論できるわけではなく、WordPress では推論できる型情報は 30% 以下に限られており、削減できる分岐コードも限られています。その結果、JIT 後にマシン コードが直接生成され、生成される ByteCode が大きすぎるため、最終的に CPU キャッシュ ヒット (CPU キャッシュ ミス) が大幅に減少します。

CPU キャッシュ ヒットとは、CPU が命令を読み取って実行するときに、必要なデータが CPU の 1 次キャッシュ (L1) で読み取れない場合、下方への検索を継続する必要があることを意味します。 、2次キャッシュ（L2）と3次キャッシュ（L3）に至るまで、最終的にはメモリ領域で必要な命令データを見つけようとします。メモリとCPUキャッシュの間の読み取り時間のギャップは、最大に達する可能性があります。 100倍レベル。したがって、ByteCode が大きすぎて実行される命令の数が多すぎる場合、多値キャッシュではそれほど多くのデータを収容できず、一部の命令をメモリ領域に格納する必要があります。

## したがって、CPU キャッシュ ヒット率の低下は、消費時間の大幅な増加を引き起こす一方、パフォーマンスの向上により、 JITによるもそれによってオフセットされます。

JIT により VM のオーバーヘッドが削減されると同時に、命令の最適化によりメモリ割り当ての数が削減されるため、間接的にメモリ管理の開発を削減できます。ただし、実際の WordPress プロジェクトの場合、VM に費やされる CPU 時間はわずか 25% であり、主な問題やボトルネックは実際には VM にありません。したがって、JIT 最適化プランは、このバージョンの PHP7 機能には含まれていませんでした。ただし、今後のバージョンで実装される可能性は高いので、期待しておきましょう。

(2) JIT パフォーマンスの改善効果は、プロジェクトの実際のボトルネックに依存します。

JIT には、ベンチマークへの大きな影響 この程度の改善は、コードの量が比較的少なく、最終的に生成される ByteCode も比較的小さく、主なオーバーヘッドが VM にあるためです。ただし、実際の WordPress プロジェクトでは、WordPress のコード量がベンチマークよりもはるかに大きいため、明らかなパフォーマンスの向上はありません。JIT は VM のオーバーヘッドを削減しますが、CPU キャッシュ ヒットと余分なメモリの減少を引き起こします。 ByteCode が大きすぎるため、オーバーヘッドが発生し、最終的には改善されません。

プロジェクトの種類が異なると、CPU オーバーヘッド率も異なり、結果も異なります。実際のプロジェクトを使用しないパフォーマンス テストは、あまり代表的ではありません。

3). Zval の変更点

実際、PHP のさまざまなタイプの変数の実際の記憶媒体は Zval であり、その許容範囲と耐性が特徴です。本質的には、C言語で実装された構造体(struct)です。 PHP を書く学生にとっては、大まかに配列のようなものとして理解できます。

PHP5 の Zval、メモリは 24 バイトを占有します:

PHP7 の Zval、メモリは 16 バイトを占有します:

Zval は 24 バイトから 16 バイトに減少しました。なぜ減少しましたか? 学生を支援するために、ここに C 言語の基礎を少し追加する必要があります。 C に詳しくない人には理解できないでしょう。 struct と Union (union) の間には若干の違いがあり、Struct の各メンバー変数は独立したメモリ空間を占有しますが、union のメンバー変数はメモリ空間を共有します (つまり、メンバー変数の 1 つが変更されると、パブリックスペースは変更後、他のメンバー変数の記録はありません）。したがって、メンバー変数がより多くなったように見えますが、実際に占有されるメモリ領域は減少しています。

さらに、大幅に変更された機能が他にもあり、一部の単純な型では参照が使用されなくなりました。

Zval 構造図:

図中の Zval は 2 つの 64 ビット (1 バイト = 8 ビット、ビットは「ビット」) で構成されます。型がlongまたはbealoonで、長さが64ビットを超えない場合、値に直接格納され、後続の参照はありません。変数の型が 64 ビットを超える配列、オブジェクト、文字列などの場合、格納される値は実際の記憶構造アドレスを指すポインタになります。

単純な変数型の場合、Zval ストレージは非常にシンプルかつ効率的になります。

参照が必要ない型: NULL、Boolean、Long、Double

参照が必要な型: String、Array、Object、Resource、Reference

4) . 内部型 zend_string

Zend_string は実際に文字列を格納する構造体であり、実際のコンテンツが格納されます。 val(char ,character type) で、val は長さ 1 の char 配列です (メンバー変数の占有に便利です)。

構造体の最後のメンバー変数は、char* を使用する代わりに char 配列を使用します。ここでは、次の小さな最適化トリックを使用して、 CPU キャッシュミス。

char 配列を使用する場合、上記の構造体のメモリに malloc を適用すると、同じ領域に適用されます。通常、長さは実際の sizeof(_zend_string) になります。文字の保存スペース。ただし、char* を使用する場合、この場所に格納されるのはポインタのみであり、実際の格納場所は別の独立したメモリ領域にあります。

# char[1] と char* を使用したメモリ割り当ての比較:

ロジック実装の観点から見ると、実際にはこの 2 つに大きな違いはなく、効果は非常に似ています。実際、これらのメモリ ブロックが CPU にロードされると、見た目は大きく異なります。前者は連続して割り当てられた同じメモリであるため、通常、CPU がそれを読み取るときに一緒に取得できます (同じレベルのキャッシュにあるため)。後者は、2 つのメモリからのデータが含まれているため、CPU が最初のメモリを読み取るときに、2 番目のメモリのデータが同じレベルのキャッシュにない可能性が非常に高いため、CPU は L2 (2 次キャッシュ) の下を検索する必要があります。 Even to 目的の 2 番目のメモリデータがメモリ領域に見つかりました。これにより CPU キャッシュ ミスが発生し、両者の時間の差は最大 100 倍になる可能性があります。

#さらに、文字列をコピーするとき、参照割り当てを使用すると、zend_string はメモリのコピーを回避できます。

5). PHP 配列 (HashTable および Zend 配列) の変更点

この図は、さまざまなポインターが飛び回っており、非常に複雑に見えます。キー値を通じて要素のコンテンツにアクセスすると、場合によっては、適切なコンテンツを見つけるには、3 回のポインター ジャンプが必要です。最も重要な点は、これらの配列要素の格納が異なるメモリ領域に分散されていることです。同様に、CPU が読み取りを行う場合、同じレベルのキャッシュにない可能性が高いため、CPU は下位レベルのキャッシュ、さらにはメモリ領域を検索する必要があり、これにより CPU キャッシュ ヒットが減少します。消費量が増加する時間。

PHP7 の Zend 配列 (PPT からのスクリーンショット):

配列構造の新しいバージョン, とてもシンプルで目を引きます。最大の特徴は、配列要素全体とハッシュマッピングテーブルがすべて接続され、同じメモリ上に割り当てられていることです。単純型の整数配列を走査している場合、配列要素 (バケット) 自体が同じメモリ内に継続的に割り当てられ、配列要素の zval が整数要素を内部的に格納するため、効率が非常に速くなります。ポインタ外部リンクでもあり、すべてのデータは現在のメモリ領域に保存されます。もちろん、最も重要なことは、CPU キャッシュ ミス (CPU キャッシュ ヒット率の低下) を回避できることです。

Zend 配列の変更:

(1) 配列の値のデフォルトは zval です。

(2) HashTable のサイズは 72 バイトから 56 バイトに減少し、22% 削減されました。

(3) バケットのサイズは 72 バイトから 32 バイトに減少し、50% 削減されました。

(4) 配列要素のバケットのメモリ空間はまとめて割り当てられます。

(5) 配列要素 (Bucket.key) のキーは zend_string を指します。

(6) 配列要素の値がバケットに埋め込まれます。

(7) CPU キャッシュミスを削減します。

6). 関数呼び出し規約

PHP7 が改良されました 関数呼び出しメカニズムパラメータ転送プロセスを最適化することで一部の命令を削減し、実行効率を向上させます。

PHP5 の関数呼び出しメカニズム (PPT からのスクリーンショット):

7). マクロ定義とインライン関数 (インライン) を使用して、コンパイラに作業の一部を事前に完了させます。 #

C言語のマクロ定義は前処理段階(コンパイル段階)で実行され、作業の一部が事前に完了しており、プログラム実行時にメモリを確保する必要がなく、関数ライクに実現できます。関数呼び出しのスタックプッシュやポップアップがないため、スタックのオーバーヘッドが発生せず、効率が高くなります。インライン関数も同様で、前処理の段階でプログラム中の関数を関数本体に置き換えますが、ここで実際に実行するプログラムを実行する際には関数呼び出しのオーバーヘッドは発生しません。

PHP7 では、この点で多くの最適化が行われ、実行フェーズで実行する必要がある多くの作業がコンパイルフェーズに組み込まれました。例えば、パラメータの型判定（Parameters Parsing）はすべて固定の文字定数であるため、コンパイル段階で完了することができ、その後の実行効率が向上します。

たとえば、下図では、左の記述方法から右のマクロの記述方法まで、渡されるパラメータの型の扱い方が最適化されています。

PHP 7.0.0 RC 2 リリースされた新機能

• パフォーマンスの向上: PHP 7 は PHP 5.6 の最大 2 倍高速: パフォーマンスは php5.6 の 2 倍

• 一貫した 64 ビット サポートは 64 ビットをサポートし、さまざまなプラットフォームで整数の長さを統一し、文字列と 2GB を超えるファイルのアップロードをサポートします。
• 多くの致命的なエラーが例外になりました 詳細 エラー エラーは例外で処理できます
• 古いサポートされていない SAPI と拡張機能の削除 古いサポートされていない SAPI と拡張機能が削除されましたサポートされている SAPI と拡張機能
• null 合体演算子 (??) null 合体演算子 (??)
• 結合比較演算子 (<=>) 結合比較演算子 (< =>)
• 戻り値の型宣言 戻り値の型宣言
• スカラー型宣言 スカラー型宣言##Anonymousクラス 匿名クラス

##具体的な例:

より多くのエラーがキャッチ可能になります 例外

PHP7 はグローバルなスロー可能なインターフェイスを実装しており、元の例外と一部のエラーが実装されています。このインターフェイスは、例外の継承構造を定義するために使用されます。インターフェースの形式。その結果、PHP7 ではより多くのエラーがキャッチ可能な例外となって開発者に返され、キャッチされなかった場合はエラー、キャッチされた場合はプログラム内で処理できる例外となるようになりました。これらのキャッチ可能なエラーは通常、存在しない関数など、プログラムに致命的な害を及ぼさないエラーです。 PHP7 は開発者の処理をさらに容易にし、開発者がプロ​​グラムをより詳細に制御できるようにします。デフォルトでは、エラーによりプログラムが直接中断されますが、PHP7 はエラーをキャプチャして処理する機能を提供し、プログラムの実行を継続できるため、プログラマはより柔軟な選択肢を得ることができます。

#たとえば、存在するかどうかわからない関数を実行する場合、PHP5 互換のメソッドでは、関数の前に判定 function_exist を追加します。 PHP7 はキャプチャをサポートしていますが、例外の処理方法を示します。

下の図の例

AST (抽象構文ツリー、抽象構文ツリー)

AST は、PHP コンパイル プロセスでミドルウェアの役割を果たし、インタープリターからオペコードを直接吐き出す元の方法を置き換え、インタープリター (パーサー) とコンパイラー (コンパイラー) を分離します。これにより、一部のハック コードが削減され、同時に実装の理解と保守が容易になります。

PHP5：

PHP7：

その他の AST 情報: https://wiki.php.net/rfc/abstract_syntax_tree

#ネイティブ TLS (ネイティブ スレッド ローカル ストレージ、ネイティブ スレッド ローカル)ストレージ）＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃

PHP は、スレッドが共有するため、マルチスレッド モード (たとえば、Web サーバー Apache のワーカー モードとイベント モードはマルチスレッドです) で「スレッド セーフ」(TS、スレッド セーフ) の問題を解決する必要があります。プロセスのメモリ空間であるため、他のスレッドとの相互汚染を避けるために、各スレッド自体が何らかの方法でプライベート スペースを構築し、独自のプライベート データを保存する必要があります。 PHP5 で採用されている方法は、大規模なグローバル配列を維持し、各スレッドに独立した記憶領域を割り当てることであり、スレッドは独自のキー値を通じてこのグローバル データ グループにアクセスします。

// PHP 7之前的写法：比较两个数的大小
function order_func($a, $b) {
    return ($a < $b) ? -1 : (($a > $b) ? 1 : 0);
}
// PHP新增的操作符 <=>,perfect
function order_func($a, $b) {
    return $a <=> $b;
}

戻り値の型宣言 戻り値の型宣言とスカラー型宣言 スカラー型宣言
PHP 言語の非常に重要な機能は「弱い型付け」です。これにより、PHP プログラムは非常に簡単に作成できます。初心者でも PHP に触れるとすぐに始めることができます。ただし、これにはいくつかの論争も伴います。変数の型定義のサポートは革新的な変更と言え、PHP はオプションの方法で型定義をサポートし始めます。さらに、switch 命令declare(strict_type=1); も導入されており、この命令がオンになると、現在のファイルの下のプログラムが関数パラメータの転送型と戻り値の型に厳密に従うように強制されます。

たとえば、add 関数と型定義は次のように記述できます。

PHP7 スカラー型宣言 RFC

• まず第一に、PHP 6 はすでに存在していましたが、それはまったく異なるものでした。 10 進法 (より正確に言えば、無限に供給される数値) により、バージョンをスキップすることが容易になり、今後のバージョンに向けて十分な量が残されています。
• 一方、他の PHP 6 では決して一般提供に達しましたが、これは依然として非常に広く公開されており、php.net によって実施されているよく知られたプロジェクトであり、現在議論されているバージョンとはまったく共有されません。 PHP 6 が何であるかを知っている人 (そして多くの PHP 6 が存在します) は、この新しい次期バージョンの内容と機能について、心の中で強い誤解を抱いているでしょう (本質的に、それはすべて Unicode に関するものであるということです)。
• オリジナルの PHP 6 である PHP 6 は、多くの PHP カンファレンスで詳細に議論されてきました。これは、機能と動作に関する詳細な説明を含む、当然のこととしてユーザーに教えられました (「邪悪な」本の著者ではなく、php.net 開発者によって)。
• PHP 6 は、Internals コミュニティ内だけでなく広く知られていました。 、ただし PHP コミュニティ全体についてです。これは、ほとんどではないにしても、多くの PHP コミュニティ メンバーが知っていた注目のプロジェクトでした。
• Web 上には、オリジナルの PHP 6 に関する PHP 6 情報がたくさん存在します。本は問題の最小部分です。
• 「なぜ 7 までスキップしたのですか?」という「トリビアの質問」とは異なり、バージョン 6 を再利用すると、人々の心に混乱が生じる可能性があります。には、まったく同じ名前を持つまったく異なる機能セットを持つ 2 つのまったく異なるバージョンに関する十分な情報が含まれています。バージョンをスキップすることは、オープン ソース プロジェクトと商用製品の両方において、前例のないことでも珍しいことでもありません。 MariaDB は混乱を避けるためにバージョン 10.0 にジャンプし、Netscape Communicator はバージョン 5.0 をスキップして直接 6.0 に、Symantec はバージョン 13 をスキップしました。スキップの理由はそれぞれ異なりますが、共通点はバージョンをスキップしていることです。
• バージョン 6 は一般に、動的言語の世界では失敗と関連付けられています。 PHP 6 は失敗でした。 Perl 6 は失敗でした。実際、これは動的言語の世界以外でも失敗に関連しています。MySQL 6 も存在しましたが、リリースされませんでした。バージョン 6 が失敗であるという認識 - 迷信としてではなく、現実世界の事実 (「Vista」という言葉と失敗の連想と同様) - は、この PHP バージョンに悪影響を及ぼします。
• The case for 6 は主に上記のいくつかの点への反論ですが、バージョン 6 をスキップすべきではない理由についての強力な根拠は示していません。PHP 7 を使用する場合、最悪のシナリオはバージョンを不必要にスキップすることになります。将来の使用に備えて、メジャー バージョンを無限に供給できるようになります。ただし、7 ではなく 6 を選択した場合、最悪のシナリオは、コミュニティ内で混乱が広がり、このバージョンについて否定的な認識が広まる可能性があります。
• #サポート対象 SAPI