haskellと高速化に関するigrepのブックマーク (22)
-
igrep 2023/04/07
-
Tuning Haskell RTS for Kubernetes, Part 1
We’re running Haskell in production. We’ve told that story before. We are also running Haskell in production on Kubernetes, but we never talked about that. It was a long journey and it wasn’t all roses, so we’re going to share what we went through. TL;DRConfigure Haskell RTS settings: Match -N⟨x⟩ to your limits.cpuMatch -M⟨size⟩ to your limits.memoryYou can set them between +RTS ... -RTS arguments
-
モナドオリンピック1-トラック競技-
はじめに 最速のモナドを決めるモナドオリンピックを開催することになりました。 この大会では、各ライブラリの提供するモナドたちが 様々な競技（ベンチマーク）に挑戦します。 競技説明 今回は副作用のないシンプルなベンチマークで計算速度を測ります。 ベンチマーク おなじみのfibをつかいます。普通のfibは返り値が整数型ですが、次の理由から偶奇を表すブール値にしています。 Int型にするとReaderモナドやIdentityモナドで返り値がUnboxingされて有利になりすぎる。 Integer型にすると演算にかかる時間が無視できない xor :: Bool -> Bool -> Bool xor True x = not x xor False x = x fib :: Monad m => Int -> m Bool fib = go where go n | n <= 1 = pure $
-
-
-
Developing QUIC Loss Detection and Congestion Control in Haskell - あどけない話
For last two months, I have been trying to implement "QUIC Loss Detection and Congestion Control" in Haskell. This blog article describes a brief summary on what I have done. ACK handling Before loss detection and congestion control were developed, QUIC packets were retransmitted, if necessary, by a simple resender lightweight thread based on timeout. The internal data structure was, of course, Pr
-
Fixing Space Leaks in Ghcide
Summary: A performance investigation uncovered a memory leak in unordered-containers and performance issues with Ghcide. Over the bank holiday weekend, I decided to devote some time to a possible Shake build system performance issue in Ghcide Haskell IDE. As I started investigating (and mostly failed) I discovered a space leak which I eventually figured out, solved, and then (as a happy little acc
-
-
-
RULESによるコンパイル時プログラミング - www.kotha.netの裏
これはHaskell Advent Calendar 2013の(3+π)日目の記事です。 (3 + pi)や(quot 7 8)のような単純な定数式は、ghc -Oが行なう定数畳み込みによってコンパイル時に計算される。uncurry (*) (3, max 5 2)のようなやや複雑な式も、インライン展開してから定数畳み込みをすることでやはりコンパイル時に整数リテラルにまで簡約される。 これは一見万能だが、再帰的な関数が一つでもあると何もできなくなる。GHCが再帰関数をインライン化しないからだ。(sum [1])ですら実行時のループにコンパイルされる*1。 どうしてもコンパイル時に計算してほしい関数がある場合はどうしたら良いか。一つの方法はTemplate Haskell(ja)を使うことだが、特別な構文を使わなければいけないこと、-fwarn-unused-binds(ja)をはじめとし
-
最強にして最速のビルダー、mason - モナドとわたしとコモナド
Haskell Advent Calendar 2019 5日目 この冬、神速のサンタクロースがやってくる—— Haskellにおいて、バイト列の表現はByteStringが定番である。ByteStringはPinned領域に直接格納され、空間効率はリストに比べればはるかに良い。しかし、Pinned領域にあるとヒープフラグメンテーションが起こりやすくなるということでもあり、細かい文字列をつなぎ合わせるような使い方はパフォーマンスに悪影響が及ぶ。そのような問題を避けるため、ビルダーと呼ばれる構造が用意されている。 Data.ByteString.Builderは、word8 42 <> byteString "hello" <> doubleLE 42のように細かいプリミティブを連結し、toLazyByteStringを呼ぶと最後にByteStringを一気に鋳出せるという仕組みである。By
-
-
Beating C with 80 lines of Haskell: wc
Despite the click-bait title I hope you'll find this post generally illuminating, or at the very least a bit of fun! This article makes no claims that Haskell is "better" than C, nor does it make claims about the respective value of either language, or either implementation. It's simply an exploration into high-performance Haskell, with a few fun tricks and hacks along the way. You can find source
-
HIW 2019で発表された、Gibbonコンパイラーについて - Haskell-jp
前回から引き続き、Haskell Implementors’ Workshop 2019への参加レポートとして、私の印象に残った発表を紹介します。 今回は、Gibbonという、GHC以外のHaskell（の、サブセット）の処理系についての発表です。 Link to hereThe Gibbon Compiler: Accelerating a small subset of Haskell 発表者: Ryan R. Newton Indiana University, Michael Vollmer Indiana University, USA, Chaitanya Koparkar Indiana University Gibbonは最適化の手法を研究するために作られたコンパイラーです。 具体的には、我々（特にHaskeller）がよく使う、木構造全体に対する処理の最適化です。 こうし
-
Haskell のリストを左結合で連結すると効率が悪い理由 - Qiita
[1,2,3] ++ [4,5,6] = 1 : ([2,3] ++ [4,5,6]) = 1 : (2 : [3] ++ [4,5,6]) = 1 : (2 : (3 : ([] ++ [4,5,6]))) = 1 : 2 : 3 : [4,5,6] 上記のように展開されていきます。 つまりこの関数は、 左のリストを a:b:c: ... :[] の形に展開していく 最後の [] を右のリストに置き換える という手順を踏んでいることに注目してください。 効率の悪い (a ++ b) ++ c をこの手順に則って見ていくと、 括弧がついてるので、 a ++ b を先に評価する a を展開する a の末尾の [] が b になり、新しいリスト ab ができる ab ++ c を評価する ab を展開する (a にあった要素も、もう一度展開される) ab の末尾の [] が c になり、新しい
-
foldr under the hood
Summary: The foldr function seems simple, but is actually very complex, with lots of layers. This post dives through the layers. The foldr function takes a list and replaces all : (cons) and [] (nil) values with functions and a final value. It's available in the Haskell Prelude and described on Wikipedia. As some examples: sum = foldr (+) 0 map f = foldr (\x xs -> f x : xs) [] But the simple foldr
-
Haskellで解くAtCoder
最近HaskellでAtCoderの問題を解いたりしているのでごく基本的な知見をまとめておく。 テクニック集 多くは割と色んな人がすでに言っていることではある。また、想定解法を正しく実装すれば以下のようなことを守らなくても時間内に収まるだろうが、GHCは最適化が効かなければ10倍遅くなる言語であるので普段から守っておくに越したことはないと思う。 環境: AtCoderのGHCは2019.04現在7.10なので注意が必要。そのうち上がるかもしれないけど。 Strict拡張がない BangPatterns拡張はある 環境構築がhaskell-platformらしいのでそれに入ってるライブラリしか使えない 文字列 基本はData.ByteString.Chan8 Stringは死んでも使わない(遅いので) Unicode文字列の扱いが必要(今の所みたことないけど)とかならtextを使うといいかも
-
-
Henri's Blog - Making Haskell as fast as C: Imperative programming in Haskell
Posted on July 30, 2018 - Discussion - All posts By Henri Verroken Implementing efficient and fast data structures in Haskell is not straightforward. A functional implementation of an abstract data type is often orders of magnitude slower than an imperative solution that provides the same functionality. This blog post compares several implementations of a concrete and relatively simple abstract da
-
Haskell のパフォーマンスをデバッグする
Posted on December 27, 2017 translated by Kotaro Ohsugi authored by Matt Parsons Great original post: Haskell Performance Debugging. 2017年 12月 18日 Matt Parsons 誰かが reddit に Treap の実装が遅い と投稿していました。それを分析して、何が起きているのかを考えてみましょう。 レポジトリはここにあります。 最初の実行 Cabalプロジェクトを作り、makefile を作ります。そして、最初のプロファイルを取ります。コードとプロファイル結果は GitHub の masterブランチにあります。 実行されているコードやプロファイル結果を見る前に、質問のデータ構造の定義を確認しておきましょう: これをプロファイリングしつつビルド
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
