Hatena::ブログ(Diary)

当面C#と.NETな記録 このページをアンテナに追加 RSSフィード

2009/11/19 (木)

[] PDC09  PDC09を含むブックマーク  PDC09のブックマークコメント

仕事はえー!

Silverlight4 beta が出たようです。こっちもはえーw 3出たばっかりのような気がしてた…

ついに右クリック解禁らしい。

トラックバック - http://d.hatena.ne.jp/siokoshou/20091119

2009/11/17 (火)

[] さよなら CAS  さよなら CASを含むブックマーク  さよなら CASのブックマークコメント

http://www.infoq.com/jp/news/2009/11/CAS-Replaced

CAS がなくなる件、InfoQ の記事になりましたね。

これってひょっとして unsafe の事実上の解禁になるのかな?よくわかってないですけど。

型安全はつまらないバグをかなり減らしてくれるんで、安易に unsafe に頼りたくないですが、これが解禁を意味するならうずうずしてしまう場面はありそうです(^^;

解禁じゃなかったらごめんなさい。記事の後半はよくわかりません…。

渋木宏明(ひどり)渋木宏明(ひどり) 2009/11/17 15:27 CAS と unsafe と型安全性は、全部別物ですよ ;-)

siokoshousiokoshou 2009/11/17 15:52 CAS がなくなって完全信頼になっても unsafe を使ったコードをさまたげる何かってあります?そこらへんがよくわからなくて…。

siokoshousiokoshou 2009/11/17 17:12 あれ、unsafe コードって特に何かに制限されてるわけじゃないようですね。
何かに制限されてるから事実上使えないのかとずっと思い込んでました…。はうっ

siokoshousiokoshou 2009/11/17 17:19 型安全が出てきたのは unsafe で型安全を壊せるって意味で出てきたんですが、文章が省略しすぎですね、すみません。

なちゃなちゃ 2010/01/07 17:09 unsafe つきでコンパイルすると、検証(コードのべりファイ)できないアセンブリになります。
※確か、べりファイしなくていいよってマークがつくイメージだったような気がします。

トラックバック - http://d.hatena.ne.jp/siokoshou/20091117

2009/11/15 (日)

[] goroutine を使ってみた  goroutine を使ってみたを含むブックマーク  goroutine を使ってみたのブックマークコメント

Go 翻訳プロジェクトが立ち上がったようですね。チュートリアルのかなりの部分がもう訳されてます。

http://go.shibu.jp/

遊んでるうちに、将来は C に取って代わりそうだなという気がしてきました。

昨日のコードの goroutine 版が動きました。まだ goroutine がどういうものかさっぱりわからないので、使い方が間違ってる可能性大ですが。

ちょっと新人いじめがすぎました。遅いです。いや、使い方が間違ってるほうが大きいかもしれないけど。

(追記) うわさの runtime.GOMAXPROCS つけたらものすごく速くなった!使えるかもと思った。コードは差し替えておきます。

4CPU割り当ててやってみたらむしろ遅くなったw みんな並列じゃ苦労してるんだねw

以下、コード

続きを読む

[] C の弱点 default のスペルミスを継承していた  C の弱点 default のスペルミスを継承していたを含むブックマーク  C の弱点 default のスペルミスを継承していたのブックマークコメント

no more creat。

package main
import "fmt"

func main() {
	a := 4;

	switch a {
	case 0, 1, 2:
		fmt.Println( a );
	case 3:
		fmt.Println( "いっぱい" );
	defuuuuult:
		fmt.Println( "defuuuuuuult" );
/*
	default:
		fmt.Println( "default" );
*/
	}
}

何も表示されません。

文法見ると禁止されてるっぽいのに、穴がありますね。「defuuuuult:」は前の「case 3:」に続く StatementList 中のラベルになってるのかも。

「$ hg log」したらこんなのが。やられたw

changeset:   3956:4a3f6bbb5f0c
user:        Ken Thompson <xxx>
date:        Tue Nov 10 15:05:15 2009 -0800
summary:     spell it with an "e"

$ hg log -r3956 -p

+	O_CREATE	= O_CREAT;		// create a new file if none exists.
トラックバック - http://d.hatena.ne.jp/siokoshou/20091115

