ユーザースペースで静的に定義したトレースポイント。Linuxには様々なトレーシング技術があり、そのなかの一つという位置付け。USDTはD言語で構造を宣言し、それをdtrace(1)でCヘッダファイルに変換してCプログラムに手動で埋め込む。ツール・スクリプト言語ともにDTrace互換らしい...が、h2oのdtrace単体テストをみるかぎり分岐もそこそこあるため、まったく同じように使えるわけではない。Foundation傘下のプロジェクト。BCCやbpftraceを開発している。SystemTapLinux用のdtrace(1)を提供するプロジェクト。使うためのCヘッダファイルを生成する。このあたりの作業フローはmacOSのdtrace(1)とほぼ同じ。blogUbuntuなどのディストリは、ディストリに同梱されたカーネルを別のバージョンに差し替えることができます。開発者の視点では、たとえばLinuxのBPFを使ったツールを開発しているときはカーネルのバージョンを本番に合わせたほうがよかったりします。あたりにあって、適切なアーキテクチャのものをダウンロード&インストールするだけなんですが、ダウンロードするのがわりと面倒くさいのでスクリプトを書きました。「インターネットの検索サイトが提供するアルゴリズムが、各ユーザーが見たくないような情報を遮断する機能」(フィルター)のせいで、まるで「泡」(バブル)の中に包まれたように、自分が見たい情報しか見えなくなること。Wikipedia/フィルターバブル世界の真の姿をみるためにはフィルターバブルに陥らないようにしなきゃな!と数年前までは思ってたんですが、最近はQoL至上主義に傾いてきて、SNSなどでもミュートをどんどん活用するようになりました。自分と主義主張が異なるという理由でミュートしたりはしません。「この話に付き合うのは大変だけど付き合うことによって世界を少しでも良くできる」と思えれば全然いいんです。ない場合は議論自体まったくの無駄かもしれません。やっても分かり合えない人たちはいるし、そういう人たちを議論によってコントロールすることはできません。そもそも他人の意見を自分がコントロールできると考えることすらおこがましいのかもしれません。自分がコントロールできることにだけ時間を使いたいと思っています。404だしぐぐってもあまり情報はないしどうしたものかと思ってました。fileを探すとよさそう、というところであれこれ探すとありました。いうとこのPackages.gzになんか書いてないですかね?今携帯なんで読めないんですが。読者になる広告を非表示にするもっと読むコメントを書く2019-12-312019年はキャリアの方向性を大きく変えた年だった2019年のまとめです。前半3Qはウェブアプリのバックエンドやフロントエンドを開発し、最終1Qで転職してC言語でHTTPサーバーを開発するという感じに大きく方針を転換した年でした。転職にあたっては「毎日楽しく開発をしたい」「生涯現役のプログラマーでいたい」というのを基本的な軸として今後のことを考えていて、これから中長期的に投資するのはどういうスキルにするべきかなあと考えた結果です。妻)に風邪がうつってしばらく仕事を休む、といった感じで思うように仕事を進められない1年でもありました(これは2018年からそういう状況)。来年はもうちょい丈夫に過ごせるといいなあと願ってやみません。あとはざっくり今年書いたブログ記事を眺めるとgfx.hatenablog.comこのあたりが印象深いです。stream完全にフロントエンドエンジニアって感じですね。いまは打って変わってHTTP/3とかRustの勉強をしています。Rustは会社の新規プロダクトでよく採用されているので、いよいよRustを仕事で使うときが来たかとワクワクしています。https://jsconf.jp/2019/talk/fuji-goroWasmを触り始めるにはまだ少しはやくて、おそらく2020年にはリリースされるであろうSIMDなどがほしいところです。いえ、JSの最適化コンパイラ(スライドではV8のTurboFanにだけ触れていますがほかのJSエンジンでも基本的には同じ傾向なはず)に頼らず安定したパフォーマンスを出せるというのは大きなメリットなので、その方面だと現在の状況でも考慮に値する可能性はあります。ところでスライドでも触れてますが、eBayのバーコードスキャナ事例は大変興味深いです。compilers.「JSはネイティブコード並の速度を出せるが、それはホットパスでJITコンパイラが高度な最適化をできる場合にかぎる」ということです。プロダクションでは最適化コンパイラが必ずしも効果がなく結果が不安定だったと。オプションを使ってベンチマークしてみるとよくわかるということですね。入社しました2019年9月9日からFastlyに入社しています。今後ともよろしくお願いいたします。3年ほどKibelaのサーバーサイドやフロントエンドアプリの開発に関わりました。Journeyで気持ちよく働けたのはたいへんな僥倖でした。ここで改めて感謝いたします。Fastlyは方向性を変えて、ウェブアプリではなくVarnishやH2Oなどのミドルウェアの開発に関わります。Kibelaは自分が数年のあいだ心血を注ぐにふさわしいサービスでしたし、実際のところ大いに開発を楽しみました。今後のキャリアの方向性を考えた結果、かねてから経験してみたいと思っていた低レイヤーなソフトウェア開発をしてみたいと決意しました。クラウド全盛のいまの時代だからこそ、クラウドサービスを提供する側を経験したいということもあります。Fastlyはまさにそういうサービスであり、仕様と実装の双方をもって「インターネットを速くする」ことが価値であるCDNサービスを提供しています。興味関心のある領域で毎日楽しく開発をして、その結果としてインターネットを速くできるのであれば、ソフトウェアエンジニアとしてこれにまさる幸せはありません。この会社で過ごすこれからの時間も楽しみたいと思っています。*1:保育園に通いはじめると頻繁に風邪をひくようになり、ひどいときには1~2週間ごとに子供が体調をくずしてそのたびに一週間ほどまともに仕事をできなくなります。バイト列の配列を1つのシステムコールでまとめて書き込めるやつです。FileHandle#writev())に渡せるようなインターフェイスになってます。moduleで正式に使えるようにしたってだけみたいですけどね*2。world!細かなバイト列の断片を連結せずに一度のシステムコールでwriteできるので、状況によってはかなりの数のシステムコールを減らせる可能性があります。サーバーの実装ではよく使いそうですね。「AssemblyScriptでライブラリコードの高速化をしてみる」という発表をした発表の機会をいただきありがとうございました。会場を提供していただいたメルカリさんにも感謝いたします。「AsssemblyScriptはTypeScriptのサブセットだから実質TypeScriptを書くだけでパフォーマンスアップ!」みたいな言説をみるにつけ、「ええ〜ほんとか〜??ほんとにやってみて言ってるんか〜??」と思っていたので、小規模とはいえ実際にやってみて検証&考察できたのはよかったなあと。speakerdeck.com特に、最適化JITの効きずらい状況(たとえばスタートアップタイムの高速化)での高速化に寄与する可能性を示唆できたのは大きな発見です。Engineという新しいJSエンジンを開発してまでスタートアップタイムを改善しようとしています。結論としては、いま着手する必要はなくて「まだ早い」になりましたが、WebAssemblyが今後注目の技術であることには違いありません。少なくとも現状だと、AssemblyScriptを学ぶ意味はあまりないと思います。同じことをするにせよ、ランタイムの小さいCまたはRustが現実的な選択肢になるのではないでしょうか。今回のコードもAssemblyScripは捨ててRustで再実装してみようとは思っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。