Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
Matzにっき(2008-03-04)
[go: Go Back, main page]

«前の日記(2008-03-03) 最新 次の日記(2008-03-05)» 編集

Matzにっき

<< 2008/03/ 1 1. Ruby 1.9.0-1 snapshot released
2. 高木浩光@自宅の日記 - 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと
3. Lisa Awards: Biggest Hack for a Language Runtime on Dion Almaer's Blog
2 1. 第一安息日
3 1. CS 11: Python track: python idioms
2. Binary search algorithm - Wikipedia, the free encyclopedia
3. Theological Cultural Analysis of the Free Software Movement
4. 小寺信良:正直、テレビはもうダメかもしれん - ITmedia +D LifeStyle
5. You Used Ruby to Write WHAT?! - CIO.com - Business Technology Leadership
6. 取材
4 1. tanjent: MurmurHash, final version.
2. lucille development blog >> Blog Archive >> LLVM 2.2 v.s. gcc 4.2
3. YouTube - JRuby: The power of Java and Ruby
4. InfoQ: Trading Consistency for Scalability in Distributed Architectures
5 1. Google Japan Blog: Google Summer of Code 2008 開催
2. Computerworld - Don't use Emacs, says Java's father
3. Rails is the best thing that ever happened to Python | Zen and the Art of Ruby Programming
4. [#JRUBY-2220] Struct performance is pretty poor - jira.codehaus.org
6 1. 取材
2. GCの改善について
7 1. 取材
2. オープンソースサロン
3. Teflon Ted: Rails Doesn't Scale
8 1. Sapphire, the Programming Language
2. OOエンジニアの輪! 〜 第 40 回 関 将俊 さんの巻 〜
3. 新見
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >>
迷惑メール対策なら Dr.WEB
『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です!


2008-03-04 [長年日記]

_ tanjent: MurmurHash, final version.

JenkinsよりもFNV1よりも速いというハッシュアルゴリズム。

またハッシュアルゴリズム取り替えようかなあ。

_ [言語] lucille development blog >> Blog Archive >> LLVM 2.2 v.s. gcc 4.2

LLVM 2.2が(Intel CPUにおいて)、GCC 4.2よりも性能の良いコードを生成したという話。 まあ、GCCのバックエンドがたまたま最良のコードを吐かないということは そんなに珍しいことではないと思うけど。

が、LLVMってのは興味深い技術だよなあ。 もうちょっと真剣に調べてみるかなあ。

_ [Ruby] YouTube - JRuby: The power of Java and Ruby

Ola BiniのGoogle TechTalk。

またMRIがけちょんけちょんにされてて悲しいんだけど。

_ InfoQ: Trading Consistency for Scalability in Distributed Architectures

eBayがトランザクションを使っていないという話から スケーラビリティをなにか(この場合は一貫性)と引き換えにする、という話。

性能となにかを引き換えるというのはよくある話で、 一番よくあるのは時間と空間の取り引き、 つまり、メモリをより消費することによって性能をあげること。

しかし、データ量そのものが大きくなると そのような取り引きは難しくなる。 メモリには限界があるから。

で、いろいろと考えるわけだ。いわく

  • 性能と正確さの取り引き(ブルームフィルタとか)
  • メモリの少なさを台数でカバー(ROMAとか)

他にどんな「取り引き」が考えられるだろうか。

本日のツッコミ(全1件) [ツッコミを入れる]
_ MSuzuki (2008-03-11 12:13)

取り引きとしては、

・性能を上げるためにより複雑なアルゴリズムを使う(マージソートとか)
・性能を上げるために機能を単純化
・メモリーの少なさを精度を落としてカバー(double->固定小数点とか)

こういったトレードオフはよくあるのですが、やっぱり一番多いのは、

短い納期を開発者の気力でカバー・・・(T-T)

お名前:
E-mail:
コメント:
本日のリンク元

«前の日記(2008-03-03) 最新 次の日記(2008-03-05)» 編集

RSS feed meter for http://www.rubyist.net/~matz/ Creative Commons License This work is licensed under a Creative Commons License.