2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

【超高速】C/C++に代わる低級言語を開発したい 7

1 :デフォルトの名無しさん:2010/05/31(月) 00:56:58
70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。

しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。

そこで、このスレッドでは、
低レベルなシステム開発のためのプログラミング言語
を一から考えたい。

既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。

「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、
という観点で考えたい。

◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 6
http://pc12.2ch.net/test/read.cgi/tech/1274015781/

2 :デフォルトの名無しさん:2010/05/31(月) 01:00:37
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

                  京都大学霊長類研究所

3 :デフォルトの名無しさん:2010/05/31(月) 01:01:24
◆新言語の要件 v0.1◆

(1)ハードウェアを直接操作する低レベルの記述が可能
(2)プログラマーが勘違いしてプログラマーの意図と違う動作をしないように言語仕様が直感的で学習が容易
(3)最新のオサレ機能が使えてワクワクしながらプログラミング可能


◆主な要望◆

・デバドラ屋だって、オサレ言語で開発したい!
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな
・低レベル記述性(絶対条件) > 構文の美しさ(読みやすさ、学習の容易さ) > 再利用性(抽象性)
・算術演算以外の演算子は後置
・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。

4 :デフォルトの名無しさん:2010/05/31(月) 01:02:50
◆新言語の名称(仮)◆

Programming Language I

◆新言語の位置づけ◆

Ruby, Python, Haskell, OCaml, Scala, Clojure, Erlang, …
烏合のごとく言語が生まれてきているのにどれも似たようなLLばかりで、ハードウェア制御のような低レベル処理を行える言語が無い。
一方、Cは40年使われ続けてきているわけで、そろそろ置き換えられる言語が出てきてもいいだろう。

そこで、C程度の性能が出せて、Cが使われている分野を全てカバーでき、
過去の互換性に囚われて構文を妥協せず、今時の機能を使えてCよりもプログラミングしやすい新言語を作りたい。

◆新言語でのリソース管理方針◆

・確保したリソースを明示的に後始末しなくても問題が発生しない
・何らかのメリットのために確保したリソースを明示的に後始末してもよい

※GCは手段であって上記が満たされていれば必ずしも必須ではない。

5 :デフォルトの名無しさん:2010/05/31(月) 01:04:49
>>1
> しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
> 新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。

概念的には全く同じものになるだろう。

6 :デフォルトの名無しさん:2010/05/31(月) 01:05:10
>>4
なんでLLが(ハッカーの手により)生まれ、Cみたいなのが生まれないのか
少し考えれば分かるだろ

7 :デフォルトの名無しさん:2010/05/31(月) 01:16:05
◆新言語を考える上でのキーワード◆
クロージャー
カリー化
型推定
構文を操作できるマクロ
ファーストクラス関数、正規表現、文字列、スレッド、XML、イベント

◆マクロについて◆
「マクロ」に必要な要件って何なんだろう。

・構文を置き換えるルールを定義できる
・シンボルを置き換えるルールを定義できる

Lisp級の構文木を操作可能なマクロを作る要件

・マッチングプログラムが簡単に書ける
・マクロの実行時に構文木を返すプログラムを書ける

また、作るのを容易にするには
・単純な式として構文解析が可能

8 :デフォルトの名無しさん:2010/05/31(月) 01:20:46
◆低水準に関連するキーワード◆

・ハードウェアを直接操作
・デバドラ
・直接アドレス参照
・OS
・GCとかVMとか目的のプログラム以外のものが動作しなくても動くこと。
・8bit/16bitCPU対応で、RAMが32KBしかなくても動作するプログラムが作れること。
・0オーバーヘッド

9 :デフォルトの名無しさん:2010/05/31(月) 05:08:33
>>6
Cを作った人こそ
当時のハッカーというよりWizardだろ
有象無象が越えれる壁じゃないよね

LispがCより速い結果だしたそうな
どうみてもCのがわかりやすい
http://www.iaeng.org/IJCS/issues_v32/issue_4/IJCS_32_4_19.pdf

所でこのスレforkしたんじゃねえの
また関数言語とgcがわくぜ

10 :デフォルトの名無しさん:2010/05/31(月) 08:14:00
forkと連呼してる奴w

11 :デフォルトの名無しさん:2010/05/31(月) 08:56:48
新言語の方は、GC付きオブジェクト指向でいくっぽいし。
低水準な方は、高級マクロアセンブラっぽいし。

>>1


12 :デフォルトの名無しさん:2010/05/31(月) 14:47:34
俺よくわかってないんだけど
超高速ってC以上に高速なバイナリ吐くってこと?
機械語に落とす時に最適化される部分をプログラマが
指定できるみたいな要件が
ってとこで>>4読んだ

リソース管理でどっちでもいいよって言うのは
結局プログラマがリソース?の状態を気にしてプログラムしないといけないから
後始末必要の方が好み


13 :デフォルトの名無しさん:2010/05/31(月) 17:38:35
Cと同じ位の低レベルな時点で
RAMリソースなんて0で動かなきゃ

14 :デフォルトの名無しさん:2010/05/31(月) 17:46:03
0ってスタックも無しかよw

15 :デフォルトの名無しさん:2010/05/31(月) 17:52:27
RISC系のCPUで変数少なかったら
葉っぱの関数ではスタックもいらないのを見越して書く
メモリとかバスユニットの初期化コードとか。

16 :デフォルトの名無しさん:2010/05/31(月) 17:54:16
正直マジでレジスタとROMしか使えないんなら素直にアセンブラ使ったほうが
良くないか

17 :デフォルトの名無しさん:2010/05/31(月) 17:55:32
仮に使ってもゴミ読むだけなら
問題ない場合もあるしな

18 :デフォルトの名無しさん:2010/05/31(月) 17:59:21
>>16
見た目は普通に書けるよ
呼び出し側はアセンブラかもしれんけど

19 :デフォルトの名無しさん:2010/05/31(月) 18:07:10
アセンブラでよくてもポータビリティのためにCに書き直すことは意味ある。

20 :デフォルトの名無しさん:2010/05/31(月) 18:13:22
俺は後で自分や他人が読むためかなw
数ヶ月たつと忘れちまうし、若い奴に見せてもアセンブラだと敬遠しやがるし

21 :デフォルトの名無しさん:2010/05/31(月) 21:30:09
>>12
そもそもこのスレのテンプレは
>>1が重要だろうと思ってるレスを 過去ログから拾って来て、
適当に羅列してるだけだから、何一つ決まってないよ。

22 :デフォルトの名無しさん:2010/05/31(月) 21:44:46
決めたい人が決めればいいよ

23 :デフォルトの名無しさん:2010/05/31(月) 22:59:29
他人が決めてくれるのを待つ必要なんて無いんだよ

24 :デフォルトの名無しさん:2010/05/31(月) 23:54:12
ははぁ勝手にやればいいよってことですね

思いつきで書き込んだんですが、今思えば
コンパイラがやってることをCのレベルに持ってくるのは難しいというか無駄?
上に乗っけるのと違って現状の処理が変わるわけですし優秀なコンパイラあるし。
でもアセンブラいじりましたって状況がなくなるなら面白そうなのかな?

とりあえずC?にもってきたらどんな記法になるかを書いてみたいけど
当方素人なのでGCCが吐いたアセンブラを変更しないといけないシチュエーションが思いつきませんw









25 :デフォルトの名無しさん:2010/05/31(月) 23:57:45
あ?

26 :デフォルトの名無しさん:2010/06/01(火) 00:12:20
テンプレートメタプログラミングは必須だな

27 :デフォルトの名無しさん:2010/06/01(火) 04:52:38
手続き型アセンブラ
オブジェクトアセンブラ
関数型アセンブラ
LLアセンブラ

28 :デフォルトの名無しさん:2010/06/01(火) 15:22:05
アセンブラアセンブラ

29 :デフォルトの名無しさん:2010/06/01(火) 16:33:48
アスペクト指向アセンブラでダックタイピング

30 :デフォルトの名無しさん:2010/06/01(火) 19:51:56
どこかに小型のCコンパイラのソースって無い?
ベル研のPCCはテーブル定義が足りない。
TCCはちょいとでかい。

31 :デフォルトの名無しさん:2010/06/01(火) 22:35:29
なぜC

32 :デフォルトの名無しさん:2010/06/01(火) 23:51:13
Cにネタを積んで遊んでみようかと。

33 :デフォルトの名無しさん:2010/06/01(火) 23:53:11
>>31
僕の理由はCの実績。すでにあるプログラムに
手を加えるだけで恩恵が得られるって夢のようだとは思いませんか?
まあCに埋め込むものがどんなものになるかはまだ想像つかないです。
コンパイラ?を拡張するならまったく違う語法?でもいいのかもしれないし
改修してしまうならCがちょっと形を変えたものになるのかもしれない。

ベースになるのはCだろうなとは思ってますが
C++やC++0x、Java、Lisp?、といった言語だけでなく
Struts2やらシンフォニーといったフレームワークだったりとか
も参考にできるところがあるんじゃないかなあと
C++0xについてはいいものを見つけられた気がします。

とりあえず僕は他の言語をつまみ食いしながら
C99をよく見直して吟味するとこからなのでマイルストーンも何も置けない状況

今日は他の事してたので進捗はナシ。

34 :デフォルトの名無しさん:2010/06/02(水) 00:30:34
schemeから始めればいいのに。

35 :デフォルトの名無しさん:2010/06/02(水) 00:45:09
プロファイラ作ってみなよ

36 :デフォルトの名無しさん:2010/06/02(水) 03:26:11
プロファイラもデバッガも仕組みさえわかれば
下の方は簡単だが問題は見せ方だよな
XcodeのInstrumentsとか面白い

37 :デフォルトの名無しさん:2010/06/02(水) 21:24:24
プロファイラを言語機能に入れてよ

38 :デフォルトの名無しさん:2010/06/02(水) 22:26:49
え?もしかして僕ですか?
言語機能には入れないけど作ることにはなるんじゃないですかねー
新言語にしか興味ないので見せ方は他の方がどこかの誰かに丸投げ