2009/11/14 (土)

[] Go でバックトラックを書いてみた  Go でバックトラックを書いてみたを含むブックマーク  Go でバックトラックを書いてみたのブックマークコメント

Go language に De Bruijn sequence を列挙するコードを移植してみました。C# で書いたときのコードは

goroutine を使って並列化したいんですが、まだデッドロックしてうまくいってませんw なのでとりあえずできたシーケンシャル版。ちなみに効率的に列挙するコードじゃなく、いじめ試験みたいなものです。

De Bruijn の読みがずっと謎だったんですが、コンピュータの数学という本では「ドブリューイン」としてました。O記法の数学のあたりにちらっと名前が出てきました。

Go は関数から多値で返す文法がきれいでいいですね。C# の out はやってることは正しいのに、汚い文法なのが悲しい。レシーバーとインターフェイスでも遊んでみたいな。Go を最初に見たときは古臭い文法だと思ったけど、調べているといろいろと今どきっぽい機能をちゃんと持ってたりします。まーまだわからないことだらけですが。

package main

import (
    "math";
    "fmt";
    "os";
    "container/vector";
)

type DeBruijnSeq struct {
    k, n, max int;
    results *vector.Vector;
}

func Init( k, n int ) ( d *DeBruijnSeq, ok bool ) {
    if k < 2 || 10 < k { return nil, false }
    if n < 1 { return nil, false }

    pow := math.Pow( float64( k ), float64( n ) );
    if float64( 0x7FFFFFFF ) < pow { return nil, false }
    max := int( pow );

    r := vector.New( 0 );
    return &DeBruijnSeq{ k, n, max, r }, true
}

func ( d *DeBruijnSeq ) Search() {
    a := vector.NewIntVector( d.n );
    for i := 0; i < d.n; i++ { a.Set( i, 0 ) }
    d.searchCore( a );
}

func ( d *DeBruijnSeq ) searchCore( a *vector.IntVector ) {
    // 重複判定
    if !d.isUnique( a ) { return }

    // 完成判定
    if d.isComplete( a ) {
        d.output2( a );
        return
    }

    // 次の反復へ
    for i := 0; i < d.k; i++ {
        b := vector.NewIntVector( 0 );
        b.AppendVector( a );  // copy
        b.Push( i );
        d.searchCore( b );
    }
}

func ( d *DeBruijnSeq ) isUnique( a *vector.IntVector ) bool {
    if a.Vector.Len() <= d.n { return true }

    pos := a.Vector.Len() - d.n;

    for i := 0; i < pos; i++ {
        if sequenceEqual( a, i, pos, d.n ) { return false }
    }
    return true
}

func sequenceEqual( v *vector.IntVector, a, b, len int ) bool {
    for i := 0; i < len; i++ {
        if v.At( a ) != v.At( b ) { return false }
        a++; b++;
    }
    return true
}

func ( d *DeBruijnSeq ) isComplete( a *vector.IntVector ) bool {
    if a.Vector.Len() != d.max { return false }

    b := vector.NewIntVector( 0 );
    b.AppendVector( a );  // copy

    for i := 0; i < d.n - 1; i++ {
        b.Push( b.At( i ) );
        if !d.isUnique( b ) { return false }
    }
    return true
}

func ( d *DeBruijnSeq ) output2( a *vector.IntVector ) {
    d.results.Push( a )
}

func main() {
    d, ok := Init( 4, 2 );
    if !ok { os.Exit( 1 ); }

    d.Search();

    fmt.Println( d.results.Len() );

    if len := d.results.Len(); len < 10 {
        for i := 0; i < len; i++ {
            fmt.Println( d.results.At(i) )
        }
    }
}

VMware Player 上の x86Ubuntu に 2CPU 割り当てて実行したんですが、結構速いかも。

トラックバック - http://d.hatena.ne.jp/siokoshou/20091114

2009/11/13 (金)

[] Go  Goを含むブックマーク  Goのブックマークコメント

ロブ パイクとケン トンプソン(と V8 の人。扱い低くてゴメンナサイ)の新言語が2009年の今、出てくるなんてスゴイですね。C/C++ の幕引きは俺たちの手で…ってところでしょうか。Plan9 もきっと Unix の幕引きのために作ったんだろうなぁ。

