GitHub - tkuchiki/alp: Access Log Profiler
$ alp --help alp is the access log profiler for LTSV, JSON, Pcap, and others. Usage: alp [flags] alp [command] Available Commands: completion Generate the autocompletion script for the specified shell count Count by log entries diff Show the difference between the two profile results help Help about any command json Profile the logs for JSON ltsv Profile the logs for LTSV pcap Profile the HTTP req
ISUCON7 予選通過した！ - Islands in the byte stream
スギャブロエックス（id:sugyan, id:kazeburo, id:gfx) で予選に出場して2日目2位でした。去年は予選敗退だったので2年ぶりの本戦出場です。 バランスの良い良問で大変楽しかったです。ISUCON運営チームに於かれましては大変おつかれさまでした＆ありがとうございました。 isucon.net スギャブロエックスのスコア推移: repo: https://github.com/gfx/isucon7-qualify 言語 採用言語はnodejsでした。もともとはPerl界隈で知り合った3人ですが、最近だれも現役でPerlを書いておらず、go, ruby あたりでやるか〜みたいな話を最初していました。途中でnodejs実装が追加されることになったので、nodejsにしたい！と希望してこうなりました。 スギャブロエックスがnodejsだと…— Ryuta Kamizono
V8エンジンでのJavaScriptの機能と最適化コードの書き方に関する5つのベストプラクティス | POSTD
数週間前に、JavaScriptが実際どのように動いているかを掘り下げて紹介する記事の連載を始めました。JavaScriptがどのような機能で構成されていてそれらがどのように組み合わさって機能していくのかを知ることによって、さらに良いコードやアプリケーションを作ることができるのではないかと思ったからです。 連載の1回目では 、エンジンやランタイム、コールスタックについての概要を紹介しました。2回目となる今回は、Google V8 JavaScriptエンジンについて細かく説明していきます。また、より良いJavaScriptコードの書き方、すなわち私たちの開発チーム SessionStack がプロダクトを開発する際に意識しているベストプラクティスについても併せて紹介します。 概要 JavaScriptエンジン とはJavaScriptコードを実行するプログラムまたはインタプリタのことです。
処理速度の遅いcurrentTimeMillis() – 後編 | POSTD
私は以前、Linuxでのシステムコールはとてつもなく高コストだと思っていましたが、この測定で、その考えが誤っていたことが判明しました。実際にはシステムコールにコストはかかりますが、例えば、L3キャッシュミス（100ns）に比べれば低コストです。 ただし、行われるアクションが短いとしても（TSCベースの gettimeofday 向けだから）、システムコールを避ける方が有利です。その場合は、vDSOの方が断然役に立ちます。私たちのケースでは、ほぼ3倍実行が速くなりました。 どうすればいいのか 最良の方法は、TSCタイムソースを持つWindowsまたはLinux以外では絶対にプログラムを実行させないようにすることです。それが不可能なら、純粋なJavaの中にいながらこの呼び出しを高速化する方法はなく、解決策は、 currentTimeMillis() があまり頻繁に呼び出されないようにすることで
スキャン速度10GB/sへの挑戦～その②～ - KaiGaiの俺メモ
一年半ほど前、次のようなエントリーを書いた。 kaigai.hatenablog.com かいつまんで言うと、多段JOINのように、実際に実行してみないと結果行数が明らかではなく、かつ、ステップ(k+1)の最適な問題サイズがステップkの結果に依存する場合、Kepler以降のGPUでサポートされた Dynamic Parallelism を使えば素直に実装できるという話である。 実際、この時期以降のGpuJoinロジックはDynamic Parallelismを用いて実装されていた。 だが、プロファイラ等を用いて詳しく調べてみると、どうやら、ある程度以上のパフォーマンスでクエリを処理している状況においては、このような設計はGPUが持つ本来の能力を引き出す上で必ずしも適切ではないという事が明らかになった。 例えば、以下のグラフは半年ほど前にStar Schema Benchmark(SSBM)
Rustでソートアルゴリズム (7)バイトニックソート (SIMDで高速化) - Qiita
# ![feature(repr_simd, platform_intrinsics)] # [allow(non_camel_case_types)] # [repr(simd)] # [derive(Debug, Copy, Clone)] struct i32x4(i32, i32, i32, i32); extern "platform-intrinsic" { fn simd_shuffle4<T, U>(x: T, y: T, idx: [u32; 4]) -> U; fn x86_mm_min_epi32(x: i32x4, y: i32x4) -> i32x4; fn x86_mm_max_epi32(x: i32x4, y: i32x4) -> i32x4; } fn sort(source: &mut [i32]) { #[inline] fn sort8(value1
VS CodeがDOMによるターミナル実装のパフォーマンスを改善できなかったためCanvasに変更
Integrated Terminal Performance Improvements Electronという史上まれに見るそびえ立つクソのようなGUIプラットフォーム上で実装されているVS Codeが、ターミナルの実装をDOMによるものからCanvasによるものに変更したそうだ。これは、DOMによる実装ではパフォーマンスの改善が十分にできなかったからだという。 DOMでターミナルを実装する際の問題ごととして、テキスト選択、テキストアライメント、GC、パフォーマンスを上げている。 テキスト選択：ターミナルのテキスト選択を実現するためにDOMのテキスト選択の挙動をだいぶ上書きしなければならない。 テキストアライメント：一部の文字はモノスペースになってくれず、workaroundとして一文字ごとに固定長のspanで包む必要があるが、これはパフォーマンス上よろしくない。 GC：DOMでターミナ
Rustで高速な標準出力 | κeenのHappy Hacκing Blog
κeenです。Rustで何も考えずに標準出力に吐いてると遅いよねーって話です。 今回、標準出力に「yes」と1000万回出力するアプリケーションを書いてみたいと思います。 println! まあ、最初に思いつくのはこれでしょうか。
SymSpell対BK木：100倍速い文字列のあいまい検索とスペルチェック | POSTD
注釈：500,000単語収録の辞書内における1,000単語の検索時間 X:最大編集距離 Y:検索時間/ms 従来、スペル修正や文字列のあいまい検索には、 BK木 が適していると言われてきました。しかし、これは本当でしょうか。 また、 スペル修正に関する私のブログ に寄せられたコメントには、BK木が、あいまい検索のためのデータ構造として優れていると言及されていました。 そのような経緯から、今回、BK木と他の選択肢のベンチマークを取って比較してみようと思い立ったわけです。 近似文字列検索アルゴリズム 近似文字列検索では、文字列リスト内の文字列を検索し、特定の 文字列メトリック に従って、それに近い文字列を返します。 文字列メトリックは多数あり、例えば レーベンシュタイン距離 、 Damerau-Levenshtein距離 、 ハミング距離 、 ジャロ・ウィンクラー距離 、 Strike a m
WebAssembly を速くするには？
[この記事は”Creating and working with WebAssembly modules“の翻訳です] この記事は WebAssembly と何が速くしたのかのシリーズの5部です。もしまだ前の記事を読んでいない場合、最初から読むことをお勧めします。前の記事では WebAssembly や JavaScript を使ったプログラミングは、どちらか一方を選択するものではないことを説明しました。多くの開発者が完全な WebAssembly コードベースを記述しているとは考えていません。開発者はアプリケーション用に WebAssembly と JavaScript のどちらかを選択する必要はありません。 しかし開発者は JavaScript コードの一部を WebAssembly に取り替えようとしています。 例えば React に取り組んでいるチームは、調整コード (別名仮想 D
HotSpot JavaVM の SIMD 最適化を効かせる方法 - Qiita
HotSpot JavaVM のベクトル化変換 最近の HotSpot JavaVM はスカラー演算の繰り返し処理をベクトル化し SIMD 命令に変換する最適化を行っています (SIMD とは何ぞやという話は後半参照)。実際に最適化が効くコードで試してみたところ 1.5～2.8 倍程度の速度向上が見られたので、大量の演算処理を行う (GPGPU に頼らない) Java ライブラリでうまく使うことが出来れば有効な最適化手段になるかもしれません。 HotSpot の SIMD 最適化は Superword-Level Parallelism (SLP) に基づいています (以降この最適化は SLP と呼びます)。元々この論文は時代を反映して SIMD 未対応の画像・音声処理をコンパイラやランタイムのレイヤーで SIMD を利用する命令に変換することを目的としていましたが、これは SIMD 命令
Tracing userspace static probes with perf(1)
The perf(1) tool added support for userspace static probes in Linux 4.8. Userspace static probes are pre-defined trace points in userspace applications. Application developers add them so frequently needed lifecycle events are available for performance analysis, troubleshooting, and development. Static userspace probes are more convenient than defining your own function probes from scratch. You ca
動くようにする、正しくする、速くする。 - Qiita
今までに扱ったことの無い分野で新規開発をする場合、いろんな問題が出てくるだろう。そのようなときに、何をどうすればよいのか迷うことがあるだろう。そのようなときに、複数の課題があるときに、何をどの順序で解決していけばよいのか迷うこともあるだろう。 私が心がけているのは、「動くようにする、正しくする、速くする。」の順序で物事の優先順位をもって考えてようにしていることです。この内容は何かの本で読んだことからきている。何かしら動かないうちは、正しくすることもできないし、正しくなっていないうちは、速くすることに意味がない。 物事を解決する際に、全てのことが同時に解決することは少ない。 前に経験を積んだことのある分野の近くでは、動いて正解率もそれなりに高くて、メモリ消費や処理時間が少ないもの１回目の挑戦で作れることがあったりもするが、それは極めてまれなことだ。 1. 何かしら既存の技術をまねて、「動くよ
遅いクエリと向き合ったり、ログ基盤を刷新したり──Cybozu Meetup #6レポート - Cybozu Inside Out | サイボウズエンジニアのブログ
まいど！ コネクト支援チームの風穴（かざあな）です。 今回は、7月25日に開催した「Cybozu Meetup #6 大規模サービスを支える名脇役たち」についてレポートします。 Cybozu Meetupとは？ 「Cybozu Meetup」は、サイボウズのエンジニアとカジュアルに交流する場として企画している、ミートアップイベントです。会場はサイボウズのオフィス（今のところ東京と大阪）なので、社内の雰囲気や社員の様子を、実際に肌で感じて頂ける機会でもあります。 開催ペースは、東京オフィスは毎月1回、大阪オフィスは3カ月に1回となっています（今のところ）。これまでに、以下のようなテーマで計6回開催してきました。 ［02/27］Cybozu Meetup #1 フロントエンド（東京、大阪） ⇒ 開催レポート ［04/03］Cybozu Meetup #2 SRE（東京） ⇒ 開催レポート ［0
プロビジョニングツール Itamae を速くする - Qiita
TL;DR Itamae を使ってプロビジョニングしていたけど実行時間が長くて困っていた ssh接続を使いまわすように改造したら40分かかっていたのが2分くらいになった（20倍の高速化） 問題 Itamae は内部的にサーバー側でコマンドを実行するところが多いみたい コマンドを実行するたびに ssh で接続、コマンド実行、ssh 接続を切断、している（実際に仕事をしているのは Specinfra） 1つ1つのコマンド実行時間は長くても数秒なので、TCPソケットのリソースがきれいに開放されるよりも早い（印象） ソケットリソースが少しづつ逼迫し、スローダウンしていく（ように見える） def create_specinfra_backend Specinfra::Backend::Ssh.new( request_pty: true, host: ssh_options[:host_name],
SREによるモンスト改善事例 / improvement-example-of-monster-strike-by-sre
hbstudy#76 第76回： SRE大全: XFLAG スタジオ編 https://hbstudy.connpass.com/event/62338/
optima - 高速パターンマッチライブラリ - Qiita
開発が成熟してきたので、ここらで拙作のパターンマッチライブラリ、optimaを日本語で解説したいと思う。ただし解説とは言っても、詳細な仕様をだらだらと解説するようなことはしない。むしろ「なぜパターンマッチなのか」を踏まえた上で、簡単な入門と使用例を示すことで、パターンマッチの重要性を認識してもらうのが狙いだ。なお、詳細な仕様についてはマニュアルを参照されたい。 なぜパターンマッチなのか Common Lispにはパターンマッチライブラリが多数存在するが、その大半は単にパターンマッチが便利だからという視点しか持っていない。たしかにパターンマッチは便利であるが、便利なだけでは人々はそれを使おうとはしない。より本質的な視点を与える必要があるだろう。 OCamlやHaskellなどの関数型言語では、あらゆるデータは、代数的データ型として定義され、それにともなうデータコンストラクタによって構成される
社内ISUCONを開催しました - Opt Technologies Magazine
2017/06/30(金)に開催した『第一回社内ISUCON』のレポートです。 あいさつ 社内ISUCONについて ISUCONとは 企画〜準備 問題/ポータルサイトの用意 Scala実装の用意 インフラの用意 当日の様子 集合〜ルール説明/サーバー配布 チューニング ベンチマーク実施 開催してみて まとめ あいさつ こんにちは、 @ocadarumaです。 おもに広告効果計測ツールの開発/運用などをやっています。 最近はちょっとRustにハマってまして、GC無しで参照を適切に管理することの難しさを噛み締めています。（でもコンパイル時に検出できるのが素晴らしい） Cargoやrustupなどのツールもよくできていて、Rustには未来を感じざるを得ません。 社内ISUCONについて オプトテクノロジーズでは定期的に社内ハッカソンを開催しており、その日は1営業日を丸々使って、各々業務を改善する
PythonでCSVを高速＆省メモリに読みたい - tkm2261's blog
今日はPython (Pandas)で高速にCSVを読むことに挑戦したいと思います。 Kaggleに参加するたびに、イライラしていたので各実装の白黒はっきりさせようと思います。 R使いが羨ましいなぁと思う第一位がCSV読込が簡単に並列出来て速いことなので、 なんとかGILのあるPythonでも高速に読み込みたいと思います。 ただ、この検証ではコーディング量が多いものは検証しません。 CSV読込は頻出するので、フットワークの軽さが重要です。（オレオレライブラリ嫌い） Pickleは早いけど。。。 結論はDask使おう！ 検証環境 データ 速度検証 pandas.read_csv() pandas.read_csv() (dtype指定) pandas.read_csv() (gzip圧縮) numpy.genfromtxt() pandas.read_csv() (chunksize指定 +
Kotlinの隠れたコストについてのベンチマーク | POSTD
@BladeCoder が書いた Kotlinの隠れたコストの調査 という一連のブログ記事は、ある Kotlin 構文にどのように隠れたコストがあるのかを説明しました。 実際の隠れたコストは、普通、不可視オブジェクトのインスタンス化やプリミティブ値のボクシング／アンボクシングに起因します。これらのコストは、Kotlinコンパイラがどのように上記の構文をJVMのバイトコードに変換するのかを理解していない開発者には特に見えづらいのです。 しかし、何らかの数字を示さずに隠れたコストの話をするだけでは、実際にどのくらいコストのことを心配すべきなのかという疑問が湧いてきます。コードベースのいたるところで、これらのコストを考慮すべきでしょうか？あるKotlin構文は単に全面的に禁止されるべきでしょうか？あるいは、最も範囲の狭い内部ループの中でだけ考慮されるべきでしょうか？ さらに挑発的な言い方をすれば
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
