タグ

ブックマーク / tanakh.jp (7)

  • Run Rust code on PEZY-SC processor - 純粋関数空間

    これはRust その2 Advent Calendarの16日目の記事です。日付と投稿日がかみ合っていなくてすみません。 概要 PEZY-SCというメニーコアプロセッサーでRustのコードを動かしてみたというお話です。 PEZY-SCとは PEZY-SCとは、PEZY Computingが開発したメニーコアプロセッサーです。1024コアのRISCプロセッサーで、各コア8スレッドのSMTになっており、トータルで8192スレッドが同時に動きます。ピーク性能は倍制度1.5TFlops、単精度3TFlopsで、これを用いたシステムが電力効率の良いスパコンとしてGreen500などで良い成績を収めています。現在さらに性能を向上させたPEZY-SC2を開発中です。 高い演算スループットと電力効率を目指しながらも、SIMDを用いない完全なMIMDプロセッサーで、ある意味コンピューター科学の常識に反してい

    xef
    xef 2016/12/20
  • 最近のWindowsの開発環境のセットアップ - 純粋関数空間

    周囲にWindowsユーザがめっきり減ってきた昨今ですが、 Windowsユーザの皆様はいかがお過ごしでしょうか。 Windows8は使えないだの、 シェルがしょぼいからあれだのと言われることも多いですが、 圧倒的にたくさんのPCで安心して動かせるOSとして、 私個人としてはとても便利に使っています。 Let’snoteのCF-S10Dという2年ほど前の機種を使っているのですが、 ようやくPanasonicのWindows8サポートがこの機種までやってきたので、 Windows8に入れ替えることにしました。 実は発売当初にもWindows8を入れていたのですが、 Let’snoteを快適に使うには必須の、「くるくるホイール」が使えなかったり、 謎の認識されないデバイスがあったりだったので、 Windows7に戻していました。 というわけで、セットアップついでにそのときの記録を書いておこうと

    xef
    xef 2013/05/31
  • Introduction to Fay - 純粋関数空間

    Fay をいじってみたので、 せっかくだから記事を書いておこうと思います。 なお、Fayは新しい言語(というより、処理系と言った方が適切かな)ですので、 ここに書いてある情報は、来年か、あるいは半年後か、 それとももっとずっと早くに陳腐化する可能性がそれなりに低くないことを、 あらかじめお断りしておきます。 この記事執筆時に用いたFayのバージョンは、 fay-0.14.5.0 です。 デモ・前置き 特に何か作りたいものが有ったわけではなかったので、 今回作ってみたものは超どうでも良いツールです。 http://tanakh.jp/tools/sudden.html _人人人人人人_ > 突然の死 <  ̄Y^Y^Y^Y^Y ̄ こういうテキストを生成するだけのツールです。 Fayのコード HTMLコード これらのコンパイルなどもhakyllでまとめて管理できるようにしました。 hakyllに

  • Beautiful Error Handling

    Beautiful Error Handling 田中英行 <tanakh@preferred.jp> 2012年夏のプログラミング・シンポジウム 自己紹介 田中英行 (@tanakh , http://tanakh.jp ) (株)Preferred Infrastructure勤務のプログラマ Haskell 愛好家 BASIC(20年), C++(15年), Haskell(10年) 「すごいHaskellたのしく学ぼう!」 (Learn You a Haskell for Great Good! の和訳) 好評発売中!! 概要 エラー処理に美しさを! エラー処理の抽象化 Haskellでのアプローチ エラー処理に美しさを! 背景 エラー処理は醜くなりがち なんで汚くなるのか? これまで適切な抽象化が行われて来なかったから なぜそういう状況になっているのか? 大きな原因の一つはプログ

    xef
    xef 2012/08/26
  • ConduitとHaskellでネットワークプロキシサーバを作る - 純粋関数空間

    この記事は http://www.yesodweb.com/blog/2012/06/conduit-0-5 の翻訳です。 conduit-0.5 をリリースしました。 conduitはストリームデータを扱うためのライブラリです。 conduitを用いると、様々な形のデータを生成、変形、消費するような処理を、 簡単に組み合わせることができるようになります。 enumerator/iterateeパラダイムと同じ問題を解決することを目的に作られましたが、 アプローチはこれらのものとは異なります。 conduitは簡単に理解して利用できるものになることを一番の目的としています。 遅延I/Oとは異なり、リソースの即時開放を保証し、 また、純粋なコードに例外を持ち込みません。 今回のリリースでSource、Sink、Conduitのそれぞれを作るための、 シンプルで効率の良い、高レベルのインターフ

    xef
    xef 2012/07/02
  • エラー処理の抽象化

    エラー処理の抽象化田中英行 <tanaka.hideyuki@gmail.com> 2012/06/26 @LOG.debug("nice catch!") 自己紹介田中英行 http://tanakh.jpTwitter: @tanakhGithub: https://github.com/tanakh Preferred Infrastracture 勤務のプログラマHaskellと、プログラミングについてあれこれ考えるのが好きHaskell入門書 すごいHaskellたのしく学ぼう! Learn You a Haskell for Great Good! の和訳 java-ja …!?とんでもないところに来てしまったぞ (((´・_・`))) ブルブル 日のお話なぜ、エラー処理は重要なのか?なぜ、エラー処理の抽象化は重要なのか?なぜ、エラー処理の抽象化は行われて来なかったのか?

    エラー処理の抽象化
  • エラー処理を書いてはいけない

    エラー処理を書いてはいけない田中英行 tanaka.hideyuki@gmail.com 2011/12/08 @PFIセミナー 自己紹介田中英行 (@tanakh, http://tanakh.jp) PFI社でプログラマやってますJubatuspficommon検索エンジンのコアエンジンHaskell愛好家msgpack / rpc / idlpeggy (パーザジェネレータ & QQ w/ AQ)Shu-thing (シューティングゲーム) / (Monadius メンテナ)今気になるパッケージは monad-controlLearn you a Haskell 鋭意翻訳中 (春頃発売予定) エラー処理を書いてはいけない日の概要エラー処理を抽象化しようというお話です 現在のエラー処理の抱える問題どのように解決するのか実際の例エラーは処理しなければならない エラー処理を書いてはいけな

  • 1