Content-Length: 373391 | pFad | http://b.hatena.ne.jp/q/Benchmark

Benchmarkの人気記事 181件 - はてなブックマーク

並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 181件

新着順 人気順

Benchmarkの検索結果1 - 40 件 / 181件

Benchmarkに関するエントリは181件あります。 performanceパフォーマンスbenchmark などが関連タグです。 人気エントリには 『「Goの父」ロブ・パイクの「プログラミング5カ条」、ネット上で話題に』などがあります。
  • 「Goの父」ロブ・パイクの「プログラミング5カ条」、ネット上で話題に

    「UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている」「キャッシュはアーキテクチャではない。単なる最適化だ」などの語録を生んだ「Goの父」とも呼ばれるロブ・パイク氏の「プログラミング5カ条」について、ネット上で話題となっています users.ece.utexas.edu/~adnan/pike.html http://users.ece.utexas.edu/~adnan/pike.html Rob Pike's Rules of Programming (1989) | Hacker News https://news.ycombinator.com/item?id=24135189 パイク氏の「プログラミング5カ条」は以下。 ルール1:プログラムのどこで処理時間がかかるかはわからない。ボトルネックは意外な場所で発生するので、ボトルネックがどこにあるかを証明するまでは、臆測

      「Goの父」ロブ・パイクの「プログラミング5カ条」、ネット上で話題に
    • ブラウザにおけるメモリリークを解決するために読んでおけると良い資料 - mizdra's blog

      最近趣味や仕事の Web アプリケーションでメモリリークに遭遇して、頑張ってメモリリークの原因を突き止めて修正する、ということがあった。その過程でメモリリークについて色々調べて知見が溜まったので、学習資料の紹介という形でアウトプットしてみる *1。 前置き 紹介する記事がかなり偏っていることに注意 冒頭で触れたメモリリークを解決するために読んだ記事をまとめただけなので、内容にそれなりの偏りがある 例えば id:mizdra が遭遇したメモリリークは全てブラウザ上で発生していたものだったので、これから紹介する内容も主にブラウザにおけるメモリリークに焦点を当てたものになる GC がどうメモリをどう解放しているか、何故メモリリークが発生するのかは全てカット 調べれば色々な記事が出てくるので、必要に応じて読んでください 基本的な知識を抑える まずメモリリークとメモリ撹拌の違いを学ぼう どちらも同じ

        ブラウザにおけるメモリリークを解決するために読んでおけると良い資料 - mizdra's blog
      • Netlifyが日本からだと遅い - id:anatooのブログ

        仕事で Netlify にデプロイしたSPAの読み込みが遅いので原因を調査してほしい、という依頼を受けてウェブパフォーマンス調査を行った。顧客から許可をもらって、この記事ではNetlifyに対してどういう調査をしたのかを書く。 結論だけをまず書くと、NetlifyのCDNのファイル配信パフォーマンスは日本国内からだと非常に悪い。パフォーマンスを改善させるためには、Netlifyに直接アクセスさせるのではなく、前段に他のCDNやキャッシュサーバを挟んだりするほうがいいだろう。 調査の前提 日本国内からのみの調査 サイトには静的なファイルをデプロイしているのみ 該当するNetlifyにデプロイしたSPAをブラウザで試しに開いてみると、確かに初回の読み込みのパフォーマンスがめちゃくちゃ悪い。 Chrome Devtoolsを開いてネットワークタブでどういうふうにリソースの読み込みを行っているのか

          Netlifyが日本からだと遅い - id:anatooのブログ
        • REST vs. GraphQL vs. gRPC · Dan Hacks

          REST, GraphQL, and gRPC are 3 popular forms client-server and server-to-server communication. Choosing can be difficult, so this concise guide can help. In each section, an example will be provided to illustrate retrieving a user. REST Notes HTTP paths describing data, e.g. /users as a collection of users Easily discoverable data, e.g. user ID 3 would be at /users/3. All of the CRUD (Create Read U

          • Internet Speed Test - Measure Network Performance | Cloudflare

            Test your Internet connection. Check your network performance with our Internet speed test. Powered by Cloudflare's global edge network.

              Internet Speed Test - Measure Network Performance | Cloudflare
            • 結局、Go言語をやめる理由はなかった件 - Qiita

              この記事は Go 2 Advent Calendar 14日目の穴埋め記事です。 はじめに @okdyy75 さんによる Go 5 Advent Calendar 14日目の の記事「だから僕はGo言語を辞めた」 が「ベンチマークっていうのはこうやるんだよ」というのを説明するために反面教師的な意味で良い教材だと思ったので、反証記事を書きたいと思います。 ベンチマークを取りながらコードを改善して、最終的にGoは遅くないからやめる必要はないということ、そして、なぜ遅いという結論になってしまったのかを掘り下げていきたいと思います。 下準備 幸いなことに、ベンチマークのソースコードがGitHubにある ので、こちらを実行しながら問題点を改善していきましょう。 ちゃんとコードが上がっているのは素晴らしいですね! 一方で、元記事には測定環境が明記されていませんでしたので、同じ環境で測定することはできま

                結局、Go言語をやめる理由はなかった件 - Qiita
              • どのウェブフレームワークが一番高速に動作するのかが一目で分かる「Web Framework Benchmarks」レビュー

                普段何気なく目にしているウェブサイトも、裏ではさまざまなフレームワークを活用しています。「Web Framework Benchmarks」はそうしたフレームワークたちがアクセスをさばくときの処理速度を計測してベンチマークにまとめたもので、2013年に公開されて以降、年々アップデートが積み重ねられて多種多様なフレームワークの実力を一目で確認できるようになっています。 TechEmpower Framework Benchmarks https://www.techempower.com/benchmarks/ 上記のURLへアクセスすると、2020年5月28日にアップデートされた「Round 19」の内容が表示されます。 こんな感じでテスト結果がランキング形式で表示されます。さまざまなテスト結果が掲載されていますが、最初に表示される「Fortunes」はデータベースを読み取ってHTMLを生

                  どのウェブフレームワークが一番高速に動作するのかが一目で分かる「Web Framework Benchmarks」レビュー
                • 【特集】 よく分かるLANケーブルの選び方。CAT.6でも10Gbps対応可能。CAT.8まで速度差を検証

                    【特集】 よく分かるLANケーブルの選び方。CAT.6でも10Gbps対応可能。CAT.8まで速度差を検証
                  • 「結局HDDは何年間壊れずに動いてくれるのか?」をHDD故障率レポートで知られるBackblazeが解説

                    例年「HDD/SSD故障率レポート」を公開していることでも知られるBackblazeが、同社が運用するHDDの総容量から、「そもそも故障率とは何なのか?」「バスタブ曲線とは何なのか?」「HDDは何年間使えるものなのか?」について解説しています。 How Long Do Disk Drives Last? https://www.backblaze.com/blog/how-long-do-disk-drives-last/ Backblazeは堅牢(けんろう)でスケーラブルながらも低コストというクラウドバックアップおよびストレージサービスを提供する企業で、その公式ページを見ると、50億個のファイルを900ペタバイト(90万テラバイト)も保存しているとアピールされています。 最高の無制限オンラインバックアップおよびクラウドストレージサービス https://www.backblaze.com

                      「結局HDDは何年間壊れずに動いてくれるのか?」をHDD故障率レポートで知られるBackblazeが解説
                    • Re: 結局、Go言語をやめる理由はなかった件 - Hateburo: kazeburo hatenablog

                      すみません、ISUCONのアレに火がついてしまったので..。 Advent Calendarとはとくに関係がありません。 qiita.com qiita.com こちらの記事をみて、気になってしまったので interpolateParams の追加とMySQLチューニングをしてベンチマークを回してみました。 ベンチマークの環境が公開されているのは素晴らしいですね。 github.com 8vCPU/16GB Memのc5a.2xlargeなEC2のインスタンスを起動して、以下の手順にしたがってdockerとdocker-composeをインストールしました。OSはUbuntu 20.04を使いました。 docs.docker.com docs.docker.com 上記のbenchmarkのrepositoryをgit cloneし、compose build && compose upし

                        Re: 結局、Go言語をやめる理由はなかった件 - Hateburo: kazeburo hatenablog
                      • Pythonコードを35000倍に高速化したい

                        はじめに Pythonは世界的にも人気のあるプログラミング言語ですが、実行速度については課題があります。Pythonの実行速度を高速化したい、という要求は根強く、これまでにも様々な処理系が開発されています。 この記事はPythonで書かれたコードを35000倍に高速化するにはどのような方法があるかについてまとめたものです。 この記事は: Pythonで書かれたアルゴリズムを35000倍に高速化する 事前コンパイル、並列化、SIMD演算を駆使する 最終的に44000倍まで高速化できた なぜ35000倍? 2023年5月2日にModular社よりPythonの使いやすさとC言語の性能を兼ね備える新しいプログラミング言語、Mojoの開発について発表がありました。低レベルのハードウェア向けにコンパイル可能なこと、文法的にはPythonを踏襲しており、既存のPythonライブラリを利用可能であること

                          Pythonコードを35000倍に高速化したい
                        • コンテナランタイムの仕組みと、Firecracker、gVisor、Unikernelが注目されている理由。 Container Runtime Meetup #2

                          Docker MeetupとかCloud Native Daysの運営をしながら、無限にスケールするインフラはないかなって、日々もやもやと考えています。 さっそく本題に入っていきましょう。 コンテナってそもそも何ですかっていうと、まず「chroot」というLinuxの機能があって、これはrootディレクトリを特定のディレクトリに切り替えて、そこから下を別のファイルシステムとして確立する、といった技術です。 そこに対して「namespace」という機能で、ユーザー、プロセス、ネットワークを個別に割り当てて、さらにリソースにも制限をかけると、まるでVM(仮想マシン)のように動いて面白いね、というのがコンテナですよ、という説明はよくされると思います。 これを図にしました。 まず、対象のディレクトリに対して「pivot_root」という機能を使ってファイルシステムのルートを作ります。 そのうえで「

                            コンテナランタイムの仕組みと、Firecracker、gVisor、Unikernelが注目されている理由。 Container Runtime Meetup #2
                          • Pythonが速度改善に本気出すと聞いたので恒例のたらい回しベンチをとってみたら、RubyがYJITですごく速くなっていて驚いた話 - Smalltalkのtは小文字です

                            2022-09-09改訂: gcc バージョンが古すぎたのと、C が内部計測でなかった点を改め計測しなおしました。結果、Rust は C より速くはなくなりました。紛らわしいことで、ごめんなさい。また、gcc のバージョンアップに伴い、Python および Ruby についてはビルドと計測をしなおしたので、これらも少し速い値に変わっています。この点もどうぞあしからず。 2022-09-10追記:ご要望のあった Python numba.njit 使用時と Go の結果を追加しました。PHP は JIT 有効化が面倒だったので断念しました^^; 2022-09-10追記2:C の計測で clock() を使うのはフェアではないという指摘がありましたので、念のため clock_gettime() を使用したコードに差し替えました。結果に大きな差はありません。 2022-09-10追記3:PHP

                              Pythonが速度改善に本気出すと聞いたので恒例のたらい回しベンチをとってみたら、RubyがYJITですごく速くなっていて驚いた話 - Smalltalkのtは小文字です
                            • どうして Fastify は生の Node.js より速いの? : (*x).b=z->a+y/c

                              Fastify 速いですね Express が hapi より遅いのは意外でした Koa は本体だけだと Express 以上に何もしないので その分速めです よくみると驚きなのが http.Server より Fastify が速いというところ http.Server はフレームワークを使わない Node.js 自体の API です Koa や hapi はこれを中で使っています これより速いということは Fastify は http.Server は使わずに net などを使って ソケット通信部分を直接操作しているのでしょうか? http.Server を使ってない?Fastify のソースコードを見た限りでは 特に設定をしなければ http.createServer でサーバを作成しています つまり http.Server を使っています https://github.com/fas

                                どうして Fastify は生の Node.js より速いの? : (*x).b=z->a+y/c
                              • 日本語LLMまとめ

                                日本語LLMまとめ ​[ English | Français | 日本語 ] 日本語LLM・海外LLMのパラメータ数の推移。日本語モデルの情報は本記事、海外モデルの情報は LifeArchitect.ai の Models table を参照しています(ただし、図のスペース上一部のモデルは省略。また、海外モデルのパラメータ数は推測値を含む)。修正・追加等ありましたらお知らせ下さい。この記事は、一般公開されている日本語LLM(日本語を中心に学習されたLLM)および日本語LLM評価ベンチマークに関する情報をまとめたものです。情報は、有志により収集されており、その一部は論文や公開されているリソースなどから引用しています。 以下の点について、あらかじめご理解とご了承をお願いいたします 本記事の内容は、完全性や正確性を保証するものではありません。これらの情報は予告なく変更されることがあり、また最新

                                  日本語LLMまとめ
                                • なぜReactは標準でComponentをmemo化しないのか?

                                  はじめに 普段はスタートアップでBtoB SaaSの開発をしているtaroと申します。 今回は、Reactのmemo化について考えている中で抱いた 「なんでReactは標準でComponentをmemo化していないんだろう?」 という疑問を解消するために、色々と調べたり考えたりした内容をまとめました! 途中でrenderのタイミングや、memo化で再renderが抑えられる理由などの前提知識の復習も含めていて、memo化について詳しくない方もmemo化の勉強にもなると思うので、ぜひぜひ読んでみてくださいー! なぜこんな疑問を抱いたのか? まずはそもそも僕がタイトルにあるような疑問を抱いた背景です。 疑問を抱くまでの思考プロセスはこんな感じです。 「再renderが余分に走ってて画面が重いから最適化したいなー」 →「React.memo()を使ってComponentをmemo化しよう!」 →

                                    なぜReactは標準でComponentをmemo化しないのか?
                                  • High Performance FastAPI

                                    PyCon JP 2021 発表資料です。

                                      High Performance FastAPI
                                    • QUICの実装はTCP並みの効率を実現できるか? Fastly奥氏らがベンチマークを紹介

                                      現在標準化が進められている次世代HTTPの「HTTP/3」は、トランスポートプロトコルとして「QUIC」と呼ばれる新しいプロトコルを採用します。 現時点のHTTPはトランスポートプロトコルとして「TCP」が採用されています。その上で、可能な限り高速な通信が行えるようにさまざまな工夫や最適化が進められてきました。そしてもうこれ以上高速にしようとすると、TCPそのものを改善していくべきだろう、というところまできたのです。 それがHTTP/3で「QUIC」が採用される大きな理由といわれています。 TCPは内部で輻輳制御や再送などを自動的に行うことで通信が確実に行われることを保証してくれる便利なプロトコルですが、それゆえに、確実に通信が行われるまで待つ必要があるために通信環境によっては遅くなりがち、などの側面があります。 そこでQUICは、TCPのような通信の保証がない代わりにリアルタイム性の高い

                                        QUICの実装はTCP並みの効率を実現できるか? Fastly奥氏らがベンチマークを紹介
                                      • S3 互換オブジェクトストレージまとめ

                                        概要 S3 互換オブジェクトストレージの サービス を自分のためにまとめている。サービスとして提供されているのが前提で、 自前運用は範囲外 。 目的 以下の内容に絞って調べている。 日本リージョンの有無 egress の費用 容量の費用 追加調査予定 PutObject 対応 PresignedGetObject 対応 S3 互換 S3 互換の条件は s3cmd や aws sdk s3 がそのまま利用できる事。細かい互換性は気にしない。 比較用の AWS S3 https://aws.amazon.com/jp/s3/pricing/ 最小プラン Tokyo / Osaka リージョンあり 1 GiB 追加の egress 転送量は 0.114 ドル 1 GiB の追加容量は 0.025 ドル TODO SLA 書いてるのと書いてないのがあって拾いにくい 対象外 Azure は S3 互

                                          S3 互換オブジェクトストレージまとめ
                                        • 改めて見直すGoの特徴

                                          極力Goならではな特徴をいくつか挙げていく。 依存解決が必要最低限で互換性を考慮しつつ決定的 モジュール単位で依存をダウンロード。コンパイル対象はサブパッケージ単位。 依存の明示方法はコードに埋め込まれ、かつ未参照のインポートはコンパイルエラー。 つまり動作するコードのすべては正確な依存ツリーが明示されていて余計な依存は引き込まれない。 そして持ち前のコンパイルの速さを含め、相当深い依存ツリーでも依存解決にかかる時間は既知の処理系の中でも最速レベル。(唯一勝てるのはプリビルドバイナリが配布されている場合くらい) また、コンパイルやリンクに必要な処理量そのものが比較的少ないため、開発環境負荷も小さい。 かなり巨大なプロジェクトであってもメモリ8GBで困るようなことが無い。つまり、CI環境の維持にもローコストで済む。 ライブラリの提供側では後方互換性が破壊されるような変更はV1->V2というよ

                                            改めて見直すGoの特徴
                                          • 3大クラウド(AWS,Azure,GCP)をそれぞれプロダクションで実運用した感想(その2 Azure固有の優位性について) - Qiita

                                            3大クラウド(AWS,Azure,GCP)をそれぞれプロダクションで実運用した感想(その2 Azure固有の優位性について)Azure 3大クラウド(AWS,Azure,GCP)をそれぞれプロダクションで実運用した感想(その2 Azure固有の優位性について) はじめに 前回記事で3大クラウドに関して、各々のクラウドのシェアと将来性に関して感想を記述したところ、トレンド1位になったりと大変大きな反響をいただきました。 長い記事であったにも関わらず、目を通してくださった読者の皆様ありがとうございます! しかしながら、予想外のバズり方をしてしまってだいぶハードルが上がってしまったのと、ちょうど弊社でインパクトの大きい経営施策(シリーズBの資金調達/事業譲渡)が立て続けに執行されたことが相まって、記事第二弾の投下が遅くなってしまいました。 楽しみにしてくださっていた方々、申し訳ございません。 今

                                              3大クラウド(AWS,Azure,GCP)をそれぞれプロダクションで実運用した感想(その2 Azure固有の優位性について) - Qiita
                                            • node.js のメトリクスの計測、ベンチマークの改善、Docker イメージの絞り方を勉強した

                                              フロントエンドのパフォーマンス計測は得意なのだが、サーバーサイド node.js のメトリクスの取り方はあまり知らなくて、いつも勘でやりがちだった。最近は業務でこの周辺で困ることが増えたので、勉強しなおした。 また、最近使ってみたかった cloudflare workers の制限で、メモリ 128MB、CPU 時間 50ms という制約があり、このためにも Node.js の CPU のメトリクスを計測できるようになっておく必要があった。 という目的を踏まえて、今回は OS やデータベースの最適化は扱わず、ネットワークとアプリケーション層だけに絞って学習した。あと仕事の Docker イメージのサイズにも悩んでたので、ここも。 (あと ISUCON 参加者が楽しそうだったのもある。 ISUCON のチューニング対象にフロントエンドは含まれないので…) 計測対象 今回実験したリポジトリはこ

                                                node.js のメトリクスの計測、ベンチマークの改善、Docker イメージの絞り方を勉強した
                                              • M1搭載MacBook Airが届いたのでJavaやDockerなどいろいろベンチマークした - きしだのHatena

                                                M1 MacBook Airが届いていろいろやってたら年も明けてだいぶたったけども、ビルド速度とかJavaとかDockerとかTensorFlowとか、技術者が気になるベンチマークを試してたので、まとめました。 MacBook Airを買ってしまった なんかM1 Mac解説動画をとるためにいろいろ調べていたら、悪質サイトのリンクを踏んだみたいで、MacBook Airを買ってしまっていた。 その悪質サイトは最初は7万円台ですよーっていっておいて、結局12万円くらいになっていた。 みんなもapple.comってサイトには注意しましょうね。 www.youtube.com とどいた! 12/12到着予定といいつつ11日になっても羽田から動いてなかったので大丈夫かーと思ったら11日深夜というか12日未明というかそのあたりには福岡に届いてて、朝発想されて夜にとどいた。 でこれだ! ベンチマーク G

                                                  M1搭載MacBook Airが届いたのでJavaやDockerなどいろいろベンチマークした - きしだのHatena
                                                • 【笠原一輝のユビキタス情報局】 「Ryzen 7 5800U」はApple M1を上回る性能で、Intel並みの長時間駆動を実現

                                                    【笠原一輝のユビキタス情報局】 「Ryzen 7 5800U」はApple M1を上回る性能で、Intel並みの長時間駆動を実現
                                                  • 【簡易レビュー】M4 Mac mini 最安モデルのベンチマークテスト結果をWindowsPCと比較

                                                    11/8に発売されたMac miniのベンチマークテストを行ないましたので、その結果を簡単に紹介します。スコアはWindows搭載のミニPCと比較しているので、気になる人はぜひ参考にしてください。Apple製品との比較は行なっていません。

                                                      【簡易レビュー】M4 Mac mini 最安モデルのベンチマークテスト結果をWindowsPCと比較
                                                    • Apple M1の参照カウントは本当に速いのか - yamasaのネタ帳

                                                      Apple M1に関して以下のようなツイートが話題になった。 18/ Another "magic" trick is how their "Swift" programming language uses "reference counting" instead of the "garbage collection" in Android. They did something in their CPU to double the speed of reference counting.— Robᵉʳᵗ Graham😷, provocateur (@ErrataRob) 2020年11月26日 fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.

                                                        Apple M1の参照カウントは本当に速いのか - yamasaのネタ帳
                                                      • Web Speed Hackathon 2021 miniでほぼ満点を出しました

                                                        gzip圧縮だとあまり圧縮できていなく、スライディングウィンドウが小さいせいかなと思ったのですが、実際に大きさがかなり違うみたいなので、それが原因としてありえそうです。 Gzip uses a fixed size, 32KB window, and Brotli can use any window size from 1KB to 16MB, in powers of 2 (minus 16 bytes). This means that the Brotli window can be up to 512 times larger window than the deflate window. Results of experimenting with Brotli for dynamic web content - The Cloudflare Blog AudioContextの

                                                          Web Speed Hackathon 2021 miniでほぼ満点を出しました
                                                        • 【特集】 同じ「4060」と「4090」だけど……GeForceのデスクトップとノートはどのぐらい違う?

                                                            【特集】 同じ「4060」と「4090」だけど……GeForceのデスクトップとノートはどのぐらい違う?
                                                          • 各種テキストエディターにおける巨大ファイル操作速度の比較資料をEmurasoftが発表/「EmEditor」を含む7つの巨大ファイル対応テキストエディターを比較

                                                              各種テキストエディターにおける巨大ファイル操作速度の比較資料をEmurasoftが発表/「EmEditor」を含む7つの巨大ファイル対応テキストエディターを比較
                                                            • Python を Go に書き換えるとどれくらい速くなる? 7つの言語で Dijkstra の実行速度を比較 - Qiita

                                                              Python を Go に書き換えるとどれくらい速くなる? 7つの言語で Dijkstra の実行速度を比較KotlinRustベンチマークJuliaDijkstra これは何 最短経路探索のアルゴリズムを使っていくつかの言語の性能がどれくらい違うかを調べてみました。 Python は手軽に実装できるけど遅い、Go は 早いけど C++ よりは遅い? 本当? のような疑問を一定解消したかったというのが動機です。 前提条件など 対象とする言語 本命 Go, Rust, C++ 興味本位 Julia Python より段違いに早ければもう少し掘ってみたい 興味本位 Kotlin 意外とトップ集団に肉薄するのではないか 参考 Python JavaScript 性能差のイメージとしては Rust == C++ > Go >> Kotlin >>> JavaScript > Python == J

                                                                Python を Go に書き換えるとどれくらい速くなる? 7つの言語で Dijkstra の実行速度を比較 - Qiita
                                                              • Reactに有利なベンチマークを作ってみた - Qiita

                                                                皆さんこんにちは。現在、フロントエンドでは宣言的UIが大流行しており、そのためのライブラリもReactを筆頭に複数存在しています。 ライブラリが複数存在するところには当然のように比較や論争が起こるものですが、UIライブラリの場合はパフォーマンスがよく焦点となります。 筆者はReactの信者ですが、Reactは古株ということもあってか、最近の議論ではReactは他のライブラリと比較されるかませ犬のような役割を担うのがよく見られます。「仮想DOMは必要ない」といった類のものです。 しかし、筆者の考えではReactは今でも、もっとも真剣にパフォーマンスに取り組んでいるUIライブラリです。特に、Reactはパフォーマンスを高いユーザーエクスペリエンスのための手段として捉えており、ドキュメントにもユーザーエクスペリエンスという言葉が多く出てきます。 そこで、今回はReactが最も有利になるようなベン

                                                                  Reactに有利なベンチマークを作ってみた - Qiita
                                                                • Go vs Rust : 特徴量DBに適するのはどっち!? (2020-04-14 実験追記) - ABEJA Tech Blog

                                                                  ABEJA で Research Engineer をやっている中川です.普段は論文読んだり,機械学習モデルを実装したり,インフラを構築したりしています.今回のブログでは,Insight for Retail の一機能として提供しているリピータ分析に用いる特徴量DBの改善に向けた言語選定について紹介します. ※ たくさんの方々からのコメントありがとうございます.いただいた観点をベースに「2020-04-14 追記」以下に実験を追加しました. モチベーション リピート分析では,任意の特徴量をクエリに最も類似した特徴量を数100msec以内に検索する必要があり,一般的なデータベースでは実現することが難しいという課題がありました.そこで,われわれは python で独自のインメモリデータベースを実装し運用してきました.このデータベースがサービスの成長に合わせて限界を迎えつつあるので,アルゴリズム

                                                                    Go vs Rust : 特徴量DBに適するのはどっち!? (2020-04-14 実験追記) - ABEJA Tech Blog
                                                                  • CPUキャッシュがGoのコードに与える影響(翻訳)|TechRacho by BPS株式会社

                                                                    繰り返しますが、正確な図はプロセッサモデルによって異なります。ここでは見積もりのため、以下の目安で考えます。メインメモリのアクセスに60ns(ナノ秒)かかり、L1キャッシュへのアクセス速度はその約50倍高速だとします。 さて、プロセッサの世界には「参照の局所性(locality of reference)」と呼ばれる重要な概念があります。プロセッサがメモリ上の特定の場所にアクセスするとき、以下のように予測を立てます。 近い将来、メモリ上の同じ場所にアクセスする可能性が非常に高い これは「時間的局所性(temporal locality)の法則」です 近い将来、メモリ上のその場所からごく近い場所にアクセスする可能性が非常に高い これは「空間的局所性(spatial locality)の法則」です CPUにキャッシュが存在する理由のひとつが、この時間的局所性です。では空間的局所性を高めるにはど

                                                                      CPUキャッシュがGoのコードに与える影響(翻訳)|TechRacho by BPS株式会社
                                                                    • プログラムのファイル読み書きで「mmap」を使うと速度が向上する理由とは?

                                                                      ソフトウェア開発において「ファイルの読み書き」は使用頻度の高い操作であり、速度の向上はソフトウェア全体のパフォーマンスに大きく影響します。そんなファイルの読み書き操作を行う際に「mmapを使った方が通常のシステムコールよりも高速にファイルを操作できる理由」について、ブリティッシュコロンビア大学の准教授であるAlexandra Fedorova氏が説明しています。 Why mmap is faster than system calls | by Alexandra (Sasha) Fedorova | Medium https://sasha-f.medium.com/why-mmap-is-faster-than-system-calls-24718e75ab37 OS上でユーザーがプログラムを実行する際、プログラムは「ユーザー空間」と「カーネル空間」と呼ばれる2種類の領域を利用します。

                                                                        プログラムのファイル読み書きで「mmap」を使うと速度が向上する理由とは?
                                                                      • DockerとPodmanの比較 [Container Runtime Meetup #3]

                                                                        Container Runtime Meetup #3 発表資料 「DockerとPodmanの比較」PodmanとはPodmanは、Red Hat社を中心とするコミュニティが開発している、Docker互換のコンテナエンジンです。RHEL、CentOS、Fedora などの Linuxディストリビューションに標準で付属しています。 Podmanの使い方は、コマンド名が docker ではなく podman である点を除けば、Docker とほぼ同じです。(例: podman run -p 80:80 --name nginx docker.io/library/nginx ) “Podman”は “Pod Manager” を意味しますが、Podmanを用いてKubernetesのPodを管理することは、基本的にはできません。ただし、CRIランタイムとしてCRI-Oを用いている場合に限り、

                                                                          DockerとPodmanの比較 [Container Runtime Meetup #3]
                                                                        • Engadget | Technology News & Reviews

                                                                          The sustainable tiny home trend at CES 2025 revived my dream of building a compoundAmid the chaos of CES we got to retreat to the well-appointed calm of sustainable pods, electric trailers and EV RVs.

                                                                            Engadget | Technology News & Reviews
                                                                          • Title Page - The Rust Performance Book

                                                                            The Rust Performance Book First published in November 2020 Written by Nicholas Nethercote and others Source code

                                                                            • そこのお前! 余計なuseMemo1個に含まれるオーバーヘッドは余計なdiv 0.57個分だぜ! - Qiita

                                                                              ※効果には個人差があります。 useMemoのオーバーヘッドについて ReactのuseMemoは、パフォーマンス最適化に使われるAPIです。コンポーネント内で計算やオブジェクトの生成を行う際に、以前の計算結果をキャッシュして使い回すことで再レンダリング時の計算を削減したり、新しいオブジェクトの生成を防ぐことができます。 useMemoに関しては、あくまで最適化のためのものであるから「無駄に使うべきではない」という言説がよく見られます。その理由は、useMemoのコストもゼロではなく、余計な使用はそれだけパフォーマンスの低下に繋がってしまうからです。 しかし、筆者はuseMemoのコストは微々たるものであり、本当に一目見て明らかに無駄でない限りは積極的に使うべきだと思っています。 そこで、筆者はuseMemoのオーバーヘッドがどれくらいかを調べるためのベンチマークを作成しました。この記事で

                                                                                そこのお前! 余計なuseMemo1個に含まれるオーバーヘッドは余計なdiv 0.57個分だぜ! - Qiita
                                                                              • RustのgRPCがGoよりも遅い?

                                                                                夏のある日、GoのgRPCが、Rustよりも2倍早いという記事を見つけました。「おいおい、測定ミスだろ」と強がっていましたが、日々、不安は高まっていきます。真実の愛であれば、疑うことは許されませんが、エンジニアの言語への愛など、所詮、状況に応じて使い分けるような打算的な愛。確認してみました。 性能測定結果上記の記事と同じく、gRPCのサーバソフトウェアは、Goはgrpc-go、Rustはtonicのgreeterの性能を、gRPCのクライアントソフトウェアghzを使って、測定しました。ハードウェアは、AWSを利用し、サーバはc5a.8xlarge(32 vCPU/64 GiB)インスタンス、クライアントはc5a.16xlarge(64 vCPU/128 GiB)インスタンスを使いました。 1台のクライアントインスタンスは、同時に3,000個のgRPCクライアントを立ち上げ、合計で6,000

                                                                                  RustのgRPCがGoよりも遅い?
                                                                                • Linuxにおける非同期IOの実装について - Qiita

                                                                                  はじめに Linux 5.1に新しい非同期IOの仕組みとしてio_uringがマージされてから既に1年以上経ってしまいましたが、これまでのLinuxにおける非同期IOの使い方や実装を見ていきながら、io_uringが登場した背景やLinux AIO(libaio)の問題点をどのように解決しているのかについてまとめました。アプリケーションの書き方については大まかにしか説明していないので、それについてはmanページや別の記事を参照してください。 またIOという範囲が広いのですが、ここではブロックデバイス上のファイルシステムにおける通常ファイルに対するread/writeについて考えています(ネットワークは考えていないのでepollの話はないです)。 前提知識 簡単に前提となる話をおさらいします。 同期IOと非同期IO IOを行うシステムコールとしてすぐに思いつくのはread(2)/write(

                                                                                    Linuxにおける非同期IOの実装について - Qiita

                                                                                  新着記事









                                                                                  ApplySandwichStrip

                                                                                  pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


                                                                                  --- a PPN by Garber Painting Akron. With Image Size Reduction included!

                                                                                  Fetched URL: http://b.hatena.ne.jp/q/Benchmark

                                                                                  Alternative Proxies:

                                                                                  Alternative Proxy

                                                                                  pFad Proxy

                                                                                  pFad v3 Proxy

                                                                                  pFad v4 Proxy