PHP 8.2リリースについて
こんばんは、Yokohama North AM第81回です。
Yokohama North AMは、ウェブ系エンジニアがテック系のキーワードをネタにして雑談をするポッドキャストです。
ホスト役は、自称PHPRのHanhan1978です。
本日の相手は、SJIこと井原氏さんと、ゼリヨシさんこと工藤さんです。よろしくお願いします。
よろしくお願いします。
よろしくお願いします。
PHPでは、毎年11月頃に、PHPが式年制御じゃないな。
式年制御。
式年制御じゃないですけど、リリースが行われて、今年もPHP 8.2がリリースされるということで。
今回お招きしているこのお二人は、井原氏さんも工藤さんも、今回のPHP 8.2にRSTを出されて、見事に採択っていうんですかね。
何て言うんだろう。受理というか、アクセプトされまして、そのフィーチャーが入っています。
PHP 8.2。
ということで、この日本人に二人も突然コミッターが現れた、このPHP 8.2のリリース直前スペシャルということで、お招きしております。
乱数について
ゲストのご紹介をすると、井原氏さんは、Infinite Loopさん所属で、バックエンドエンジニアですよね。
そうですね。
今回のPHP 8.2だと、コンスタントイントレートを実装されましたと。
もう一人、工藤さんは、Twitterはゼリヨシさんで、今回のPHP 8.2に関しては、ランダムのエクステンションを作っていただきましたということで、よろしくお願いいたします。
よろしくお願いします。
僕は工藤さんのコロプラの乱数に関する資料が、僕大好きで、あれを参照して、これ紙資料だよとかって言って、会社によく流すんですけど、あんまり反応がなくて、あれ?みたいな。
そうなんですよ。反応がないんですよね。乱数って結構、PHPの要素だと今のところ特殊だったっていうのもあって、あんまり見向きはされないし。
それはもうMLでの議論の時からもう露骨にわかっていたやつでしたね。
初めてあれ読んだ時に、もうめちゃくちゃ興奮して、なんだこれ、暗号のことめちゃめちゃちゃんと書いてあるし、ユースケースとか、どういうふうに事業で使ってるとかっていうのも書いてあって、
本当にいい資料だって言って、そのテンションのまま紹介しに行って、あまりの無反応さに、あれ?みたいな。違う。俺なんか、やばい、異世界に迷い込んだ。
実際、偶然にも私と工藤さんの方は、どっちもPHP使ってる人の中でもスマートフォンゲームのサーバーサイドのプログラムみたいなのをやっているということで、この仕事は結構乱数ってのが縁があるんですよ。
いわゆるガチャってやつがありますんで。いわゆるガチャってのがあるんで。
結構乱数って縁深い機能だったりするんですけども、他のウェブ系のエンジニアの人だと乱数ってどういうふうに見てるんでしょうね。
僕まさに普通のウェブ系というか、ゲーム系ではないウェブ系なので、そもそも乱数ほとんど使わない。
まあそうですよね。
MTランドがメルセンヌツイスターで不具合があってみたいな、そういうのを資料として見たりとかっていうのはするけれど、実際の業務として何か使うかっていうと、ほぼほぼ使わないかなっていう感じがあるんで。
乱数を使うID生成するときとか、トークン生成するときとかにたまに使うのかなぐらいの気がするんですよね。
そうですね。本当にそんなもんですね、用途としては。
一時的にURL知ってる人だけが見れるパブリックなエンドポイント作るとか、そういった用途で使うときがあるかな。
使うって言ってもライブラリーの中で使えてるみたいな。
そうですね。ライブラリーの中であんまり生で使うのは避けてる感じはありますね。
PHP 8.2のRFC作成について
だからそんなもんかな、こういう世界あるんだなと。
ウェブの用途だと確かにあんまり使わないなっていうのと、
ただテストとか書いてて、乱数のあるテストってあんまりよろしくないのが常なんですけど、
再現性がどうしても必要になってくるとか、そういうときには使うのかなと思ってて、
ただちょうどPHPの乱数がね、状態がグローバルっていう結構エグめな感じだったんで、
最初はなんか普通に自前で拡張書いてなんとかしようって感じだったんですけどね、
いろいろML漁ってたらみたいな、そんな感じでした。
ごめんなさい、めっちゃ話下手なんでごめんなさい。
大丈夫、気にしないでください。
お二人ともRFCを、僕からするとすごい雲の上みたいな状態に最初は見えていて、
RFCを出されて実際にPHPにコミットしていくっていうところなんですけど、
実際にどれぐらいの期間かかって、RFCを出そうって思うまでに、
どれぐらいの期間インターナルの議論を見たりとかってそういうことをしてたんですかね。
どういうきっかけで出していったのかなと思って。
そうですね。
どうしよう。
結構多分私が長かったというか、結構グだったなっていうのがあって、
1回そもそもその前にRFC出してたんですね。
パッと実装してたものをとりあえずあった方がいいんじゃないって感じで、
昔のMLを漁ってみたら、最初ペクルに投げたんですよ。
ペクルに拡張作っておいたんですね。
ペクルで公開してみて、これで保守していこうと思ってたんですけど、
インターナル図のMLをカコロが漁ってみたりしてみたら、
オブジェクトスコップというかグローバルスコップまずいよねみたいな議論があったみたいで、
実装しようかなっていう話が出て、そこで止まってたんで、
じゃあ実装してみたんですけど、どう?っていうのをMLに投げたところから始まって、
大体期間としては丸1年ぐらいかかったんじゃないかなと思いますね。
なんならPHP8.1に最初は出してたんで、
もう間に合わないねってなって、8.2で帰っていった感じだったんで、
それで言うとすごい井原さんの、パッと始まってパッと議論が行われてパッと入ったみたいな、
すごいスピード感があって、めっちゃ議論盛り上がってるなって思って、
ちょっと羨ましいというか、なんなら過激な発言とかも出てきて、
いやこれは面白いなって。
あれですよね、完全に締め切り駆動っていう感じで、
そろそろ8.2のRFCというかフィーチャーフリーズが来るから、
PHP 8.2の開発プロセス
そしたらRFCの議論期間、投票期間それぞれ2週間ずつで必要だから、
この段階では始めてないとみたいなタイミングがちょうどそろそろ来るなっていうふうに思ってたら、
今駆動さんはこの乱性拡張の話をずっとされてるし、
ちょうどTwitterの方ではタイムラインの方にはPCPコンファレンス、
そろそろCFPが締め切りですかっていう話が同時に出てくるし、
PCPコンファレンスといえば締め切り駆動、締め切り駆動で案を決していったら、
じゃあこれPCPの方に出してもRFC出してもいいかなみたいな、
そのくらいの酷いのがあったんで、
そういう意味では完全にせべり込みで入ってるので、
普通にずっとコアの開通やってる人たちからすると、
印刷所の人が極端によく送られてるみたいな、そういう気分になると思うんですよ。
なんでこのタイミングでコメディに出てくるの、もうちょっと早く行ってこいよみたいな。
実際結構ギリギリの感じでどうにか収まったっていう感じだったんで。
Twitterでまだいけるかなみたいな。
着眼点がすごい素晴らしいなと思ってて、
本当にトレイトって何ならどういう位置づけなのこれみたいな状況で放置された部分でもあったんで、
そこの考える機会にもなったっていうか。
でもあれでしたね、あんなに議論が出る話だと思ってなかったんですよ。
どう見てもこれただの実装の例だから入れた方がいいよなみたいな。
みんな同意してくれるだろうなっていう。
トレイトの話題と議論
この議論の余地がない話だったら簡単に入るだろうぐらいに、
軽い気持ちでめちゃくちゃギロになってしまって。
あれ?って聞かせれたらトレイト消すべきじゃんみたいな、そういう話になって。
なんならトレイトは消すべきだみたいな話で。
そこまで言うみたいな。
びっくりしましたよ。めちゃめちゃ使わせるなトレイト。
憎むべしみたいな感じになって。
全然そういうつもりじゃなかったんだけどみたいな感じになってしまって。
でもそこにしっかりと対応されてたのが、格の違いを見せつけられた感があって、
私結構英語が苦手っていうのもあって、だいぶ回答がやばかったんですけど、
PSPカンファレンス2022の時もそうだったんですけど、
議論で結構しくじってた部分があったのに、
そこをいがらしさんも完璧っていうかスムーズにちゃんとこなしてたんで、
改めてやっぱりいがらしさんすげえって思いましたね。
あれ何だったんでしょうね。
意外と見え方してくれる人がいて、
俺があんまり説得できたという気持ちはしないんだけれども、
しゃべった方に説得できてない気がするんだけど、
なんかよくわかんないけど勝ったみたいな感じになってる。
だいたい日記師先生がですね、
日記師先生がこれいいんじゃないって言ったらのほうがそのままっていう。
投票も結構。
投票そうですね、最初本当厳しかったですね。
議論期間や議論の進行について
10対2とかってなったけどどうしようかと思いました。
これそんなに拒否の話なんみたいな思いながらも。
ここでひょっとしてここから20票ぐらい入らないとこれ通らないじゃんみたいな感じになっちゃって。
その後の議論で持ち帰したのがなんかすげえなって。
あれ良かったですね。
不思議でしたね。
会社で一応スクリプト作って、
冒頭の割合を毎日計算するスクリプトを作ったんで、
コマンドでポンって押すとだいたい何%なってるんですけど。
これはダメかなって思いながら。
NOもだいぶ冷静だぞって。
最初にもうトレイトシスメ氏みたいな人たちがすごい勢いでNOを投票していったんですよね。
そうですね。
Pレグマッチトレイトで引っかかったらフォルスみたいなそういう人たちがたぶんたく一杯だろうと思います。
やっぱり投票してる人たちも完全に自分の判断で票を入れてるかっていうと、
やっぱり他の人が誰がどういう風に投票してるかみたいなのを参考審議しながら自分の態度で決めたりするっていうのもよくある話なので。
なのでこれダメかなと思ったんですよ。
この結果傾いたら無理かなと思ったんですけど。
いやーもうでも逆転したときに盛り返しましたからね。
そう、感動しました。
これ勝ったろみたいなこと言ってフラグだからやめてって。
ありましたね、その話は。
だいぶ早朝にそれ、これもう勝ったなと思って早くいがらしさん閉じないかなと思って。
早く閉じて早く閉じてと。勝ってるうちに閉じてと。
完全に本当にタイミングギリギリだったので、あれなんですよね。
2週間の議論期間って24×14のこの時間ぴったりでいいのかなとかですね。
切り替わりの基準値いつなのかみたいなのとか。
実際よくわかんなかったりしたんですけど。
てか多分ないんでしょうね。
普通に閉じ忘れてるまま不決されてる時とか普通にあったりしたんで。
細かいルールないからいいかみたいな。
wikiに裏技があるらしくて設定すると自動で閉じるらしいんですよ。
なんかありますね、そういうのありますね。
そうそうそう。
ティムさんがちょうどランダムパクチョのもう一人のメンテナーであるティムさんが
自動で閉じるよそれっていうのをおっしゃってましたね。
なんかありました。
誰もwikiの機能をあまり知らないで使ってるっていう。
なんかPHPらしさを感じていいですね。
多分そんな時間ギリギリでやる必要ないんですよね本当は。
そもそもでいくと。
でもなんとなくですけどやっぱ議論の期間が長くて
みんなが見てるRFCって割とすんなり可決されていくなっていう感じはありますね。
なんかぽっと来てぽっと投票入ると
なんかこうにべもなく打ち死にしていくみたいな感じはちょっとあるから。
しょうがないですよね。
これ入ってもいいかなって思うと
なんか全然ダメだなこれみたいな感じで否決されていくんで。
そうだからそこいくとだから
工藤さん長かったじゃないですか。
そうですね長くなっても私のは多分悪い意味で長くて
なんだろうマジで議論が進まないからほっといたっていう感じと
PHP 8.2における議論について
あと途中で私があまりに反応してもらえないから
やる気がなくなってしまったっていうのがあったんですけど
正直なところ一回モチベが死んでたんですけど
なんかガン無視されるから拾われてるのかなと思って
なんかでもしっかり短期間でも議論がしっかり進めばいいかなと思って
だいたいその否決されるのって議論まだ進んでないのに
投票に入っちゃうとだいたい否決される感じはある
それはそうだろうなってところはあるんですけど
そこは大事だろうなと思って
とりあえず同意が取れてっていうか
みんなまあいっかっていう感じになってからじゃないと
いやいやいや待てよってなるっていうのはありそうですね
なんかJSONバリレートとかそのいい例だと思ってて
結構ちゃんと議論したから入ったっていうか
あれ私正直難しいだろうなと思ってたんですけど
あれはでもなんか題材的にコメントもしやすかったのかなっていうぐらい
みんながいろいろ言ってくれて進んだって感じありますよね
なんか僕ぐらいでもCの実装も全然わかりやすかったし
なんかポイントも抑えてて
メモリの消費量どうなってんのみたいなやつにもちゃんと回答をして
なんか全部できて投票したらもう圧勝みたいなそんな感じでしたよね
ああいうのはいいなと思って見てました
逆になんか個人的に惜しいなと思ったのは
バーレプリゼンテーションかな
モダンなPHPでシリアライズというかPHPのJSONみたいに
PHPコードで構造を吐くっていうのがあったと思うんですけど
あれ結構個人的にはなんかいいんじゃないって思ったんですけど
まあなかなか厳しかったですね
なんか何ですかね
Better to haveみたいなやつはなんかちょっと落ち気味なんですかね
なんかこうあるといいなーみたいな感じ
なんかそこら辺のニュアンスというか
なんか僕もインターナル全部読むや始めてから
まだ6ヶ月ぐらいしか経ってないんであれなんですけど
いや続いてるのマジですごいと思います
そうですねあれそうですよね
だいぶ慣れてきました
さすが
もうWindowsって見たらもうすぐ閉じようと思うんで
Windowsはもう見るのやめたっつって
いろいろテックを身につけてきただけなんですけど
それちょっとわかりますね
GTSについての話題
多分これは俺の人生にあまり意味がないからっつって
一時期私もGTSのことを無視してた時代があったんですけど
なんかGTSは結構今後生きる可能性のあるものなんで
最近は見てるんですけど一時期はもう
そのせいでランダム拡張もGTSでビルドするとぶっ壊れるっていうものがあってね
ベータが動かないっていうWindowsがあったんですけど
全ドスレットセーフティ
モジュールグローバルズ周りが結構GTSなんか適当というか難しいことになってて
未初期化アクセスでやらかしがあったりとかね
あれですね
初期化順がちょっと独特なんですよね
そうですねあれは結構直感的ではないなって思います
仕方ないんですけど考えれば
全然僕ZTSとかマジで知らないですよ
どんな風に書けばいいとか
フランケンの人が結構今ZTS周りでシグナルが動かないとかなんだかんだとか言って
一周でやり取りとかしてるので
そういうのを見て大変そうだなって思ってるけど
自分がまだやる身ではないからみたいなところはあります
でもなんとなくこれだったら僕も手伝えそうだなみたいなのとかは
一周が何個かあったりするんで
そういったところから手つけられたらいいかもなとかって思います
それがRFCに繋がるのが
いまいちどうやったらRFC書こうって思うのかなっていうのはちょっと分かんないですよね
なんかPHPに別にもう満足してるなみたいなところもあって
新しい機能が欲しいと思ったりしないから
もっと使ってもっともっといろんなことをやって
これができたらいいなみたいなのができるとRFCを出すのか
それともいま抱えている何かの問題点とか不具合だとか
不具合だとフィーチャーにはならないのかな
それで言うと私がRFC出したのは自分でメンテしたくなかったからですね
もちろんしていくんですけど
自社だけで持つとか自分だけで持つっていうのはやっぱり
コードの品質的にも維持するの難しいし
あとPHPのアップストリームについていくのも大変なんで
そこら辺があったんで
別にあっても困らないし
逆に言うと今ユーザーランドでどうしようもないんだから
出してみるかっていう
やっぱり保守したくなかったがでかいかもしれないですね
アップストリームフォースト的な感じですよね
それはめちゃくちゃ正しいですよね
個人の人が開発されたモジュールとかに
例えば自社のプロダクトが依存しているとか
やっぱり良い状態ではないと思うから
それが本体に取り込まれてくれたら
コミュニティがサポートしてくれるわけだから
それはやっぱり素晴らしいですよね
めちゃくちゃ良い態度だと思ってて
まさしくそうだなと思って
私の場合はあれですね
PHPについては流れというか
成り行きで中身を追いかけたりとか
開発したコミュニティの議論を追いかけるようになったので
損しない時間の使い方
活用方法ってなったら
PCPについての話題
PCPをいじる方向に通した方が良いので
ただそれだけの理由で
PCPで嫌だなと思うところとか
ここもうちょっとどうにかなったらいいなみたいなところを見つけ次第
メモつけていって
メモつけていったやつの中で
気分が今回盛り上がったので
やれそうなやつを取り出したって感じですね
短めな時間でやれそうなやつを
ちなみに今持っててこれ次
ネタ調みたいなの聞いてもいいんですかね
ちょっと興味が
やりやすいところはトレートいじるのがやりやすい
そうなんだ
PHPの機能についての不満と改善案
トレート足りないところがいくつかまだあるので
ここはいじりやすいですね
コミュニティでの議論が通れば
っていうところはあるんですけど
明らかに足りてない機能の一つなので
よく欲しいなと思うのは
配列とか文字列のスライス簡単に取るやつが欲しいですね
なるほど
今はPCPでスライス取ろうとすると
コピー作ることになってしまうので
効率もあんまり良くないので
インプレスでスライス取れるような仕組みが作れると
公文的な
記法的な面でも書きやすくなるし
パフォーマンス的な面でも有利になるので
そういうのはちょっと欲しいなと思ってますね
両立できるのはいいですね
パフォーマンスと書き心地が
これは多分突っ込まれるところで
書き心地を良くするっていう話と
パフォーマンス上げるっていう話は独立してる話
なので本来は
普通にそういうライブラリー関係を提供しても良いんじゃない
っていう話も無くはないですよね
そこは話の進め方とか実際やってみてどうなるか
ってところではあるんですけど
そういうのよく見ますよね
これでできるじゃんみたいなのよく見ますよね
僕そういう意味で言うと
PHPをいじってて不満を持った時に
なるほどPHPではこうなんだって納得しちゃうんですよ
だから不満に
今まであんまり思ってなかったなと思って
インターナルのメールとか一周を読むと
なるほどこういったところがポイントなんだみたいなのがあるんで
そこはメモしてったりはしてるけど
まだまだ全然
すげー不満っていう感じはないな
中の人が
この間もアレイマージの効率を良くするみたいな話を一周で
あげてられたりとかして
そういうの面白そうって思ったりはするけど
そこに自分で気づけるかってなると
なかなかどうして気づかないなみたいな
がありますね
ゲームアプリケーションって結構
PHPがやるべきことではないとは思うんですけど
ものすごい極端な使い方をすることが多いので
ボトルネックが見つけやすいのはあるかなっていうのはありますね
APMとかで軽く見るだけで
絶対ここが足引っ張ってんじゃんみたいなのが見えてきたりするんで
どうしても日常的にあれですもんね
性能検索やりますもんね
常に性能を見つつとか不可試験とか
ベンチマークとかめちゃくちゃやるんで
やっぱ気になっちゃう
やりつつもなんでPHPなんだろうっていうのはちょっと思ったりはしてます
私PHP大好きです
私PHP大好きなんですけど
私は本当にPHPが一番好きな言語なんですけど
PHPの運用性と可能性
結構ウェブ向けの言語だから
使い方としてはなかなか
なんて言えばいいんだろう
エッジが効いているというか
だなって思うことが多いですね
よくあるシーンとはちょっと違う使い方になりますよね
そうですね
WordpressとかCMS動かす用とかそういうのとはちょっと
やっぱ経路が違ってくるのかなっていう気がしますね
僕らもゲームではないけど
ウェブ系の仕事をしてると
だんだん物がでっかくなってくると
UX改善するんだったらフロントエンド分離しましょうよ
だんだんフレームワーク使ってるけど
ほぼAPIサーバーみたいになってくると
そうすると
PHPである必要あるのかみたいな
こういう疑問が開発者たちから
もこもこ出てきたり
するところはありますよね
そこはアーキテクチャの決断として
バランスは見なきゃいけないところですし
PHPはとにかく情報はたくさん
ウェブ上に転がっていて
なんとなく頑張れば誰でも読めて
なんとなく書けて修正できるみたいなところが
めちゃくちゃ強みではあると思うんで
どうやってでもゴーに書き直すべきかとか
そういったところはちょっと考えなきゃいけないな
みたいなポイントであります
だいたいPHP使い始めるのには
大した理由いらないんだけど
大した理由なくて使い始めるケースが多いと思うんですけど
そうするとそれ使い続けるにも
多分あんまり大した理由じゃなくてですね
PHPでもできるからPCでいいかって
なんかあとあれですね
PHPって結構実行形態が
かなり安全に寄せてあるのが結構ポイントなのかなって思ってて
リクエスト単位で
完全にVMというか
PHPの実行環境
ランタイムが捨てられるっていうのが
結構扱いやすいかなって思ってて
Goとかで下手に書くと
余裕でリソースリークとか起こすし
ノードとかも結構便利なんですけど
その分リソースのことちゃんと考えなきゃいけないとかがあるんで
その点なんかPHPってちょっとやんちゃなことしても
許されるとかっていうところもあるので
運用しやすい言語だとは思いますねすごく
このやり方にしては青年もまあまあ出れるんですよね
そうそうそうそれですよね
そうなんですよ
だからこそイスコンとかに勝つのは
難しかったりするんですよね
イスコンについてはなんか私
あれで勝てない気あまりしてないんですよ
僕が今持ってる知識群だとちょっとまだまだ
足りてないなってところがあって
そのPHPの本領まで発揮させられてないなっていうのがあるんで
そういったところまで目が向くようになれば
普通にいけるかなと思いますね
1位は結構厳しいんじゃないかと思うんですけども
本選に行きますぐらいは多分
これやれる人はやれるだろうなって感じがしてですね
だいたいGOとかでやってるような
パフォーマンスチューニングと同じことを
他の言語の上位入選者の人がやってるのと同じこと
PHPでもできる
全く無理なくできるというものはほとんどなので
PHPのパフォーマンスと課題
ほとんどクエリとかインフラ的な回線とかばっかりなので
この間私がイスコンで本選に進まなかったら
単なる実力不足ですね
言語のせいではない
そうですね
うちのチームとかもやっぱり正しいことはやっていて
プロセスは正しく回せていて
ただスピードが足りなかった
手を動かすっていう意味でのスピードが足りてなかったみたいなところがあるんで
そういったところが改善できるとPHPでも本選出場ぐらいは
いけそうだなという感じがあります
ただ確かに本当にトップは厳しそうだなって
Goでhttpサーバーとか書くとすごい思います
なんかもう根元が違うなみたいな感じが
してきちゃうんで
やっぱりあれなんですよね
PHPでパフォーマンスだと思うと
思わずとどういう風にそれが動いてるのか
軽く考えなきゃいけなくなる時が来るんで
あんま考えなくても思った通り動いてくれるとかの方が
2本目だ
やりやすいんだろうなとか
今井原さんが目の前で
もう今夜11時41分に
コーラを飲み始めたという
2本目のコーラを開け始めたっていうつこみが思わず
映像が見えてる
ちょっとびっくりしてしまった
衝撃的
お母さんに怒られますよ
こんな夜中に
なんで
歯溶けるよって言われます
なるほど
YouTubeで本当は溶けないとか
そういう動画も見たことあるから
ずっとつけたら溶けるかもしれないですけど
飲むくらいの時間なら大丈夫ですよ
そうですね
データベース接続とトランザクション
胃の方が横の強い
何の話をしてるんですか
APS-Cの高速化していくってなると
どうしてもどう動いてるかを
考えなきゃいけないっていう
ガベコレと似てますよね
ガベコレある言語もちゃんとガベコレのことを
ガベコレ無視してガリガリ書くと
めっちゃ足引っ張られますみたいな
PHPもガベコレあるんですけどね
変な言い方ですけど
PHPで
動いてないと
ガベコレが必要にならない
モードPHPとかでワンリクエストで消えちゃうと
特にガベコレとかは必要なく
3章カウントで普段は
GCのタイミングは3章が全部外れたタイミングで
すぐ消えるんだけども
熟患3章が発生してる場合に関しては
マーク&スイプ的なガベコレを動かさないと
除去できないので
熟患3章がたくさん溜まるような形で実行される
スイプとデーだけ影響するって感じですね
ですよね
PHPもCLIで
ずっとホイールで
ぐるぐる回ってるみたいなアプリ
そういう構造でキューニング処理するとかも
あると思うんですけど
そうなってくると気になったりするやつですね
そういうことやらないと気にならない
ってことですよね
そこがアーキテクチャの勝利だと思うんですよね
最近の常時実行型で高速化を図るアプローチってのは
そこが天秤にかけなきゃいけないところだと思うので
なかなかっていうのがありますね
ちなみに
最近見た今の話題に関連する話で
超面白かったことがあってですね
超面白かったのが
リクエストごとに環境状態を破棄するって話を
今してるところですけども
我々この負荷的なものを
ある程度気にする人たちの中では
状態はリクエスト関連持ち越したい
処理したいという言葉が時々あってですね
例えばですね
例えばなんですけども
データベースの接続とかですね
データベースの接続とかはですね
リクエストごとに切断して
また再接続してやってるとですね
どうしてもデータベースの方で
接続しに行くコスト自体もかかりますし
ソケットの利用状況的にも結構
重んでってしまうので
タイミングウェイト的なツールで重んでってしまうので
なんでリクエスト間で接続状態を
持ち越そうっていうですね
パーシステント持続的接続的のが一応あってですね
PHPさんに
これ使うとですね
PDOのパーシステントコネクションを使うと
そうするとリクエストが終わってもですね
同じプロセスがですね
同じデータベース接続を破棄しないで
そのまま使い続ける
敵のリクエストも使い続けるっていう
PDOのパーシステントコネクション
PDOを入手したら同じデータベース接続が内部的に使われるっていうですね
そういう面白いものがあるんですよ
ここでですね重要なのがですね
トランザクションがどうなるかというとですね
トランザクションはですね
このPDOのインスタンスがデストラクトされるときにですね
デストラクターでですね
トランザクション中の場合は
ロールバックするっていう
自動でロールバックするっていう
PDOの頃に入ってるんですよ
これ非常に重要な点なんですけども
パーシステントが有効だと
PDOのインスタンスが
複数回入手されても
同じインスタンスが使われると
でそのPDOがデストラクトされるときに
データベースロールバックされる
これ合わせるとですね
仮にですね仮にですね
ある処理のためにですね
連続的な処理
例えばテストかもしれないですし
急実行かもしれないですけども
連続的に何か処理していく
いろんな仕事を処理していくようなですね
PCPプロセスが至るきにですね
一方PDOを入手するじゃないですか
パーシステントを有効で入手するじゃないですか
ある処理のために
でこれがもしもこのPDOのインスタンスが
乗ってきならない事情によって
循環参照によってですね
PDOが即座に
インスタンスが破棄されない頃になったとします
循環参照なので
声が実際にデストラクトされるのは
循環参照GCが走ったときです
でこの状態で
PDOとデータベース接続の注意点
PDOのインスタンスがふわっと注意に浮いたままで
次の別の作業に進みます
次の別の作業に進んで
なんか
やっぱりそこでPDO入手してですね
同じデータベース接続が使い回されてですね
その仕事をやっている最中に
循環参照GCの発動条件が
突然乱されたとします
そうするとですね
全然よく分かんないタイミングでですね
急にですね
データベース接続がですね
ロールバックしかけたですね
トランザクションの
これは仮の話ですか
みたいなことがですね
普通に起こり得るというところでですね
やっぱりリクエスト関連の状態を持ち越さないと
リクエストの状態の持ち越しの難しさ
いろいろ話が単純になるんだけども
持ち越さなければならないという話になると
急になんかいろんなままなが押し寄せてくる
そうですね
そうですね
本当に
ステイトレスのありがたみを
こうね
知るというか
俺これ何が起きてるのか分かった時に
バカじゃねえのって思いましたもんね
マジで意味分かんないですよ
お客さんに言われる
どんなこともあり得るんで
ちょうど霧のいいところでですよ
車輪と車輪の合間のところでですよ
GCOですよ
GCOを始動で実行するようにしたらですよ
急に変なところでロールバックされてたら
亡くなるっていうですね
不可解なロールバックが消えて解決するっていうですね
なんだこれ
このコメント消すとバグるみたいな
完全にそういう世界ですよね
直列実行されてるから
急になんかこの接続が使われる可能性
いや待てよって
GCO
変なところで
インタープレッチャーさんがGCOを読んでる
そいつのせいでロールバックが走ってるみたいな
そうですねだからもう
リクエスト持ち越しは多分夢でもあり
禁断のあれですね
扉かなともすごくありますね
パンドラの箱のような存在
ゲームとかのデータとかだと
そういうのが多分多いと思うので
そういう使い方をする
したいっていう人が結構いて
それこそ最近だと
タイソンアンドレさんのコミッターの一人かな
あれコミッターですよね
APCUをフォークして
リクエストを持ち越しで
シリアライズなしで
値を保持しておける
メモリ内データのコピーとキャッシュの最適化
イミュータブルキャッシュっていう拡張を
作ってらっしゃるんですけど
まさにそういった思想のもとに
作られているので
PTOみたいに
いろいろ外とのコネクションを持つものじゃないので
まだ安全だとは思うんですけど
パフォーマンスをカリカリにしたくなっていくと
やっぱそういう世界が
見えてくるという
感じかなという気がしますね
ただなんか
ガベコレの副作用
怖いですよね
ノードで
ノードを書いているときに
私もガベコレに
いろいろと悩まされたときがあったんで
いやー
マスターデータを取ってくるときとか
あの
マスターデータを取ってくるときとか
マスターデータを取ってくるときとか
外のストレージにアクセスしたくないんですよね
うん
うん
決まりきった値を
メモリにずっと入れときたいという
パターンが多いんですよね
どうしてもちょっと
レイテンシーが気になってしまうので
うん
その辺も割と
ちゃんと計測して
やってみて
で、あ、思ったほど
効果が出ないとかっていうのが
分からないと
今さっき
工藤さんがおっしゃってたみたいな
リクエストを持ち越して
すぐに取り出す
PHPのオブジェクトが欲しい
みたいな話って
ピンとこないなみたいなところって
ありますよね
僕も結構最近ですね
APCU使って
キャッシュしてて
最初は早いなと思ってたんですけど
あれ?みたいな
オブジェクトになってくると
PHPに戻すときの処理の
やっぱコストが
バカにならんもんだなと思って
これ最高じゃんみたいな
レディスなんかアホみたいなことを
最初は思ってたけど
いやそんなことないぞ
もっといけるぞPHPはみたいな気持ちになってくるんで
そこもトライアンドエラー
やってみないと
やってみないことには出てこない要望ってあるんだな
みたいなところが感じますね
メモリの中でのデータコピーは
遅いと思うかどうかみたいなのありますよね
あー確かに
うーん
そうか
僕でも
最初思ったのは
メムキャッシュDがすごい流行ったときがあって
データベースの
接続が遅いよねって
メムキャッシュDに
例えばユーザーの
情報とかをキャッシュしておいて
セッションから取得したIDから
複合するみたいな
世界線があったと思うんですけど
最近もう全然そんなの
レディスもネットワーク接続じゃん
みたいなそういう頭が
持てるようになってくると
いいですよね
レディスに取りに行っても
YSQLに取りに行っても
あんま速度実は変わんないんじゃないか
みたいな視点が持てるようになってくると
プログラミングが面白くなってくる
それの場合あれですね
バトルネックがQA実行なのか
0.1なのか
そうですよね
レディスが結構昔
メムキャッシュド前世紀に比べて
進化した感じは個人的にあるなと思ってて
今結構
当時は結構
まだメムキャッシュDに比べると
ちょっと遅いけどみたいなポジションだった
気がしているんですけど
今はもうメムキャッシュDあんま使う意味ないじゃん
みたいなところまで来てるかなってのがあって
PHP 8.2 リリースに関する話題
やるとしたら
YSQLが
ラムで
レディスが
メモリで
APCUが
一時キャッシュ
みたいな
そんなのになってきてるんですよね
個人的には
すごい
なるほど
ただもっと早いものは欲しくなってくるんで
いやー
すげーわからないかと
探し続けてます
なんでこの間のゼリウスさんのツイートに
すごい興味派進んで
一体この人は何に不満があって
こういう発言をしてるんだろうな
気になります
あれなんですよね
さっきおっしゃってたように
シリアライズとデシリアライズのコスト
特にデシリアライズのコストが結構えぐくて
そこを何とかしたい気持ちがやっぱ強かったって感じですね
結局
参照を持てるオブジェクトって
やっぱり
やっぱり
やっぱり
結局参照を持てるオブジェクトって
ドアが開いてもシリアライズしなきゃいけないんで
やるとしても
構造体というか
固定帳のデータを持ってるものを
入れとくぐらいしかできないとは思うんですけど
アクセス時に
デシリアライズするとか
遅延解決みたいな方法しかないとは思うんですけどね
そういえばJSON
JSON
デシリアライザブルみたいなのって
あれ
いらないんですかね
JSON
JSON
JSONシリアライザブル
シリアライザブルだと
あれじゃないですか
そっちはあるじゃないですか
オブジェクトは
JSONエンコードしたら
こうなりますよって表現をして
できるやつあるじゃないですか
JSONのオブジェクトを
JSONデコードって
やった時に
SADクラスになるじゃないですか
どうやっても
SADクラスだと何も嬉しくないじゃないですか
そうですね
何も嬉しくない
何も嬉しくないから
結局ユーザーランドで
改めて
バリのようなやつとか
ハイドレーターみたいなのを使って
また
PHPの
ユーザー定義型のクラスの方に
マップするみたいな
過程を踏むことが多いと
思うんですけれども
それどうしてもコストになるじゃないですか
そうですね
通信データで
飛んでくるJSONデータを
PHPのシリアライズも
PHPシリアライズとか
PHPデジタルライズだったら
PHPの方に
復元できるんですけども
JavascriptからPHPシリアライズ形式で
送ってくれって言いづらいじゃないですか
言いづらいというか
というかもう
あれはなんかそもそも
互換性が崩れてるんで
危ないですね
内部表現として送ってくるっていうのも
ダーンみたいな感じになるので
やっぱそこはJSONから
JSONデジタルライズを
やはり
コアの側で
きちんと実装するべきではないか
JSONデジタルライズ
確かに
どうなんでしょうね
個人的にそこの用途だと
プロトコルバッファーとか
そういうJSONから離れた形式を
取るのがいいのかな
と思ってたりもするんですけど
確かにJSONで戻せたら
気軽にできていいですね
それは確かに
別にプロトコルバッファーでもいいんですけどね
いいんですけどね
うん
標準で組み込むっていうのは
絶対ありえない世界なんでプロトコルバッファーを
だからJSONでもできるよっていうのは
普通にありだな
っていう気がしますね
あと全く関係ない
どうでもいい話なんですけど
PHPの
GRPCの拡張がでかすぎて
コンパイルに死ぬほど時間かかって
すごい辛いっていう
そんなの
あのね
本当に辛い
PECLで入れると
特に
コンパイルが
どっかはPHPに
コンパイルがね
マルチヘルトでできないっていう問題があって
PECLインストールだと
地獄みたいな時間がかかる
PECLどうにかしてほしいですけどね
PHPってまだ
あれですよねGRPCの
クライアントにはなれるけど
サーバーってあるんですかね
安定した実装とか
サーバーはないですね
どうしても
実行形態的に無理なので
でもあれか
実行形態から
揺るがす系のものだったらありますね
それこそロードランナーとか
そうですね
JSONデシリアライズに関する話題
普通のPHPでってのは
ちょっと無理ですね
JSONデシリアライザブルの方が
ペチパーには確実に受けそうな
GRPCに関する話題
気がしますね
人気がありそうな
ララベルとかそういうのを
めっちゃそういうのを
望んでそうな気がしますね
そういうのがあるとめちゃくちゃ嬉しい
があるんじゃないかなって気がします
ララベルさんどうでしょうね
既存の
ララベルさん仕組みがあるっちゃあるからな
リクエストレスポンスオブジェクトが
そうか
確かにもうあるって言われたら
それはそうかな
オブジェクトという既存の路線とは
あまり乗っからない気がします
イルミネートの
シンプルに
APIを作りたいって
需要は満たせそうですよね
だから
どっちかというとララベルというよりかは
普通にプレーン
PHPでサーバーやりたいです
のが需要あるのかな
に近い構成の方が役立ちそうな
気がしますけどね
ララベルって使えないことはないですよね
使えないことはないですよね
ルーティングから
ルーティングから
コントロールアクション起動するまでの
流れに手を入れて
ララベルでの開発について
RPCっぽく使えるようにする
みたいなところまで整備
するんだったらララベルでもいいけど
ララベルやる人がそんなにそういうことやるかというと
あまりやんない気がしますね
やんなそうですよね
そこまでするかっていう感じはありますよね
リクエスト
リクエストオブジェクト使ったらバリレートってやりますし
みたいな感じになる気がしますね
そうですね
そうそう
十分便利ではありますからねあれでも
あとたぶん
そんなパフォーマンスを誰も求めてないかもしれない
使う人
それもそうかもしれない
パフォーマンス的観点だとそうかもしれない
そうそう
とりあえずララベル使って
なんかこう
金になる事業をとりあえず立ち上げるみたいな
ことを
そこはまずは
求められていない
そこが
求められるような分解になったら
金がいくらでもあるので
いろんなことが
ララベルはなんかでも
ほんと
すごい
いいポイントついてるんだなっていうのは
思いますね
バランスがいいというか
PHPってもともとこういうもんだよね
みたいなそんなノリを感じなくもないですね
まあ
どっちかというとPHPっていうかもともとはレイルズの
世界の
観点なのかもしれないですけど
やっつけで作るのにはいい
ものなんですよね
うーん
そうですね
やっつけで作らないといけないというか
やっつけでどんどん作っていくべきという
仕事はまあまああるんです
助かりますやっつけの時は
結構すごい追い詰められてる
助かります
あのいつだったか
ラベルのその日本
日本まあ公式だったっけ
公式じゃなかった気がするんですけど
なんか仕事を終わらせて帰りたい人のための
フレームワークって誰かが
おっしゃってた気がしてて
確かにその通りって今になって思いますね
あの
そうなんですよね
だからこそ
集中できるっていう意味がすごく
ラベルに軽量DDDとかを
言えようとする動きは僕はあんまり
賛同できないというか
なんかこうそれってこう
なんか
意図と反してないかい
っていう風にちょっと思ったりする
いや別に個人的にはなんか
いいと思うんですよそれはそれでも
DDD駆動開発について
それはそれでもいいと思うんだけどもそもそもで
言うと軽量DDDってなんだよとかですね
あーまあそうですねそうそうそもそも
そもそもで言うと
ドメインで駆動しないドメイン駆動開発
ってなんだよみたいな
なんかこう形駆動開発
みたいになっちゃうんで
一体そもそも何を求めて
それをやろうとしたんだいみたいなところは
すごいあるんで
この話はですねあまり言うと治安が悪くなって
しまうんで僕も
あんまりしたくない
そうですねちょっとなんかこうなかなかこう
危ない話題になってくる
危ない話題になってくるんで
何かが思い出したい
ツイッター上でなんか
俺の大好きな中江さんが
DDD駆動開発
って言ってたのがすごい好きで
DDDDだって
そうそうそうそう
いやでも
本当になんか世の中って
でも結構そんな感じなこと
多いですね
何かそのね
なんかこう
最適な選択肢と言うよりかは
まずそれあっての
なんかっていうのは結構あるかなっていう気がしますね
笑
笑
まあ100歩譲ってそれでもいいとして
100歩譲ってそれでもいいとして
なんでエロウケントはリポジトリ
でラップするんだよみたいなですね
笑
それはもう本当に思います
簡単に臭いものに蓋を
放していいじゃないかっていうですね
いやーちょっとね
これなんか言いづらそうな顔してる
JSONデシリアライザブルについて
その話題よくない?
コイント知らそうな顔してる人がいる
いやでも個人的には
個人的にはね
いいと思うんですよ
というのもエロウケント本当にやばいんで
ラップしといた方がとりあえず安全だとは思う
笑
笑
後から困ると思うので
それはいいと思うんですね
確かにやってることは不毛なんだけど
困るよりはいいじゃんっていう気がする
笑
いやー
やっぱりやめよう
笑
なんでもないです
やめましょうかこの話題
この話題はちょっとやめましょうか
だいぶ気合の悪い話になりましたね
すいませんでした
笑
今一個
チャットでリンクを送ったんですけど
さっきJSON
デシリアライザブルの話が
あったと思うんですけど
なんかちょっと前にインターナルで
あれをキャストして
できるようにするといいじゃんみたいな話が
ありましたね似たような話かもしれないですけど
なんかセットステートを使って
オブジェクトでキャストできるようにする
なんかこれに近しいこと
ララベルもできた
気がする結構もうユーザーランドで
やってるのがある気がしますね
なんかこう
配列ベースでやるみたいなのは
ただ確かに
なんか欲しい
気持ちはやっぱりさっきのJSON
デシリアライザブルも
なるほどっていうところあったし
この議論最初見た時は
なんか
みんなまた詰めたくあしらうのかな
と思ってちょっと怖かったんですけどね
気持ちはめちゃめちゃ分かりますよね
配列もそうだしJSONもそうだけど
DTOみたいなやつに
PHP配列の内部表現と最適化に関する議論
やっぱ詰め替えしたくて
そのためにあんまりコードは書きたくない
っていうこの全員の
共通の意識がこういうところに
出てくるんだなと思って面白いですよね
なんなら
PHPの配列って
万能すぎるんで
上手く片付けられたらもう配列のままでいいじゃん
っていう気がちょっとしなくもないんですよね
それは不毛なんで
だからなんか
それはさすがにやらないんですけど
PHPの配列も万能じゃん
と思う時は結構あって
これに識別しつけられたら
それで結構十分な場面多いよね
そういうことはあるな
実際割と配列で
どうにかなるんですよ
静的解析の時
割と配列でいけることは
いけるんですよ
リスト型のRFCで出てましたっけ
リスト型のRFCは
RFCまで
行ったんだったかな
行ってないな
話はしてましたよね
RFCに出したらいいじゃんとか
そういうとこ狙い目が
なかなかこれ
納得できる形でRFCにまとめるのは
難しいところはあるかもしれない
ただ今の暗黙の状態は絶対
良くないですね
突然でかい純粋な配列に
キー文字列で
ぶち込まれると大変なことになるので
あれは本当によろしくない気はしてますね
あれをなんとか
禁止する
アレイの方が
方法があるといいなと
僕の知らないところでやられると困っちゃうんで
あともう一個
あともう一個思うのが
そろそろアレイ括弧とリスト括弧を
廃止しようぜっていう気持ちがね
ワードプレスの人が
怒りますよそんなことしたら
ワードプレスの人に
怒られますけど
アレイの方が分かりやすいよねっていう
なるほど
初めて見たときはそんなバカな
思い出をしたけどね
突然混ざるよりは
いいっていうのがあるのかもしれないですね
本気でそれ言ってる人は多分あんまいない
気はするんだけどな
いやどうだろう
わかんないいるかもしれない
なんかでもすごいあれと
リストと配列が
別物で内部としてはあって
まずアレイ括弧とリスト括弧っていう
表記があるのはすごいややこしいと思ってて
あれ
ちょっとなんか
なんとかならないのかなっていう気はしてますね
あと変換しないで
あれ確かPCP8.2から
あれですよね
配列内部的に
本物の配列になる場合に
前は各要素に
ハッシュテーブル
になっていたときの
普通の配列とも
ハッシュテーブルだったときの名残で
余計なデータ
パックされるようになってたんですけど
8.2から完全に
Zバルだけの
Zバルの配列本物の配列になります
なんで配列の
データサイズが半分くらいになるはずです
それめちゃくちゃいいですね
純粋な配列である限りの
メリットがどんどん増えていくので
7のときも確か
7のときからでしたけど
純粋配列が内部的に別物になった
あれっていう言葉と
リストっていう言葉が
確かにあんまり良くないですよね
あれが配列を表現できるから
生字リストが
純粋リストを表現するためのものなのかな
っていう気がして
勘違いされる方が
周りに何人かいて
それはタプル展開です
みたいな話がちょっとね
8.1で入ったじゃないですか
アレンジリストっていう
初めて見たときに
これは
私にはわかるが
これは外から来た人にはマジでわかんない
配列は配列みたいな
なんだこの関数は
確かに英語的に読むと
やばいですね
PHPをやってる人だから
これが解読できるんですけど
意味的に
よくわからない
PCPの配列についての説明は
他の言語から
PCPに来ましたっていう人に
必ず説明してる気がしますね
配列っていうか
マップなんですよね
全てが
全てって言ったら今語弊はあるんだよな
難しい
来る人来る人に
あたり方のセマンティックスを持ち
意味的には全部コピーなんだけれども
コピーオンライトによって
実際のコピーは
書き込み時に遅延され
かつ内容としては
配列とは言ってるんだけども
順序付きハッシュテーブルなので
放位置で入れた順に取り出せる
かつ辞書として
引くときには辞書のスピードが出る
んだけれども
実際には
本当に数値スイッチの連番の
配列の場合は
いわゆる配列と内部的に同じ構造を取るという
最適化も入ってます
毎回してるんです
そこの説明
そこまでうまくまとめられるのすごいですね
私すごい毎回困ってるんですよ
特にJava書いてたとかっていう人に
どう説明すればいいんだ
みたいなのが結構あって
僕まさにJavaからPHP入ったんで
めちゃくちゃ
めちゃくちゃ困りましたね
これ何ですかって思って
これ何だろうと思って
これJavaで言うハッシュマップかな
アレイリストかな
これ何なんだろうと思って
特徴的に
PHP 8.2でのアップデートと配列の新しい表現
最適化できるし
特に8.2からの
内部表現の変更が
さらに差を生むんで
そろそろもう別物として
扱えるようにしてもいいんじゃねっていう議論が
オペキャ集に関する技術的な話
再現してもいい頃かもしれない
難しいところですね
同じであることによる
不利益って何だって
話になる
せいぜい変換だけど
変換なんて起きるような使い方すんなよが
それが正論でもあるから
難しいところです
そこまでこだわるんだったら
数値解析で普通に区別できますかって
言われると
そうですねってなるし
言われそう
絶対インターナルで言われそう
可能な操作が異なるわけではないので
可能な操作が異なるわけではないので
振る舞いが違うわけじゃないですかね
なので型が違うかと言われると
同じでもいいから見たら気持ちもなるっていう
難しい
難しいですね
これすごいなリアルワールド
プログラムですね
なんかそれで言うと
静的解析が最近
すごい
盛り上がってるって言ったらあれですけども
相当前から来てるとは思うんですけど
発達していくことで
逆に今実行時型検査が
足枷になっているっていうのをちょっと感じたりもしてますね
死ぬほど呼ばれる
クロージャーとかに
片付けない方がいいよっていうとか
なるほど
毎回検査走っちゃうから
微妙ですねそれ
微妙ですね
なんで微妙かというとですね
なるほど
オプキャ集の最適化で
型情報を見るので
微妙なんですよ
なるほど
計測との間になんとも言えないです
確かに
私のパターンだけだと
ちょっと重くなってたんですけど
確かにそうだ
オペキャ集が
参考にできる情報でもあるので
一概になくすべきではないのはそう
結構隠蔽されるケースがあるんですよ
最適化の分で
結果的に
例えばですね
引数は全部外した方がいいけど
回率の型は付けた方が
微妙に早いみたいなのがあり得るんですよね
サイクルベンチマークレベルで
微妙な話題ですね
すごいトリッキーな
でもそれでいうと
参考になるどこだけ使うみたいな
私あんまり詳しくないですけど
HACKは確か実行時は
保証しないっていうスタンスで
言ってるんでしたっけ
どうなんでしょうね
実行時はいらないと思いますけどね
実行時型検査は
型を保証しないけど付けておけるみたいな
ノリで
最適化には使えるとかじゃなかったですかね
あんまり追ってないのであれなんですけど
性的に検査される限定が取れると
確かに最適化のことを
ちゃんと考えると
オペキャ集が
PHPの性質に関する話
オペキャ集も常に有効でよくないかと思ったりもしますけど
なんとも言えない気持ちですね
なんで分かれてるんだろう
デバッグが大変かも
コアのデバッグが大変なの
時々オペキャ集を有効にしてるときで
小キャラみたいな気があったりするので
なんとも言えないところですね
それはありますね
マイナリリリース
済んだばっかりの時とかですね
そうそうそうそう
よくある
私一回オペキャ集というか
ジットですけど
ジット有効にしたらスイッチのケース吹っ飛ばされてびっくりしました
ってこともあるでしょうね
最適化って
確かにやりすぎは良くないというか
選択的であった方が
いいのはそうかもしれないですね
ただ分かりづらいと思うんだよな
ロードランナーとか
あるじゃないですか
ロードランナーは
完全に各ワーカーが独立した
CLIプロセスをエグゼキュートされるやつなので
オペキャ集が共有されないんですよね
そうかCLIで走ってるんだ
別プロセスとして走ってるんで
あれの場合は
与法道CPUバウンドのアプリケーションを動かすとき以外は
オペキャ集を切った方がメモリー効率が良くなるんですよね
イネーブルCLIの意味が
そうですね
CCP的に思いやすい
の場合だけ
そういうのをロードランナーで動かすときだけ
オペキャ集がいるけど
それ以外のときだったら切った方が効率良いっていう
難しい状態なんですよね
すごい
PHPの気持ちが分からないと
色んな最適化ができない
というこの世界は面白いですね
エクストリームPHPの世界かもしれない
最適化に関する話
そうですね
それぞれのプロセスが
オペキャ集をシェアをメモリー持っているから
っていうところまで考えて
でもさっきの
引数の型は外すけど
戻り値
返り値があった方が早いとか
めちゃめちゃ面白い
この間ちょっと自分で作っていったベンチマークで
そういうのがあってびっくりしたんですよ
前からベンチマークで
これひょっとして
微妙に
こっちは検査した方がいいけど
こっちは型確定に必要だから
残した方がやっぱりちょっと早くなるみたいな
すごいもう気持ちを分かって行動を変えていくやつですね
僕はもう型を外す方向でやっちゃったんです
前なんか数読ソルバー
すごいマイクロベンチで
早くするっていうのをずっとずっとトライしてて
最終的に型を全部なくすと早い
やったーって思ってたけど
今の実装
実は一部残した方が早くなったりもするのかな
俺はなんか
ファミコイメディターの最適化をするときに
基本的に外した方が早いなと思ってたんですけど
何度か推進したら
型付けてても全然
PHP 8.2に関する専門的な話
オフキャッシュ有効にするだけで
隠蔽されるぞみたいな
検査コストで隠蔽されるぞみたいなところが
出てきたりして
ここは外した方が効果が出るけど
ここは外さなくても見れん
そんなバカな
あれですね
受け入れるところはやっぱり
ないほうがいいけど
出すところは狭まるんで
あったほうがいいっていうのは概念的にはちょっとわかるかもしれない
なるほど
感覚的に言えば
ここは読んだらもっと確実だと思うんですけど
いがらしさん的に
そっちのアプローチだと思うんですけど
感覚だけで言うと
オフキャッシュのコード読むと
気持ちがわかる
なんなんじゃないですか
オフキャッシュのコードは読めない
読めないです
オフキャッシュのコードは読めないし
JITのコードはもっと読めない
最近プルリクエとか
ダイヤスムは意味がわからない
バグ修正のコミット見ても
何やってるのか全くわかんない
DSLっていうか
言語内の
言語って感じなので
多分時間
腰すいて見ないと多分覚えられないですね
多分あれ読むの
本当に
プロセッサの
命令の仕様とか読まないと
わからんレベルなんで
そこまでやる気はちょっとない
プロセッサの命令の仕様
だけ
ダイヤスムは多分わかんないです
あれは完全にダイヤスムのこと
わかんないとわかんない
しかもダイヤスムって
公式なドキュメントないんですよ
あれ
ドミトリーさんは
あれに賭けるって感じで
時間使うぞって感じで
腰すいてやるぞって思ってやってるから
いいけど
ちょっと見てみようかなレベルの人が
あれに時間
ぶっこむっていう判断はなかなかやりづらい
あれは
逆に言うと最初に
PHP 8.0でJITがリリースされたときの
これからのPHPの
回とかでもおっしゃられたと思うんですけど
JITこれ使ったらやばくねっていう
単一障害点になりかねないよね
PHPファウンデーションでの取り組み
確かにそうあると思ってて
ニキータさんもちょっといじってましたけど
本当に今
ドミトリーさんいないと
あの機能ないじゃないんで
ちょっと怖いなってところはありますね
最近やっぱりそれは
多分あの人たちも問題視してるので
アーノルドさんでしたっけ
アルノさんだかアーノルドさんだか
わかんないですけど
割とJITの方にコメント入れてるシーン
いじってるシーンありますよね
なるほど
多分あれ
PHPファウンデーションの方で
割と課題として
考えて取り組んでるのかなと思ってみてましたけど
ですよね
だってあれはなかなか
お金ちゃんと
対価払わないと
なかなかできることではない
PHPで仕事としてやっちゃうっていう
プロセッサベンダーの協力によるJIT機能の問題点
気持ちのある人しか手出せないですよ
だから
手出せないですね
インテルとかアームダバーの人とかも
JIT
そう
あの辺の人たちが専門家として
仕事で取り組むのはわかる
グラビドンとかの
IWSの人とかが
JITアーム対応するとか
頑張ったりとか
インテルの人がやったりとか
要はコンパイラ作るようなもんだから
プロセッサーベンダーの
協力がないときついっていう
なるほど
なんか
すごいですよね
いや読めねえなって思ったんですよ
何やってんだろうなこれ
JITの前にオプション最適化
キーの段階でもたぶん
あれはコンパイラの最適化の勉強した人じゃないと
わかんない
そうですね
計算のやつ
やらないと無理ですね
わかんない
読めねえなのレベルがJITの
読めねえなは読めるようになる
何をやってるかすら
わかんないんですよね
何か
オペキャッシュの方はまだ
何かに代入して何をしてるとか
まだわかるんですよ
それが何を意味するか
まあわかんないけど
ダイアゾブ書かれてる部分に関しては
何がしたいのか
何をしてるのかすらわからない
そう
引っかかりがないんですよ
何も引っかかんない
何かあの
ラン数を見てるかのような
気持ちになる
そうそう
あれを単体で見ても
きっとわかんないんだと思って
きっとなんか修正が入るから
そのdiffを見たら
何かわかるかもしれない
わかるわけがない
わかるわけがない
やっぱりわかんない
やっぱりわかんない
すいません
遥かに1時間オーバーしてしまったので
そろそろ終了の時に
ありがとうございます
すいません
めちゃめちゃ楽しくて
普段私もめっちゃ楽しくないんで
こんなコアな話ができる人って
あんまりいないんで
私はもう
フォロワーなんで全然いらない
元々その
PHPのチェンジログを
Kiitaで書かれてた時から
すげーなこの人で
追ってた感じだったんで
こんな機会があったのは
すごく嬉しいなと思って
楽しくてずっと喋っちゃう
ありがとうございます
わかりました
会社でも
RFCの話とかしても
あんまり反応ないんで
寂しいなみたいな
だからちょっと
エピソードの締めくくり
今日は楽しかったです
じゃあちょっと待ってくださいね
終了の提携文読みます
今週も放送を聞いただきありがとうございます
番組のフィードバックや要望は
ハッシュタグ横浜のせいもつけてツイートしてください
本日の相手は
いがらしさんとくどうさんでした
ありがとうございました
ありがとうございました
