そろそろ64ビットCPUでプログラムをやってみたい。
表計算とか256×65536→1024×100万ぐらいになる？
ペイントで30,000×30,000が扱えるようになるかも
DVDレベルのデータがメモリにのる。
みなさんは何がやりたいですか？
メモリの無駄使い
確かに・・・
64bitUNIXの世界に触れたい。
いや、金なくてSunが買えないのです；；
（ ´_ゝ`）ﾌｰﾝ
というかExcelのシートはなんであんなに小さいんだ？
あれは286のころの名残ですか？
アルファベット系のスクリーン感覚はあんなもんじゃない？文字そのものの形からインスピレーションを受け取るわれわれとはちょっと違うと思う(w
>>4 Bladeｼﾘｰｽﾞ 買って後悔する64ﾋﾞｯﾄPC
>>6 縦に65535もいらんから、横をせめて1024位にまで拡張して欲しいな。
Excelは意図的に制限してるんじゃないの？
あの制限を超えるのは、表計算ソフトとしての使い方として
間違ってるからAccess買いなさい、と。
10 ：
仕様書無しさん：03/06/23 07:59
>>9 そのわりには、Wordみたいな使いかたをする奴とか、
印刷できないサイズの表を作っておきながら
印刷時の文字サイズに難癖つける奴とか、一向に減ってないけどな。
11 ：
剛万太郎 ◆uuJAVAsys2 ：03/06/23 09:02
６４Bit用のJAVA VM 早くでねえかな
素パー子マシンかいな
13 ：
仕様書無しさん：03/06/23 10:29
ＥＸＣＥＬをＷＯＲＤみたいに使う奴は負け組
NetBSDがgcc3を取り込むまではOpteronは様子見かな。
今の時点でも動くみたいだけど。
Digital UNIX つかってましたが。
さあそこで Mac OS X 10.3 がどうなるか。
EXCELのオートフィルタの便利さを知って、
「EXCELだったら簡単できますよ！」といったら10万件データがあった。
その後、ACCESSを知った。
「EXCELで出来ないようなデータでも扱えるですよ！」
サーバのORACLEのデータを全てローカルに持ってきてインポート
ファイルサイズが1ギガバイト近くいってファイルが破壊。
だから、早く64ビットの世界を手に入れたい。
女性プログラマは，64bit CPUでのプログラムとか
興味ないのかな！
とはいえ，64bitOSで何を作るか？
Win32APIみたいな感動はあるだろうか...
こいつ独り言でスレ伸ばすタイプだな(W
>>21 見抜かれた
俺もそれくらい人物を見抜くSEになりたいものだ。
23 ：
仕様書無しさん：03/06/24 09:21
24 ：
仕様書無しさん：03/06/24 09:28
25 ：
仕様書無しさん：03/06/24 09:31
おまいらはどれ買うよ？
おれは1.8GHzのやつだな。
遂に漏れもマカーの仲間入りだ。
26 ：
仕様書無しさん：03/06/24 09:36
いまだに32bitのドザってﾀﾞｻ（ﾌﾟ
27 ：
仕様書無しさん：03/06/24 10:50
ﾏｺｽﾃﾝ最強
30 ：
仕様書無しさん：03/06/24 15:52
intをdoubleにキャストして
またintに戻して精度が落ちている事に
気づかずに悩まされる悪寒age
31 ：
仕様書無しさん：03/06/24 16:03
なんか32ビットが64ビットになったのでメモリ空間の上限が2GBから
4GBになりました、とか書いてあるんだけどさ、アップルのサイト。
それってなんかおかしくない？メモリアドレス空間が純粋に32ビット
から64ビットになったのなら、二倍じゃなくて二乗になるはずでは？
32 ：
仕様書無しさん：03/06/24 17:00
2GBの2乗は4GBで合ってないかい？
2GB * 2GB == 2GBの 2乗
4GBじゃ 1bit増えただけじゃねーの？
34 ：
仕様書無しさん：03/06/24 17:06
>>32 下の答えはいくつですか？
2GB * 2 =
>>32 なんでやねん。
2GBの二乗は4エクサバイトだよ。
36 ：
仕様書無しさん：03/06/24 17:28
>>31 後、根本的な部分を叩いて悪いが、8GBです。
これね。
他の何かがボトルネックになってるんだろうなぁ。
64-bit breakthrough
新しい64ビット PowerPC G5 プロセッサのおかげで、
Power Mac G5はとうとう4GBの壁を突破し、
いままでの典型的なPCの約4倍の最大8GBもの
メインメモリをサポートできるようになりました。
>>36 ああ、すまん、凡ミス。
しかし依然として2乗になってないのが不思議。
ということは4GBの2乗だから16EBか。
40 ：
仕様書無しさん：03/06/24 19:09
ますますもってわけわからん
AAは略ｗ
やっぱマ板だな、ここは。
1024B = 1KB
1024KB = 1MB
1024MB = 1GB
1024GB = 1TB（テラバイト）
1024TB = 1PB（ペタバイト）
1024PB = 1EB（エクサバイト）
44 ：
sarada：03/06/24 19:30
いいから黙ってﾏｺｽﾃﾝ買え！
物理メモリの搭載量はたんにハードウェアの制限だ。
ど ど い マ わ
＿＿＿＿ な ま カ っ
／ ＼ い す が
| /l/lハハl＼l | し よ
| | ● ● | | よ ？
| |ι | | ・ 〟- ― - 、
| ヽ_ ⊂⊃ノ | ・ γ⌒///ハ＼＼Ｙ⌒丶
|/l／ ＼￣l＼ﾊﾉ / /|(● (● | ヽ
/ ＼ ∀ ＼ l / （ Ｊ)＼ |
| ＼＿＼ |／＼ し' ＼ [￣] ノ ゝ、ﾉ
| ＼＼＿|＿＿＼ /￣／ 丶
| `ー―――(ξξ`┴―＼／|
47 ：
仕様書無しさん：03/06/24 22:04
48 ：
仕様書無しさん：03/06/24 22:20
マックはやっとNintendo64に追いつきましたage
49 ：
仕様書無しさん：03/06/24 22:23
ドザは未だにセガサターンです。
>>48 G3 に取って変わられたゲーム機なんかどうでもいいですsage
…つか、元の POWER 4 から随分パワーダウンしたなぁ＜G5
53 ：
仕様書無しさん：03/06/24 22:26
64bitだろーが128bitだろーが、うちで使ってるソフトのC版はでっかい数に対応してないので関係ありません。
「何とかして使う方法ないんですか？」
「COBOL版ならできます」
…答えになってねえよウワァァン！
なんかMacの情報になっていますねー
ちょっと調べてみよう
>>47 ほーなんかすごいらしい
以下引用
プロのクリエイターに64ビットという比類ない処理能力を提供し、
同時に32ビットのアプリケーションにもネイティブで対応します。
PowerPC G5は最高2GHzのクロックスピードで動作し、
事実上、18エクサバイト(180億バイト) ものメモリに対応可能です。
56 ：
仕様書無しさん：03/06/25 00:27
64bitのアドレス空間っていうのは多分50年は使えるだろうな。
16 -> 32という拡張とはレベルが違うんだよ。
128bitのアドレス空間っていうのは多分2500年は使えるだろうな。
32 -> 64という拡張とはレベルが違うんだよ。
58 ：
仕様書無しさん：03/06/25 02:15
つまりMACHが最強ということです
そろそろEMSでも買っとくか
エクササイズ
61 ：
仕様書無しさん：03/06/25 06:10
RS6000でMac OS Xが動くらしい
>> 57
2^128=
340,282,366,920,938,463,463,374,607,431,768,211,456
or
340,2823,6692,0938,4634,6337,4607,4317,6821,1456
読めないぐらい凄い数字ですねー
K,M,G,T,P,E,Z,Y 足りない
万、億、兆、京、垓、杼、穣、溝、澗
メモリ空間は5年でおよそ3.3ビット拡張されてきた。15年で10bit拡張される勘定だ。
よって (64-32)*5/3.3=49年で
>>56 は正しい
一方
(128-64)*5/3.3 = 97 であるので
>>57 は全く正しくない。
ムーアの法則が守られるなら来世紀には128bit空間も不足するのである。
66 ：
仕様書無しさん：03/06/25 07:23
ハードウェアの能力はリニアに伸びるけど、ソフトウェアの
生産性、処理効率は殆ど頭打ちですね。ハード屋さんが
ソフトの人を無能呼ばわりするのもなんとなく分ります。
それだけ、ソフトウェアは難しいものだとも言えるかもしれないけど。
ハード屋さんは自ら培った技能で本人がクラスチェンジしてゆくけど
ソフト屋さんは人間の方がチェンジされてくからね・・・・
ソフト作成能力の測定ができないのが一番の問題だろう
技術革新は、計測技術の革新といってもいいと思っている。
69 ：
仕様書無しさん：03/06/26 11:06
>>65 5歳児を見て、
「こいつはハタチになったら、身長6メートルくらいになるな」
みたいな感じ？
ムーアの法則が来世域まで守られる筈が無い。 その意味では
>>65も そして
>>57も正しくない。
ありえな話だが、仮に1ビットの情報を分子1個で記録できたとして、
分子の重さ１個を 512* 1.67×10-27kg だとしよう。
8*2^128 メモリを実装するのに必要な重量を計算してみよ。
>70
電子1個の間違いじゃないのか?
ちなみに電子の質量は9.12*10^(-28)グラム
>>71 記録する媒体がいるから電子1個じゃ無理だろ
>>70はそれも含めて分子1個と言ってるのかもしれん
73 ：
仕様書無しさん：03/06/26 15:17
分子とかいうと実感湧かない。
新聞紙で例えてくれ。
>>69 いや、冷蔵庫を100回開閉するとお湯が(ry
12月には気温が60度（ｒｙ
分子 8*2^128 * 512* 1.67*10E-27 /1E3 23テラトン
電子 8*2^128 *9.12*10E-28/1E6 24.8メガトン
流れを戻したい...........
QXGAディスプレイ
ハイビジョン画像のFLASHなんてことが出来ないものか？
79 ：
仕様書無しさん：03/06/27 23:29
64bit×2で128bit級のMacを語るスレはここでつか?
>>79 Macなら、80万円で8ギガのメモリ空間が手に入る
どうしますか？
何をしますか？
81 ：
仕様書無しさん：03/06/28 06:32
OpteronとG5の影響か、Itaniumが現実的なパフォーマンスと
値段で出てくるらしいじゃないか。
おまいらにはPS2で十分
>>81 16ビット→32ビットを思い出すと
次はOSとドライバーと開発環境の対応か
Microsoft Windows95 が懐かしい
それはそうと
CPUが32ビットになって、
OSが32ビット対応で普及するまで
何年かかったんだ
それを考えると64ビットはまだ先か？
DOS や Windows95 を出したように
「これは使える」というようなものが出てくるのか
32bit化は当時望まれてたからね。 RAM 16MByteは あきらかに16bit空間には狭すぎた。
今RAMはまだギガに手が届いた程度。この広さはまだ32bitに収まる上、CPUの速度からして十分に広い。
後５年先には少し狭く感じるようになるだろうが、しかしバス速度がそれほど増えない以上、
メモリの増設にそれほどの意味がない。
また、今の32bitCPUの速度で動画も扱える現在、個人需要を喚起できるような用途が見つかるかどうか・・・
まあ、可能性があるとしたら人工知能かな。
そろそろ容量的には人間に匹敵するわけで、人工知能的なペットとかの応用が尖兵になりえるかもしれないね。
現在のx86は最大64GBまで扱えることを考慮すると、
現実問題として当分メモリ不足を理由とした64ﾋﾞｯﾄ化は考えにくい。
だが、16ﾋﾞｯﾄ期の芸術的なﾒﾓﾘ割り当ての再来を嫌って、
今の内にと言うことならあり得るかもしれない。
64ﾋﾞｯﾄ化するのは恐らく扱えるﾌｧｲﾙｻｲｽﾞ（巨大なﾌｧｲﾙが扱えるｼｽﾃﾑを作りやすくなると思われる）と、ﾒﾓﾘｱｸｾｽのﾊﾞﾝﾄﾞ幅拡張に伴ってと言うところか。
AMDがIntelに対抗して、とりあえず64ﾋﾞｯﾄ化しとこう、というだけかも・・・
10ギガバイトのメモリを確保
char *pData
pData=(char *)malloc(10737418240)
初期化だけでも凄く時間がかかりそう
やっぱりネックは、メモリアクセスのバンド幅不足ですねー
そういうことで芸術的なコードが必要になりそうです。
砂漠のようなプログラムでは無理です。
森林のようなプログラムへ...
なぜ割り当てた段階で初期化する必要があるんだ。
最初にアクセスするまでページ不在にしておけばいだろ？
88 ：
仕様書無しさん：03/06/29 22:23
64bitアドレス空間とは、先行投資だよ。
大事なものは新しい世界が見えると盛り上げること。
そこで新たな需要を喚起できるなら言うことないじゃん。
「今必要ない」なんてのは、経済というものを分ってない。
89 ：
仕様書無しさん：03/06/29 22:24
>>87 VMMについて知らないひとが多いからな。
また使っていないメモリはOSによってバッファキャッシュとして
使えるという事実も無視されがち。
91 ：
仕様書無しさん：03/06/29 22:33
んなこといったって2G以上のメモリを一つのプログラムが使うことなんてそうもないだろう・・・。
脳の容量って何テラだったっけ？
93 ：
仕様書無しさん：03/06/29 22:38
>>91 アドレス空間とは、万が一に備えて広げておくもの。
そしてPCとはデスクトップからサーバまで、同一の
プロセッサを使うことによりコストダウンが図れた。
となれば、AMD64しかないと思いますが。
>>91 懐かしい昔ばなしとして、その書き込みを思い出すのは何年後だろうな?
96 ：
仕様書無しさん：03/06/29 22:51
>>93 メモリリークありでもしばらく動いてなきゃいけないようなものを動かす場合なら
セーフティネットとしてアリかもしれませんな
しかしだ、
>>94 16bit のときゃそりゃ大変だった。
でも、2Gもあればヒトがプログラミングするなら十分。
喩えるなら、水撒きするのに
8bit: 撒く水無し
16bit : 注射器
32bit : ホース
64bit : ダム施設
みたいなもんだ。ボトルネックはとっくに解消されてるんだよ・・・
バス幅二倍。よき事かな。
5GBぐらいあるストリームをmmapできるなどと考えただけでﾊｧﾊｧだな。
>>99 まー、だんだんそういうゴージャスな使い方になっていくんだろうなぁ。
取り敢えず、ファイル周りは既に2GB超えまくりだな。
102 ：
仕様書無しさん：03/06/30 05:14
で、OpteronとG5のどっち買うのよ？
>>102 漏れはOpteron
>>91 DBMSとかに取っては2GBや4GBの上限は厳しいだろう。
あと、単純に扱うデータ量が2GBを越える場合、ﾒﾓﾘがｲﾊﾟｰｲあれば、
ﾃﾞｨｽｸに待避するように作り込む必要が無くなる。と言ってみるﾃｽﾄ。
104 ：
仕様書無しさん ：03/06/30 06:57
0xffffffffffffffff
って16進数も表記が倍になって見づらくなるな。
ところで、64bitUNIXはtime_tはデフォルトで8バイトなのかな？
>>103 メモリ容量にアクセス速度が追いついてない以上、結局そういうキャッシュの代替としての利用しかない感じだね。
そういやバス幅は既に64bitですよね？
>>104 数値リテラルの間に _ が挟めるコンパイラがあるよ。
0xffffffff_ffffffff みたいに。
107 ：
仕様書無しさん：03/06/30 11:55
Athlon64まだぁ～
109 ：
映像制作板住人：03/06/30 13:07
正直、動画をやっている住民には、数年前から32bitの壁があった
一ファイルが、2GB,4GB(0x01<<(sizeof(int)*8))じゃたりねーんだよ！
今や動画は数十GBの世界。無圧縮ハイビジョンが出てくればTBに迫りそうな勢い。
はっきり言って、今のコンピュータの性能は全く足りない。メモリもGB単位で
積んでほしい。
だから、DTV板の住人は64bitコンピュータの登場を待ち望んでいる。
大きなデータを扱う人は、みんな待ち望んでいる。速くハード＆ソフト
（おまいらが作るわけだが）を出してくれ。
110 ：
映像制作板住人：03/06/30 13:09
ようやくPG板にまともなスレが立ったな
MSはItaniumなんて放置しちゃってOpteronに専念してくれれば
いいんだけどなあ
この前、初めてHP-UX触ったけど、ファイル周りなんかの関数が、
32bit引数版と64bit引数版とで、微妙に名前を変えて二重に用意されてて、
何か汚いと思った。
>>109 2次元ウィンドウでのイベントドリブンプログラムしか
書いたことない自分にとってはハードルが高い。
まず、仕様書を書いて欲しい。
何がしたい？何が問題？
114 ：
仕様書無しさん：03/07/01 16:51
なんだかんだで結局Pen3のPCサーバが今後も売れつづけていくんだろうな
いくらなんでもずっと製造されるとは思えんので印TEL次第のような。
117 ：
仕様書無しさん：03/07/03 05:08
Itaniumは正直凄いな。
Linux用のエミュレータを使ったことあるひといる？
Win32だと、よく
HogeHoge* hoge = new HogeHoge();
HogeAPI( (DWORD)( hoge ) );
みたいな書き方したりしてたけど、
これって再コンパイルだけじゃ64ビット化しないんだろうな。鬱だ。
....いや、DWORDが64ビットと解釈されればOKか....
>>119 DWORD → QWORD？
64ビットに書き換えれば、
しばらく大丈夫か？
逆に、今度こそ一回書いたら
かなり長く使うことになるから、綺麗な設計、簡素で力強いが理想
トンネル、橋、ダムを作ること考えるような感じでしょうか
ファクタは、”メモリの増大”と”アクセス速度の向上”
64ビットは
動画がキーワードとしても何をしていいやら
300ギガバイトのディスクを4つ付けて、ソフトウェアRAIDで１寺つかえたら
何かできる予感がするけど...
だれか地球全体の50ｍメッシュデータとか持ってないですか？
カシミールで世界旅行出来そう
122 ：
仕様書無しさん：03/07/08 22:04
処理はすべてメモリ空間で行って、ログアウトするときまとめてデータをＨＤに書き込む。
ってシステムくれ。
123 ：
仕様書無しさん：03/07/08 22:07
デバッグが羽ぜーョ
データぶちこみや、スナップショットがたいへんだ
>>1 64bits版Javaでもインストール汁。
おまいの想像するようなことはエミュレートすりゃ64bitsでなくてもできるがな。
125 ：
仕様書無しさん：03/07/08 23:20
>>122 作業中にクラッシュしたら、全部消し飛ぶ。
なんの手がかりも残さずに。
またログアウト時にHDDのボトルネック分の処理時間が全てかかる。
数GB分の作業を書き込む程度でも、結構待たされると思われ。
64ナリナリ日記？
>>126 電源を落とさず、ログアウト出来ないようにすればいい。
万が一落ちた場合はそれまでよっと。
__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
~￣￣￣￣
130 ：
仕様書無しさん：03/07/18 07:27
メモリたくさんの安いOpteron 環境ないでしょうか？
>>130 安いのはAthlon64まで待ちじゃない？
今のは高いメモリ買わないとダメなんだよね。
Deerfieldまだぁ？（AA略
Intelって結局誰かに尻を叩かれないと何もしないのな
Deerfieldは買うつもりだけどさ。なんつうかもっと早くに
こういうことできないのかね。
134 ：
仕様書無しさん：03/07/19 16:02
>>133 Deerfield+Win2003sv+Oracle9i+XML+PNG or
Deerfield+Win2003sv+FTTH+動画 がサクサク
だとすばらしいけど
>>134 そいういう用途ならOpteronの方が速そうだがどうだろう。
136 ：
仕様書無しさん：03/07/19 20:40
ポインタは動画とか扱わない限り、32bitでも十分広いから、
余った半分の32bitを別の何かに使いたいんだけど、
そういう事ってできる？>64bitCPU
x86で言うと、仮に64bitレジスタqax(qah=拡張 qal=eax)があったとして、
ポインタ演算は[eax]でもよく、
qahを別の何かに使える、とか。
>>136 最初から32bitアプリケーションとして書けばいいんじゃないの？
139 ：
仕様書無しさん：03/07/19 21:39
>>136 いっている意味を本当に理解してるのか？
意味のないことをいっていることに気づいているか？
140 ：
仕様書無しさん：03/07/20 02:26
(2^64)^2
＝ 2^128
＝ 340,282,366,920,938,463,463,374,607,431,768,211,456
＝ 340グミ282ゼッピ366グルーチ920ハーピ938ヨッタ463ゼッタ463エクサ374ペタ607テラ431ギガ768メガ211キロ456
142 ：
仕様書無しさん：03/07/22 22:32
つまり
≒340.3グミっていうことでage
143 ：
仕様書無しさん：03/07/22 22:39
ヾ(*ΦωΦ)ﾉ Win64API
Win64を意識してコーディングしてます？
おｐてろｎ
155 ：
仕様書無しさん：03/07/31 19:33
∧＿∧
（ ＾＾ ）＜ ぬるぽ（＾＾）
∧＿∧ ∧＿∧
ﾋﾟｭ.ｰ （ ・３・） ( ＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
＝〔~∪￣￣￣∪￣￣〕
＝ ◎――――――◎ 山崎渉&ぼるじょあ
シングル用Opteronってあんまり意味なさそうじゃない？
mad64用の開発マシンが欲しいなら、Athlon64まで待った方がいいし。
64ビットプログラマ
>>159 Athlon64ってまだまだ待ちそうなのでは？
164 ：
仕様書無しさん：03/08/12 17:51
AMD64はCompatモードと64ビットモードでは、
CS.Lでの両モードの切り替えだけで、命令体系はそのままなの？
つまりシステムレベルの操作は別としても、デフォルトのオペランド、
アドレスのデータ長が変わるだけであとは同じというか。
だとすると、一見ごちゃごちゃしてるように見えて、かなりスッキリした
印象ですね。
それにしても64ビットモードのオペランドのデフォルトデータ長が
なんで32ビットなのかな。アドレスと同じデータ長のデータを扱うことの方が
多い気がするけど。
165 ：
仕様書無しさん：03/08/12 17:58
(？？Д？？)？？？？？？<br>？？？？？(？？Д？？)？？？？？？
166 ：
仕様書無しさん：03/08/12 18:38
AMD64向けにライブラリ書いてるひととかまだいないのかな。
こっちはまだシステムマニュアルちょびちょび読んでる程度だけど。。。
167 ：
仕様書無しさん：03/08/12 18:58
>>167 せっかくスレッドを立ち上げながら
技術的に引っ張っていけなくてすいません。
薄っぺらいプログラマーなのがばれてしまった
具体的にどの辺りから読めばいいのでしょうか？
169 ：
仕様書無しさん：03/08/12 21:43
static char buf[0xffffffffffffffff];
(⌒V⌒)
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
intのサイズが大きくなりすぎです。
>>173 >でも使えるメモリは１アプリ４Ｇバイトまでらしい
OS が 32bit のままだからじゃないでしょうか?
175 ：
仕様書無しさん：03/08/19 23:26
>>172 8byteくらいけちんな
そのうち、
char* p;
p = (char*)malloc( 0x01<<32 ); /* 4GBでﾊｧﾊｧ */
と書くようになるだろう・・・
176 ：
仕様書無しさん：03/08/19 23:29
変数のサイズだけど、
[32bit OS]
char 1byte
short int 2byte
long 4byte
int 4byte
float 4byte
double 8byte
[64bit OS]
char 1byte
short int 2byte
long 8byte
int 8byte
float 4byte
double 8byte
となるらしいな。longは4byte固定と思いこんでうってた・・・まずいなぁ～
177 ：
仕様書無しさん：03/08/19 23:34
Darwin作ってるエンジニアってLinuxやNetBSDの
人たちと比べると、ヘタレ臭くないですか？
178 ：
仕様書無しさん：03/08/20 05:09
MSは64bitへの対応をItaniumのときに済ませてるから、
Opteronへの対応はあっというまにやってしまった。
あぽーは今回が始めてのケースだから恐らく時間がかかるものと思われ。
ただでさえ、ソフトウェア弱いのに。カーネル、libc、GNUツールが
対応したところで、開発ツールなんかいろいろと大変そうだし。
>>176 確か、所謂 UNIX 系は LP64 (int:4byte/long:8byte)、
Windows は LLP64 (int:4byte/long:4byte/long long:8byte) だったかと。
>>173 そんな応用ﾚﾍﾞﾙの物はただのﾗｲﾌﾞﾗﾘでｻﾎﾟｰﾄされる物だろ？
OSに標準で付属するﾗｲﾌﾞﾗﾘで、
その他のAPIと同じ感覚で使えるのなら、
APIを名乗る可能性はあるけど、
ｶｰﾈﾙﾚﾍﾞﾙで特別なｻﾎﾟｰﾄを行う物では無いと思うな。
intが32bitのままだなんて、夢が無いな(;´Д`)
nForce3 Pro 150 のレポート
http://pcweb.mycom.co.jp/benchmarklab/2003/25/ >>179 1Byte,2Byte,4Byte,8Byte
それぞれのsigned,unsigned
どう使うのがよいか迷ってしませんかねー
それより画像ＳＱＬミドルウェアを作りたい今日この頃
insert into Table col1 values GRAPHIC('File Name');
で画像を追加
SET OUTPUTHTML=TRUE
select col1 from Table でHTMLで出力されて画像を確認できるようなもの
あと、データベースで時刻型と同じようなレベルで
緯度経度型が使えるような方法を考えてみたい。
やっぱり、これだけいろいろやるには６４ビット？
183 ：
仕様書無しさん：03/08/21 22:58
OSXは重い。
184 ：
仕様書無しさん：03/08/23 02:49
ビッグでもリトルでもいいから・・・・・
エンディアンはどっちかに統一してくれぃ
188 ：
仕様書無しさん：03/08/24 17:24
SQL ServerのEnterprise Managerでテーブル作成するとき、
char型のカラムはデフォルトでは10桁になる。
これに数字入れてintにParseして使ってたら、21億超えでハマった。MSの罠。
>>188 >intにParseして使ってたら、21億超えでハマった。MSの罠。
罠でも何でもない気がしますが…
191 ：
仕様書無しさん：03/08/29 10:11
Athlon64が欲しいんだが、なんだか雲行きが怪しくなってきたな。
おまえらも買ってやれよ、頼むから。
192 ：
仕様書無しさん：03/08/30 15:23
Athlon64-Mって出るの？
ノート買ってもいいんだけど、値段次第
で、なんかいい事あんの？？
もっさりPen4よりはいいことあるだろう
194 ：
仕様書無しさん：03/08/30 16:07
>>186 俺も作ってたよー。
Windowsでもできる仕事なんだけどなあ・・・。
195 ：
仕様書無しさん：03/08/31 02:25
昔は、bool型は1byteだったが、ちょっと前に4byteに変更された。
そのうち、bool型は8byteになるのであろうか？
1bit格納するのに、64bit使うとは・・・
boolのバイト数が増える度にbool（真偽のほど）の精度は高くなっていく
0 完全に嘘 ～ n(最大の数) 完全に本当
n/2 嘘かどうかは判断しづらい
n/6 やや嘘っぽい
などなど。なお、環境によって0が完全に本当という意味になることもある。
197 ：
仕様書無しさん：03/08/31 13:32
構造体の荒井メントも8バイトになるの？
>>196 そうか、64ビットはファジーなんだな！
ぬいふぃゃく ぐぇっとぅぅぅ
改めて見ると、64ビットはでかいな
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000001
・
・
1111111111111111111111111111111111111111111111111111111111111111
メモリ１テラでも全然平気だろうな、やはりＤＢに最適！
あとは慣れだろうな、「メインメモリって遅いんだよなー」とか
言えるぐらい慣れたら．．．
202 ：
仕様書無しさん：03/09/05 20:14
３２ビットアライメントで構造体作ってるアプリ全部うごかねーんじゃねーの？
しかしAthlon64なりのアプリケーションってものがなかなか思い浮かばないな。
プログラマなら64bitってのはそれだけでﾜｸﾜｸするもんだけど、一般のユーザに
具体的メリットを示すのは難しいかも。ホントはメリットがあるかどうかじゃなくて
無理やりでも買わせるような方向に行けばいいんだけどなかなかねえ。
207 ：
仕様書無しさん：03/09/11 12:59
Athlon64MB単体で予価18000
CPUは予価58000になるみたい。
IA-64やx86-64な実行ファイルを生成するコンパイラって何があるかな？
gccが両対応、Intel C++ CompilerがIA-64対応ぐらいしか思いつかない。。。
Visual Studioとか対応せんのかな。。。
>>209 psdkにはia64用コンパイラが無料で付いてくるけど(ia32用はなし)
213 ：
仕様書無しさん：03/09/13 19:28
214 ：
仕様書無しさん：03/09/13 19:43
プレステ２で
128bitのメモリやレジスタ扱ってると
気疲れしてきます。
int32, int64, int128...ｻｲﾃｰ
216 ：
仕様書無しさん：03/09/14 11:15
AMD64やItaniumと比べると、POWERのドキュメントってなんか貧弱だな。
LinuxやGCCのPOWERに関するコードはIBMの人間が多くを書いてるけど、
もしかしてハードの情報はわりとクローズドなの？
Athlon64発表会一般参加抽選の当選通知ｷﾀ─wwﾍ√ﾚvv～(ﾟ∀ﾟ)─wwﾍ√ﾚvv～─!!!!
219 ：
仕様書無しさん：03/09/21 22:50
221 ：
仕様書無しさん：03/09/23 16:25
>>176 Ｃ/Ｃ++言語嫌い！出来ん！使えん！
ＣＰＵのレジスタサイズやプログラムカウンタに依存して変数の型の長さが変わるなんて使い物にならん。
222 ：
仕様書無しさん：03/09/23 16:31
1byteのビット数は実装依存らしいな。
>>221 システム記述に使えるもっといい言語はないでしょうか？
CommonLISP？ML？
>>221 >ＣＰＵのレジスタサイズやプログラムカウンタに依存して変数の型の長さが変わるなんて
それを当然と思えないあなたは、いったいどんな環境でプログラムを書かれているんでしょう??
せめてCではなくPascalが流行っていたら、
言語改良の向きもあったろうに。もうだめぽ。
225 ：
仕様書無しさん：03/09/24 10:45
ところで結局言語仕様はどうなるのですか？
今までintと書いてた所が64Bitになるの?
その場合32Bitは？
それともint64で使うのですか？
情報に疎い私に教えてプリーズ
>>225 WindowsはP64(int=32,long=32,long long int=64)
UNIXの主要な実装はLP64(int=32,long=64)
となっています。アドレス値は当然どちらも64です。
アドレスのデータ長をなんらかの型と同じと見なした書き方を
しているプログラムは64bitアプリケーションとしてビルドするにあたり
書換えが必要になるでしょう。
構造体のアライメントは一般的に最大データ長にあわせられる
ものですが、intとポインタからなるよくある構造体の場合、
アライメントが4⇒8となるので注意が必要かもしれません。
227 ：
仕様書無しさん：03/09/24 11:59
228 ：
仕様書無しさん：03/09/24 18:31
230 ：
仕様書無しさん：03/09/24 19:42
>>226 ありがとございます。
ということはポインタは全て8Byteって事ですね。
構造体メンバとかにマクロ使わずにintとかboolとか打ってる奴はまずい？
なんかすごい嫌な予感が……。
まずいのは PCHAR( hoge.x) とかのポインタ/整数メンバ変換やってる場合でしょ。
今時構造体をそのまま通信・ファイル入出力で使ってるような事やってないでしょ？
それなら問題なし
>>230 いや、intやboolはそれだけじゃ問題にならない。
問題になるのはポインタのデータ長が変わること
(UNIXではlongも変わる)それだけ。それにともなって
structやらunionでいくつか問題もでてくるかもしれないけどね。
それ以外は大丈夫ではないだろうか？
WindowsもUNIXも32/64混在環境にはしないつもりらしいし。
むしろシステム標準の型がどういったふうに定義されてるかに
左右されそうなことが多いかも。size_tはUNIXもWindowsも64らしいです。
他のものはヘッダをよく見てみないと分りません。
>WindowsもUNIXも32/64混在環境
これはプロセス辺りっていう意味ね
まあ、あれだ。
IT=いわゆるフロッピー
これさえ押さえておけば大臣になれる。
235 ：
ぽんぽん お腹いっぱい：03/09/24 20:42
大臣 だいすき
ついでに がりちょこだいすき
236 ：
仕様書無しさん：03/09/24 21:33
MAC最強！！！
WindowsXP for Opteron and Athlon 64-based System
なんか簡単に読む方法がないものか
英語版のβ版が出るみたいだが
238 ：
仕様書無しさん：03/09/25 00:18
そろそろ会社で買ってもらってる香具師の具体的な話が聞きたいな。
Cの型云々とかならヘッダを読めばいいんだけど、使って得られる
実感を分けてほしい。。。
240 ：
仕様書無しさん：03/09/25 09:10
ズバリ32->64Bit構造改革はいつ起きますか？
やっぱOSが出てからですか？
16->32に比べたら 切迫感も無いし 待望感もないし・・・
>>240 いや、いまどき64bitを意識してコード書いてないのは不味いでしょ。
16⇒32みたいなめんどくささがあるわけでもないし。
実装依存になってしまうところってのはどうしても出てくるけど、
そういった箇所をちゃんと認識して#ifしておくだけでもいいかと。
>>241 Windows用の業務用のアプリケーションなら別に32bit向けだけを考えて
いてもいいのでは？余計なことかんがえて時間がかかるのもおかしな話だし。
個人的にはそういうところは.NETなんかで済ませた方がいいと思うけどね。
いづれMSが.NETランタイムをAMD64やia64向けに出してくれることを期待して。
243 ：
仕様書無しさん：03/09/25 22:23
>>231 今時かかれたコードならまずありえない。
でも今時かかれたコードじゃなくても現役のコードっていくらでもあるでしょ。
あと古いコード(K&Rの時代)だとプロトタイプ宣言が不十分な奴があるよね。
本来はプロトタイプ宣言が無いと、
void *hoge(void*,void*);
が
int hoge(int,int);
と解釈されちゃう。
ILP32環境だと動いててもLP64だと動作しない。
lintぐらいかけろよと思ってしまう。
プロトタイプ宣言がないのぐらいコンパイルエラーにしろよ
246 ：
仕様書無しさん：03/09/25 22:35
世の中の全てのUNIXが64bitマシンで動くようになったら、
38年問題は解決するのかな？
>>246 すべてのアプリがLP64のデータモデルでコンパイルされない限りそれは無い。
基本的に64ビットOSでも32ビットのバイナリは動作するので
メモリ使用量の問題でも無い限り積極的に64ビット化をする必要は無いんでなかなか
64ビット化は進まないと思う。
>>247 だがNetBSDみたいな組み込み指向のシステムですら、
32bitのuserlandをどうして用意しないのか？って
質問に対して開発者の人は64bitの方が速いし、
今時メモリも沢山積まれているから問題ないって答えてましたよ。
つまり32bitの互換性とはバイナリに対して確保されているもので
あって、新たに何かをビルドするときは64bitとしてビルド
するものだと。
つまり、
>すべてのアプリがLP64のデータモデルでコンパイル
これはそれほど遠い未来の話でもないだろうってことです。
>>246 time_t型の変数の問題のことだろ？
2038年問題って書かなきゃわかんないやつもいると思うぞ。
答えはyesだ。
25年も先のことを心配するなら、西暦10000年問題を持ち出すぞ。
いまどきの32bitプロセッサには64bit整数を扱う機能があるみたいですが、
そういうシステムにおいてはtime_tをlong long intとして定義すると
どんな不都合が出てくるんでしょう？
>>248 すべてのプログラムが単純にLP64オプション（solaris9なら-xarch=v9オプション）つけるだけで
済むならそれはあってるけどね。
つーかほとんどはそれで問題ないけどね。
そうも行かないケースもたまにある。
>>251 time_t型を返す関数の精度は相変もわらず32ビットだから意味無い。
>>253 カーネルやlibcに対する変更も含めての話です
>>254 細かい条件が不明だから答えようが無い。
どこかで新しい日付のデータ型を取り入れて、アプリケーションプログラムの
ソースの書換えを徐々に促すしかないんでしょうか。
time_tを64bitにしたところで、何か他のlongとして定義されてる型と
同じデータサイズっていう前提が入ってるだろうし。
64ビットOSでプログラムをはじめる前に
128ビットを意識するのは大変だ。
どちらも大きすぎる。
>>257 128ビットの環境ではデータ型の変更は
ポインタが128ビットになるだけの予感。
P128とか。
long long ing = 64bit
long long long ing = 128bit
long long long long ing = 256bit
とか増えていくのかな？ｗ
261 ：
仕様書無しさん：03/09/26 00:55
Itanium2の方はどうなってるんでしょ
現行でいくとint64, int128, int256になるのでは？
なんか名前がつくか
264 ：
仕様書無しさん：03/09/26 11:45
ソフトウェアエンジニアに朝鮮的な課題を突きつけるIA64萌え
265 ：
仕様書無しさん：03/09/26 12:26
>>263 Deerfield搭載のワークステーションが出るのはもう少し先みたいですねえ。
自作板情報によれば今年の12月頃だとか。
あと、IA32のエミュレーションレイヤはWindowsだけですか。
Linuxは自分等で実装汁ってことですか。。。
266 ：
仕様書無しさん：03/09/27 01:50
267 ：
仕様書無しさん：03/09/28 08:00
あの、64Bitになってintのサイズが変わるのは分かるんですが、
他はどうなるんでしょうか？
longとかfloat, doubleと言った所は？
floatとかってもしかして将来64Bit精度になったり？
>>267 そもそもわかって無いじゃん。
LP64,LLP64,ILP32をググってみれ。
>>267 どうせなら
8,16,32,64,128,256bit
に型名を振っとけばいいと思いません
ただ、
>>259 のようだと見づらい
>>214 のようだと味気ない気がする
64bitを中心に
16→short short、32→short、64→int、128→long、256→long long
がいいかな
short shortって★真一ですか？
それはさておき、現状のPentiumですら128bit整数演算が
出来るんだから、プロセッサが128bitになるとか関係無しに
128bit long intがCに必要だと思うのね。もしかして既に実装してる
コンパイラなんかあったりするの？
整数はint8,int16,int32.int64,int128・・・
浮動小数点はfloat32,float64.float128・・・
でいいじゃないですか
CPUやOSなどの違うプラットフォームで共通で動かす必要があるソフトを書いているので
64ビットの実装が現状だといろいろあってめんどくさい
printfとかの内部も%d32 %d64 %f32 %f64
になってはくれないものだろうか
>269
のようなことされるとビットの拡張が行われるたびにプログラムの書き直しはめんどくさすぎ
現状だとLLP64が広まるとうれしいかな
LP64だと32ビットのつもりでlong使ってる前の引継ぎの問題があるから・・・
>>271 複数人で開発していると確かに引き継ぎの問題発生するかな
64ビットプログラムで考えると
C言語の案件はほとんどが移行だろうし、
COBOLはUNICODE対応とかオブジェクト指向とかあって
ぼろぼろになりそうだ
綺麗なソースはJavaだけになるかな
でもパフォーマンスがいまいちだしな
結局どの言語がいいでしょう 64ビット
long long ago=0;
Itanium 2用
Windows XP 64-Bit Edition Version 2003
AMD64用
Windows XP 64-Bit Edition for 64-Bit Extended Systems
高性能コンピュータほどWindowsじゃなくていいような気がするのですが．．．
CPUごとにOSがいる、というんじゃ面倒で仕方がないな。
どっちかに統一してくれよ
>>276 すでに統一されました。AMD64の互換機をインテルが作るらしいので。
ia64はパソコンユーザには多分関係ないです。
>>276 ItaniumはAT互換機じゃないだろ。
64bitコンピューティングなんてもう夢でもないでしょ。
AMDのおかげだけど。
>>279 >ただ、支援を受けられるのは、会社側が認定した社員だけとなる。
スレ違いだけど
つーことは、会社が認定した社員じゃないと辞めたら損ですよ、と。
つーことは、認定されたら辞めてもいいよ、と。
つーことは、認定されたら辞めろ、と。
特定人物対象の首切りなんだな・・・ただの。
>>281 Ｄ言語ですか、なかなか面白そう
ＳＱＬは使えるか気になるなー
今の仕事では
シーケンシャルＦＩＬＥとＩＮＩファイルと
ＤＢのカーソルとＸＭＬとレジストリに
ぱっとアクセスできるＣＯＢＯＬを希望
さらに、繰り返し使うデータをメモリに置かなくても
メモリをファイルとして扱えると便利だが
LINUXでRAMディスクってあるのだろうか？
>>ＳＱＬは使えるか気になるなー
個人的にはCの型システムとそろそろ決別して欲しい。
LLP64だとかLP64なんてのをOSとして採用するのは辞めて欲しい。
Cで書かれた過去の資産とは、ソースのことであって、
Cの型システムではないはず。そんなもんに意義を見出すのはナンセンス。
Cの型を定義するときも、言語共通の定義方法をまず確立して
それを用いてやってほしい。
CLIなんてのは、どちらかというとOSを抽象化したあとに見出されるもの。
これまでもこれからもOSはC(or C++)で書かれるだろう(MSは知らない)。
一般庶民に必要なのは、OSを抽象化するような夢を見ることじゃなくて、
OSに対してCからの非依存を確保すること。
ｲｲｶｹﾞﾝCとは決別しましょうよ。OSをCで書かないという意味ではないですよ。
なにかを定義するときに、Cの概念、Cによって暗黙に規定される意味を
なるべく使わず、厳密に定義しましょうということ。
POSIXの仕様を言語非依存で書こうという話あったようななかったような。
>>285 LP64ってのはOSとして採用じゃなくてC,C++コンパイラの実装の話でしょ。
>>288 OSにコンパイラがべったりくっついてる事態をあげてるわけだよ。
>>289 その寒さの原因を克明に説明してみよう。
新規でつくりゃー好きに出来るよ。ＯＳ作るスレにでもいきやがれ。
>>294 ＯＳ作るっていう発想がなかった
そういう点では思考停止になっている
まあ、ＯＳよりさきに言語つくんねーと意味ねーが・・・。
297 ：
仕様書無しさん：03/10/12 21:04
128bitCPUが出てきたときには、
UNIXはintは32bitのままでlongが128bitとかなるのかな。
intとvoid*が同じと見なしたコーディングが不味いのは
その通りだけど、 void*にintが二つ格納できるなんて
考えるのも不味いのかもなー。LP64というくらいだから
longとvoid*は同じと見なしてよいらしいけど。
unionの定義で問題になりそうだけど、入れてよい過程と
入れてはいけない過程はきっちり区別しておかないとだめかもなー。
心配するな。 64bitのメモリ空間が狭くなるのは5年で10倍になりつづけたとして50年先だ。
実際はあと10年で容量増大競争は理論限界に達してしまう。
>>297 つーか、今時UNIXでプログラミングするのに (u)intptr_t を
知らないってのはどうかと思うぞ。
# SUSじゃ昔からあったし、最近じゃC99標準にも採り入れられたし。
正直、Athlon64を買ってきてはOCしてぶち壊してる
自作板のガキどもが羨ましい。
ところでGentooLinuxのAMD64のインストーラ早くできないかしらん。
unixじゃ６４ビット化したのはずいぶん昔と聞いたが、いつなんだろうねぇ。
でも先月のCマガの結果ではＣ９９積極サポートのコンパイラってGCCぐらいなのでは？
まぁ他の数十万もする商用Cコンパイラはしらないけど少なくともVCとBCは対応する意思なさそうだし・・・
>303
SPARCは確かUltraSPARCⅡeから64bit対応してたはずだよ
>>305 パソコンで普通に使えるものだとI CL が C99 に対応してるような気が。
話変わるけど、Win32 の SDK のヘッダでも普通に DWORD_PTR とか使われてて、
すっかり 64bit 対応完了してますね。。。
>>305 BC++BuilderX にはプレビュが付くとアナウンスしてるね
欲しいのう。Athlon64。
冬のボーナス出たら買おうと思う。
309 ：
仕様書無しさん：03/10/15 23:48
俺のチンコも64ビットにならねぇかな
>>306 今日仕事をしていて思ったこと
10万個ぐらいの管理対象を
ウインドウズのエクスプローラの
1.「大きなアイコン」
2.「詳細形式」
ともう一つすすんで表計算形式となって、データが編集できるといいな
一つ100KBのデータとして、全体で10GBもメモリがあればいいな
>>306 310は306とは関係ない話になっていました
すまんm(__)m
仕事で既存アプリの 64bit 化やったけど ('A`)ﾏﾝﾄﾞｸｻ かった。
ポインタを int に代入するのが NG なのはもちろんだが、
とあるコンパイラでは配列の添え字が int だと Warning の嵐。
しかも AIX の Visual Age for C++ では time_t が 32bit のままというおまけつき・・・
>>314 >ポインタを int に代入するのが NG なのはもちろんだが、
これは当然として、
>とあるコンパイラでは配列の添え字が int だと Warning の嵐。
これの意味が分からんです。
int array[100];
for(int i=0;i<100;i++) array[i]=0;
こんなのがワーニングになるの？
>>315 まあそうだろうな。ワーニングレベルを誰が決めたのか知らんが･･･。
32bitでいうところのこんな感じだろう。
for(char i=0; i < 100; i ++ ) array[i]=0;
これはヤバイと思うよな。だからワーニングで妥当だろう。
enumの扱いはどうなるんしょうか？
318 ：
仕様書無しさん：03/10/17 14:59
つーことはこれからintではなくllintとタイプでつか？
enumのビット数を気にするあたりがもうね。
enumデータをファイル出力したりしたことないのか？
ファイル管理が必要なければ、ずいぶん楽になることだろうなぁ。
でも、そもそもファイルに書き出す場合はビット数を意識して書き出すのが
当たり前だろうし、enumやらintやらを安易に書き出したら、そりゃまずいのでは？
ファイルだけじゃなくて、異なる環境間での通信も気をつけなきゃ。
つまり、intやらなんやらはクソみたいな定義だってこった。
ビット数記述方式にさっさと変更しないかな。
コンピューターおばあちゃんとは無関係のスレだったか
>>324 並列やってる香具師には朗報だろうけど、結局のところ
これ以上単体の速度は上がらんってことなのかな。
ＣＰＵをフルに使うのはＰＧの責任になるのか。
マルチスレッドで効率よく動くのって書くの大変だからなぁ。
単位は違うがネットワーク帯域より
少しメモリ容量が大きいといいらしい
10Mbps <= 32MB
100Mbps <= 128MB
1Gbps <= 1GB
ということははやく10Gbpsのネットワークが
普及すればメモリが10GBを超えるということか
このスレにはAMD64を買ったやしはおらんのか。。。
プログラマ＝貧乏 の法則はここでも健在か
つーか古いプログラムってろくすっぽ
lintもかけてないからﾏﾝﾄﾞｸｻｻが増すよな。
>>321 データをファイルにシリアライズする汎用的な方法ってあるの？
せめて{ILP32,LP64}×{BIGエンディアン、LITTLEエンディアン}
の範囲でできないものか？
334 ：
仕様書無しさん：03/10/24 13:55
いまだに32ビットパソコン使ってるのはヘタレ
>334
まぁまぁ。家庭の事情とかあるでしょ。
言ってあげるのは可哀想だよ。
>>333 SNMP も使ってる ASN.1 とかは？
XMLは一つの解決方法だろうけどな。
バイナリできちきち詰め込むと打つ手なし、
と俺は思う。（苦い経験でもある）
339 ：
仕様書無しさん：03/10/25 15:55
Athlon64欲しいぞｺﾞﾙｧ。しかし金がない
Opteron240が3万ちょっとで買えるってことは、
こっちの方がいいかもしれないな。プログラマ的には。
＞このスレにはAMD64を買ったやしはおらんのか。。。
＞プログラマ＝貧乏 の法則はここでも健在か
６４ビットＣＰＵを使ってやりたいことがアセンブラレベルでのデバッグ
というのでなければ、そうそうすぐ買ってどうのとはならんだろうに。
会社や学校でやってるやつはとっくの昔にUnix系で導入してるだろうし。
こんなスレじゃ、プログラムやっててその辺話題にしようというニンゲンは
こないだろう。
>>347 OSXはカーネルだけしか64bit化されてません。
libcですらまだみたいです。お話になりません。
それはそうとAthlon64がﾎｽｲ。NetBSD使いたい。
>>349 自作板のAthlon64スレによると、
クロックが落ちたときはCPUファンも止るとか。
ああもう、Itanium対応まんどくさ杉ヽ(`Д´)ﾉ
Windows2003(64bit)なんて誰も買わないって。
この忙しいのに工数かけさせないでＹＯ！ ＿|￣|○
なんでintは64ビットじゃないんだろう＿|￣|○
誰だlong longなんて糞型言い出したやつは。
勘違いするじゃないか。
long long long very long
int
vlint
例えば５ギガバイトのデータをメモリ上に置くプログラムを考えてみると、
サーバからネットワーク経由で取得するにしても、
ハードディスクから読込むとしても時間が掛かりそうで
ここら辺りの値をきっちり測定してプログラムする必要がありそうだ
まず、圧縮してデータをやり取りするレイヤーを整備する必要があるか．．．
>>356 >サーバからネットワーク経由で取得するにしても、
>ハードディスクから読込むとしても時間が掛かりそうで
そうでもないよ。
HDD 160MB/s の転送速度がフルに発揮されたら、10G なんてわずか1分 OSのブートに毛の生えた程度
359 ：
仕様書無しさん：03/11/04 13:28
64bitか～。そのうちうちのソフトも64bit対応に向けて動くんだろうなぁ。
めんどくせｗ
360 ：
サイドビジネス：03/11/04 13:29
>>356 一気に読み込むのではなくてMappedBufferみたいな仕組みを用意すればいいのでは?
後はIntelの１０GBitEthernetに期待すると・・・
10GbEってバスはどうなるんだ？
ひとつのアプリケーションで１０ＧＢのメモリを扱い
２００スレッド動作するとして
１スレッドあたり５０ＭＢを利用するのか
クライアントならではの平べったくないアプリケーションを
作りたいな～～～
でも、デバッグが大変そう！どうやってやるのだろう
ＧＩＳ＋動画＋流体力学計算みたいなすごいプログラム
>>363 デバッグは小さいデータでやればいいじゃん。
>>364 平べったいアプリケーション＝
小さいデータでデバッグしてスケールアップするようなアプリケーション
の意味で書いたですが．．．
>>365 しかしまあ、線形時間である事を確認しておかないと大変だな。
64bitの世界はアルゴリズムをちゃんと操れなる人じゃないと厳しいかもしれないね。
>>363 おいおい、スレッドとプロセスの区別位しろよ
369 ：
仕様書無しさん：03/11/07 16:52
>>369 ありがとう
早くメモリ４ギガバイト超過のＰＣが欲しい
あくまでＰＣだが
371 ：
仕様書無しさん：03/11/08 04:41
＿ A_A
／￣ （*ﾟーﾟ） ⌒＼
__ / ＿| | |
ヽヽ / / ＼ | | ,,,,,,,iiiiillllll!!!!!!!lllllliiiii,,,,,,,
＼＼| |＿＿__| .| | .,llllﾞﾞﾞﾞﾞ ﾞﾞﾞﾞﾞlllll,
＼/ ＼ | | .|!!!!,,,,,,,, ,,,,,,,,,!!!!|
| ヽ＿「＼ | |､ | ﾞﾞﾞﾞ!!!!llllliiiiiiiiiilllll!!!!ﾞﾞﾞﾞ .|
| ＼ ＼――､. | | ヽ .| .ﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞ |
| / ＼ "-､, ｀| | ヽ | |
＿／ / "-, "' （_ ヽ ヽ .| |
／ ＿_ノ "'ｍ__｀＼ヽ_,,,, ヽ | |
｀ー―￣ ヽ､__｀/ー_,,,, ﾞﾞﾞﾞ!!!!!!!lllllllliii| |
＼ﾞﾞﾞﾞﾞﾞﾞ!!!!!lllllllliiiii| Hummer |
＼ ヽ | |
ヽ ＼ | |
| ＼.| |
｀ヽ､,,＿ノ| |
ﾞﾞ!!!,,,,,,,, ,,,,,,,,,!!!ﾞﾞ
ﾞﾞﾞﾞ!!!!llllliiiiiiiiiilllll!!!!ﾞﾞﾞﾞ
／.// P4EE∵ヽ＼
>>363 >ひとつのアプリケーションで１０ＧＢのメモリを扱い
>２００スレッド動作するとして
>１スレッドあたり５０ＭＢを利用するのか
いや、何言ってるのか全然判らん。
なんで thread local …?
>>372 タスクマネージャでインターネットエクスプローラの状態を見ると
アニメーションＧＩＦやＦＬＡＳＨがある場合、その度に
メモリやスレッドが増えている
そこからの帰結です。
ＶＢとかＣＯＢＯＬのプログラムしかやってないので
どうもスレッドの意味が分かってないかも...
>>373 スレッド。
昔は一プロセスは一スレッドだった。（スレッドという言葉自体が一般的でなかった）
別の動作単位を動かしたいときは、新たなプロセスを生成しなければならなかった。
新たなプロセスを生成するのはオーバーヘッドが大きいので、動作効率上の問題が発生した。
そこで一プロセス内で並行して動作する単位が考えられた。これがスレッド。
だから一プロセスは必ずｎスレッド（n>=1）で構成される。
しかし、それからもっとスレッド切り替えが高速であって欲しかったな。
というか、スタックポインタを自由に触らせてくれれば スレッドは必要ならアプリ側でやればいい事なのにと悔しさ100倍。
欲しいのは AlocStackArea(size); だけ
アドレス用途ではIPを上位128ビットに
中位64ビットにプロセス番号
下位64ビットにメモリアドレス
計算用途では 64bit double × 4 発のMMX系インストラクションで
これで 256bit CPUにしてみる。
でかいビット幅はあればあったで使い道はありそうかな。
377 ：
仕様書無しさん：03/11/09 02:01
>>376 うーん。だけどHWコストの面で駄目そう。
bit幅拡大はそのニーズがあったからそうなってきたのだと思う。
データ量の増大と、（普通に使える）データの値域の拡大が、そのニーズだと思っている。
でも64まで拡大すると、当分それ以上の拡大は無いと思う。もしかして生きてるあいだ。
#128bitプロセッサが一般的になったら思いっきり嘲笑ってくれい。
整数のサイズが大きくなるのはそれはそれでいいけど、
小数のサイズも気になるなぁ。
科学計算とか、メモリを大量消費するような小数計算する時には、
やっぱ小数の精度も気になってくるんだよな。
http://pc.watch.impress.co.jp/docs/2003/1017/mpf04.htm 最近はスペックに対して命令セットは殆ど寄与しないみたいだね、
Intelが64ビットは要らんとかたまに言ってるのも判らんでもない
でもね～
64ビットっちゅーのは、浮動小数点のdoubleサイズと一致して、
メモリーもそろそろ4G超えしそうだし、ファイル64ビットでなければアドレスできない。
x86なんて言わずに、スッキリした64bit命令セットのCPUが欲しいよな。
TRONチップの命令セットを64bitにして今風に作り直して標準化したりとかしたらいいのにと思ったり。
CISCでもRISCでも変わりないなら、あのチップはかなり作りやすいので好みなんだけど。
Solarisの入ったOpteronが出たら、買っちゃうだろうな。
Windowsはインテルと裏で何やってるのか知らないけど、
XP64がなかなか出ないし。
>>340 その程度なら完全に非現実的ってわけではないなー。
某XREAのアクセス解析のデータベースサーバは250GBHDDを24台使っているみたいだし。
64ビットワードアドレッシングのCPUとか出来たらどうなるかな…。
387 ：
仕様書無しさん：03/11/15 23:40
うぉー、これはﾎｽｲ。PenMと同程度の値段じゃん。
しかもこれ、アイドル状態でクロック落せるんでしょ？
いいなあ。
OSはTurboLinuxの64ビット版とかを自分でインストールする？のかな。
すげートラブりそう。
>>389 時間に余裕があればインストールの失敗はデータ消えることもないし楽しめるのだけれども…。
392 ：
仕様書無しさん：03/11/17 16:08
395 ：
仕様書無しさん：03/11/19 01:20
474 ：月刊アスキーの後藤氏の記事より ：03/11/18 20:39 ID:NRND0u/5
「Intelの90nmPrescottのTDPは最初に登場するmPGA478版で100W以上、次に
登場するLGA775版で120Wを超えると言われる。」
( ﾟдﾟ)ﾎﾟｶｰﾝ、INTEL終わったな・・・・
475 ：SOI が鍵になる The Registerの記事より ：03/11/18 20:40 ID:NRND0u/5
アナリスト Rick Whittingtonによれば、AMDの90nm移行はうまくいきそうだという。90 nm Opteronのデモでは、
「マザーボードのデザイン変更をもたらすような何らかの特別な冷却が必要だとは思えなかった」
、2.2 GHz , 2.4 GHzの90nm Opteronは、AMDの言う TDPは70Wではなく、TDPは45Wで動作している、
「ざっと計算してみたところ、この分なら、今のTDP85-90Wのスペックのままで 3-4GHzまでいきそうだ」という。
同氏はまた、AMDの90nmプロセスの完成度からすれば、90nm Opteronのサンプルを年内に始めて、ウェハー
の量産開始を来年前半中に始めることもできるだろう と述べている。
476 ：アムダー ：03/11/18 22:20 ID:NRND0u/5
A＿A
（ ・∀・ ） ＜64ﾏﾝｾｰ
家で使うPCは静かじゃないとヤだ
十分です。
日本IBMは、64ビットプロセッサ「PowerPC 970」を
搭載するブレードサーバ「IBM eServer BladeCenter JS20」を
発表した。PowerPC 970は、アップルコンピュータの
「Power Mac G5」シリーズに搭載されている「PowerPC G5」とも
呼ばれるもので、同社製品での搭載は初めて。価格は43万2,000円からで、
来年3月の出荷開始予定。
http://pcweb.mycom.co.jp/news/2003/11/19/17.html これってLinuxを入れて売り出すのかな？
それともDarwin？まさかね＾＾；
400 ：
仕様書無しさん：03/11/20 01:20
論理メモリ空間が64bitのOSが64biOS,
アドレスバスの幅が64bitのCPUが64bitCPU
だと思ってるやついないか？
402 ：
仕様書無しさん：03/11/20 01:34
機械語命令長が64bitのCPUが64bitCPU
だと思ってるやついないか？
404 ：
400=402：03/11/20 01:38
じゃあ何が64bitCPUの定義か言ってみやがれ！
>>404 定義なんてできねえよ
でも、いまどきフラットな64bitアドレス空間ぐらいは提供できないと
64bitCPU名乗っちゃまずいだろ。
>>405 別に。レジスタが６４ビットならそれで桶。
410 ：
仕様書無しさん：03/11/21 18:05
time_tが将来64bitになるとしても、今現在のコンパイラでtime_tを使うと2038年には必ず問題が発生します。
明日出荷するソフトにtime_tを使うべきでしょうか？
当然場合により違うでしょう。
毎年のようにバージョンアップしてる現状で、かつ客先もそれに応じてくれてるなら64bitになるのを待てば良いでしょうね。
そうでなければ、time_tは捨てましょう。 自前で時間処理を書いてもそんなに大変ではありません。
http://www.tensyo.com/urame/date/Y2038.htm 特にコメントなし
そういえばZ80は16bit演算できたな
I/Oのアドレッシングもメモリアドレス空間も16Bitだったよな
>>413 あの16ビットってなんともたまらない物があるよ、
計算するとフラグが使えない・・・やっぱり8ビットだぁ
68000が16にも関わらず32ビットに見えたのと違って、隠しきれていないところがちょっと好き
PG64さん偉い！SuSEのパッケージまで買って・・・
>>417 リンク先のWEBページの作者は
私ではありません
すいません
HP-UX も３２ビットアプリの方が速いです、っていってるし、６４ビットアプリだから
ってどうということはないな。メモリを４ギガ積む方が先決だ。
32→64よりも、
x86だったらレジスタが増えてたり、ia64だったらEPICだったりと、
新しいアーキテクチャっていう要素が大きいかな。
アドレス空間の広がりは今すぐにはメリットないかもしれない。
いずれ必要になるとしても。
計算科学の分野ではアドレス空間の広がりは切実なケースがややある。
データベースベンダの64ビット化は必至、じゃなかった必死みたい
むやみに売り込もうとするなよ・・・
みんなAthlon64は手に入れたかい？
漏れは
>>386のノート、金がなくて買えない。もうだめぽ。
426 ：
仕様書無しさん：03/12/08 19:05
427 ：
組み込み屋さん：03/12/08 21:00
メモリが64ビット
基本的にIntel/AMDってのは出来レースでしょ？
430 ：
仕様書無しさん：03/12/08 23:47
PS2なんてずっと昔から64bitだよ。いまさら何したい？
>>430 R5900って32bitプロセッサだろ
433 ：
仕様書無しさん：03/12/09 13:11
4004からの正統的後継者だからなー＜AMD64
30年かけて、電卓もここまで成長しましたって感じかな。
人の生き様のようだ。そんなプロセッサに対してMSがOSを
リリースしないのはおかしい！早く出せ、ｺﾞﾙｧ！！
>>430 PS2 を持ち出すあたりが間抜けですね。
Alphaで散々やらされたから飽きた
NT4.0だったから普通のVCとあまり変わらなかったけど
Windowsが出ないとなあ。PC-UNIXerは基本的に貧乏で
過去の骨董品マシンを大事にするタイプだしねえ。
おれ？おれももちろん貧乏だよ（ｗ
PDFを穴が空くほど読んでから買うのさ～
近くのジャンク屋でO2三万で売ってた
Windowsが出てもコンパイラが出ないと役にたたんからなぁ
>>440 Windowsは何でコンパイルされてるの？
OSよりも普通開発ツールを先に移植するよねえ
>>440 どう考えても開発環境のほうが先に出るだろ。
443 ：
仕様書無しさん：03/12/14 04:19
446 ：
仕様書無しさん：03/12/15 01:14
AMD64マンセー！！！
別にそのものに開発環境がなくても、
クロスコンパイルすれば済む話だしな。
454 ：
仕様書無しさん：03/12/16 22:53
俺32ビットのBOOL型に我慢できない。
キャリーフラグ使わせろよ。
455 ：
仕様書無しさん：03/12/17 04:10
Intel 64-bit x86を2004年中盤に発表か
Intelは近いうちにx86ベースの命令をネイティブ実行できる
64-bitプロセッサを発表する可能性があると、American
Technology Researchが伝えているようだ。これまでにも、
Intelがx86-64と同様の方法で64-bit拡張を実装する"Yamhill"
技術をリリースするという話が伝えられていたが、内容は投入が
2005年以降になりそうだという見通しのみだった。
今回、Intelでは64-bit x86という市場が出来ればそれに
参入するという意向を示しているようで、時期的に見て、
おそらくこのチップは2004年中盤に発表され、2005年の
量産出荷になると考えられるという。Intelとしては、
2004年にはAMDが64-bitへの移行を緩やかに進めるうちに
マザーボードなど基盤面のサポートを整備しつつ、自身は
PrescottやDothanといった32-bitプロセッサを大規模に
販売していく計画と見られるようだ。
http://www.septor.net/ >>447 配布バイナリが分かれるのは致命的だと思うが
現にAlphaやMIPSのNTもそれで苦戦したし
客先で環境に応じたバイナリでコンパイルすれば良いのさ
459 ：
仕様書無しさん：03/12/19 19:29
460 ：
仕様書無しさん：03/12/19 19:52
461 ：
仕様書無しさん：03/12/19 23:44
Intanium2はごっつほすいな。
WindowsとHP-uxのﾃﾞｭｱﾙﾌﾞｰﾄ
夢のようだ。
alpha-21364のほうがほしい
私の給料では無理…。これから約10年間ほどこのPC一筋になると言うならできますけど。
目移りは絶対にするだろうし、今の時点で考えたら、5年前のPCでも使いたくないからｗ
でも、良いよな。金稼げる人がうらやましい。自宅にあったら今、細々としてる研究に使うのになぁ。
21264のベアボーンは20万くらいであったけどな
>468
藻前、世間知らずだなぁ
471 ：
仕様書無しさん：03/12/24 00:19
>>11 >６４Bit用のJAVA VM 早くでねえかな
J2SDK 1.4.0 の SolarisTM-SPARCTM プラットフォーム版では、Java HotSpot Server VM を
使用すると、64 ビット Sparc-v9 プラットフォームで 64 ビットの動作がサポートされます。
64 ビットのアドレス空間があるので、4 G バイト以上のヒープメモリが使用可能です。
Java HotSpot Server VM は 32 ビットと 64 ビットの両方をサポートしています。
ユーザはコマンド行フラグ -d32 または -d64 を使用して 32 ビットまたは 64 ビットの動作を
選択できます。
472 ：
仕様書無しさん：03/12/24 01:19
473 ：
仕様書無しさん：03/12/24 01:22
64bit版のフリーUnix系OSとJDK早く出ねえかな
474 ：
仕様書無しさん：03/12/24 02:13
メモリ空間の一部でいいからフラッシュにして、そこからＯＳ起動してくれ。
起動時のＨＤＤガタガタはもういい。
>>477 32bitで事足りる演算なら64bitCPUで計算したところで
基本的には変わらないかと。
プログラミングインタフェイスとしてのレジスタ数の増加や
メモリコントローラ内蔵なんかのハード設計的な要因は
全ての面に影響するけどね。
>>478 16bit ---> 32bit の時はコンパイラ変えただけで2倍とはいかなくても
1.5倍は速くなったんだけど、あの期待は今回はほとんどできないわけね。
となるとあんまし64bitで走らせて見たい衝動はわかないなぁ。
巨大なデータベースを扱うとか
巨大な数値計算を行うとか
そんな用途にしか効果は発揮しないんじゃね？
いまのところはマーケティング要素の方が強いんじゃないのかな。
デスクトップに64ビットの仮想アドレス空間が必要ないとしても、
それでいくらかでも需要を喚起できるならしめたもの。DOSユーザだって
386,486のプロテクトモードを7,8年もの間ずっと使わずにいたわけだし。
PC事業の基本的な考えは上から下まで同じ部品を使うことでのコストダウンな
わけだから、64bit化は間違っていないと思う。ia64かAMD64かっていう話は
また別としてあるかもしれないけど。
ES47なら会社にあるけど
>>479 Alpha AXP のときに OpenSSL とかそこら辺の RSA 暗号関連の
コードが 64bit でビルドすると結構早くなったような記憶がある。。
32bitでflowするような処理は圧倒的に速くなる
NTなんかでも結構64や128ビット長のデータを多用するし
windowsってカーネルレベルじゃSSEはおろかMMXすら利用しちゃいないのね。
なぜかって？ゲーム等真に拡張機能を必要とするアプリが利用するたびにコロコロと退避/復帰しないといけないじゃん
数の限られた拡張レジスタよりも、
汎用レジスタ自体が64ビット化するメリットは十分ある
AMD64は真の64ビットＣＰＵでないというような
記事があった気がする。
どういうことなのでしょうか？
（*（*（* ---2004年(平成16年)は64bit--- *）*）*）
>>488 その前にその人のいう64ビットプロセッサの定義が大事だ罠
（*（*（* ---2004年(平成16年)は64bit--- *）*）*）
「2003年 64ビットプログラム １０大ニュース」はなんでしょう
（*（*（* ---2004年(平成16年)は64bit--- *）*）*）
１０大ニュースにするほどイベントが無かった？
（*（*（* ---2004年(平成16年)は64bit--- *）*）*）
週間アスキーでは
第１０位でした なんでだろう？
（*（*（* ---2004年(平成16年)は64bit--- *）*）*）
このスレッドは2003年内で終了します
来年はありふれているだろうしな．．．
494 ：
仕様書無しさん：04/01/13 13:12
あれ？213ってなんかCDオーダーだけじゃない？落とせる？
安いMIPSの携帯端末で遊べ
言語もわかり易いし、いいぞ
497 ：
仕様書無しさん：04/02/04 12:23
Alpha21164とNT4.0あとはVC5.0/RISCがあれば十分
499 ：
仕様書無しさん：04/02/05 05:56
○○があれば十分とかいうの、もう飽きた
500 ：
仕様書無しさん：04/02/07 01:11
501 ：
仕様書無しさん：04/02/15 20:00
AMD64なんて殆ど386と変わらんじゃん。
386でカーネル書く事と何が変わるというのかな。
64bitだからと何かが変わるわけじゃない。
16->32のときとは違う。
ざっと見た感じ、殆ど変わらないけどちょっと違うという感じみたい。
まあ人柱萌えってトコ。
504 ：
仕様書無しさん：04/02/15 20:21
やろうとしてることは別にいいんだけど、
AMD64のサンプル実装ならNetBSD,Linuxで十分なのでは？
全然新しいことでもないのに新規性とか言い出すと、
OSASKみたいになっちまいますよ。
64bit時代のDOSとか言ってるから、新規性とは別に……。
ねぇー、いつ128bit時代来るの～？
508 ：
仕様書無しさん：04/02/18 12:06
【IDF速報】Intel社，64ビット・アドレシングに向けた86系命令の拡張を発表
2004.02.18
米国サンフランシスコで開催している「Intel Developer Forum」（IDF）の
初日に開いた基調講演で，米Intel Corp. CEOのCraig Barrett氏は，
64ビットのアドレス空間を扱うための86系命令の拡張について明らかにした。
2004年第2四半期に出荷を予定するXeonプロセサから拡張命令に対応する。
米Advanced Micro Devices, Inc.は既に「AMD64」と呼ぶ64ビット命令を備えた
マイクロプロセサ「Opteron」を製品化している。Intel社が追加する命令の多くは
AMD64との互換性を備えるもようだ。
Intel社はIA-64アーキテクチャで64ビットのアドレス空間に対応しているが，
Barrett氏は「Itaniumと64ビットのアドレス空間に対応したXeonは市場が異なる」
と説明した。前者は浮動小数点の演算に高い性能が要求される用途や
信頼性を重視する上位のサーバ機に向けるのに対し，後者はワークステーションや
普及価格帯のサーバ機などへの搭載を想定しているという。
基調講演では64ビットのアドレス空間に対応したXeonを搭載するワークステーションの
試作機を使って，エンジンを設計する3次元CADの画面を表示するデモを行った。
試作機の筐体には米Dell Inc.のロゴがついていた。
http://ne.nikkeibp.co.jp/members/NEWS/20040218/102012/ 509 ：
仕様書無しさん：04/02/18 12:11
ﾌﾟ。相変わらずバイトマシンかよ（ｗ
511 ：
仕様書無しさん：04/02/23 16:03
512 ：
仕様書無しさん：04/02/24 10:00
まあこれで64bit化の流れが決まったのでよかったじゃないですか。
どっちにしてもAMD64の名前は出せないかと。
というわけでWin64APIの使い方をそろそろ調べておかなくてはなりませぬな。
WinFXまでのつなぎなわけだが
>>514 まあキミがどう考えるかは自由ですけどね
516 ：
仕様書無しさん：04/02/25 00:08
_INT64 を使わなくてもすむようになるのか？
64bit環境では、intはなぜか32bitらしいが。
int を64bitにしたOSってあるんかいな
>>516 AMD64,ia32eではデフォルトオペランドサイズは32bitです。
これがint=32bitに丁度当てはまるわけなんだろうけど。
