アカウント名:
パスワード:
曖昧な記憶なんですが、C#を設計した人って、Delphiを設計した人と同じじゃありませんでしたっけ。言語としては非常に素晴らしい出来だ、とその方が自信を持っているという話を聞いたことがあります。
...そろそろ.NETもさわってみようかなぁ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
結構使える (スコア:4, 参考になる)
言語としてもよく考えられていると思うし、開発効率もいいし。
自分はC, C++, DelphiといろいろとやったのですがDelphiがRADとして比重を置いていますがC#はC,C++の中間みたいな感じで非常にバランスよく感じます。
自分が公開しているソフトもC#で書かれたものがありますが……。
あまり見かけないですがどのくらいの人が
Re:結構使える (スコア:2, 興味深い)
曖昧な記憶なんですが、C#を設計した人って、Delphiを設計した人と同じじゃありませんでしたっけ。言語としては非常に素晴らしい出来だ、とその方が自信を持っているという話を聞いたことがあります。
...そろそろ.NETもさわってみようかなぁ。
C# の言語 設計者は James Gosling なのでは... (スコア:3, 参考になる)
僕が検証したところ文法だけ見て C# が Java と根本的に違うのは 5点のみ。
多次元配列の存在、primitive 型(C# では predefind 型)の call by reference、unsafe 構文の存在、check/uncheck、goto 文。
あと小さな違いとしては decimal 型とか、文字列定数の書き方とか、文字列を case にした switch 構文の存在とか。
残りは糖衣構文(syntax suger) のある/なしだと思います。
# 糖衣構文というのは、同じ書き方がもっと基本的な構文の
# 組み合わせで書けるの
コンタミは発見の母
Re:C# の言語 設計者は James Gosling なのでは... (スコア:0)
あと、理論的な根本的違いは多くないかもしれませんが、現実として大きく異なってくる部
Re:C# の言語 設計者は James Gosling なのでは... (スコア:1)
私自身が .NET framework については学習中なので何かを言えるレベルには達していません。
# でも デジャビューの連続なのですが...
> あと、大きく違う部分としてユーザ定義の値型struct(C++のそれとは全く異なる)、
> これを入れないでどうしますか
あ、struct を書き忘れていました。でも概念的には C++ の struct そのものですよ。ポインタが取れないことを除いては。
私自身、C# の仕様を一読したときに "struct" を見つけた時には感激したものです(*1)。ただ struct は参照がとれない制限や、固定長であっても配列
コンタミは発見の母
スタック割り付け (スコア:0)
escape analysis (スコア:1)
unsafe はユーザー責任とはいえ、GC のある言語で dangeling pointer なんぞ作られたらたまりません。デバッグ不能です。
# でも似たような機構を realtime Java の仕様で見たことがあるような、ないような。
セキュアなスタックアロケーションをやるためには C# の struct のように制限をもうけてやる方法以外に、コードを解析することによって安全に割り付けられることを検証したり、参照が外部に漏れてた場合をランタイムで補償する方法があります。
私の関心はこちらにあります。
ただ、すべての new に対してをスタック割り付けが可能かどうか解析していくのはコストが高いので、ユーザーに「ここを解析しろ」と指示を書いて欲しい。そのための修飾キーワードが(昔の C 言語の register のように)言語レベルで欲しいと思っているのですが、如何でしょう?
コンタミは発見の母
Re:escape analysis (スコア:0)
うーん,そこまで言われると困りますなぁ.
いまこの場での議論でC#の規格を決められたらいいのですが.
で,まずは「stack allocation によるパフォーマンスの改善(可能性)」から「デバッグコスト」へと話題が増えてますしね.
私から見れば「dangeling pointer なんぞ作られたらたまりません」な人も「stack allocation によるパフォーマンス改善」を望む人もわりと他人事なので,何書いてもそれなりに妥当な返答が返ってくる当事者の方か
Re:escape analysis (スコア:1)
> ではfloat×16の行列を多用するのですが,これはSSEへの最
> 適化のため16byteアライメントするように推奨されています.
> これをC#から使えるようにしたとき,Microsoftがライブラリ
> にどういう実装を行うかには結構興味がありますね.
> 個人的にはアライメント用の属性を作るんじゃないかと思って
> ます.
アライメントの指定すること自体は属性で簡単にできると思いますが、問題は仮想マシンをどうつくるかです。
ガーベージコレクションの対象となるヒープ空間上では、GC によってオブジェクトが度々 移動します。そのたびにアライメントを考えてデータの構造や大きさまでをも組み替える必要があります。これは骨ですよ。
特定のデータに特化する手法を用いる場合なら、float×16の行列を扱う専用のクラスを作ってやればよいと思います。ヘッダーが 8バイトだとすると、オブジェクトの大きさを32バイト固定にしてアライメントによって行列部を前に詰めたり、後ろに詰めたりすれば実装可能です。
# CLR も 8バイト境界を採用しているでしょうから、詰め方は 2パターンしかない。
任意のクラスに任意のアライメントを指定する場合は面倒になります。
私ならオブジェクト毎にアライメントに関する情報を持たせる方法か、オリジナルのクラスからアライメントを特化させたサブクラスを作成する方法のどちらかを取ると思います。
前者の場合、オブジェクト毎にアライメント用のフィールドを余分に持つ必要がありますしアライメント指定のない通常のオブジェクトのアクセスに余分なオーバーヘッドが掛かるので後者の方が効率はよいでしょう。
p.s.
まったくの余談ですが、float 型の配列の配列部は 8n + 4 となる境界に載るという、数値演算系の人からみると冗談としか思えないような JavaVM の実装があります。
# オブジェクトが 8 バイトアライメントに揃っていて、各オブ
# ジェクトは 8 バイトのヘッダー情報を持ち、配列の場合は配
# 列長をしめす領域が 1 ワード(4バイト)が余分についていて、
# その直後から行列のデータ部分がはじまる。
## ということは double 型の配列も 8n + 4 境界からはじまる?、
コンタミは発見の母
Re:escape analysis (スコア:1)
> のかですかねぇ.
> 私が配列ベースで作業する場合は,記述性から Fortran とか
> Mathematica 使いますから.
C# の場合、多次元配列がはじめからあるので FORTRAN のプログラムをそのまま MSIL に変換してしまっているのではないでしょうか?
プログラムを一つのクラスとして、共通ブロックはグローバルなクラス変数、プロシージャ・変数を static メソッドとして置換すればよいと思われます。
無論、問題は最適化。
ループ最適化など高レイヤーの最適化は中間言語レベルでもある程度有効だと思いますが、software pipeling 等の命令レベルの最適化はレジスタが見えないとほとんど無理です。
# 少なくとも私は書けない。手袋を着けた状態で盲牌するようなもの。
CLR 側の JIT コンパイラは、売り物のコンパイラと比べると簡単な最適化しか入っていないようです。また、FORTRAN が相手にするようなプログラムだと JIT のメリットはそんなにありません。AOT コンパイルをじっくりやった方が特です。
# FORTRAN77 は virtual function call 以前に recusive call すらないので、
# 静的にコントロールフローグラフがきっちり書ける。
# 条件分岐もループ由来のものが多いので分岐方向は予測可能。
実際に Lahey/Fujitsu Fortran for .NET [lahey.com]のパフォーマンスに関する問言は非常に控えめです。ただ、native code に変換してしまう機能があるようなので、そちらを使えば従来と同様のパフォーマンスが出るのではないでしょうか?
p.s.
余談ですが、FORTRAN はコンパイラに演算の実行順序を入れ替えるような最適化を認めているので、浮動小数点演算ユニットが IEEE754 に準拠していたとしてもコンパイラによって計算結果が異なることがあります。
一方、Java は "Write Once, Run Anywhere" を掲げて、浮動小数点が誤差のレベルまで一致させんという高邁な理想を持っています。多次元配列がないのも痛いのですが、コンパイラ最適化の多くが禁止されるのがさらに痛いです。
売り物の FORTRAN for JavaVM が出ない理由の一つですね。
コンタミは発見の母