「Workshop OT 2023 最適輸送とその周辺 – 機械学習から熱力学的最適化まで」で用いたスライドです
Image by @Th3RoadVirusIf you’d peeked in on me at work five months ago you’d find me with my nose in a textbook reading up on cutting-edge academic research on constraint-solving problems. Three months ago I was applying that knowledge to code, drafting and tweaking a new algorithm that united that research with a real-world tool. One month ago I was adding the last few features and polishing it u
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
Go Conference 2021 Springの登壇資料です アウトライン 1. 検索エンジンとは ~ 一般的な検索エンジンの仕組みと構成要素 2. 自作した検索エンジンの紹介 ~ 具体的に自作した検索エンジンの構成要素と動作例 3. 自作した検索エンジンの実装 ~ アルゴリズムとデータ…
ネットワークフロー好き好きマンとして,フローを布教したくなったので記事を書きました. ただし,フローの解説資料は既に素晴らしいものがたくさんあるので,今回は今まであまり焦点が当てられてこなかった部分を推して話をしたいと思います. テーマは,数あるフローの問題の関係を整理することです. フローの問題たちには共通の歴史があり,共通の定式化があり,共通のアルゴリズムの思想があります. その「共通」の部分を理解することで,フローに対する理解が深まり,より面白いと感じられると僕は思っていて,そこについて書きます. かなり基本的な内容しか書いてないので,強い人が得るものはあまりないかもしれません. あとこの記事はおきもちを書いてる部分が多いです. また,この記事では問題の話だけをしてアルゴリズムの詳細の話をほとんどしません.この辺りは 保坂さんのスライド などが非常に分かりやすいので,そちらを参照して
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog こんにちは、LINEメッセンジャーのサーバーサイドとモニタリングプラットフォームの開発を担当しているフィ(@dxhuy)です。この記事はLINE Advent Calendar 2017の20日目の記事です。 今日は、モニタリングシステムでよく使うレイテンシーやその計算方法などについて紹介したいと思います。LINEでは、日々ユーザが楽しくメッセージを送れるように、システムの安定性を第一に考えています。安定したシステムを保つためにたくさんの指標を見守る必要がありますが、その指標の1つが「レイテンシー」です。 ウィキペディアでは、レイテンシーは以下のように定義されています。 デバイスに対してデータ転送などを要求してから、その結果が
こんにちは、BASEのフロントエンドチームでエンジニアリングマネージャーをやっている松原(@simezi9)です。 私は最近ではマネージャーとしてコードを書くことよりもチームの編成や採用などをメインに業務を行っているのですが、 そんな中でチラっと書いたコードで見事に落とし穴にハマって失敗をしたのでその共有記事です まえがき BASEのフロントエンドチームは現在15名ほど(うち業務委託5名)で運営されています。 この人数は今後もどんどん増えていく予定なのですが、目下全社的にリモートワークになっている事情も手伝ってメンバー同士の関係性が希薄になってしまう懸念を持っていました。 BASEの中では常に複数のプロジェクトが走っているのですが、それぞれのプロジェクトにフロントエンドエンジニアは2〜3名ずつ配置されています。 そんななかでアサインされた人同士がフロントエンドエンジニア同士であるにも関わら
PHPとPythonとRubyの連想配列のデータ構造がそれぞれ4〜5年ほど前に見直され、ベンチマークテストによっては倍以上速くなったということがありました。具体的には以下のバージョンで実装の大変更がありました。 PHP 7.0.0 HashTable高速化 (2015/11) Python 3.6.0 dictobject高速化 (2016/12) Ruby 2.4.0 st_table高速化 (2016/12) これらのデータ構造はユーザーの利用する連想配列だけでなく言語のコアでも利用されているので、言語全体の性能改善に貢献しています1。 スクリプト言語3つが同時期に同じデータ構造の改善に取り組んだだけでも面白い現象ですが、さらに面白いことに各実装の方針は非常に似ています。独立に改善に取り組んだのに同じ結論に至ったとすれば興味深い偶然と言えるでしょう2。 本稿では3言語の連想配列の従来実
計測方法は、(10**6).times{ }のような最小限のコードです。 実際、制限時間が2秒だとして、10の7乗台前後から、想定解法でも厳しくなってくる印象です。 それ以前の1,000,000回(10の6乗)で2秒超えてTLEするなら、自分の書いたアルゴリズムを疑いましょう。 今のC++は10の7乗だと「余裕をもって間に合う」レベルらしいので、C++と比べるとRubyは10倍遅い感じです。 競技プログラミングでは、問題に与えられた要素数も 方針・アルゴリズムを考えるヒントになるので、このあたりの感覚はもっておくとよさそうです。 高速化手法のまとめ・見方 先に高速化のまとめがあった方が親切かと思い、簡単にまとめておきます。 (まとめの方にしか書いてないのもあります……) 本記事は、アルゴリズムの話も少し混じっていますが、アルゴリズムはRubyに限らないので、ほぼ触れてません。 「アルゴリズ
以前、Rainbow Table の説明で、ソルトに関して id:JULY:20100515 Windows のパスワードの場合、「ソルト」と呼ばれる、パスワードに付加する乱数が無いので、同じパスワードから必ず同じハッシュ値が得られる、という側面もあります。UNIX 系 OS では「ソルト」が付加されるので、Rainbow Table が作りづらくなっています。 とサラッと流したのが、自分でも気になっていたのですが、エフセキュアブログの「ソルト付き SHA-1 は大丈夫か?」という話に言及*1したので、ソルトの効用に関して書いてみます。 ソルトとは 塩です。 というボケは置いといて、パスワードを保存する時に、何らかの「非可逆処理」を行った結果を保存しておく事は多いです。Windows での LM ハッシュや NTLM ハッシュ、UNIX 系であれば、古くは伝統的な「crypt」関数を使った
こんにちは! エンジニアリンググループ マルチデバイスチーム 新卒1年目の小林です。 エムスリーでは、2週間に1度、Tech Talkという社内LT会(現在はリモートで)が開催されています。これは、とある回の発表テーマリストです。 Tech Talkのとある回の発表テーマリスト このように、最近エムスリーでは文字列が流行っている(?)ようなので、その勢いに乗って私も文字列照合アルゴリズムについて書きたいと思います!(業務とは全然関係ない話です) Knuth-Morris-PrattやBoyer-Mooreアルゴリズムは解説記事がたくさん出ていると思うので、この記事ではシンプルかつ高速なQuick-SearchとQuite-Naiveアルゴリズムについて説明し、速度比較を行った結果についてご紹介します。 文字列照合アルゴリズムとは テキストとパターンという文字列が与えられたときに、中に出現す
広島大学は8月31日、富士通研究所と共同で、多くのデータ圧縮方式で採用されている「ハフマン符号」の並列展開処理を高速化する新しいデータ構造「ギャップ配列」を考案したことを発表した。NVIDAのGPU「Tesla V100」を用いて実験した結果、従来の最速展開プログラムと比較して、2.5倍から1万1000倍の高速化を達成できたとしている。 同成果は、同大学大学院先進理工系科学研究科の中野浩嗣教授らの共同研究チームによるもの。詳細は、2020年8月に開催された国際会議「International Conference on Parallel Processing (ICPP)」において発表され、269件の投稿論文の中から最優秀論文賞に選ばれた。 インターネットを介して多数の画像ファイルや動画ファイルなどを転送したり、また記録メディアに保存したりする際、データの圧縮は誰でも日常的に行っている。そ
こんにちは。「家族アルバム みてね」の開発チームに所属している黒川と申します。今回は、その「みてね」の機能の1つで、写真や動画をDVDにして注文できる機能を動的計画法を使って改善した話をします。 「みてね」では家族の写真や動画をアップロードし、アプリ上で月ごとに振り返ることが可能になっています。一方、たとえば自宅のテレビやパソコンでまとめて振り返りたいという要望もあり、「みてね」では最長過去1年間の写真や動画をDVDにまとめて注文することができます。 このときに問題となるのがDVDのディスク分割です。1年分の写真や動画はともすると1枚のディスクに収まりきらず、複数のディスクに分割する必要があります。いままでは、動画を月ごとに分けて各ディスクに入れていく、というシンプルなアルゴリズムで分割を行っていました。しかし、ユーザーさんからは「1枚のディスクにすこしの動画しかないがどうなっているのか」
概要 インデックスに対してMongoDBはB Treeを採用し、MySQLのInnoDBはB+ Treeを採用しています。 どうして採用しているアルゴリズムが違うのだろう?と思って調べてみました。 主な違い B+ TreeはほとんどB Treeと同じですが、以下の点が異なります。 リーフノードとリーフノードを結ぶポインタがある データはリーフノードのみに保持する 具体例 言葉だけだと分かりにくいので、Visualizeするツールを使って具体例を表示します。 [1, 2, 3, 4, 5, 6, 8, 10, 15, 18]という数列に対し、Order: 3で作ってみます。 Orderは1ノードから出る枝の数のことです。 B Tree B-Tree Visualization B+ Tree B+ Tree Visualization 先程のB Treeと違って、データはリーフノードに持つの
※この内容は個人的な考察なので、間違っている箇所もあると思います。そういう部分を見つけた際はぜひ教えて下さい。 RDBMSの検索を早くするためにIndexって使いますよね。例えばこんなテーブル CREATE TABLE user ( id INT UNSIGNED NOT NULL, name VARCHAR(255) NOT NULL, UNIQUE INDEX (id) ); idカラムにIndexを張っています。これはidでの検索を高速にするためです。ここでidカラムにIndexが貼っていない場合と比べると検索時間が大幅に変わってきてしまいます(特にレコードが多くなった時) ではなぜIndexを貼ると検索が早くなるんでしょう?? Indexとはその名の通り索引を意味します。特定のカラムの索引を作成しておくことで検索を高速化します。 (本の最後によみがな順で単語が並べられたりしています
1.コーディングインタビューとは何か コーディングインタビュー(Coding Interview、またはProgramming Interview)とは、1時間ほどの制限時間内に小さなプログラミング問題を解かせる面接形式のことをいう。プログラマー、またはデータサイエンティストなどの採用試験として、米国を含むいくつかの国で用いられている。「物理的なホワイトボード上にプログラムを書く」という形式で実施されることが多い。「オンライン上の共有エディタで書く」といった形式のこともある。Googleなどは自社のYoutubeチャンネル動画でも説明している。 出題される問題としては、例えば、「複数の数字numbersと整数kが与えられたとき、合計がkとなる数字の組を1つ出力せよ」といったものがある。この問題は有名なので通称が付いており、Two Sumと呼ばれる。 Two Sumの一例。与えられた数値の並
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く