でも、Go って名前の googlability 悪すぎ。わざとだろうけどw 検索するとイラっとくるw

それにしても、初日からプログラム書いた人があちこちにいてすごい。

とりあえず Go のチュートリアルをちまちまやって楽しんでます。

(追記) x86用の汎用 Makefile おいときます。1ソース→1実行ファイル用

.SUFFIXES:.go .8
.go.8:
	8g $<

.SUFFIXES:.8 .out
.8.out:
	8l -o $@ $<

GO	= $(wildcard *.go)
OUT	= $(GO:.go=.out)

all:	$(OUT)

!8 とかやると泣けるので(T-T)


(追記2) The Go Programming Language とか書いておかないと気付いてもらえない気がしたので書いておく。でも Issue 9 って名前に変わるならそれでもいいw

文字列の長さは utf8.RuneCountInString( s ) で取れた。len(s) だとutf8でのバイト数が返ってくる…

Rune は Unicode character のことを短くそう呼んでるそうな。


(追記3) /go/src/pkg/exp/spacewar/ こ、これは伝説のwww

// This package and spacewar.go implement a simple PDP-1 emulator

// complete enough to run the original PDP-1 video game Spacewar!

でも make できない!

トラックバック - http://d.hatena.ne.jp/siokoshou/20091113

2009/11/12 (木)

[] string の IndexOf は .NET4 でもカルチャー依存のまま  string の IndexOf は .NET4 でもカルチャー依存のままを含むブックマーク  string の IndexOf は .NET4 でもカルチャー依存のままのブックマークコメント

昨日の記事は例が悪かったのでわんくまの中さんに正反対に誤読されて残念なので、わかりやすく一覧表にしてみました。

string の StartsWith, EndsWith, IndexOf, LastIndexOf のカルチャー依存/非依存(ordinal)の状況

.NET2〜3.5.1カルチャー依存
.NET4 CTPordinal
.NET4 beta1カルチャー依存 (元に戻した)
.NET4 beta2カルチャー依存
.NET4 正式版カルチャー依存 (たぶん)

CTP ではセキュアな変更を行ったものの、互換性のために beta1 以降元に戻されました。

BCL チームによると

UPDATE for .NET 4 Beta 1 In order to maintain high compatibility between .NET 4 and previous releases, we have decided to revert this change. The behavior of String's default partial matching overloads and String and Char's ToUpper and ToLower methods now behave the same as they did in .NET 2.0/3.0/3.5. The change back to the original behavior is present in .NET 4 Beta 1. We apologize for any interim confusion this may cause. We continue to recommend being explicit about the string comparison behavior you want, by always specifying a StringComparison value for the methods on String that accept it.

http://blogs.msdn.com/bclteam/archive/2008/11/04/what-s-new-in-the-bcl-in-net-4-0-justin-van-patten.aspx

だそうです。

ちなみに Silverlight3 は ordinal です。

そしてもう一度書いておくと、BCL Team 曰く「StringComparison パラメータをとるオーバーロードが存在するときはいつでも、このパラメータをとらないオーバーロードの代わりにそれを使ってください。それは、あなたのコードをより明白で維持するのをより簡単にします。」だそうです。

推奨事項は http://blogs.msdn.com/bclteam/archive/2005/06/01/424012.aspx

また、FxCop が指摘してくれるので使うことをおすすめします。

何が危ないの?って問題は昨日の記事を読んでください。

この問題とは別に〇の問題などが修正されているようです。

2009/11/11 (水)

[] あなたがやりたいことはきっと "Hoge".IndexOf( "Hoge" ) ではなく "Hoge".IndexOf( "Hoge", StringComparison.Ordinal )  あなたがやりたいことはきっと "Hoge".IndexOf( "Hoge" ) ではなく "Hoge".IndexOf( "Hoge", StringComparison.Ordinal )を含むブックマーク  あなたがやりたいことはきっと "Hoge".IndexOf( "Hoge" ) ではなく "Hoge".IndexOf( "Hoge", StringComparison.Ordinal )のブックマークコメント

