タグ

stackに関するhiroyukimのブックマーク (5)

  • Go言語のスタックとヒープ

    GoCon 2013 Autumn で「Go言語のスタックとヒープ」という発表をしました。 資料はこちら: http://goo.gl/s6at62 スライドだけでは分かりにくい部分もあるので、ブロク記事として以下にも記しておきます。(この記事を読めば、スライドは読まなくてOKなはず) スタックとヒープについて 実行時に動的にメモリを確保する領域として、スタックとヒープがある。 スタックメモリは関数のコールスタックを格納していて、ローカル変数、引数、戻り値もここに置かれる。 スタックのPushとPopは高速なので、オブジェクトをスタックメモリに確保するコストは小さい。ただし関数を抜けてスタックがPopされると解放されるので、関数の寿命を超えてオブジェクトは生存できない。 一方のヒープメモリは、コールスタックとは関係ないので、関数スコープに縛られずにオブジェクトを確保しておける。ただし空き領

    Go言語のスタックとヒープ
  • Stackでやる最速Haskell Hello world! (GHCのインストール付き!) - Qiita

    昨日第23回Haskellもくもく会 @ 朝日ネットで初めてstackを触ったのですが、 あまりにも簡単・高速にパッケージ作りの準備ができたので、やったことを共有したいと思います。 GHC(Haskellの最も有名なコンパイラ)のインストールまでやってくれるので、これからHaskell始めます!みたいな人にもオススメです。 stack自体が何かは @tanakh さんのHaskellのビルドツール"stack"の紹介をご覧ください。 一言で言うと「GHCのインストールからパッケージのインストールにビルドまで、ワンストップでやってくれる神ツール」ですかね。 各OSごとに微妙に違うみたいなので、公式ページの解説をご覧ください。 とはいえ、基的には実行ファイルをPATHのどこかに置くだけなので、この手の作業に慣れている人には朝飯前でしょう。 1ファイルだけでインストールできちゃうのも魅力ですね

    Stackでやる最速Haskell Hello world! (GHCのインストール付き!) - Qiita
  • Stackを使って楽しくHaskellスクリプティング - Qiita

    今までいまいちモチベが上がらなかったHaskellでスクリプトを書くというのが、急に現実的になってしまったので、紹介します。 Haskellでスクリプティングする上での問題点 Haskellはもともと簡単なテキスト処理を書きやすいプログラミング言語ではあるのですが、標準で提供されているライブラリはあまり多くないので、必要に応じてコミュニティーパッケージを導入しなければその力を存分に発揮することができません。 通常のパッケージなら、cabalに依存関係を書けばパッケージマネージャで自動的に(コケることもありますが、理想的には)管理できるのですが、シェルスクリプトやPerl、あるいは最近ならPythonでやるような、コードを直接インタプリタで実行するような形のコードでは、そのような依存関係を自動で解決することは難しく、その上、仮にやろうとしたところで、いつまでもその依存パッケージが新しいコンパ

    Stackを使って楽しくHaskellスクリプティング - Qiita
  • Haskellのビルドツール"stack"の紹介 - Qiita

    Stackとは? つい先日のことですが、Stackage界隈からstackというツールがリリースされました。リリースされたとはいえ、開発され始めたのがちょっと前のことですし、現在も盛んに機能が追加されているので、絶賛開発中であるとかそういったほうがいいかもしれません。 まだ開発の始まったばかりのツールなのに、なぜこんな紹介記事を書こうと思ったのかというと、このツールがHaskellの開発において極めて有用になることが確定的に明らかであって、すでに荒削りながらも、大変便利に使えているからなのです。そしてここで紹介することで、多くの読者の方に興味を持ってもらって、それで開発がさらに盛り上がっていくと嬉しいなあと、そう思った次第であります。 なお、stackの開発が始まる少し前に、stackage-cliを始めとするいくつかのツールがリリースされましたが、今後開発はstackに一化されるような

    Haskellのビルドツール"stack"の紹介 - Qiita
  • memologue - g++ でのスタック使用量の動的解析

    Linux Memory Overcommitment の話とも関係するが、組み込み機器向けのプログラムを設計・実装する際は、たとえターゲットがMMU/仮想記憶を利用できるモノであるとしても、使用するスタック量の見積もりくらいはしておきたいと思っている。 UNIXではsetrlimit(2)で、スタック使用量をunlimitedにしてしまえば、スタック使用量の自主制限にひっかかってsegvすることはなくなる。ちなみに ulimit -s での制限は、Linuxであってもstrictに効く。しかし、物理的な限界は確実に存在するわけで、スタックのある領域にアクセスした時に物理ページに空きがなければ、プロセスはSIGSEGVで死ぬかSIGKILLで殺されてしまう。 C言語で書かれたプログラムであれば、再帰や関数ポインタさえ上手に処理(コーディング標準で制限など)できれば、コードを静的に解析して最

    memologue - g++ でのスタック使用量の動的解析
    hiroyukim
    hiroyukim 2015/06/25
    “Linux Memory Overcommitment の話”
  • 1