僕のがモノになるのはずーっと先だろうなあ。

39 :デフォルトの名無しさん:2010/06/02(水) 23:08:41
アセンブラ言語から先は同じでいいんだからプロファイラ自体は先に作れるのかな?
アセンブラだから評価はステップベースでいいしあとはリソースの扱いを考えて・・・
静的なメソッドごとのステップと消費リソースを吐き出せばおkだったり





40 :デフォルトの名無しさん:2010/06/02(水) 23:32:36
アセンブラ言語って呼び方やめてくれ。ムズ痒くなる

41 :デフォルトの名無しさん:2010/06/02(水) 23:42:53
アセンブラングエッジ

42 :デフォルトの名無しさん:2010/06/02(水) 23:46:01
アセンブラ言語なんていってごめんねアセンブラ言語なんてもう言わないよ
あーあーアセンブリ言語をアセンブルするアセンブラ。


43 :デフォルトの名無しさん:2010/06/02(水) 23:50:28
ラ行3段活用?

44 :デフォルトの名無しさん:2010/06/02(水) 23:52:13
国語の話はやめてくれ。ムズ痒くなる

45 :デフォルトの名無しさん:2010/06/03(木) 07:20:54
国語の能力とプログラミング能力の相間について

46 :デフォルトの名無しさん:2010/06/03(木) 09:37:35
国語というより作文能力とは相関がある

47 :デフォルトの名無しさん:2010/06/03(木) 21:03:20
どうせアセンブラやらないといけないし
プロファイラ先に作ってみる

48 :デフォルトの名無しさん:2010/06/03(木) 22:40:29
○静的な機能として

・ラムダ式
・名前空間
・テンプレート
・型推論
・マクロ

○動的な機能として

・文字列
・リスト、キュー、スタック、ハッシュテーブル
・正規表現
・並列処理
・多倍長演算
・ベクトル演算

49 :デフォルトの名無しさん:2010/06/03(木) 23:27:50
文字列とリスト以外いらん

50 :デフォルトの名無しさん:2010/06/04(金) 02:48:10
これからの時代、ベクトル計算は要るだろ。

51 :デフォルトの名無しさん:2010/06/05(土) 00:21:49
メニーコアプロセッサが普及するだろうから、並列処理とベクトル計算は必須。

52 :デフォルトの名無しさん:2010/06/05(土) 02:04:23
結局理想を追求したらGoになったでござるの巻

53 :デフォルトの名無しさん:2010/06/05(土) 09:21:19
低級言語にベクトル計算とか要らないよ
インラインアセンブラでやってくれ

54 :デフォルトの名無しさん:2010/06/05(土) 09:34:05
ベクトル計算機のベクトル計算のことだろ。
そういう計算機では機械語がベクトル計算なんだが。

55 :デフォルトの名無しさん:2010/06/05(土) 09:49:56
ベクトル演算専用言語を作るのは面白いけど
それが目的じゃないならインラインアセンブラでやればいいんじゃないの

56 :デフォルトの名無しさん:2010/06/05(土) 12:53:14
ベクトル演算は言語標準でまではいらないが
標準クラスライブラリに含まれて然るべきだろう。
その方が演算器にCPUだけでなくGPUも使えていい。

57 :デフォルトの名無しさん:2010/06/05(土) 15:38:56
ここはあれか、Core2DuoとかCellとかが最低ラインなのか。

58 :デフォルトの名無しさん:2010/06/05(土) 15:43:43
最近のコンパイラは配列をループで回したら勝手にベクトル化してくれるから、ベクトルかが良くかかるガイドラインを示せば言語仕様には特に組み込む必要は無くないか?

59 :デフォルトの名無しさん:2010/06/05(土) 16:03:11
C/C++って低級言語じゃないんじゃ?

60 :デフォルトの名無しさん:2010/06/05(土) 16:55:03
配列はベクトルでは無い
ベクトルは行列、そして積和演算

61 :デフォルトの名無しさん:2010/06/05(土) 16:57:13
>>58
> 最近のコンパイラは配列をループで回したら勝手にベクトル化してくれるから、ベクトルかが良くかかるガイドラインを示せば言語仕様には特に組み込む必要は無くないか?

ガイドラインを示すくらいなら、言語仕様に組み込んだほうがいいだろう。

特殊な小手先のハンドオプティマイズより、言語仕様に基づく公式なやり方の方がソースのポータビリティーも確保できる。

62 :デフォルトの名無しさん:2010/06/05(土) 19:34:13
>>581
つfortran

63 :デフォルトの名無しさん:2010/06/05(土) 20:23:27
Fortran と正しく書かないと

64 :デフォルトの名無しさん:2010/06/05(土) 21:03:25
えらいロングパスだな

65 :デフォルトの名無しさん:2010/06/05(土) 21:47:59
581に期待

66 :デフォルトの名無しさん:2010/06/05(土) 22:37:03
並列処理の構文欲しい

67 :デフォルトの名無しさん:2010/06/06(日) 03:10:37
ベクトル演算ってどんな感じで作るんですか?

68 :デフォルトの名無しさん:2010/06/06(日) 03:59:51
int a[5], b[5], c[5];
c = a*b;

int d[3][5], e[2][3], f[5][2];
d = e*f;

こんな感じとか。

69 :デフォルトの名無しさん:2010/06/06(日) 09:53:07
配列とベクトルは論理的に違うもの。
記述性を考えればdouble2,int4,float3とかのベクトル型は
組み込みで持っていたほうがいい。

70 :デフォルトの名無しさん:2010/06/06(日) 10:09:47
>>69
>配列とベクトルは論理的に違うもの。

これはどういう事?

71 :デフォルトの名無しさん:2010/06/06(日) 10:24:49
3次元が特殊なのは分かるけど
その他は特殊な事ってあったっけ

72 :デフォルトの名無しさん:2010/06/06(日) 10:40:41
>>70
「行列演算」でググれ

73 :デフォルトの名無しさん:2010/06/06(日) 10:48:50
>>72
ググったってたくさん出てくるから>>69が何を言いたいのかよく分からないよ。
具体的に説明して欲しい。

74 :デフォルトの名無しさん:2010/06/06(日) 10:56:09
>>69
配列で十分だろう。ベクトルの足し算だってループでまとめて記述できるしコンパイラが自動的にベクトル化してくれる。

75 :デフォルトの名無しさん:2010/06/06(日) 10:59:44
regster int a[5], b[5], c[5];
c = a*b;

regster int d[3][5], e[2][3], f[5][2];
d = e*f;

こんな感じで、コンパイラに努力目標を伝えられたらいいかもね。

76 :デフォルトの名無しさん:2010/06/06(日) 11:02:49
行列演算なんて普通lapack/blasだろ

77 :デフォルトの名無しさん:2010/06/06(日) 12:16:40
>>76
そういう機能をうまく構文に取り込めるといいね。

78 :デフォルトの名無しさん:2010/06/06(日) 12:24:56
志村!スレタイ、スレタイ

79 :デフォルトの名無しさん:2010/06/06(日) 12:24:57
だからFortranを勉強しろと
FORTRANじゃないぞ? Fortranだ

80 :デフォルトの名無しさん:2010/06/06(日) 12:26:51
Fortranに変わる新言語を作りtai!!のスレになりました。

81 :デフォルトの名無しさん:2010/06/06(日) 18:12:11
AVXとかLNIとかに対応できる構文があればいいよね。

>>79
「Fortranを」と言うより、「Fortranのどの機能が良いから新言語に取り入れよう」と提案した方が議論が進むと思うよ。


82 :デフォルトの名無しさん:2010/06/06(日) 18:31:37
みんなロングパス受け取ってくれたみたいだな

83 :デフォルトの名無しさん:2010/06/06(日) 18:32:52
>>81
この流れでは並列演算に決まってるでしょ

84 :デフォルトの名無しさん:2010/06/06(日) 18:37:50
>>83
それが決まってるのは結構なことだけど、それがどう良いのかの説明があればもっと議論が深まるのにね。

85 :デフォルトの名無しさん:2010/06/06(日) 18:41:03
素直にFortran知りませんと言えばいいのに

86 :デフォルトの名無しさん:2010/06/06(日) 18:46:29
別に知らないことは無理に表明しなくてもいいんだよ。
それぞれが知っていること、成し遂げたいことを語ったほうが前向きだからね。

だから、Fortranの並列演算に価値を見出している人がいるなら、その人がどう良いのかを説明して仲間を増やせばいいと思うよ。

87 :デフォルトの名無しさん:2010/06/06(日) 18:50:32
Fortranの並列演算なんてライブラリで出来んじゃねえの
どうせならOccamとかの方が面白いだろ


88 :デフォルトの名無しさん:2010/06/06(日) 18:50:49
行列に関しては、clapakでだめなの?

並列演算(SSE2/VelocityEngineほか)を直接制御したいというのは別だろうか。

89 :デフォルトの名無しさん:2010/06/06(日) 18:52:21
>>87-88

既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。

90 :デフォルトの名無しさん:2010/06/06(日) 18:57:38
マルチコアのプロセッサが今後主流になるだろうから、並列処理の構文はあったほうがいいだろう。

整数の四則演算だってライブラリで提供することは可能だが、多くのプログラミング言語にはしっかり構文があるわけだし。

91 :デフォルトの名無しさん:2010/06/06(日) 19:02:44
脊髄反射すんなよ
高速演算ライブラリの必要性や配列の演算出来るって話は否定しないが
言語の話するなら並列実行構文の方が面白くねえかっつってんの


92 :デフォルトの名無しさん:2010/06/06(日) 19:04:17
あ、89に書いたのよ
お前みたいな凡人が寄り集まってんだから既存の言語を参考にすんのは当然だろうがよ

93 :デフォルトの名無しさん:2010/06/06(日) 19:04:41
並列実行構文の方が面白いと思う。

94 :デフォルトの名無しさん:2010/06/06(日) 19:07:01
並列に実行して!という構文より
並列化コンパイラが作りやすい構文にした方が