ずいぶん前にも書きましたが string の IndexOf には罠があります。ただ単に IndexOf( "Hoge" ) と書くと IndexOf( "Hoge", StringComparison.CurrentCulture ) の動作をしてしまいます。きっとあなたがやりたいことは IndexOf( "Hoge", StringComparison.Ordinal ) だと思います。

.NET4 で、この文字列の危険な落とし穴を修正しようとしたようですが、結局変更はキャンセルされたようです。BCL Team Blog によると、CTP では StartsWith, EndsWith, IndexOf, LastIndexOf をカルチャー依存から非依存(ordinal)に変更したけど、β1で戻したよとあります。実現していれば大きな影響を与えただけに反対されたのでしょうか?

変更しようとした理由はセキュリティへの懸念で、開発者が気づかずにカルチャー依存の文字列比較を行ってしまうことを防ごうとしたようです。これやばいんじゃね?とタレこんだけど使い方次第だと却下された私としては変更して欲しかったのですが、実現ならずで残念です。でも、BCL チームが変更しようとしたということは、やはり危険だと強く認識してるってことなので、無駄じゃなかったのかなとちょっと報われた気持ちです(私のタレこみがきっかけかどうかはわかりませんが)。

もう一度 IndexOf で遊んでみます。@IT 会議室の @echo さんの例を試してみます。「〇」は漢数字の零です。

using System;

class P
{
  static void Main()
  {
    Console.WriteLine( "AA".IndexOf("〇A") );           // 0
    Console.WriteLine( "AA".IndexOf("〇") );             // 0
    Console.WriteLine( "A〇A".IndexOf("AA") );         // 0
    Console.WriteLine( "〇A〇A".IndexOf("AA") );       // 1
    Console.WriteLine( "〇A〇A".IndexOf("〇A") );       // 1
    Console.WriteLine( "〇A〇A".LastIndexOf( "〇A" ) ); // 3
    Console.WriteLine();

    Console.WriteLine( "AA".IndexOf( "〇A", StringComparison.Ordinal ) );         // -1
    Console.WriteLine( "AA".IndexOf( "〇", StringComparison.Ordinal ) );           // -1
    Console.WriteLine( "A〇A".IndexOf( "AA", StringComparison.Ordinal ) );       // -1
    Console.WriteLine( "〇A〇A".IndexOf( "AA", StringComparison.Ordinal ) );     // -1
    Console.WriteLine( "〇A〇A".IndexOf( "〇A", StringComparison.Ordinal ) );     // 0
    Console.WriteLine( "〇A〇A".LastIndexOf( "〇A", StringComparison.Ordinal ) ); // 2

    Console.ReadKey();
  }
}

右側に書いた結果は Windows7/.NET3.5.1 での実行結果です。@echo さんの当時の実行結果と違いますが、やはりおかしいのは一緒です。どうしてこうなるのかわかりません。Ordinal での比較は OK ですね。@IT 会議室にめーさんが投稿したきっかけはカルチャー依存比較で無限ループするという問題でした。ソースコードは一見正常に見えるので、カルチャー依存がデフォルトなのは、問題が起きるまで気付かないタイプのいやらしい問題を産むということがわかります。怖いですね。

でもまあ FxCop が指摘してくれるので、使うことをおすすめします。

BCL Team 曰く「StringComparison パラメータをとるオーバーロードが存在するときはいつでも、このパラメータをとらないオーバーロードの代わりにそれを使ってください。それは、あなたのコードをより明白で維持するのをより簡単にします。」だそうです。recommend

でも、忘れちゃうんだよね…。やっぱり変えて欲しいんだけどなぁ…。

(追記) Silverlight で試してみると、ややこしいことにカルチャーに依存しない動作がデフォルトでした。つまり、"Hoge".IndexOf( "Hoge" ) が "Hoge".IndexOf( "Hoge", StringComparison.Ordinal ) の動作と同じです。

それはそれでいいんですが(ややこしいけど)、VisualStudio 2010 beta2 で試してみるとカルチャーに依存しない動作をしました…。どーなってるんだ…。

