タグ

concurrentに関するa2ikmのブックマーク (37)

  • Ruby に Software Transactional Memory (STM) を入れようと思った話 - クックパッド開発者ブログ

    技術部でRubyインタプリタの開発をしている笹田です。コロナの影響で、リモート勤務などに移行し、新しい生活スタイルを満喫されている方々がたくさんいらっしゃるんじゃないかと思います。ただ、私は以前から自主的に自宅勤務することが多かったので、正直生活がぜんぜん変わっていません。 さて、家で私が何をしているかというと、Ruby 3の準備です。その中でも、数年取り組んできた Ruby で並列処理をするための仕組みである Ractor の開発をしています(以前は Guild というコードネームで呼んでいました)。Ractor という名前は、Ruby の Actor みたいな意味で付けました。Erlang とか Elixir で有名な Actor model というアレです。厳密には、Actor model でよく言われる特性をすべて備えているわけではないのですが、並列で動く Ractor を複数作る

    Ruby に Software Transactional Memory (STM) を入れようと思った話 - クックパッド開発者ブログ
  • 君たちの「並行」の理解は間違ってる

    TL;DR 並行計算の理解を間違ってる人が多いので正したい 並行計算=同時に実行すること 並列計算≒同等のタスクを並行計算すること もうちょっとちゃんと書いたフォローアップ記事も合わせて、お時間が許すようであればお読みください。 状況 並列と並行 / 多言語からみるマルチコアの活かし方に見られるように並行(concurrent)とは「複数の処理を順番に実行すること」とする誤った記述を、この記事に限らずチラホラ目にします。 大事になことなので繰り返しますが、間違った記述を含んでいるのはこの記事だけに限りません。 そのような誤った記述を見かけるたびに「ああこの人も間違ってるのか」と諦観を抱くだけというのもあまりに非生産的なので、間違ってますよとポインタとして示せるように簡単な読み物にしたものがこの記事です。 事実 計算=computingの分野においては並行=concurrentと並列=par

    君たちの「並行」の理解は間違ってる
  • Guild → Ractor

    Guild → Ractor ささだこういち Ruby 3 さみっと 2020/04/17 背景 • Ruby の 1 プロセスでは(基的には)並列処理できない • 同時に複数 CPU を使う処理 • Ruby(MRI)のThread == 並行処理 • マルチプロセスは難しそう… • そもそも Thread 難しい • 適切な同期漏れ • データレース • レースコンディション • デッドロック、ライブロック • 再現性がなくデバッグが困難 簡単に 並行・並列処理 したい! 間違いを起こさないためには? • スレッドを良い感じにサポート • 再現性をあげる(OS scheduler に手を入れるなど) • デバッグサポートを行う(Thread Sanitizer, helgrind, etc) • データの書き換えを禁止 • Erlang など • データ(オブジェクト)を共有しない

  • Writing a Ractor-based web server<!-- --> • Kir Shatrov

    Ractor, the new concurrency primitive in Ruby, has been merged to the upstream few days ago. I’ve been following that PR and watching the author’s talk at RubyKaigi (in Japanese, I wasn't able to find the translated version but it should be available somewhere), which got me excited to try Ractor myself. A web application server is the first thing that comes to mind when playing with concurrency.

  • goroutineがスイッチされるタイミング - Qiita

    goroutineがスイッチされるタイミングについて調べていました。 結論 Go言語で、goroutineは 必ずしも スイッチされるわけではない。 スタックに触れないような、「for(){}」みたいなビジーループをGOMAXPROCSの指定数以上に含ませるとスイッチされなくなる。 goroutineがスイッチされる(主な)条件はこれらと思われる。 - goroutineの関数が最適化でinline化されていない - スタックを操作するような処理を行った - (その他の契機もあるようなので「経緯」で書く) 経緯 処理のないビジーループが有ると、goroutineがスイッチされず処理が止まることに気づきました。 # 処理の中身を全部コメントアウトしてデバッグしていたら気づいた package main func busy() { for { } } func main() { go busy

    goroutineがスイッチされるタイミング - Qiita
  • atomicパッケージが必要な理由と使い方 - Plan 9とGo言語のブログ

    この記事はQiitaで公開されていました 以下のコードは通常分かりづらいバグを持っています。 package main import ( "fmt" "runtime" "sync" ) type Counter int32 func (c *Counter) Inc() { *c++ } func main() { var c Counter var wg sync.WaitGroup for i := 0; i < 1000; i++ { wg.Add(1) go func() { c.Inc() wg.Done() }() } wg.Wait() fmt.Println("Count =", c, "GOMAXPROCS =", runtime.GOMAXPROCS(0)) } このコードは、GOMAXPROCS の値が2以上の場合、最後にプリントされるカウンタが1000にならない場

    atomicパッケージが必要な理由と使い方 - Plan 9とGo言語のブログ
  • Unicorn vs Puma vs Passengerの比較まとめ | Scout APM Blog

    Rubyのアプリケーションサーバーのエコシステムは、Unicorn、Puma、Passenger 5 の3つを中心に出来上がっています。Rubyにおいて、アプリケーションサーバーが解決しなければならない具体的な問題はなんでしょうか。どのようにして最適なアプリケーションサーバーを選択すればよいでしょうか。2019年にはこれらのアプリケーションサーバーのニーズはあるでしょうか。 この記事ではこら全てを取り上げ、Rubyの主要なアプリケーションサーバーを比較していきます。 How important is an app server's raw speed? アプリケーションサーバーそのものの速度がアプリケーションの速度に対して多くの要因となることはほとんどありません。アプリケーションコード、データベースのクエリ、HTTPコールのRubyアプリケーションサーバーとの間の応答速度が、マイクロ秒ない

    Unicorn vs Puma vs Passengerの比較まとめ | Scout APM Blog
  • Lock-Free definitions galore

    We've talked before about the definition of Lock-Free, but there is a lot of confusion around its definition and the other definitions of Progress Conditions, so lets take a closer look at it. If you google a bit for the definition of Lock-Free, you'll see that there are several: Wikipedia: "An algorithm is lock-free if it satisfies that when the program threads are run sufficiently long at least

  • Go言語のio.Pipeでファイルを効率よくアップロードする方法

    パイプ(土管)をGo言語でも楽しめるはじめに前回はGo言語のmime/multipartパッケージによるファイルのアップロードを見ましたが、パフォーマンスの特徴にはあまり触れませんでした。 大規模なETLジョブや、制限の厳しいサーバーレスの環境などでは、ファイルを扱うプログラムのリソースを慎重に考える必要があります。記事ではメモリ使用量を大幅に減らすio.Pipeの使い方を見ていきます。 全てのコードはサンプルレポジトリにあります。 同期処理にある問題前回のコードをもう一度見てパフォーマンスを考えてみましょう。 // ファイルを開く file, _ := os.Open(filename) // リクエストボディのデータを受け取るio.Writerを生成する。 body := &bytes.Buffer{} // データのmultipartエンコーディングを管理するmultipart.W

    Go言語のio.Pipeでファイルを効率よくアップロードする方法
  • Go並行処理やり直し

    Go 並行処理やり直し 2019-04-20 Umeda.go 2019 Spring Yosuke Kumakura

    Go並行処理やり直し
  • Improving Ruby Concurrency

    Asynchronicity should be a property of how the program is executed, not what it does. Ruby currently implements mutually exclusive threads and exposes both blocking and non-blocking operations. It also supports Fibers which can be used to implement cooperatively scheduled event-driven IO. The cognitive burden of dealing with these different APIs is left as an exercise to the programmer, and thus w

    a2ikm
    a2ikm 2018/10/29
    “We present an approach to concurrency that scales well and avoids the need to change to existing programs. ”
  • innodb_thread_concurrencyに関する話 | GREE Engineering

    こんにちわ。せじまです。今回の話は軽く書こうと思っていたのですが、長くなりました。まぁInnoDBの話なのでしょうがないですね。 はじめ 今回はinnodb_thread_concurrencyについてお話しようと思います。できれば、事前にInnoDB の mutex の話(入門編)を読んでいただいた方が、より深く理解していただけるのではないかと思います。 長いので、最初に五行でまとめます 現代において、ほとんどのケースでは、innodb_thread_concurrencyはデフォルトの0のままで問題ないと思います。なぜなら、最近のInnoDBはかなり良くなってきたからです。 それでもinnodb_thread_concurrencyをチューニングするとしたら、「高負荷状態になったときでもスレッド間の公平性をなるべく担保し、安定稼働させるため」と割り切って使うのが良いでしょう。 inno

    innodb_thread_concurrencyに関する話 | GREE Engineering
    a2ikm
    a2ikm 2018/07/03
    良い記事
  • Go言語でTCPやソケット通信を多重化,高速化するsmux(ソケットマルチプレクサ)をつくった · THINKING MEGANE

    サーバ間で分散処理を行う際の相互通信におけるボトルネックを解消するため,smux(Socket multiplexer)を開発している. サーバ間の相互通信におけるボトルネックとその解決策 一対のサーバ間で多数のリクエストとレスポンスが送受信され,信頼性の高い通信としてTCPを利用する場合,コネクション確立のオーバーヘッドを排除するために接続の再利用が行われる.しかしながら,クライアントは送信に対する受信を待つ必要があるため,レスポンスまでに幾許かの処理時間を要する状況では送信のキューがたまってしまう.そこで複数の接続を利用することでこれを解消する方法が取られるが,追加の接続はリソース使用に関するオーバーヘッドを発生させてしまう.なにより各接続におけるレスポンス待ち時間は依然として解決しておらず,接続の利用面から見て非効率である.そこで,単一の接続において,仮想的に並行送受信を行う方法が提

    Go言語でTCPやソケット通信を多重化,高速化するsmux(ソケットマルチプレクサ)をつくった · THINKING MEGANE
    a2ikm
    a2ikm 2018/05/03
    HTTP/2が早々に頭打ちになってるのはヘッダとかの処理の差?
  • Go Concurrency Patterns: Pipelines and cancellation - The Go Programming Language

    Tips for writing clear, performant, and idiomatic Go code

    Go Concurrency Patterns: Pipelines and cancellation - The Go Programming Language
  • Lock, Concurrency and Throughput of Exclusive Operations

    Lock, Concurrency and Throughput of Exclusive Operations

    Lock, Concurrency and Throughput of Exclusive Operations
  • Rubyで並列処理をやっていく #AdventCalendar - ainameの日記

    mixiグループアドベントカレンダー2016 1日目です。 今回は、自分が今まで利用したRubyでの並列処理を書くためのgemとか知見を紹介します。 機運 先日のRubyKaigi 2016で、Ruby3ではGuildという新しい並列処理のモデル*1が、導入されるというセッションがあったり、concurrent-rubyというgemの開発が流行り初めて居たりと、Ruby界隈でも何となく並列処理がブームきているように感じます。 マルチプロセス/スレッド しかしRubyで並列処理するのは言語の仕様としてそれなりに制限があり、他の言語のようにThreadをバンバン立ててマルチコアで計算!爆速化!!みたいなのは難しいです。 というのも、Ruby1.9からネイティブスレッドは導入されたものの多くのC拡張を使ったgemのスレッドセーフ性が問題となるため、GIL(Global interpreter l

    Rubyで並列処理をやっていく #AdventCalendar - ainameの日記
  • Goroutineハンターが過労死する前に - Qiita

    Goroutineハンター、それは逃げ出したgoroutine達を捕まえるため、日夜戦い続けるエンジニア達のことである。Goroutineハンターは番環境でOOM Killerが発動するたびに呼び出され、逃げ出したすべてのgoroutineを捕まえるまで家にかえることが出来ない。しかし、あなたが書いた何気ないコードによって、今日もまた新しいgorutine達が野に放たれるのであった。 Goroutineリークとの戦い Goを使用してある程度規模のプログラムを書くと、必ず問題になるのがgoroutineのリークである。goで生まれたgoroutineが、何らかの理由で正常に終了しない場合、それは「リーク」していると見なされる。リークしたgoroutineはプロセスが続く限り永遠にリソースを手放さないため、リークしたgoroutineが蓄積するに従って、プログラムのパフォーマンスは低下してい

    Goroutineハンターが過労死する前に - Qiita
  • Go言語の並行性を映像化する | POSTD

    Goというプログラミング言語の強みの1つは、 Tony Hoare考案のCSP に基づくビルトインの並行性(Concurrency)です。Goは並行性を念頭にデザインされているため、複雑に並行したパイプラインの構築を可能にしています。でも、それぞれの並行性パターンがどのように見えるものなのか気になったことはありませんか。 もちろん、気になったことはあると思います。恐らくそれぞれ形は違っても、誰もが頭に描いているのではないでしょうか。もし、「1から100までの数字」について聞かれたら、無意識に頭の中で数字のイメージを思い浮かべると思います。例えば、私の場合、自分の前から1から20までがまっすぐに並び、21以降は90度右に曲がり1000以降まで続くイメージが浮かびます。これは多分私が幼稚園の時に教室の壁に沿って数字が貼られていて、ちょうど角に数字の20があったからなのだと思います。別の例えをす

    Go言語の並行性を映像化する | POSTD
  • Can Ruby Fibers be Concurrent?

  • MySQL5.6と5.7のちょっとした違いとinnodb_thread_concurrencyの影響 - hiroi10のブログ

    この記事はMySQL Casual Advent Calendar 2016の22日目です。 innodb_thread_concurrencyを最近のデフォルトである0と論理CPUコア数の2倍の48に設定した場合に観測出来た小ネタです。ベンチマークのtpsを載せていますが、1回しか取得してないので、割と誤差があると考えられるため、目安程度に見てください。 環境 CentOS 6.6(2.6.32-504.12.2.el6.x86_64) Xeon E5-2643 v2 3.5GHz x 2(2P12C24T) Memory 64GB (8GB x 8, DDR3 1866MHz) HDD SAS 300GB x 2 10k rpm(RAID1 BBU付き) FileSystem ext4 ベンチマークのデータ量はinnodb_buffer_pool_sizeに収まる量 メモリで殴るような

    MySQL5.6と5.7のちょっとした違いとinnodb_thread_concurrencyの影響 - hiroi10のブログ