95 :デフォルトの名無しさん:2010/06/06(日) 19:07:50
並列実行構文 と 並列演算構文 を両方議論を進めよう。

96 :デフォルトの名無しさん:2010/06/06(日) 19:08:54
>>94
自動で並列化してくれるのはもちろん嬉しいけど、プログラマがある程度制御できるようにもしておきたいかも。低レベルを目指しているので。

97 :デフォルトの名無しさん:2010/06/06(日) 19:18:13
並列に実行して!
ってだけじゃなく、出来れば並列に実行して!みたいなのが面白そう

98 :デフォルトの名無しさん:2010/06/06(日) 19:28:00
並列化を考えるなら、OpenMPのforの分担みたいにデータを並列化するんじゃなく、
普通のマルチスレッドアプリみたいな処理を分担するものを自動生成できるといいなあ
思いつかないけど

並列度は、明に指定も出来るし、デフォルトはシステムのプロセッサ数とかから
自動的にチューニングできるといいね。

あと、同期とかスレッド間通信もある程度は検討したい。
goのchannelはシンプルながら面白いよね

99 :デフォルトの名無しさん:2010/06/06(日) 19:33:22
channel面白いね
でもやはり同期と排他と共有メモリは欲しくなるね

100 :デフォルトの名無しさん:2010/06/06(日) 19:35:06
channel欲しいかも。

101 :デフォルトの名無しさん:2010/06/06(日) 19:37:50
粒度が荒い並列はスレッド的な何かでいいが
細かいのは

102 :デフォルトの名無しさん:2010/06/06(日) 19:47:28
ワッフルワッフル

103 :デフォルトの名無しさん:2010/06/07(月) 08:12:59
並列化ってのは、そう難しいものじゃないんだけど、
並列時でもACIDを保証する事とパフォーマンスをスケール
させる事が難しくて、この難しさは、ようは、リエントラント性の
確保と、キャッシュ分散に関わってくる所なので、その辺をどう考えてるの

したいとか言う気分述べられても困るんだよね。

OSが無い状況で、言語が資源を持つ事の意味をどう位置付けるのか
その辺を考えないと議論にならない。

104 :デフォルトの名無しさん:2010/06/07(月) 09:11:33
どうせ低レベルじゃそんなの保証できないししてちゃ性能でないだろ
最低バリアーopとかcasみたいなのでクリティカルなとこだけ保護できれば後はなんとかなるんじゃね

粒度の高いのはコンパイラマターでいけるし
低いのはRTOSのカーネル程度のショぼいディスパッチャとスケジューラをランタイムに入れとく。
分散はライブラリ。

105 :デフォルトの名無しさん:2010/06/07(月) 09:14:45
単なるディスパッチャとかmutexとかメッセージ含めて数kb程度でおさまるだろ
OS上で動かす時はそいつをpthreadとか使うように置き換えで

106 :デフォルトの名無しさん:2010/06/07(月) 09:34:08
>>104-105
そのモデル違いがいかに混乱を巻き起こすのかってのは、
Linuxの事例で明らかなんだけどね。

君らその辺の難しさも理解しないで暮れ暮れ言い過ぎ。



107 :デフォルトの名無しさん:2010/06/07(月) 09:57:46
一応OS屋のはしくれだが
どこらへんが明らかか後学のために教えて欲しいね

108 :デフォルトの名無しさん:2010/06/07(月) 10:10:15
>>107
ふぇ?最近のOS屋はそんなレベルなんだ・・・

109 :デフォルトの名無しさん:2010/06/07(月) 11:04:46
>>108 結局具体的には説明できないわけだ。

110 :デフォルトの名無しさん:2010/06/07(月) 11:08:12
>>109
OS屋なのに>>107を質問する奴(詐欺師)
とは付き合えないよ。

111 :デフォルトの名無しさん:2010/06/07(月) 11:11:49
具体的な説明は一切できずに人格攻撃か。

112 :デフォルトの名無しさん:2010/06/07(月) 11:25:29
職業倫理の問題なので、人格攻撃と捉えられても困るし。
詐欺師を叩く事が、人格攻撃というのなら、そうなんだろうが、
俺は詐欺師の存在が、社会へ対する害悪だし、詐欺師へ攻撃する
事の方が正しいと思う。

君が詐欺師好きなのは分かったけども、そんな人間だと公言されても
困るだけだし。

113 :デフォルトの名無しさん:2010/06/07(月) 12:02:39
ただの質問をしただけの他人を詐欺師と決めつけて攻撃するほうが、
社会へ対する害悪だし、そういう馬鹿に対して馬鹿と言う事の方が正しいと思う。

君が馬鹿なのは分かったけども、馬鹿が馬鹿を晒すのは勝手にすればいいし。

114 :デフォルトの名無しさん:2010/06/07(月) 12:08:29
全角に期待した俺がアホだったかな
学校でうだうだしてないで社会に出なさいよ

115 :デフォルトの名無しさん:2010/06/07(月) 12:12:35
あ、113にじゃないよ

116 :デフォルトの名無しさん:2010/06/07(月) 12:36:38
>>113
OS屋さんが、ただ質問したいと言って質問する内容じゃないよ。
OS屋さんであんな質問するのは詐欺師。

117 :デフォルトの名無しさん:2010/06/07(月) 12:44:48
ランタイムライブラリにリアルタイムOSカーネルを乗っけるのか。
さっぱり分からん。OS-9辺りから学べばいいか?

118 :デフォルトの名無しさん:2010/06/07(月) 13:29:25
RTOSのカーネルなんてしれてるよ
言語に並列組み込むなら
環境によってOS上ならスレッド、
無しなら小さいディスパッチャと
基本的なmutexとメッセージはいるやろって話
うーむ。詐欺師かねえ

119 :デフォルトの名無しさん:2010/06/07(月) 13:31:50
で、具体的に Linux の事例、ってどういうこと?

120 :デフォルトの名無しさん:2010/06/07(月) 15:28:57
>>119
ライブラリスレッディングが、スピンロックするんだけど、
それがLinuxのLWPと競合して、スピンロックのエスカレーションを
発生させて、システムを致命的な状況に落としかねないって話と、
スケールアウトしないって問題を引き起こしていて、GNUPOSIXに
問題があるので、ユーザーランドスピンロックを解消しにくいとか、
じゃあOS側でLWPのスケジューリングをどうしようかってのが、
ここ2年議論されつづけている。

LWPそれ単独、ユーザーランドスレッディングそれ単独では成り立つ
話でも混ぜると大騒ぎって話で、色々とね、難しいのよ。
排他制御のタイミングも違ってくるし。リソースの待ち方も違ってくるし。



121 :デフォルトの名無しさん:2010/06/07(月) 16:16:17
で、それをOS屋であれば周知のはずだと思い込むのが犬厨か

122 :デフォルトの名無しさん:2010/06/07(月) 16:28:39
>>121
Linuxに限った話じゃないからね。

123 :デフォルトの名無しさん:2010/06/07(月) 19:58:07
僕じゃ理解できないかもしれないけど>>120の議論について読んでみたいので
進行形のスレッドか議論の流れがまとまってるサイトが知りたいんですけど
そういうのってどこ見ればいいんですか?

124 :デフォルトの名無しさん:2010/06/07(月) 21:04:39

もったいぶった割につまらんオチだったな


125 :デフォルトの名無しさん:2010/06/08(火) 09:25:02
なかなか、有意義な話じゃないすか

126 :デフォルトの名無しさん:2010/06/08(火) 11:15:18
bsdとかSolarisとかでも相当昔に揉んだ話
どっちにしろ言語の並列機能やるならOSの上に乗っかるから関係ない
俺はまたthread以外の有用な並列化のモデルが出てくるかと思った

127 :デフォルトの名無しさん:2010/06/08(火) 12:30:01
クライアントサーバモデルに代わる言語を開発したい

128 :デフォルトの名無しさん:2010/06/08(火) 15:19:05
晩ご飯のおかずに代わる言語を開発したい