(追記2) aetos さんからのコメントによると、.NET4 Beta2 の IndexOf はカルチャー依存で、〇のおかしな挙動が修正されたとのことです。おそらく .NET4 が Unicode 5.1 準拠になった影響と思いますが詳しいことはわかりません。

aetos さんの濁点のテストを Silverlight でやってみると、やはり Silverlight の IndexOf は Ordinal でした。そして、StringComparison.CurrentCulture を明示した場合は一致と判断されました。

egtraegtra 2009/11/11 10:41 変更が無理なら、いっそStringComparisonを引数に取らないものにObsoleteAttributeでも付けたらどうなのでしょうかという気がしてきますね。

siokoshousiokoshou 2009/11/11 11:09 ですよねー、まったくです。

aetosaetos 2009/11/11 16:22 Beta2 では、上記のコードは CurrentCulture を明示しても Ordinal と同じ結果になります。
"が".IndexOf("か゛") は 0 となり、"が".IndexOf("か゛", StringComparison.Ordinal) は -1 になります。
MSDN にはやっぱりカルチャー依存って書いてあります。
http://msdn.microsoft.com/ja-jp/library/k8b1470s(VS.100).aspx

Ordinalになったのではなく、CurrentCulture のバグが修正されたような気がします。
Win7 なのも関係している?

siokoshousiokoshou 2009/11/11 20:00 おお、なるほどー、そういうことなんですね!
Win7の影響か、もしくは .NET4 が Unicode 5.1 準拠になった影響か、そこらへんっぽいですね。
すっきりしました、どうもありがとうございます(^^)

トラックバック - http://d.hatena.ne.jp/siokoshou/20091111

2009/11/4 (水)

[] WPF を使ったブラウザ  WPF を使ったブラウザを含むブックマーク  WPF を使ったブラウザのブックマークコメント

f:id:siokoshou:20091104221105j:image

実用性はないけどおもしろいw

こんなにゆがんでてもスクロールできるし、クリックもできる。Chromium を利用しているっぽい。よく読んでないのでよくわかってないんだけど。ClickOnce でインストールできますが、サーバーが遅いのかものすごーく時間がかかるのでご注意を。5年後のインターネットはブラウザの四角い枠がなくなってるかもね。

via http://chriscavanagh.wordpress.com/2009/08/25/a-real-wpf-webbrowser/

こちらにソースもあります。

