Rubyの並列並行処理のこれまでとこれから - クックパッド開発者ブログ
技術部の笹田です。今日で退職するので、バタバタと返却などの準備をしています。 本記事では、Rubyの並行並列処理の改善についての私の取り組みについて、おもに RubyKaigi 2022 と 2023 で発表した内容をもとにご紹介します。 並行と並列はよく似た言葉ですが、本記事では次のような意味で使います。 並行処理（concurrent processing）は、「複数の独立した実行単位が、待っていればいつか終わる（もしくは、処理が進む）」という論理的な概念で、古典的にはタイムシェアリングシステムなどが挙げられます。 並列処理（parallel processing）は、「複数の独立した実行単位のうちのいくつかが、あるタイミングで同時に動いている」という物理的な概念で、古典的には複数のCPU上で同時に実行させる、というものです。最近では、1つのCPU上で複数コアが同時に動いている、という
SQLite、複数クライアントからの同時書き込みを可能にする「BEGIN CONCURRENT」文を実装へ
SQLite、複数クライアントからの同時書き込みを可能にする「BEGIN CONCURRENT」文を実装へ SQLiteの開発チームは、複数クライアントからの同時書き込みを可能にするBEGIN CONCURRENT文を実装していることを明らかにしました。 これまでSQLiteでは書き込みの同時実行はできず、つねに1つのクライアントだけが書き込み可能でした。 同時書き込み処理は、データベースのジャーナルモードが「wal」（Write-Ahead-log）もしくはwalを改良した「wal2」で、BEGIN CONCURRENT文を実行した場合に可能となります。 どのように同時書き込み処理が行われるのかについては、上記のWebページの説明を引用しましょう。 ロックが延期されることで同時書き込みが可能に まず、書き込み時のロックがCOMMITまで延期されることで同時書き込みが実現されると説明されて
JestとVitestのisolateについて
現状 Vitest が Jest など他のテスティングフレームワークに比べて遅くなる場合があることがわかっています。 (確実に遅くなるとはいえない。が、私自身もテストの速度が遅くなったことを経験しています。) また Vitest を実行する場合、--single-threadオプションをつけると速くなるということもわかっています。 (0.29.0以前は --no-threads) 公式 Docs にも最大３倍速くなることが記載されています。 WARNING This option is different from Jest's --runInBand. Vitest uses workers not only for running tests in parallel, but also to provide isolation. By disabling this option, yo
Concurrent JavaScript: It can work!
With the recent addition of SharedArrayBuffer, concurrency is finding its way into the JavaScript language. This addition allows JavaScript programs to perform concurrent access to SharedArrayBuffer objects. WebKit supports SharedArrayBuffer and it has full optimization support in our compiler pipeline. Unfortunately, JavaScript does not allow any objects other than SharedArrayBuffer to be shared.
えっちな grep をつくった - はやくプログラムになりたい
H(uman-friendly) な grep コマンド hgrep をつくりました． github.com '\w+ で検索した時の出力 ファイルを特定のパターンで検索し，マッチした箇所を構文ハイライトしたコード片で表示します．超ざっくり言うと，ripgrep で検索して bat でマッチ箇所付近を表示するような感じです． grep -C によるコンテキスト表示に似ていますが，マッチ行が近い時は1つのコード片にまとめる，周囲何行を表示するかをヒューリスティックに少し賢く決めているなど，ちょっと出力は工夫しています． 動機 手元のリポジトリでコードを検索する時は 単純に grep で検索してマッチ結果を眺める grep | fzf のように検索結果を fzf で絞り込んだりプレビューする vim $(grep -l ...) のように検索結果をエディタで開く あたりを使い分けているのですが
ZIO | ZIO
Type-safe, composable asynchronous and concurrent programming for Scala
API を 1 回だけ呼んであとは同じ結果を得たい場合、値ではなく Promise をキャッシュする - Qiita
REST API の呼び出し結果を、集中的に何度も使いたいような場合、API のレスポンスをキャッシュするのではなく、Promise をキャッシュすることで、API が 1 回だけ呼ばれることを保証できます。 何もキャッシュしない場合 まず最初に、何もキャッシュしない場合を見てみます。 import axios from 'axios' class App { /** * API に GET リクエストを送信するメソッド。何もキャッシュしないバージョンです。 */ async request(url) { return await axios.get(url) } /** * API を使ってなにかするメソッドです。 */ async doSomethingWithAPI(url, index) { const result = await this.request(url) consol
monad-par
The Par monad offers a simple API for parallel programming. The library works for parallelising both pure and IO computations, although only the pure version is deterministic. The default implementation provides a work-stealing scheduler and supports forking tasks that are much lighter weight than IO-threads. For complete documentation see Control.Monad.Par. Some examples of use can be found in th
Accelerateとglossで作るライフゲーム - Qiita
やっぱり並列計算したいじゃないですか。でも「イチからディープラーニング組むぜ！！」というのも流石に無謀がすぎるのでライフゲームの盤面計算をAccelerateでやり、表示をglossでやってみました。glossについてはこちらの記事を参考にしました。 glossではじめるグラフィック描画 :: Haskell入門の次に読む記事 - Qiita - https://qiita.com/lotz/items/eb73e62a64bc208c2dd6 GPUじゃなしにIntel Core i7-8550U 8コア 4GHzでも5120x5120のライフゲームを秒間30回くらいまで計算できました。こちらのソースコードを元に解説していきたいと思います。 使うモジュールはこんな感じ。 import Data.Array.Accelerate as A import Data.Array.Acceler
Pinpointing deadlocks in Haskell - FP Complete
Concurrent programming is hard! I still remember the moment of my introduction to multi-threaded programming at the University of New Mexico, our professor grabbed his head and said: “Here be demons!”. There are all sorts of issues that arise in a concurrent setup, such as race conditions, starvation, deadlocks, data corruption, you name it. All of these are also applicable to Haskell, and in this
JavaScript のスレッド並列実行環境
これは Chromium Browser アドベントカレンダーの十日目の記事です。本記事では Chromium における JavaScript のスレッド並列実行環境について仕様・実装・API の面から包括的に紹介します。ブラウザの内部実装に興味がある人を対象に、各機能の使い方ではなく実行モデルに焦点を当てて説明しているため、難易度は高いです。使い方を知りたい人は MDN などの記事を読んでください。この記事をきっかけに実装解読に挑戦してみる人が一人でも増えると幸いです。 本記事を書くにあたり、yuki3 さんに多くのコメントをいただき、議論に付き合っていただきました。ありがとうございました。なお、文責はすべて私 (nhiroki) にあります。誤りや補足、質問などは気軽に GitHub Issue もしくは Twitter へお寄せください。 更新履歴 2018/01/15 Layout
Haskell における並行処理と並列処理と最適化 - Qiita
TL;DR 並列処理はかなり有効 並行処理もそこそこ有効（forkIO） 並列処理に迫る並行処理もあった（async） はじめに Haskell で処理をマルチコアに分散したい場合どのようにすればよいかをまとめておきます。 負荷のかかる処理としてフィボナッチ数の導出を以下のように行うことにします。
Haskell の並列処理と遅延評価の罠 | Webシステム開発／教育ソリューションのタイムインターメディア
少し前までは Haskell はインストールが非常に手間がかかる上に、ライブラリ類のバージョン整合性をとるのが非常に困難なのが大きな欠点だったのだが、 Stack なるビルドツールが現れてからはその点が一気に解消されて大変便利になった。コンパイル時に様々な問題を一気に洗い出してくれる Haskell は、書いている自分でも驚くほど正しく動くし、変更にも強い。言語の選択はもちろん適材適所なので一概には言えないが、堅牢なプログラムを素早く書くという観点ではお勧めできる言語だ。 しかし一方で、Haskell で書かれたプログラムにはパフォーマンスバグ（時間、空間、あるいはその両方）が含まれていることも多い。ビルドさえできればたいてい「正しく動く」が、意図したパフォーマンスが得られなかったり、余計なメモリを消費し続けたりといったことでは片手落ちである。 今回は、そんななかでも並列プログラミングを行
高速なキューを作る話（後編） - Qiita
前編の続きです。前編ではChan.Unagiには以下の欠点があることを解説しました。 読み出しを行うスレッドに対する非同期例外の扱いが面倒 データがすぐにGCされない 後編では、Chan.Unagiの欠点を克服したキューを作るやり方について解説します。 不要になったデータをGCできるようにする まずは簡単な方から解決していきましょう。 Chan.Unagiで読み出し終わったデータをMutableArrayから削除できないのは、Chan.Unagiがチャネル（書き込まれた値を複数のキューに書き込まれたかのように読み出す機能を持つ）であるためでした。 であるならば話は単純です。作りたいのはチャネルではなくキューなのでデータを削除すればよいのです。 具体的には、MutableArrayに入れるデータ型の定義に読み出し終わった状態を追加し、読み出し処理の終わりに、この値を書き込めば解決です。 この
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - lehins/scheduler: A work stealing scheduler
GitHub - dtaskoff/skip-var: Implementation of skip variables (a special case of skip channels)
GitHub - roman/Haskell-capataz: OTP-like supervision trees in Haskell
GitHub - mcschroeder/ttrie: A contention-free STM hash map for Haskell
GitHub - facebook/infer: A static analyzer for Java, C, C++, and Objective-C
GitHub - nshimaza/thread-hierarchy: Simple Haskel thread management in hierarchical manner