129 :デフォルトの名無しさん:2010/06/08(火) 16:37:48
>>126
また脊髄反射かよ(w

前にリンク張ったからもう張らないけども、
なんでその俺は分かってるんだって文体で
頓珍漢書くかなぁ・・・

議論の流れを追えば、OSがあるからって
発言はありえないだろ。
諦めてOSに任せるべき、という発言になるべきだろ。

130 :デフォルトの名無しさん:2010/06/08(火) 16:49:43
OSに任せると性能が出ないから、ってんでたとえば Erlang なんかは言語が並列化を
まる抱えしてるし、どこをどう読めば「諦めてOSに任せるべき、という発言になるべき」
なんだかわけわからんわ。

131 :デフォルトの名無しさん:2010/06/08(火) 17:04:51
>>130
あぁ、君がスレッドモデルを小学生レベルで理解してない事を
理解し損ねて俺が頓珍漢な発言をしてた。ごめん。
Erlang なんかは、この時点で君がキチガイだと了解したわ。

スレッドモデルを勉強しなおせWikiにまとまってるのでOK

132 :デフォルトの名無しさん:2010/06/08(火) 17:07:41
どんだけアイちゃんスレだよ

133 :デフォルトの名無しさん:2010/06/08(火) 17:24:18
アイちゃん隔離スレだろ、ここはw

134 :デフォルトの名無しさん:2010/06/08(火) 18:55:37
アイちゃんって何匹も居るの?

135 :デフォルトの名無しさん:2010/06/08(火) 19:01:58
しむらすれたい

136 :デフォルトの名無しさん:2010/06/08(火) 20:41:48
まずはシングルスレッドの動きを規定すべきだろ。
マルチスレッドはシングルスレッドの動きに直交する形で設計すりゃ良い。
だからForthを(ry

137 :デフォルトの名無しさん:2010/06/08(火) 23:19:46
>>136
シングルスレッドの議論も、マルチスレッドの議論も並行に進めていいよ。

シングルスレッドの動きを規定する案があるなら提案してくれると、議論が進むと思うよ。

138 :デフォルトの名無しさん:2010/06/09(水) 00:22:36
OSがいない状況、言語がリソース管理、GC?
低級言語にしては大きくなっちゃう、
スレッドをCPU数やリソースに応じたチューニング、アイちゃん

139 :デフォルトの名無しさん:2010/06/09(水) 02:25:49
>>131
お前ほど自分で人に書いてる罵詈が自分に当てはまる奴も珍しいなw

Erlang出したのは俺じゃないが、今更カビの生えたスレッド実装の問題出した上に結局スレッド使えとかレベルが低すぎる。最近の論文とか読んでないから期待したじゃねえか

もういいからちょっと齧った程度の狭い知見で恥さらすな。お前程度の話ならみんなわかってるよw

140 :19:2010/06/09(水) 10:43:45
スレッドの実装って通常はC言語で実装されているのですか?
それともアセンブラで実装されているのですか?
インラインアセンブラですか?

141 :デフォルトの名無しさん:2010/06/09(水) 12:28:29
両方だよ
つ−か分家へ帰れ

142 :19:2010/06/09(水) 13:15:53
>>140
あまり気になるようなら19はフィルタしてください。
C言語とアセンブラで書くということですね。ありがとうございます。

143 :デフォルトの名無しさん:2010/06/09(水) 19:16:47
そんなてきとーな回答しなくていいのに
いまや分家の方が本家っぽい


144 :デフォルトの名無しさん:2010/06/09(水) 19:55:34
新言語でも、新言語とインラインアセンブラを組み合わせて開発ができるといいな。

145 :デフォルトの名無しさん:2010/06/09(水) 23:54:25
Cにネームスペースが入れば満足

146 :デフォルトの名無しさん:2010/06/10(木) 09:47:08
ネームスペースは要らない

147 :デフォルトの名無しさん:2010/06/10(木) 09:58:09
クラスだけでいい。

148 :デフォルトの名無しさん:2010/06/10(木) 10:13:22
クラスはもっといらない

149 :デフォルトの名無しさん:2010/06/10(木) 10:14:13
ソフトウェア開発しないならクラスもデザインパターンもいらないわな

150 :デフォルトの名無しさん:2010/06/10(木) 10:29:09
要る要らないじゃわからんから、理由も付けれ。

151 :デフォルトの名無しさん:2010/06/10(木) 19:58:23
ネームスペースは必要だよ。

名前に接頭辞を付けると名前が長くなって可読性が低いけど、
ネームスペースならコード中で省略できるから可読性が高い。

152 :デフォルトの名無しさん:2010/06/10(木) 22:12:37
確かに複数ファイルにまたがるスコープなら、あっても良いような気がする。

153 :デフォルトの名無しさん:2010/06/10(木) 22:33:43
クラスは要らない。

というかあっても良いと思うんだけど、マルチパラダイムな言語では、
ぐちゃぐちゃなヒドい実装になりがちだからダメ。

OOPLにするならするで、現状C言語を使わざるをえないような
チープな環境はターゲットとしては捨てるべきだよ。

154 :デフォルトの名無しさん:2010/06/10(木) 22:35:54
糞環境だけにピンポイントかよwCOBOL並みの糞言語じゃん

155 :デフォルトの名無しさん:2010/06/10(木) 22:52:28
COBOLは、糞ではない。
幾多の消え去った言語を尻目に、いまだにたくさん使われている。

156 :デフォルトの名無しさん:2010/06/10(木) 22:53:45
一時期デファクトスタンダードみたいになったからだろ。今から積極的に学ぼうなんて奴はいない

157 :デフォルトの名無しさん:2010/06/10(木) 23:00:39
OOPって本当はピンポイントだけど、C言語風のOOPは汎用っぽく見えるよな

158 :デフォルトの名無しさん:2010/06/11(金) 01:31:44
クラスはともかくとしても、デストラクタは欲しいから、結局クラスがあったほうがいいんだろうな。

159 :デフォルトの名無しさん:2010/06/11(金) 01:58:09
GCに代わるデストラクタをピンポイントしたい

160 :デフォルトの名無しさん:2010/06/11(金) 09:56:13
今ってコボラーが一番平均年収高いんだぜ?
つまり最高の言語って事じゃん

161 :デフォルトの名無しさん:2010/06/11(金) 11:19:55
レガシーシステムの管理者が貴重なだけだろ

162 :デフォルトの名無しさん:2010/06/11(金) 11:33:31
だから、そんだけ払える(価値がある)ってことだろ
社会的に「最高に価値のある言語/技術者」と評価されているわけ
わかった?

163 :デフォルトの名無しさん:2010/06/11(金) 11:35:25
じゃあなんで大学で必修にしないのかな
なんで「学習する価値がある言語」と評価されてないのかな

164 :デフォルトの名無しさん:2010/06/11(金) 11:37:10
COBOLが糞か糞でないか、終わってるか終わってないかの議論では
糞だし終わってるというのが一般的な見解だろ

165 :デフォルトの名無しさん:2010/06/11(金) 11:43:29
>>163
うんまぁそういう事は大学行ってから言おうね
大学で教えるのは、学習に適した言語だよ

166 :デフォルトの名無しさん:2010/06/11(金) 11:44:44
COBOLは糞だし終わってるが、お前らより遥かに社会的に価値がある。以上。

167 :デフォルトの名無しさん:2010/06/11(金) 11:46:37
COBOLを有難がってる奴の社会的価値は終わってる。社会的に抹殺した方が良い

168 :デフォルトの名無しさん:2010/06/11(金) 11:55:48
次スレは 【超年収】COBOLに代わる金融言語を開発したい で

169 :デフォルトの名無しさん:2010/06/11(金) 12:01:04
都会は下水道完備だが田舎ではまだまだボットン便所が多数派だ。
ボットン便所は確かに糞だが汲み取り業者はお前らより遙かに社会的に価値がある。以上。

170 :デフォルトの名無しさん:2010/06/11(金) 12:06:55
バキュームカー臭い議論すんな

171 :デフォルトの名無しさん:2010/06/11(金) 15:14:47
おまいらの給料だってCOBOLがハンドリングしてるんだろ

172 :デフォルトの名無しさん:2010/06/11(金) 16:47:58
COBOL以後にそれ並みになったのは、C、BASICぐらい。

173 :デフォルトの名無しさん:2010/06/11(金) 17:21:52
まあ、なんだぁ
おれには「それ並み」って言葉の意味がわからないけどな
日本語なのか?

174 :デフォルトの名無しさん:2010/06/11(金) 19:58:28
金融系でCOBOLから
他の言語に移行なんてベンダー主導でやらないと無理じゃん

175 :デフォルトの名無しさん:2010/06/11(金) 20:04:43
ベンダーってなんですか?
社内で科学技術計算する立場なんですがIT業界の用語が良く分からないんですよね

176 :デフォルトの名無しさん:2010/06/11(金) 20:09:15
すまんが、マ板でやってくれ。

177 :デフォルトの名無しさん:2010/06/11(金) 20:24:10
>>175
ぐぐってきたぞ。製品を販売する会社なんだって。
汎用機だとIBM,富士通,、NECか金融系の開発受託してるのは違う会社か

>>176
語るならCOBOLは言語的にどう優れているのかって点かなあ




178 :デフォルトの名無しさん:2010/06/11(金) 20:41:58
>>177
他の言語で金の計算なんてやってらんねえよw

179 :デフォルトの名無しさん:2010/06/11(金) 20:55:40
勘定系は伝統的にcobol、pl/iだったけど
市場系は開発スピードが評価されて20年くらい前からc/c++だけどね

180 :デフォルトの名無しさん:2010/06/11(金) 21:22:43
二進化十進表現はのいいものかも。贅沢

181 :デフォルトの名無しさん:2010/06/11(金) 21:29:46
>>177
余計なことができない言語は特定分野で重宝するのは事実。

182 :デフォルトの名無しさん:2010/06/11(金) 21:32:05
ウメハラのような言語か

183 :デフォルトの名無しさん:2010/06/11(金) 21:32:40
一山なんぼのバカでも使えるからな

184 :デフォルトの名無しさん:2010/06/11(金) 22:31:48
ほんとのバカにはCOBOLで書くプログラムはまかせないけどね。

185 :デフォルトの名無しさん:2010/06/11(金) 23:01:05
バカにプログラムは任せないし、COBOLでプログラムも書かない。

186 :デフォルトの名無しさん:2010/06/11(金) 23:17:28
ガキのケンカw退屈。

クラスについてだけどマルチパラダイムな状況を許容することで
自由な実装ができてるのだと思うけどどうなんですかね
可読性と天秤にかけられるものなんでしょうか。
ガッチリ決めちゃえば実装は楽になるとは思うけど。
あとクラスがあるからスレッドの実装なんかも楽になってるのでは?




187 :デフォルトの名無しさん:2010/06/11(金) 23:35:53
クラス考えるならインターフェイスどうするか考えないと。

まあ、簡単にはメソッドオンリーだろうけど。
チャネルとかストリームとかトランザクションなんかも魅力的だけど重たいしね。

188 :デフォルトの名無しさん:2010/06/11(金) 23:52:13
>>187
よくわからない。違う話してる?

189 :デフォルトの名無しさん:2010/06/11(金) 23:58:52
>>187が最近知ったことの話をしてる

190 :デフォルトの名無しさん:2010/06/12(土) 09:23:55
あくまで低級言語なんで、
マルチパラダイム万歳で、リッチな言語は違う気がする。

191 :デフォルトの名無しさん:2010/06/12(土) 14:12:13
新言語の記述レベルは低レベルであっても、記述力はリッチにしたい。

特にビルド時に処理できる構文は積極的に取り入れていい。

192 :デフォルトの名無しさん:2010/06/12(土) 15:03:36
低級言語って、Cは低級言語ではないのだが
(Cは高級言語です)
低級言語を開発するという意味が
よく、わからない。

最初にスレタイを考えたやつは
アホではないでしょうか?

193 :デフォルトの名無しさん:2010/06/12(土) 15:05:07
今更何言ってんだ?空気嫁よ

194 :デフォルトの名無しさん:2010/06/12(土) 15:08:54
そう思うあなたは分割されたスレ行けばいいと思うの

195 :デフォルトの名無しさん:2010/06/12(土) 15:13:41
>>192
高級アセンブラといいたいんですね。解ります

196 :デフォルトの名無しさん:2010/06/12(土) 15:24:55
>>192
> 低級言語を開発するという意味が
> よく、わからない。

先ずは、このあたりをどうぞ。

>>1 >>3-4 >>7-8

197 :デフォルトの名無しさん:2010/06/12(土) 16:54:18
昔はCは高級言語であるとされてきたが、近年はそうとはかぎらない。高い低いはあくまで、比較してどうかだから。

198 :デフォルトの名無しさん:2010/06/13(日) 09:26:26
>>197
> 昔はCは高級言語であるとされてきたが

いつ頃の話してるのか知らんが、昔から PL/I だの Ada だのの豪華な
言語はあったから、コンパイラ言語としては C は常に末席付近だった
と思うぞ。

199 :デフォルトの名無しさん:2010/06/13(日) 09:42:29
>>198
初期の lisp に比べても十分低レベル
つか, 非常に良くできた高級アセンブラだわな
# それがいいんだけど…


200 :デフォルトの名無しさん:2010/06/13(日) 10:59:38
PDP-11 の頃と今の違いといえば並列
それと翻訳環境の怪物化

パイプラインやベクトル演算も簡潔かつ辛辣に抽象化した
移植可能アセンブラができれば C の二番煎じにはなるだろう

# 実はそれっぽいのがもうあったりするが文法的な面白さがいまいち

あと operator くらいあれば浮動小数点あたりは強制から任意に緩和できる
もっと言えば基本型は bool と配列だけでいい

ワード幅 8bit はそろそろぶっ壊してもいいと思う

201 :デフォルトの名無しさん:2010/06/13(日) 14:21:29
192じゃないが、>>196で見直して気付いた。

「C言語、C言語」言ってるから騙されたけど、
欲しいのはCの代替じゃなくて「綺麗なC++」なのか。

C言語が選択される理由のうち、
記述が機械語に近しいって所はいらんのだな。
コンパイラが作りやすいとか、
コード見てアセンブリが想像出来るとか。

202 :デフォルトの名無しさん:2010/06/13(日) 14:57:21
>>201
その二つを両立させたいんだろ
Cの代替であり、尚且つC++並みの高機能にしたい
前者を捨てて後者に特化した言語はごまんとあるから、もうこれ以上いらない

203 :デフォルトの名無しさん:2010/06/13(日) 14:58:32
なら、まずC++の何が不満かを洗い出さないと

204 :デフォルトの名無しさん:2010/06/13(日) 15:11:25
>>203
C++があるのにCの人気が衰えないことが不満なんだよ

205 :デフォルトの名無しさん:2010/06/13(日) 15:14:50
C++への不満が絶えないことが不満

206 :デフォルトの名無しさん:2010/06/13(日) 15:35:25
進化、成長しないことが不満
抽象的なモデルより、具体的なソフトを作る人間の方が勝ってると思われることが不満

207 :デフォルトの名無しさん:2010/06/13(日) 16:15:41
C++0xは進化でも成長でもないと

208 :デフォルトの名無しさん:2010/06/13(日) 16:30:39
0xの勉強するより、Cだけでソフト作った方が有意義だろ常識的に

209 :デフォルトの名無しさん:2010/06/13(日) 16:34:01
常識を覆す言語を開発したい

210 :デフォルトの名無しさん:2010/06/13(日) 19:58:03
そのためにはまず常識を理解しないと

211 :デフォルトの名無しさん:2010/06/13(日) 20:18:55
岡目八目ってこともあるが

212 :デフォルトの名無しさん:2010/06/13(日) 22:09:53
ストラウさんの
「c++の設計と進化」あたりを読むのがいいんじゃないですかね。
いろいろ c と simula の不満を述べてますがな。

213 :デフォルトの名無しさん:2010/06/13(日) 22:33:49
>>202
そうかぁ。
知識不足ですまんけど、動的メモリ確保無しで書けて、物理メモリアクセスや
チップのクロックに依存するようなタイミング制御が出来るような
高機能な言語ってC++ぐらいしか知らんので、
そういう方向もアリかな、と思ったんだ。

214 :デフォルトの名無しさん:2010/06/14(月) 19:10:45
Cはシンプルさを目指した言語だし
C++は複雑化する一途だし別物なだけ

215 :デフォルトの名無しさん:2010/06/14(月) 20:00:19
>>214
そのとおりだとおもう。
でもC++はどんなに複雑でも零オーバーヘッドの原則ですべてが許される。

216 :デフォルトの名無しさん:2010/06/14(月) 20:23:44
C++ の不満。ぱっと思い付いたのだけ。

* C との構文的互換性。文脈自由文法でない → リファクタリング支援系のツールの貧困さ
* モジュールが無い
* 巨大な std 名前空間
* 例外を投げない保証を明示できない → 例外安全なコンテナを作るのが難しい
* 資源管理の責任の明示が困難 ( move である程度改善? )
* 型安全な可変個引数が無い
* 可変長テンプレート引数が無い


217 :デフォルトの名無しさん:2010/06/14(月) 21:10:30
C++は、0オーバーヘッドじゃないだろ。

218 :デフォルトの名無しさん:2010/06/14(月) 21:30:06
オーバーヘッドの必然性がない所は
0オーバーヘッドにするように作られている

219 :デフォルトの名無しさん:2010/06/14(月) 21:37:53
0.01ぐらいで許せ

220 :デフォルトの名無しさん:2010/06/16(水) 15:18:44
C++は共用体を安全に使うのが難しそう
Cは安全とか考えないから楽

共用体の配列のかわりにポインタの配列を使うとか
ポインタ配列に何か代入するたびにnewするとか
Java臭いコードになりそう

221 :デフォルトの名無しさん:2010/06/16(水) 16:39:49
共用体は型フィールドのチェックのオーバーヘッドがある
けど分岐予測が当たりやすい気がする

仮想関数はパイプライン的にどうなるのかよくわからん

222 :デフォルトの名無しさん:2010/06/16(水) 19:56:51
型安全な共用体なら boost::variant があるから OK

> 共用体は型フィールドのチェックのオーバーヘッドがある
の意味が良く分からないんだけど。
これは C++ 側の話じゃなくてユーザコードでってこと?


223 :デフォルトの名無しさん:2010/06/16(水) 20:42:01
> 仮想関数はパイプライン的にどうなるのかよくわからん

分岐予測泣かせ

224 :デフォルトの名無しさん:2010/06/16(水) 20:45:24
分岐予測ってそんなに重要なの?
いや、ループでは重要なんだろうけど、
switchのような類いのものはあまり役に立たないんじゃないかと

225 :デフォルトの名無しさん:2010/06/16(水) 20:50:25
switchを繰り返すループがよく出てくるんだが

226 :デフォルトの名無しさん:2010/06/16(水) 21:10:47
switchでは失敗しまくって、
ループでは成功しまくってんじゃないの

227 :デフォルトの名無しさん:2010/06/16(水) 22:27:38
>>222
そう。型フィールドの値をassertとかswitchするユーザコード。
switchはdefaultとか特定のケースに偏ってないと役に立たないと思う。
assertの類のチェックは、失敗することは滅多にないから役に立つ。

228 :デフォルトの名無しさん:2010/06/17(木) 13:42:51
分岐予測が当たるかどうかで50%ぐらい性能低下する場合もあるよ

229 :デフォルトの名無しさん:2010/06/17(木) 13:51:55
レンホー「なぜ低級言語なんですか。Cじゃだめなんですか」

230 :デフォルトの名無しさん:2010/06/17(木) 13:56:18
リストの各要素の仮想関数を呼び出す場合
交互に別の呼び出し先だったりすると
分岐予測機能一般化後の主流各CPUだとパターン検出すら出来ずに全て予測失敗する
パイプラインが長いCPUだと即死短くても瀕死になる

231 :デフォルトの名無しさん:2010/06/17(木) 18:19:09
>>230
わかりそうで分からない。

多分、個々の用語が一般的ではないオレ用語・用法だからだろう。

232 :デフォルトの名無しさん:2010/06/17(木) 18:56:52
>>229
一意じゃないとだめなんです

233 :デフォルトの名無しさん:2010/06/17(木) 19:16:54
>>230
それはCでどちらを実行するか分岐しても同じなんじゃないの、と

234 :デフォルトの名無しさん:2010/06/18(金) 08:27:23
>>230は一番たちの悪い部類の馬鹿

235 :デフォルトの名無しさん:2010/06/18(金) 11:36:29
マルチコアもパイプライン無い時からCは存在してたのかな?


236 :デフォルトの名無しさん:2010/06/18(金) 11:39:43
卵が先か玉子が先か

237 :デフォルトの名無しさん:2010/06/18(金) 16:03:22
今のCPUはC的言語に最適化されとる

238 :デフォルトの名無しさん:2010/06/18(金) 16:29:52
C++で分岐予測が外れた時どれ位のオーバーヘッドが生じるか試してみました

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
struct foo {
__int64 start, end, freq;

HANDLE hprocess;
DWORD oldclass;

foo() : hprocess(GetCurrentProcess()), oldclass(GetPriorityClass(hprocess)) {
Sleep(10);
// SetPriorityClass(hprocess, REALTIME_PRIORITY_CLASS);
QueryPerformanceFrequency((LARGE_INTEGER*)&freq);
QueryPerformanceCounter((LARGE_INTEGER*)&start);
}
~foo() {
QueryPerformanceCounter((LARGE_INTEGER*)&end);
// SetPriorityClass(hprocess, oldclass);
printf("%d\n", (int)(end - start));
}
};

void func1() {}
void func2() {}
void func3() {}
void func4() {}
void func5() {}
void func6() {}
void func7() {}

239 :デフォルトの名無しさん:2010/06/18(金) 16:32:13
void func8() {}
void func9() {}
void func10() {}

#define MAXITER 10000000

int main()
{
void (*func[])() = {func1, func2, func3, func4, func5, func6, func7, func8, func9, func10};

{
printf("Alternative Call : "); // 分岐予測が効きやすい

foo f;

for (int i = 0; i < MAXITER; i++)
func[i % 2]();
}

{
printf("Ranom Call : "); // 分岐予測が効きにくい

foo f;

for (int i = 0; i < MAXITER; i++)
func[(std::rand() >> 4) % 10]();
}
}

自宅の環境(Athlon64 X2 5000+)では乱数CALLの方が10倍強のコストが
生じました

240 :デフォルトの名無しさん:2010/06/18(金) 16:43:08
上、%2なん?
randのコストは?

241 :デフォルトの名無しさん:2010/06/18(金) 16:48:16
>>234
何一つ間違った事は書いていないが

242 :デフォルトの名無しさん:2010/06/18(金) 17:06:09
>>240
てか、そもそもこれ予測分岐のコスト評価になってるか?

243 :デフォルトの名無しさん:2010/06/18(金) 18:13:54
>>242
分岐予測が外れる以外に10倍近く差が開く理由はないだろ

244 :デフォルトの名無しさん:2010/06/18(金) 18:19:41
>>240
そんなに気になるなら

func[std::rand(), i % 2]();

とでもしろ
ほとんど結果に影響しないから

245 :デフォルトの名無しさん:2010/06/18(金) 21:18:33
コード見るとレベルが知れるな

246 :デフォルトの名無しさん:2010/06/18(金) 21:21:12
同じ計算コスト、コードで分岐頻度だけ異なる場合でないと意味ない

247 :デフォルトの名無しさん:2010/06/18(金) 21:25:16
そもそも分岐予測で間接ジャンプ?

248 :デフォルトの名無しさん:2010/06/18(金) 22:10:23
>>245
まだ提示する方がお前さんのような上から目線よりはいいと思うZE

249 :デフォルトの名無しさん:2010/06/19(土) 10:48:24
細かく突っ込みたいが…釣りだよな

250 :デフォルトの名無しさん:2010/06/19(土) 12:15:36

  ------------------------------------------------------------
    こ  こ  ま  で  成  果  物  一  切  無  し
  ------------------------------------------------------------

251 :デフォルトの名無しさん:2010/06/19(土) 12:51:44
俺が成果だ

252 :デフォルトの名無しさん:2010/06/19(土) 13:41:38
成果なんか永遠に出ねえよ

253 :デフォルトの名無しさん:2010/06/19(土) 13:46:25
このまま2chにスレを立て続けてたところで何も出てきやしねぇよ。 >>1

254 :デフォルトの名無しさん:2010/06/19(土) 13:50:46
何か出るのを期待してる>>250>>253が馬鹿なだけ
さっさと2chブラウザを閉じろw

255 :19:2010/06/19(土) 23:42:33
いちお、このスレ見てやる気が出てきて、色々作ってますよ。

template<T>T add(T a, T b) { return a + b; }
というものをうまいこと型推論などで型付きで
add(a,b){return a+b;}みたいに書けるといいなと思うのですが、
どうでしょう?


256 :デフォルトの名無しさん:2010/06/20(日) 00:10:22
省略なしの場合

def add(a : int, b : int) : int { return a + b; }

型推論で

def add(a, b) { return a + b; }

単一式returnの場合のreturn省略で

def add(a, b) { a + b; }

何か関数型言語じみてきたが、
最近の言語はおしなべて関数型言語に近づいてる感があるので問題はなかろう

257 :デフォルトの名無しさん:2010/06/20(日) 00:15:34
型推論はPTしづらい、と思ってんだがどうだろう?
低水準な開発は実機来るまでプログラムが動かないんで
関数レベルの単体テストが結構重要だと思う。

むー・・・既に時代遅れな考え方な気もするんだけどね。

258 :デフォルトの名無しさん:2010/06/20(日) 00:18:23
関数テンプレートを作る意図がなければ
型を省略しなけりゃいいだけじゃない

259 :19:2010/06/20(日) 03:19:44
>>256
そんな感じがいいと思います。
省略可能な文法でパースも楽なのがいいなと。

型推論なしでもtemplateの型用トークンを用意するというのはどうでしょう?

def add(a:'T, b:'T):'T = a + b

こんなかんじで、'Tから始まる変数はテンプレート型とするので
template<T>って書かなくてもいいとか。

260 :デフォルトの名無しさん:2010/06/20(日) 08:13:20
型理論やばいなあ
落とし所が見つからないと廃人になる

261 :デフォルトの名無しさん:2010/06/22(火) 22:47:01
プログラミング言語 を作ってみたよ
http://d.hatena.ne.jp/yuroyoro/20100621/1277104092

262 :デフォルトの名無しさん:2010/06/22(火) 23:28:51
Brainf*ck系はもういいよ!

263 :デフォルトの名無しさん:2010/06/23(水) 23:53:36
で?成果品ないの?

264 :デフォルトの名無しさん:2010/06/24(木) 21:43:21
>>252 >>254

265 :デフォルトの名無しさん:2010/06/24(木) 21:46:43
勉強したはずの>>238に期待

266 :デフォルトの名無しさん:2010/06/25(金) 23:19:24
シビレを切らした>>1が、とにかく成果物出せとわめくスレになりました

267 :デフォルトの名無しさん:2010/06/26(土) 00:57:05
1日1スレ消費する勢いだったあの頃

268 :デフォルトの名無しさん:2010/06/26(土) 22:49:15
いまみたいに規制されてなかったからな


269 :デフォルトの名無しさん:2010/07/16(金) 21:01:51
tesutesu

270 :デフォルトの名無しさん:2010/07/17(土) 01:32:04
一気に過疎化したな

271 :デフォルトの名無しさん:2010/07/17(土) 03:20:16
全部他力本願だもん
そりゃ過疎化するわ
誰かが自分で処理系作って発表しないかぎり机上の空論でしかない

272 :デフォルトの名無しさん:2010/07/17(土) 03:44:46
お前もそうじゃんw

273 :デフォルトの名無しさん:2010/07/17(土) 08:21:55
言語なんて空想しているときが一番楽しい

274 :デフォルトの名無しさん:2010/07/27(火) 17:33:39
>>271
自力で作れる人がアイデアを精査したく、議論を投げても
ループマンや、LISP厨、一行コメンター等が酷すぎて議論にならないって
はっきりしてしまうんだと思うのですよ。

少し高度な話題振ってる人間も、単にC++0xの議論を持ち込んでる
だけですし。C++0xがの流れを否定してるこのスレなのに、そのスレ主旨
の違いが分からず、C++0xで議論(本当に酷い人はC++0xのスレのコピペ)
されてることを書き込めば、レスが付く、スレに参加してるとでも勘違い
してるかのように。

どうも2chは勢いのスレに参加してると何かメリットあるとか勘違い
してる、無能な屑がかなり存在してるみたいで、それがこの結果>>270
なんだと思うんですよね。

275 :デフォルトの名無しさん:2010/07/27(火) 17:56:25
便所の落書きに何を期待しているんだ?

276 :デフォルトの名無しさん:2010/07/27(火) 22:35:24
>>274
いや、べつにC++0xの議論を持ち込んでもいいんだよ。

ただ、現状のC++0xは従来のC/C++とのある程度の互換性というシバリを引きずっているから、記述が非効率で、美しくなく、学習しにくいといった問題がある。
だから、従来のプログラミング言語にとらわれず、新しい言語がほしい。
ところが、今出てくる新しい言語といえば、LLばかリで、CやC++がカバーしている分野につかえるような言語はなかなか無い。

そこで、「C/C++に代わる低級言語を開発したい」というこのスレッドが立ち上がった。

過去のしがらみで不必要な制約がなければ、結果的に従来のプログラミング言語に似ていても問題ないよ。

277 :デフォルトの名無しさん:2010/07/28(水) 00:47:22
じゃあGCを入れるべきか議論しようか

278 :デフォルトの名無しさん:2010/07/28(水) 00:49:39
入れるべき。以上

279 :デフォルトの名無しさん:2010/07/28(水) 19:08:09
GC の是非はしがらみじゃない

280 :デフォルトの名無しさん:2010/07/28(水) 20:28:15
言語設計の観点からは、無いのはかなり困る
むしろGCとうまく付き合う方法を考えてくれ

エスケープ解析や明示的な寿命指定で
GCへの負荷をある程度下げることはできるだろうし
もともとスループットだけで言えば、GCは下手な手動管理より高効率

しかし、やはり最悪停止時間が保証できない問題は残る
部分的にGCを停止させるぐらいで妥協できないかなあと考えてるが、
う〜ん……

281 :デフォルトの名無しさん:2010/07/28(水) 20:43:56
スレタイ目指すならGCなんてありえんだろ。
別スレでやれw

282 :デフォルトの名無しさん:2010/07/28(水) 21:23:09
>>281
無しで考えてもいいが、
それだとC/C++と大差なくなるんじゃないかなあ

283 :デフォルトの名無しさん:2010/07/28(水) 23:04:58
>>280
GCって使うのめんどくさいんだな

284 :デフォルトの名無しさん:2010/07/28(水) 23:43:31
そういやGCな言語って最大使用RAMとか見積もれるのか?
これが無理だと、かなり組み込みで使えるトコが限られるんだけど。
実はまだメモリ解放されてません、とかだと凄く困る。

285 :デフォルトの名無しさん:2010/07/29(木) 00:22:38
>>284 GC ってのは資源が有り余ってるときに使える手法
GC が発生する頻度とその時に回収出来るメモリー量と回収に必要な時間が
許容範囲内なら使える
つか, 「malloc 実装したとしてメモリー足りなくなったときにブロックするの禁止」
な, 世界ではほぼ使えない


286 :デフォルトの名無しさん:2010/07/29(木) 03:39:49
引数に渡すものを構造体限定にすれば速くなるんじゃない?

他には、
スタック関連の呼び出しや初期化を極力抑えて、
メモリの割り当てもメモリープール的な考え方で割り当てて、
メモリ解放の概念を取っ払って、
安全性のチェックを全部やらない。

要するに、ハードウェアは弄るけど、全責任を開発者に投げる的な。
最悪、OSごと落ちるかもしれないけど、高速化するんだったらこうなるでしょ。
後は、Pen4以前をサポートしないようにしたり、
SIMDの命令をもうちょっと使いやすいようにしたり。

287 :デフォルトの名無しさん:2010/07/29(木) 05:18:03
そんなシロモノは
C/C++に代わる低級言語
にはならないと思うなボクは

288 :デフォルトの名無しさん:2010/07/29(木) 06:58:43
たしかにメモリ開放のタイミングを制御できないGC言語はC/C++の代用にはならんわな

289 :デフォルトの名無しさん:2010/07/29(木) 12:40:58
GC言語がメモリ解放のタイミングを制御できない?????

290 :デフォルトの名無しさん:2010/07/29(木) 18:22:29
> 後は、Pen4以前をサポートしないようにしたり、

んなクソでかい CPU を強制される言語はやだな

>>289
仮に制御できたとして、だから何だい?
288 はタイミングとしか言ってないから開始時期のみの話にも聞こえるが
仮にベストなタイミングで開始できても何秒かかってもいいってことではあるまい

291 :デフォルトの名無しさん:2010/07/29(木) 20:59:48
C/C++って組み込みでしかシビアな組み込みでしか使われてないと思ってるの?

292 :デフォルトの名無しさん:2010/07/29(木) 21:01:26
日本語が変になった。つまりアンチGCは頭の固いただの老害ってことだよ

293 :デフォルトの名無しさん:2010/07/29(木) 21:17:13
いわゆる「富豪的」な環境でもかまわんよ
ナノ秒がミリ秒に遅延する仮想記憶でさえ要注意な場面はあるわけで
ナノ秒が秒まで遅延する仕組みが天使の取り分でいつも済むとは限らない

おまえさんの言う老害は年齢ではなくシステムプログラミングに対する知見の違いで
もしかしてブーメランかもね

294 :デフォルトの名無しさん:2010/07/29(木) 21:19:34
何言ってんだコイツw
なんでGC言語ではGCを必ず使わなければいけないって決まってるわけ?www

295 :デフォルトの名無しさん:2010/07/29(木) 21:25:38
で、free という GC を選択的に使えばいいわけだw

296 :デフォルトの名無しさん:2010/07/29(木) 21:31:33
マジで言ってるのなら頭が悪すぎて話にならない

297 :デフォルトの名無しさん:2010/07/29(木) 21:45:32
おまえに褒められても気持ち悪いだけさ

298 :デフォルトの名無しさん:2010/07/29(木) 21:59:48
お前もGCされたら?


299 :デフォルトの名無しさん:2010/07/29(木) 22:08:24
>>294
てか今時GCが使える状況でC/C++を選択する理由が思いつかんのだけど
どういう状況でどういう利点があるの?

300 :デフォルトの名無しさん:2010/07/29(木) 22:18:06
実際に使われてるんだから仕方ないだろ

301 :デフォルトの名無しさん:2010/07/29(木) 23:12:26
しょぼ・・・
C++しか使えない奴らが作ってたり、過去資産があるだけのトコに
互換性のない言語突っ込んで何がしたいの?

302 :デフォルトの名無しさん:2010/07/29(木) 23:13:49
日本語でおk

303 :デフォルトの名無しさん:2010/07/30(金) 02:01:15
私にとって、本当のオブジェクトのセマンティクスに関する素晴らしいことの1つは、
本当のオブジェクトが「端から端まで本当のコンピュータ (RCATWD)」であることです。
これによって、何でも表せる完全な能力をいつでも保持できます。古いやり方は、
すぐにコンピュータではない2つのこと、データとプロシージャに行き着き、
不意にふるまいに合わせて最適化と特定の決定を任せる能力を失っていました。
言い換えれば、常に本当のオブジェクトを持つことにより、ほしいものを再現し、
惑星の周りに送る能力を保持します。そして、RCATWDはまた、両方向を完璧に保護します。
これはインターネットのハードウェアモデルの中に見られます。(使えるもので、
唯一の本当のオブジェクト指向システムかもしれません) 無料で言語拡張機能を手に入れるには、
メッセージ形式に従うだけです。私が70年代に考えたのは、パーソナルコンピューティングと
同時に取り組んでいるインターネットは、本当に素晴らしいスケーラブルな設計であり、
ハードウェアでキャッシュできる仮想マシンの仮想インターネットを作るべきだというものでした。
これが実現されなかったのは本当に残念です。

304 :デフォルトの名無しさん:2010/07/30(金) 02:02:05
私は、オブジェクト指向プログラミングというものに疑問を持ち始めました。
Erlangはオブジェクト指向ではなく、関数型プログラミング言語だと考えました。
そして、私の論文の指導教官が言いました。
「だが、あなたは間違っている。Erlangはきわめてオブジェクト指向です。」
 彼は、オブジェクト指向言語はオブジェクト指向ではないといいました。
これを信じるかどうかは確かではありませんでしたが、Erlangは唯一のオブジェクト指向言語かもしれないと思いました。
オブジェクト指向プログラミングの3つの主義は、メッセージ送信に基づいて、
オブジェクト間で分離し、ポリモーフィズムを持つものです。

305 :デフォルトの名無しさん:2010/07/30(金) 05:17:44
お年寄りの話は面白くないです

306 :デフォルトの名無しさん:2010/07/30(金) 05:30:58
元々緩やかな下降線にはあったけど、人が減った事によって
それまでは人混みに隠れていた工作員の存在が目立つようになったのが致命傷だったな
工作員の誘導を嫌って参加者が減り、他所からの工作員を排除しようとして規制をするから
参加機会が奪われて更に参加者が減るという負のスパイラルにおちいってる

307 :デフォルトの名無しさん:2010/07/30(金) 05:47:45
このスレまだあったのか

308 :デフォルトの名無しさん:2010/07/30(金) 07:40:46
こんなゴミスレでもスレタイにC++が入ってるだけでパート7まで行くとはな

309 :デフォルトの名無しさん:2010/07/30(金) 07:58:26
仲間に入れずクラスの後ろでブツブツ言ってるヤツ >>307-308

310 :デフォルトの名無しさん:2010/07/30(金) 15:41:13
GCを実装していても低級言語と呼べるのか。勉強になる。
だったらGCを実装したアセンブラとかならスレタイを満たすんじゃないのかな。

311 :デフォルトの名無しさん:2010/07/30(金) 16:24:31
もしかしたらハードウェアレベルでGCの機能を提供できるようになるかもよ

312 :デフォルトの名無しさん:2010/07/30(金) 16:25:56
アホが1人キレやがったw

313 :デフォルトの名無しさん:2010/07/30(金) 18:47:38
>>290
>んなクソでかい CPU を強制される言語はやだな
なぜですか?

>>299
リアルタイム系だと止まるのでGCは使いません。
ゲーム(XNA)だと勝手にGCを発動されるとフレーム描画が止まるので、
ロード中に全て開放して全て読み出しています。
ゲーム中はデータの読み込みやnewを一切行いません。止まるので。
メモリの中にあるものが全てです。

314 :デフォルトの名無しさん:2010/07/30(金) 18:54:56
C/C++ は元々システムプログラミング用言語で how な部分に深く立ち入ることにミッションがある
what に特化したアプリ用言語と相容れないのは論を待たない

オブジェクトが動的か否かも how の領域であり、問題そのものが本質的に持つ要求ではなく
アプリの土方がここに無気になることには上も下も見えていない滑稽さが漂う

315 :デフォルトの名無しさん:2010/07/30(金) 19:53:59
>>314
>what に特化したアプリ用言語と相容れないのは論を待たない

そうやって思考停止して満足してるわけだ。

316 :デフォルトの名無しさん:2010/07/30(金) 20:03:53
昔はそういう止まると困るものは割り込みで処理するようにして、
本体では重い処理をやるようにしてたものだが。

317 :デフォルトの名無しさん:2010/07/30(金) 23:18:26
>>313
「開放」と「解放」の区別もつかない人に語る資格はないと思うが。

318 :デフォルトの名無しさん:2010/07/30(金) 23:26:48
人民開放軍ではなく
人民解放軍なんですね

319 :デフォルトの名無しさん:2010/07/30(金) 23:40:12
>>317
介抱してやれ

320 :デフォルトの名無しさん:2010/07/31(土) 02:14:48
言語にRTOSを組み込めば解決だな
gcもスレッド毎にon/off
gcより高レベルなタスクは止まらないとか

321 :デフォルトの名無しさん:2010/07/31(土) 02:39:40
>>320
CPUごとに異なる言語を作るって意味ね。がんばれ。

322 :デフォルトの名無しさん:2010/07/31(土) 02:42:17
機械語やってろよもう

323 :デフォルトの名無しさん:2010/07/31(土) 09:10:57
>>320
残念ながら不可能

324 :デフォルトの名無しさん:2010/07/31(土) 09:54:04
> CPUごとに異なる言語を作るって意味ね。がんばれ。

意味がわからん。
言語がモニタとかの同期機構の面倒を見る、というのはAdaなんかであたりまえにやってるし、
AdaがCPUごとに異なるなんて話は聞いたことがない。

325 :デフォルトの名無しさん:2010/07/31(土) 09:59:30
なんで伸びてるのかと思えば、>>1が巻き添え規制から解除されてまた暴れてるのか。

326 :デフォルトの名無しさん:2010/07/31(土) 10:14:06
言語にRTOSを組めば→そのRTOSは何言語で組むの→その言語自身で… 

327 :デフォルトの名無しさん:2010/07/31(土) 10:18:37
>>313
GCで不意に止まっちゃ駄目な環境で最近作ってないんだけど、
昔ながらにプールしてGC極力走らせないとか毎フレ強制GCしたりの他に、
止まらないGCとかそういう手法みたいなのって開発されてないの?

コンシューマ機だと本体はC/C++ばっかりだと思うけど
最近はLuaとか当たり前に使われているよね?
そのへんどうしているのかな、と思って

328 :デフォルトの名無しさん:2010/07/31(土) 10:35:03
>>324
VESAのような統一規格があるモニタと、全くないCPUを同一と考えてるの?
CPUの型番で周辺機器も異なるし、物理メモリ空間の使い方も異なるし、
割り込み番号の振り方だって違うんだよ?
フリーのOSのソースコード読んだことある?

329 :デフォルトの名無しさん:2010/07/31(土) 10:54:45
モニタと言われて同期機構のことだとピンとこないような、RTOSのド素人は黙ってたほうが身のためですよ?

330 :デフォルトの名無しさん:2010/07/31(土) 11:06:45
OSとか組み込みマイコンとかの”チープな環境”の領域まで、
C(/C++)にとって変わらなくていいだろ。

言語にOS乗っけるとか、H/WでGCしろとか、本末転倒な話ばっかりじゃんかよ。

331 :デフォルトの名無しさん:2010/07/31(土) 11:27:12
ガベコレにはOSやハードウェア支援があったほうがいいし(現状あまり研究とかないけど)、
言語機能とOSの機能が(たとえばスレッドとか)密であっても悪くないだろ。

どこが本末転倒?

332 :デフォルトの名無しさん:2010/07/31(土) 12:23:44
>>324
モニタって既存RTOSのサポートがあってこそ。
既存CPUすべてサポートしてるRTOSなんて聞いたことないが。

333 :デフォルトの名無しさん:2010/07/31(土) 13:04:47
そりゃPICからスパコンまで全部サポートしてるシステムなんてないだろ。

>>321 は、CPUが異なったら、同期機構が異なるものになる、と主張してるようにしか読めん。
確かにテストアンドセット系のプリミティブはCPUごとに異なるけど、もしかしてそれを
直接言語にしたら、っていう意味なのかな?

たいていのOSでは、OSで共通化した同期機構を提供していて、CPUのそういったプリミティブは
掩蔽されているものだが。

334 :デフォルトの名無しさん:2010/07/31(土) 20:40:17
「C/C++に代わる」というのスレタイの解釈が、GC有り派とGC無し派で違うから
話が全くかみ合わない。

335 :デフォルトの名無しさん:2010/07/31(土) 20:46:08
>>1 としては「超高速」の存在によってGC有りは排除されると考えてるんじゃないだろうか。

336 :デフォルトの名無しさん:2010/07/31(土) 22:21:41
GC前提のコーティングとGCレスのコーティングって全く違ってくると思う

337 :デフォルトの名無しさん:2010/07/31(土) 22:25:43
GC有り排除は考えなくていいよ。

言語仕様にはGCを含めて、実装できる環境なら実装すればいい。
はじめから無しとする必要はない。

338 :デフォルトの名無しさん:2010/07/31(土) 22:28:07
GCがあって高速な言語がいまだかつてあっただろうか?

339 :デフォルトの名無しさん:2010/07/31(土) 22:39:23
LISPってC並に速いんじゃなかった?

340 :デフォルトの名無しさん:2010/07/31(土) 22:41:49
瞬間最大じゃなく瞬間最小が問題になるんだが

# 保証という課題に対する思想が深刻にまずいのがいるな

341 :デフォルトの名無しさん:2010/07/31(土) 22:42:14
実測結果を提示せよ

342 :デフォルトの名無しさん:2010/07/31(土) 22:46:31
このスレで考えようとしてるのってどう考えてもC++以下のゴミ言語だよね
アセンブラの方がマシってレベルだよ。脳みそ空っぽなんだろうな

343 :デフォルトの名無しさん:2010/07/31(土) 22:51:34
GC有りでCより速いのはないよな?
つまりGC有りは議論の余地すらないんじゃないか?
ここらでばっさり不要なものは枝刈りしないか?

344 :デフォルトの名無しさん:2010/07/31(土) 22:53:07
>>339
その主張には前提があって、
Lispのほうが高水準で、マクロとかの道具立てがあるから
アルゴリズムとかの試行錯誤がやりやすい、
だからより良い結果にたどり着きやすい、という意味

http://blog.practical-scheme.net/shiro/20100620a-lisp-speed

十分に大量のリソースが与えられたのなら、Cのほうが速くなるはず
実際、Lisp処理系を機械語レベルで眺めると、
C処理系ほど高品質なコードは吐かないらしい

>両者の生成コードの間には、実行効率の点で今だに無視出来ない開きがあるのも事実である。
http://jp.franz.com/base/seminar/2009-11-20/Seminar-09-AbeCompiler-Eval.pdf

345 :デフォルトの名無しさん:2010/07/31(土) 22:55:08
LISPのマクロは星井

346 :デフォルトの名無しさん:2010/07/31(土) 22:58:24
アセンブラのマクロって意外と便利だよな
俺はああいうのでいいよ

347 :デフォルトの名無しさん:2010/07/31(土) 23:02:25
>>343
ほんっっっっっとうに、頭悪いな

348 :デフォルトの名無しさん:2010/07/31(土) 23:02:57
>>343
GCは汎用のアルゴリズムだから、問題領域固有の条件を用いることができない
だから、理屈の上では、プログラマが慎重に手動管理すれば
速くなる可能性はある

……理論的にはね

349 :デフォルトの名無しさん:2010/07/31(土) 23:05:05
>>348
何その手動管理って。
GCレスより面倒な気がするが?

350 :デフォルトの名無しさん:2010/07/31(土) 23:15:21
汎用のアルゴリズムと言いつつ、
GC有り無しは完全に言語を2分する存在だよね。
このスレでも「GC有りは遅い」と思い込む人多数。
つまり性能がどうあれ需要がない。
そして需要はコード品質に直結する。
GC有りのJabaやどとねとは業界権力で生き残ってるけど、
使われてるから使うだけで、単なる1技術として見たら
本来は見向きもされない存在。

351 :デフォルトの名無しさん:2010/07/31(土) 23:19:31
シムラ、後ろ後ろ

352 :デフォルトの名無しさん:2010/07/31(土) 23:19:49
.NETからしか使えないようにするとか
DirectX10以上じゃないと動かないとか
すべて商売上の都合だな
あ、javaは影響力弱いから無くても困らないけどな

353 :デフォルトの名無しさん:2010/07/31(土) 23:21:37
GC無しの言語こそ需要ないけど

354 :デフォルトの名無しさん:2010/07/31(土) 23:23:44
GCって、意味解析レベルでGC発動がいつ起きて何を開放するか、
ってわかんないんだよね。これが気持ち悪いって人いると思う。
ライブラリで一応実装できるんだから言語機能に入れることないよ。

355 :デフォルトの名無しさん:2010/07/31(土) 23:26:09
最近の言語は、言語機能もライブラリで実装されているから、
ライブラリで一応実装できるんだから言語機能に入れることない、なんて必要はない。

356 :デフォルトの名無しさん:2010/07/31(土) 23:30:32
>>354
まあ失うものは結構あるけども、
それはそれで一つのアプローチだとは思う

357 :デフォルトの名無しさん:2010/07/31(土) 23:34:46
ところでPerl並に普及してるGCなしのスクリプトってある?
shとか?

358 :デフォルトの名無しさん:2010/08/01(日) 00:27:48
>>333
「掩蔽」じゃなくて「隠蔽」だな
>>354
「開放」じゃなくて「解放」だな

359 :デフォルトの名無しさん:2010/08/01(日) 01:32:04
とりあえず、GCありきの文法にならなきゃ、あろうがなかろうがどうでも良い話。
最後の最後に辻褄あわせるようにGC向けの構文入れりゃ満足だろ?

360 :デフォルトの名無しさん:2010/08/01(日) 01:34:38
構文上、プログラマーが意識しなくても適切にリソース管理が行われるなら、GCは無くてもいいよ。
GCは手段であって、目的ではない。

361 :デフォルトの名無しさん:2010/08/01(日) 02:44:46
>>327
GCのメリットデメリットは自動的に監視して解放することだから、
仮に自動監視を外したとしてC/C++でメモリをリスト使って管理するのと大差なくなるのでは?

Luaで止まるってことはなかなかないですよ。
どの道、利用しているのはC/C++の関数やクラスなので、
止まるとしたらC/C++側の問題のほうが多いです。
関数の実装に近いような使い方をするので生成とかは通常させません。

362 :デフォルトの名無しさん:2010/08/01(日) 02:47:44
int *hoge = (int*)GC::alloc(sizeof(int)*10);

これでいいんじゃないか?

363 :デフォルトの名無しさん:2010/08/01(日) 06:54:00
> GCって、意味解析レベルでGC発動がいつ起きて何を開放するか、
> ってわかんないんだよね。

資源を確保するところで起きる可能性がある。
はっきりわかってるじゃないか。

364 :デフォルトの名無しさん:2010/08/01(日) 06:56:34
「使わない」選択のない realloc か

365 :デフォルトの名無しさん:2010/08/01(日) 08:03:26
ほらな、みんなPCで動かすことしか考えてない。

366 :デフォルトの名無しさん:2010/08/01(日) 11:03:52
>>365
どうしてそう思っちゃったの?

367 :デフォルトの名無しさん:2010/08/01(日) 13:32:20
チープな環境ならGC使わなきゃ良いっつーけど、
ぶっちゃけ言うと、リソース管理を自力で出来ない奴が
その言語経験者としてアサインされることが一番困る。

368 :デフォルトの名無しさん:2010/08/01(日) 16:47:10
そこは事前に振り分けとけよ。

369 :デフォルトの名無しさん:2010/08/01(日) 21:17:43
その人事振り分けもやってくれるコンパイラを作ればおk

370 :デフォルトの名無しさん:2010/08/02(月) 02:04:38
>>327
ソフトリアルタイムシステムまでであれば
Erlangっていう実例があるので、決して不可能ではない

----
Erlangをベースとする初期のプロダクトが1993年に開発されていた頃、
(Javaのような)ゴミ集め処理を伴うVM用にコンパイルする言語を、
ソフトリアルタイムシステムに対して使うなどというのは狂気の沙汰だと批判されたものです
(Francesco Cesarini, Simon Thompson著 『Erlangプログラミング』より)
----

76 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)