3Dバージョンもあった(^^;



(追記) そんなものよりこれがおもしろかった。クリックが止まらないw

Silverlight。2D 物理エンジンなのかな。プルプルムニムニモフモフ

トラックバック - http://d.hatena.ne.jp/siokoshou/20091104

2009/11/2 (月)

[] EXE を作るプロジェクトのデフォルトが Any CPU から x86 に変わった理由 - または Any CPU の本当の意味  EXE を作るプロジェクトのデフォルトが Any CPU から x86 に変わった理由 - または Any CPU の本当の意味を含むブックマーク  EXE を作るプロジェクトのデフォルトが Any CPU から x86 に変わった理由 - または Any CPU の本当の意味のブックマークコメント

Visual Studio 2010 では EXE を作るプロジェクトのデフォルトが Any CPU から x86 に変わります。また、DLL を作るプロジェクトは Any CPU のままです。これらの理由を説明している記事を見つけました。

AnyCPU Exes are usually more trouble than they're worth - Rick Byers

良い記事なのでかいつまんで勝手に訳してみます。だいぶはしょっているいいかげんな訳なので、できれば原文も読んでください。それと、訳についてアドバイスがもらえるとうれしいです。


勝手訳

AnyCPU Exes are usually more trouble than they're worth

AnyCPU EXE は通常、価値よりもトラブルのほうが多い

私は過去数ヶ月にわたってここ(と一部の顧客)の人々と「AnyCPU」(アーキテクチャ中立)のマネージ EXE のコスト/利点のトレードオフについて興味深い議論をしました。それはほとんどあなたが望むものではなく、そして Visual Studio のデフォルトであってはならないという合意に達したと思います。この話題が一部の人々の興味(そして、ショックさえ)を引くかもしれないので、この根拠を共有しようと思いました。


Background - .NET and 64-bit

背景 - .NET と64ビット

Win64(64ビットバージョンの Windows)によって PE ファイル(EXE と DLL)は32ビット「または」64ビットとマークできるようになりました。32ビット EXE は Win64 上では、プロセスに32ビットオペレーティングシステムの幻想を見せる「WOW(Windows32 on Windows64)」の中で走ります。通常、32ビット DLL は32ビットプロセスだけにロードでき、64ビット DLL は64ビットプロセスだけにロードできます。CLR2.0 で64ビットサポートを加えたとき、マネージバイナリは難しい CPU 依存がなかったので32ビットと64ビットのどちらでも使えるようにしました。私たちは人々に32ビットと64ビットの両方のプロセスから再利用できる .NET ライブラリを書くことができて欲しかったので、Windows の OS ローダーサポートを拡張してアーキテクチャ中立(AnyCPU)な PE ファイルを使用可能にしました。

マネージのアーキテクチャ中立 DLL は32ビットと64ビットのどちらのプロセスにもロードでき、正常に動きます。AnyCPU EXE は64ビット OS では(ldr64 が何か言わなければ)64ビットプロセスとして動き、32ビット OS では32ビットプロセスとして動きます。Visual Studio 2008 では AnyCPU が C#VB プロジェクトのデフォルトプラットフォームです。これはデフォルトであなたがコンパイルするアプリケーションが32ビット OS では32ビットプロセスとして、64ビット OS では64ビットプロセスとして動くことを意味します。これはすばらしいことで、確かにたいていうまくいきます。しかし、ちょっと不利な面がいくつかあります。


The costs of architecture-neutral EXEs

アーキテクチャ中立 EXE のコスト

AnyCPU が EXE のデフォルトであってはならないと考える理由がいくつかあります。誤解しないで欲しいのですが64ビットハードと OS は間違いなくよいものです。しかし、それが大部分のプロセスが64ビットでなければならないことを必ずしも意味するわけではありません。私が Visual Studio の EXE プロジェクトのデフォルトを x86 にすることを正当化するために、議論で使ったリストはこれです。


1. 2つの非常に異なるモードで動作することは、製品の複雑さとテストのコストを上げます

しばしば人々はアーキテクチャ中立アセンブリのネイティブインタロップの意味に気づいていません。それは、あなたが依存するネイティブ DLL の32ビットと64ビットバージョンが同じように利用できることを確実にする必要があることを意味します。そして適切なほうが自動的に選ばれます。OS の API を呼ぶのは WOW のおかげでとても簡単です。しかし、マネージアプリにネイティブ DLL を一緒に配布している人々は64ビットシステムで32ビット DLL が問題を起こすことにはじめは驚きます。また、マネージでは珍しいですがポインターサイズのバグ(IntPtr と Int32 のサイズを同じと仮定してしまったり、マーシャリングの宣言を誤るミス)もいまだにあります。

また、コードを二回テストしなければいけないという問題があります!すべてのプラットフォームでテストし、サポートするには大きなコストを払うことになります。


2. 32ビットはいずれにしろより速い傾向があります

アプリケーションが32ビットか64ビットモードで走るとき、32ビットモードのほうが少し速い傾向があります。大きなポインターは多くのメモリとキャッシュを消費します。そして利用できる CPU キャッシュのバイト数は32ビットと64ビットプロセスで同じです。もちろん WOW レイヤーは若干のオーバーヘッドを加えますが、私が見た大部分の現実のシナリオではネイティブ64ビットプロセスより WOW のほうが速いことを示しました。


3. いくつかの機能が64ビットでは利用できません

32ビットと64ビット間で完全に同じ機能にしたいのですが、現実はまだそうではありません。CLR v2 は混在モードデバッグを x86 だけでサポートしました。そして、CLR v4 で x64 サポートを加えましたが、エディット&コンティニューや IntelliTrace はまだ x64 でサポートしていません。CLR チームで新しい機能を加えるときは、いつも x64 を第一級市民と考えています。しかし、現実は我々が複雑なコードベース(例えば完全に別々の32ビットと64ビット JIT コンパイラ)を持っており、トレードオフをしなければいけないということです。


So how is Visual Studio 2010 and .NET 4.0 changing?

それで Visual Studio 2010 と .NET 4.0 はどう変わりますか?

CLR やコンパイラは何も変えていません。両方のモードをサポートし続けます。しかし、これらの問題を議論した後、VS プロジェクトシステムチームは、VS2010 で EXE プロジェクトのデフォルトを x86 にすることに同意しました。AnyCPU は DLL(どんなプロセスにロードされるか必ずしもわからない)ではまだすばらしい価値があり、AnyCPU をやめる十分な正当性はありません。そのため、DLL プロジェクトは AnyCPU のままです。

[訳注: ベータ1では誤って DLL も x86 になっていたらしい]

[訳注: DLL は32ビットと64ビットの両方のプロセスで使えるので、両方でテストが必要です]

この問題を議論したとき、ほとんどの人は x86 をデフォルトにすることは少なくとも数年間は最高の選択と同意しました。これは64ビット OS とフレームワークのサポートの減少を意味するものではありません[訳注:全体の半分くらいがこの点についてくどくど書いてありますが、ばっさり省きました。よっぽど言われたんだと思います]。


おまけ

ildasm で PE ヘッダを覗いて AnyCPU/x86/x64 を比べてみました。ia64?あー、聞こえない。

COFF Header の Machine Type は AnyCPU/x86 は I386(0x14c)。x64 は AMD64(0x8664)。

PE Optional Header のマジックナンバーは AnyCPU/x86 が 0x10b = 32bit(PE32)、x64 は 0x20b = 64bit(PE32+)。

CLR Header

AnyCPU .corflags 0x00000001 // ILONLY

x86 .corflags 0x00000003 // ILONLY 32BITREQUIRED

x64 .corflags 0x00000001 // ILONLY

AnyCPU の PE ファイルは見かけは32ビットの体裁をとっているようです。

2009/11/1 (日)

[] 従来の並列化と最近/これからの並列化の違い  従来の並列化と最近/これからの並列化の違いを含むブックマーク  従来の並列化と最近/これからの並列化の違いのブックマークコメント

一昔前の CPU の進化とはシングルスレッド性能を伸ばすことでした。

ソフト屋はこの進化にただ乗りし、ソフトをいったん作ればあとは何もしなくても、新しいハードでは速くなる、時間が経ってハードを買い換えてくれれば速くなるというおいしい状況でした。

Windows XP は発売当時、見た目だけハデにした重い OS と言われたのに、今では軽い OS として評価が高いのはハードの進化のおかげです。ハード進化の一翼が CPU のシングルスレッド性能の伸びでした。MS が Vista 発売にあわせて XP を軽くなるよう改良したわけではありません。

これをソフト屋がおいしい思いをしている、ただ飯を食ってるってことで、フリーランチと言います。


ところが今では CPU は進化の方向を変え、シングルスレッド性能の伸びはゆるやかになり、その代わりコア数が増えていく方向になりました。

これまでのようなソフトを書いていたのでは、ほっといても速くなりません。フリーランチに預かるには、コア数にあわせて速くなるようにプログラムを書く必要があります。


つまり、処理の並列化が必要で、それもこれまでのような一定数のスレッドを使うのではなく、コア数に応じて性能が伸びる仕組みが必要です。そうしなければ、ソフトは新しいハードでも速くならず、競争力がないソフトになってしまいます。数年後に軽いソフトとして評価が上がるということもないわけです。

可能な限りの処理を並列化してしまおうという方向です。

さらに最近は、並列にできない部分が処理のネックという意見も出てきました。そんなこと言われても困ってしまいますが…。


で、ソフト屋が並列に乗っかるにはどうすればいいかという模索が始まり、それが関数型言語だったり、TPL/PLINQ のようなライブラリだったりするというわけです。


いくつか聞いた話をあわせるとこんなところでしょうか。

たまにはこんなことを書いておくのもいいかなと思って書いてみました。

トラックバック - http://d.hatena.ne.jp/siokoshou/20091101
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 06 | 09 | 11 | 12 |
2007 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 08 | 09 | 10 | 12 |
2009 | 01 | 03 | 04 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 07 |
2011 | 04 | 07 | 10 |
2012 | 04 | 12 |
2013 | 08 |
2014 | 03 | 08 |
2017 | 09 |