ToDo:
あの英語は失笑を招くほどひどいらしい。
みんな英語うまくていいなぁとしか思えない。
や、日本ぽい発音てのはそだけど、 どう考えても通じると思われるので別にいいじゃんね…
あれがダメだっていう人はこう、 インド英語とかもダメってことになると思うんだよな。
なんか楽天に関しては色々思うことが混じっていると思う。
最後の意味でこいう意見はとてもこわい。
http://d.hatena.ne.jp/nishiohirokazu/20100707/1278509600
僕個人はさっさと転職を選択すると思うけど、 しかし仮にうっかり愛社精神が強くあったりしたら悩むと思うので、 英語ができないくらいで仕事できないとか言われることになって、こわい。
ところで、よく TeX とか C とか人を長期に渡って 苦しめててひどいとか言うけど、 英語の方がよっぽどひどい言語と
(00:59)
なんか C はいいものだけど、 ハードウェアってそれなりに変わったらしいし、 C の守備範囲でもちょいなんか無いもんかねみたいな話を よくしたり聞いたりするんだけど、 なんか機能で考えるより何が実装できればいいかを考えればいいんかな。
アセンブラや言語拡張無しで、
このあたりかなぁ。
(02:05)
| 前 | 2010年 7月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
backtrace? stack frame に対する操作ですかね．一瞬バックトラックかと思った．大体同意します．JIT書けるっていうか，（限定された）コード書き換えを言語レベルでサポートして欲しい．
x86-64 は stack frame 無いので言語なりライブラリがそいう抽象化レイヤーを提供してくれないとどうにも…もちろん C でも libunwind 使えばいいじゃんというのはそうなんですけど、標準に無いとなーという。
で、同意していただけるなら是非作ってください!! R なんとかはたぶんもう十分実用なのでもういいです!!!
なんていうか、 C を C の無い状態から発明したってのは、具体的にはよくわかりませんがすごい偉業なんじゃないかなーと思っていて、上に書いたような要求とか、「SSE 的なベクトル命令が普通に書ければいいねー」とかは言えるんですけど、具体的にどういう仕様になってれば嬉しいのか、ってのがよくわからないというか。
時間をかけた完璧なsimd化と、そのキャッシュがあれば十分な気がします>ベクトル命令
最適なメモリアラインがCPUアーキテクチャ毎に異なるのが難しいですね。
SIMD って完璧にできるんですか? なんか画像処理とか暗号とかの最内ループ付近は結局アセンブリ手書き的な感じなのかなぁとか。ですが、 cell の spu-gcc が持ってた組み込み vector 型とそれを扱う関数群みたいなのがあればだいぶラクなんじゃないかなーと (素の GCC のやつでもいいんですが、 cell のやつの方が手が込んでる感じでした)。 portable にするには、こういう命令ありますか? って聞ける命令があるといいのかなーとか。それなんて autoconf ですが。
あ、あともちろん「ほとんどのケースでは C で十分である」的なことはその通りだと思います。ただ現状の C は高級アセンブリと呼ぶには、今のハードウェアと乖離しすぎてて、「ほとんどのケース」からこぼれるケースが結構多いなぁと。とはいえ上に書いた 5 点とかみたいなケースばかりなわけですけど。