benchmarkに関するt2y-1979のブックマーク (76)
-
t2y-1979 2023/11/10
-
Pythonコードを35000倍に高速化したい
はじめに Pythonは世界的にも人気のあるプログラミング言語ですが、実行速度については課題があります。Pythonの実行速度を高速化したい、という要求は根強く、これまでにも様々な処理系が開発されています。 この記事はPythonで書かれたコードを35000倍に高速化するにはどのような方法があるかについてまとめたものです。 この記事は： Pythonで書かれたアルゴリズムを35000倍に高速化する 事前コンパイル、並列化、SIMD演算を駆使する 最終的に44000倍まで高速化できた なぜ35000倍？ 2023年5月2日にModular社よりPythonの使いやすさとC言語の性能を兼ね備える新しいプログラミング言語、Mojoの開発について発表がありました。低レベルのハードウェア向けにコンパイル可能なこと、文法的にはPythonを踏襲しており、既存のPythonライブラリを利用可能であること
-
改めて見直すGoの特徴
極力Goならではな特徴をいくつか挙げていく。 依存解決が必要最低限で互換性を考慮しつつ決定的 モジュール単位で依存をダウンロード。コンパイル対象はサブパッケージ単位。 依存の明示方法はコードに埋め込まれ、かつ未参照のインポートはコンパイルエラー。 つまり動作するコードのすべては正確な依存ツリーが明示されていて余計な依存は引き込まれない。 そして持ち前のコンパイルの速さを含め、相当深い依存ツリーでも依存解決にかかる時間は既知の処理系の中でも最速レベル。（唯一勝てるのはプリビルドバイナリが配布されている場合くらい） また、コンパイルやリンクに必要な処理量そのものが比較的少ないため、開発環境負荷も小さい。 かなり巨大なプロジェクトであってもメモリ8GBで困るようなことが無い。つまり、CI環境の維持にもローコストで済む。 ライブラリの提供側では後方互換性が破壊されるような変更はV1->V2というよ
-
-
Python 3.11の新機能(その1） CPython高速化計画 - python.jp
今年も、Pythonのメジャーリリースの季節がやってまいりました。2022年10月3日にリリース予定となっているPython 3.11の新機能を紹介します。 CPython 高速化計画¶Python 3.11で最大のニュースは、なんと言っても Faster CPython: CPython 高速化計画 が開始されたことでしょう。 CPython 高速化計画は、Mark Shannon氏が提案したプランに基づいてPythonの高速化を行うもので、Pythonを毎年50%高速化し、互換性を保ちつつ 4年間で5倍高速化する ことを目標としています。 この計画はMicrosoft社の出資を獲得し、Pythonの父であるGuido van Rossum氏も加わって開発が進められています。 ベンチマーク¶さて、CPython 高速化計画最初のリリースとなるPython 3.11では、どの程度の高速化が
-
Sustainability with Rust | Amazon Web Services
AWS Open Source Blog Sustainability with Rust Rust is a programming language implemented as a set of open source projects. It combines the performance and resource efficiency of systems programming languages like C with the memory safety of languages like Java. Rust started in 2006 as a personal project of Graydon Hoare before becoming a research project at Mozilla in 2010. Rust 1.0 launched in 20
-
-
Go 言語でスライスから要素を消すには
の様に直感的な操作ができるはずです。しかし Go 言語の場合、スライスの伸長にて発生するメモリアロケーションを append 関数と代入を使う事で透過的に行える仕組みを採用しています。例えばスライスの伸長は この様に行います。C言語をかじった事のある方や、プログラミング言語の内部データ構造をご存じの方であれば、リストといった物が伸長の度にメモリを再確保する様な事をやっていない事はご存じだと思います。Go 言語のスライスも同様で、スライスには長さとキャパシティを持っており、キャパシティを超えない範囲で長さだけが増えていき、キャパシティを超えるとメモリが再確保されるという作りになっています。ですので、上記のコードであれば、スライス(実際は SliceHeader)が内部で持っているポインタ、長さ、キャパシティを、代入してやる事で上書きしています。 スライスから要素を消す スライスの伸長と同様に
-
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(
-
WebAssembly Is Fast: A Real-World Benchmark of WebAssembly vs. ES6
WebAssembly Is Fast: A Real-World Benchmark of WebAssembly vs. ES6 Disclaimer: All opinions thoughts / work were made personally by me and do not represent any of my employer’s thoughts or work. Edit (12/21/18): Added Firefox performance bug / issue IntroductionWhen developing for the web, there have been plenty of times where I couldn’t bring my idea to fruition due to browser performance. Browse
-
Why You shouldn’t use lodash anymore and use pure JavaScript instead
So why shouldn’t you use lodash? Here are two main issues. SpeedThe first and most important thing is speed. Because performance really matters for a good user experience, and lodash is an outsider here. We’ll look at two scenarios using features such as find and reduce. And compare them with JavaScript analogues. To calculate the time difference, we will use the built-in Date constructor. (All ca
-
Benchmarking low-level I/O: C, C++, Rust, Golang, Java, Python
This post is a continuation of Measuring network service performance. When my computer doesn’t have an Internet connection, I find that there is not much I can do with it. Indeed, we mostly use our laptops and smartphones to access information stored or generated somewhere else. It’s even hard to imagine the utility of non-user facing apps without network communication. While the proportion of I/O
-
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し
-
Pyston v2: 20% faster Python
We’re very excited to release Pyston v2, a faster and highly compatible implementation of the Python programming language. Version 2 is 20% faster than stock Python 3.8 on our macrobenchmarks. More importantly, it is likely to be faster on your code. Pyston v2 can reduce server costs, reduce user latencies, and improve developer productivity. Pyston v2 is easy to deploy, so if you’re looking for b
-
Presto Experiment with Graviton Processor
This December, AWS announced new instance types powered by Arm-based AWS Graviton2 Processor. M6g, C6g, and R6g are designed to deliver up to 40% improved price/performance compared with the current generation instance types. We can achieve cost-effectiveness by using these instance type series. Presto is just a Java application, so that we should be able to run the workload with this type of cost
-
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
-
Benchmarking Go, Crystal, Python and JavaScript
Benford’s Law⌗ After watching a Netflix documentary about Benford’s Law (“connected” Season 1 Episode 4 “Digits”), I got really interested in it because it can help detect fraud in e.g. balance sheets. So I searched my favorite programming languages and detected that there is no npm Package for checking Benford’s Law. Sooo … Long story short: I created nearly identical libraries for doing a Benfor
-
Benchmarking Apache Kafka: 2 Million Writes Per Second (On Three Cheap Machines)
Benchmarking Apache Kafka: 2 Million Writes Per Second (On Three Cheap Machines) I wrote a blog post about how LinkedIn uses Apache Kafka as a central publish-subscribe log for integrating data between applications, stream processing, and Hadoop data ingestion. To actually make this work, though, this "universal log" has to be a cheap abstraction. If you want to use a system as a central data hub
-
Async Python is not faster
50th and 99th percentile response times are in milliseconds, throughput is in requests per second. The table is ordered by P99, which I think is perhaps the most important real world statistic. Note that: The best performers are sync frameworks but Flask has lower throughput than others The worst performers are all async frameworks Async frameworks have far worse latency variation Uvloop-based opt
-
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
