タグ

architectureとhaskellに関するnsyeeのブックマーク (6)

  • GHC STM Notes

    Note: this document now lives here Introduction This document give an overview of the runtime system (RTS) support for GHC's STM implementation. We will focus on the case where fine grain locking is used (STM_FG_LOCKS). Some details about the implementation can be found in the papers "Composable Memory Transactions" and "Transactional memory with data invariants". Additional details can be found i

  • I/Oストリーミングライブラリの実装の基礎 - 後編 - Pixel Pedals of Tomakomai

    前回の続きである。予告通り、2つのストリーミングの「出力」と「入力」をつなげる処理、そして、ストリームの命令列を解釈する処理系を実装する。 2つのストリームを1つにする(考え方) 「出力」と「入力」をどうくっつけるといいのか。それぞれのストリームは命令の列なので、2つの命令の列があると考えられる。ちょっと考えると、これらをうまく並べ替えることで、1つの命令の列を作れることがわかる。 例えば、「Notify(1), Wait(2), Done(3)」という列の出力を、「Wait(4), Notify(5), Done(6)」という2つの列の入力につなぐことを考えよう。様々な処理をつなげる場合、取り出したい演算結果は下流で生成されると考えられるだろう。そこで、合成後の命令の列は下流のWait(4)から開始される。Wait(4)では上流からのデータを期待するので、次は上流の命令であるNotify

    I/Oストリーミングライブラリの実装の基礎 - 後編 - Pixel Pedals of Tomakomai
  • I/Oストリーミングライブラリの実装の基礎 - 前編 - Pixel Pedals of Tomakomai

    conduitやpipesなどのストリーミングライブラリの実装は結構わかりにくい。Pipes to Conduitsという一連のエントリが分かりやすい解説なのだが、それでも序盤からFunctorやFreeモナドを駆使していてハードルが高めな印象を受ける。 理解するには自分で実装するのが一番の近道だろうから、このエントリでごく簡単なストリーミングライブラリを実装してみよう。ストリーミングライブラリではI/Oを扱うのが目的であるため、来であればモナドを扱えるように実装しなければ意味がないのだが、ストリーミングの基的な仕組みとしてはモナドは重要ではないので、ここでは純粋な値のみを扱うストリームを作成する。 ストリームを表す型 ここが一番重要かつわかりにくい部分だと思われる。今回の実装では、「入力」「出力」「結果」の3つの型をストリームで利用する。が、「出力」と「結果」の違いとはいったいなんな

    I/Oストリーミングライブラリの実装の基礎 - 前編 - Pixel Pedals of Tomakomai
  • The Architecture of Open Source Applications (Volume 2)The Glasgow Haskell Compiler

    Figure 5.3: The syntax of Core A typical structure for a compiler for a statically-typed language is this: the program is type checked, and transformed to some untyped intermediate language, before being optimised. GHC is different: it has a statically-typed intermediate language. As it turns out, this design choice has had a pervasive effect on the design and development of GHC. GHC's intermediat

  • 高速WebサーバMighttpdのアーキテクチャ | IIJの技術 | インターネットイニシアティブ(IIJ)

    IIJ-II技術研究所では、2009年の秋からMighttpd(mightyと読む)というWebサーバの開発を始め、オープンソースとして公開しています。この実装を通じて、マルチコアの性能を引き出しつつ、コードの簡潔性を保てるアーキテクチャにたどり着きました。ここでは、各アーキテクチャについて順を追って説明します。 ネイティブ・スレッド 伝統的なサーバは、スレッド・プログラミングという手法を用いています。このアーキテクチャでは、1つのコネクションを1つのプロセスかネイティブ・スレッドが処理します。 このアーキテクチャは、プロセスやネイティブ・スレッドを生成する方法で細分化できます。「プール」方式では、あらかじめ複数を起動しておきます。例としては、Apacheのpreforkというモードが挙げられます。「都度」方式では、コネクションを受け取るたびに生成します。このアーキテクチャの利点は、制御を

    高速WebサーバMighttpdのアーキテクチャ | IIJの技術 | インターネットイニシアティブ(IIJ)
  • 1