88コメント24KB

☆アプリが64bit化されても速くはなりません

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

0001名称未設定

03/09/22 09:40ID:Xvnt32p+

どうも64bitに最適化されると速くなると思ってる人が多いようなので…

0002名称未設定

03/09/22 09:45ID:S7TYRkaW

2

んなことない

終了

0003名称未設定

03/09/22 09:53ID:Xvnt32p+

やっぱ勘違いしてますね

64bit化の恩恵
1）バカみたいな桁数の計算は速くなる（そんなのするかって
2）使えるメモリー空間がふえる（メモリを大量に使わないと意味なし
　
だけだよ

0004名称未設定

03/09/22 09:57ID:fUYDS37N

了解しますた。
今後ともよろすく。

0005名称未設定

03/09/22 09:58ID:FMudMX4j

マカエレテスト

0006名称未設定

03/09/22 10:00ID:89vigADv

それで何？

0007名称未設定

03/09/22 10:11ID:mWhX8ScX

64bitってやっぱペテンなのね。

0008名称未設定

03/09/22 10:12ID:I9qK4zyr

いや、アップルがペテンなだけ。

0009名称未設定

03/09/22 11:12ID:y0n1vZxK

>>3
>1）バカみたいな桁数の計算は速くなる（そんなのするかって
速くなるんじゃん

0010名称未設定

03/09/22 11:56ID:UjR8dbUn

まじめに質問していい？
mpeg2のエンコードとかは速くならないの？

0011MACオタ＞10 さん

03/09/22 12:04ID:wsW0LtX1

>>10
メモリが足りてる限りわ、速くならないす。

0012名称未設定

03/09/22 12:05ID:vFd1lZmG

>>3を補足すると
> 2）使えるメモリー空間がふえる（メモリを大量に使わないと意味なし

は、16bit->32bitのときは使えるメモリが激しく少なかったので、速さ的にも充分な意味があったんだけど
現状で32bitアドレス空間で足りないような使い方をするアプリはコンシューマ向けには
あまりないので意味がないということ。

スレタイは正確には「アプリが64bit化されても劇的に速くはなりません」ってことだな。

>>10
64bitアドレス空間 + 膨大な物理メモリっていう状況なら
動画ファイルがほとんど物理メモリに載ってしまうのでそういう状況なら劇的に早くなり得ます。

0013名称未設定

03/09/22 12:05ID:EQ96GIJV

http://page2.auctions.yahoo.co.jp/jp/auction/b41031423
これ買って

0014MACオタ＞12 さん

03/09/22 12:12ID:wsW0LtX1

>>12
　　-----------------------
　　動画ファイルがほとんど物理メモリに載ってしまうので
　　-----------------------
MPEG2圧縮後に4GBになるようなデータじゃG5の最大メモリ搭載量8GBでも
収まらないと思うすけど？

0015名称未設定

03/09/22 12:13ID:vFd1lZmG

>>14
あぁ、別にG5限定の話ではないです。一般論です。

0016名称未設定

03/09/22 12:14ID:+anEebwq

ラムディスクだー。

0017名称未設定

03/09/22 12:42ID:uM8mJRH8

つうかRAMディスク復活させてほしい。

0018さるさるさる

03/09/22 12:53ID:e6TUliYs

>>17の援護射撃
Photoshopのように他のApplicationもRAM容量に依存するようにしてくれ。

0019名称未設定

03/09/22 13:43ID:D4Up4/Jb

どうせ体感速度なんで、64bitつうのと気分に依存だろ。

0020名称未設定

03/09/22 14:00ID:v49C41Sn

アプリが64bit化ってのも変な言い方だとおもう。

OSが64bit値を処理するようになると（ファイルI/Oとか）
アプリ的にはそれが不要でもそのインターフェイスを
使わざるを得ないし。

32bit OSで64bit値を処理するより64bit OSで処理した方が
速いでしょ。

0021名称未設定

03/09/22 15:14ID:HVwv1hFR

(´・ε・｀)ナーンダ　ジーファイヴ　ニ　キタイシテ　ソンソン　ジーフオー　デ　ジウブンカ

0022名称未設定

03/09/22 15:46ID:OKoAOMSa

>>20
それほど変でもないです。API は別な筈ですから。
(アプリが 64bit 化 → 64bit API に対応、くらいの意味に取ればいいんでないかと)

ただ現実問題、整数って 32bit あれば困らないし、実際 C で作ってると
64bit でコンパイルしても整数は 32bit なんですよねぇ。
浮動小数点演算に関しては、G5 に最適化されていれば
しょぼい AltiVec よりは速くなるんじゃないかという期待はありますが。

0023名称未設定

03/09/22 15:58ID:HVwv1hFR

>>22 (´・ε・｀)どれくらい速くなるか予測できないですか？

0024名称未設定

03/09/22 17:34ID:kcU0eZa7

期待があるとすればメモリーマップトファイルシステムだが
G3/G4を切り捨てるようなOSは当分無理だろうな

0025MACオタ＞24 さん

03/09/22 18:12ID:wsW0LtX1

ファイルのメモリマップわ，64bitだと大きいファイルでも大丈夫と言うだけすけど。。。
その上，プログラミングが簡単になると言う話で動作速度にわ，あんまり関係ないす。

0026名称未設定

03/09/22 18:56ID:U0hPnSHY

>>17
OS X でも RAMディスクは標準で使える
ただし遅い

002720

03/09/23 00:25ID:zrit7Mq6

>>22
OSが64bit化されるのが重要なのであって、という意図でした。

>>25
32bit OSでも64bit ファイルシステム使えるけど、64bit OS
のほうが効率がいいでしょ。

0028名称未設定

03/09/23 00:25ID:Fy1x9P+g

あげん

0029名称未設定

03/09/23 01:00ID:R/Cuoatk

しかし実際早くなってもらわなこまるし、
将来はもっと早く…むにゃむにゃ
じゃなきゃ、コンピュータが人間と会話できんよ。

0030名称未設定

03/09/23 01:24ID:JOm66Urd

>>25
メモリマップした方がカーネルによる先読みが効きやすいし
カーネルとプロセスの間でバッファコピーが起こらないので早い。
特に大きいファイルを読むようなときには効果が大きいはず。

0031名称未設定

03/09/23 01:30ID:wuxPQbtj

>>29
何で困るんだ？

0032MACオタ＞30 さん

03/09/23 01:34ID:2+Dbsrng

>>30
それ以前の問題として、ファイルのメモリマップってSystem 7時代から
取り入れられているすけど。。。

0033名称未設定

03/09/23 01:52ID:JOm66Urd

>>32
オタさん、ぼけたのか?w
大きいファイルをメモリマップする話でしょ。
System 7のことは知らないけども、大きいファイルをメモリマップで扱えないと
余計なバッファコピーが必要なreadを使うしかないって話です。

0034名称未設定

03/09/23 01:57ID:Fy1x9P+g

まあそんな大きいファイルがひ（ry

0035名称未設定

03/09/23 09:21ID:Fy1x9P+g

オタあげ

0036名称未設定

03/09/23 19:39ID:7Lc0MNnq

10.2.8ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━!!!!

0037MACオタ＞33 さん

03/09/23 19:44ID:2+Dbsrng

>>33
メモリマッピングで、データの実体わ仮想記憶としてディスク上にあるすから、
別に速くなるわけじゃないすよ。
　　----------------------------
　　余計なバッファコピーが必要なreadを使うしかないって
　　----------------------------
ここの部分でコーディングが楽になるだけだと思われるす。

0038名称未設定

03/09/24 01:42ID:yDhG8MnY

>>37
オタさんはハード専門だからOS詳しくないのかな?

readの時はディスク → カーネル空間のページキャッシュ → ユーザー空間のreadバッファって
データがコピーされていく。
ページキャッシュとユーザーバッファには当然別の物理ページが割り当てられるから
必然的にそこでコピーが発生する。

でも、読み込みのみのmmapをしたときはカーネル空間のページキャッシュを
そのままユーザーの仮想メモリ空間に張り付けるだけだから、同じ物理ページを指しているだけで
無駄なコピーがコピーが発生しないってこと。
書き込みがあった時点で、新しい物理ページがユーザーの仮想メモリ空間に割り当てられて
カーネル空間のページキャッシュからコピーされる(copy on write)。

用語はlinuxのモノなので多少齟齬があるかもシレンが、基本的には同じことかと。
読み込みのみの場合はreadよりmmapの方がコピーが少ない分早いと思います。

0039MACオタ＞38 さん

03/09/24 02:30ID:TKPeoLZ7

>>38
理論上はその通りすけど、ディスクのリードわディスクインターフェース自体がボトルネック
すから、それで画期的な性能向上がある訳じゃないすよ。

0040名称未設定

03/09/24 02:38ID:Pcx9Rgwi

>>39
だから、メモリが多ければ多いほど、差が出て来るってことでしょう?
シーケンシャルにアクセスするような場合でもmmapの方がカーネルによるプリフェッチも効きやすいし。
物理メモリも効率的に利用できるし、インターフェースのボトルネックを隠蔽できるので
差は出てくると思いますよ。

0041MACオタ＞40 さん

03/09/24 02:58ID:TKPeoLZ7

>>40
多くの（つーかほぼ全ての）64-bitの実装で、物理アドレスが64-bitより少ない
のわ、mmap等によって物理メモリ以外の領域にアドレスを振り当てることで、
仮想的にメモリ上のオブジェクトとして便利に扱うことが主目的だからす。

メモリの多い少ないと64-bitアドレシングわ直接関係無いすよ。

0042名称未設定

03/09/24 03:05ID:Pcx9Rgwi

>>41
たくさんの物理メモリがあっても、32bitアドレスだと大きいファイルはmmapできないから
readを使うしかなくて、その場合には余計なコピーが「必ず」発生するから、
64bitアドレスで大きいファイルをmmapすることには速さの面でメリットがあるといっているのだけど?
で、物理メモリが多ければ多いほどカーネルによるプリフェッチの効果が大きくなるし、
キャッシュに載る割合も大きくなると。

便利に扱えることに加えて、速度的なメリットもあるのではないかという主張です。

0043名称未設定

03/09/24 03:30ID:Adct7kvK

>>42
ほう、何TBものメモリを実装すると、そんなハナクソほどのメリットしかないわけ?
それで実際に実装するのはバカマカだけだな。つか、いつ出来るわけ?

0044名称未設定

03/09/24 03:32ID:Pcx9Rgwi

>>43
もうちょっと勉強してから、発言しようね

0045名称未設定

03/09/24 06:25ID:LJDlE9g8

>>1
オマエはアホか！！
64bitになったら32bitの約2倍速くなるに決まってるだろ！！

...って人がいないのが意外ですね。
他のスレではそれが常識だと思っている人を時々見かけるんだけど。

0046名称未設定

03/09/24 07:12ID:w0iRDPkE

このスレに一人いたような気がするな
ネタだけど

0047名称未設定

03/09/27 01:29ID:Yq2m7N9X

結局オタの言うのは正しいのか？

0048名称未設定

03/09/27 01:32ID:6LNnMado

オタがルールですから

0049名称未設定

03/09/27 01:37ID:LA7KDuG6

この話題に関してはオタが間違ってそう

0050名称未設定

03/09/27 02:21ID:Qq1QPOzz

６４０Ｋバイトは、誰にとっても充分なはずだ
１９８１年、ビル・ゲイツ

0051名称未設定

03/09/27 02:27ID:czyTX+pP

もう眠いから詳しくは書かないけど、mmap の方が速いと言うのは
妄想っすよ。ケースバイケースです。特に read で必ずコピーが発生する
っては、古い実装例っす。

0052名称未設定

03/09/27 02:31ID:6bJM5i2p

うん。640kは、十分すぎたよ。（遠い目。
仕方ないから、VRAM をラム代わりにして、シミュレーションやったよ。

0053名称未設定

03/09/27 02:37ID:LA7KDuG6

>>51
linuxは今でもそうだと思うが、違うっけ?

0054名称未設定

03/09/27 03:10ID:0a1s8yNd

128bitメモリ空間はいつ必要になりますか？

0055名称未設定

03/09/27 09:04ID:Yad4VmqF

カツオが大学に入る頃じゃない？

0056名称未設定

03/09/27 11:10ID:2MO8eVOX

logicer.comでのベンチで、2G Dual＋memory2GByteって構成が
恐ろしい性能を叩き出してるんだけど、内部32Bitなデータ処理でも
結構変わるモンなんですかね。
ttp://www.logicer.com/blog/archives/000509.html
これは周波数だけの問題じゃない気がするんですが。

：ウチのPowerBookG4/667MHzではリバーブかまさない
：EXSテストで24トラック程度。プラグインできる数で言えば
：トラックテストがリバーブ10個で止まるので、10倍弱の
：差がついてる気がします。

メモリやハードディスク周りのボトルネックがG5で大幅に解消されたとかかな？

厨房のころPC98でアセンブラ弄くった程度の知識しかないんでアレだけど。
64Bitなレジスタ（？）に32Bitのデータ二つ流し込んで一気に
論理演算処理とかで読み書きの負荷が半分になってたりとか
しないのかな。

素人発言済みません。ヘボながら燃料投下って事で。

0057名称未設定

03/09/27 11:51ID:h1ZyLB/h

>>56
>4Bitなレジスタ（？）に32Bitのデータ二つ流し込んで一気に
>論理演算処理とかで読み書きの負荷が半分になってたりとか

それはSIMDって言ってPowerPCで言えばAntiVec
Intel系で言えばMMXやSSEがそれに該当する。
128bitのレジスタに8/16/32bitのデータ入れて一気に加減乗除みたいな。

性能の差は単純に周波数の差でしょ。

0058名称未設定

03/09/27 23:57ID:Z2XRBKrh

41のMACオタさん、
>（つーかほぼ全ての）
ってのが激しく偽物っぽい……

0059名称未設定

03/10/10 01:51ID:F5tE3mzf

あげとくよ

0060& ◆mwRv4U4X/A

03/10/26 17:54ID:w/snXrs6

tes

0061名称未設定

03/11/07 22:14ID:VDooJ5zX

iTunes、Napsterが1週間に販売した曲数の5倍にあたる150万曲を販売
～合法ダウンロード販売市場の80％以上のシェアを占める
ttp://internet.watch.impress.co.jp/cda/news/2003/11/07/1044.html

0062名称未設定

03/11/22 15:05ID:5QEXCjhG

あがってみるか…

0063名称未設定

03/11/23 10:23ID:p4p+r4iZ

>>58
オタさん、都合が悪くなったので、いつもの自作自演で尻尾切りですか？

0064名称未設定

03/11/23 13:27ID:tn3Y3Cho

64bitあげ

0065名称未設定

03/11/23 13:47ID:G932wXtn

なんでもdouble(64bit)で変数を用意してしまう
matlabなんかは
ぐっと早くなると思う

いま画像処理ソフトは、すべて24bitカラーでやってるけど
これは足りない。

64bit時代になれば
48bitカラーが標準になれるのが嬉しいかなあ。

0066名称未設定

03/11/23 13:53ID:PkJ4WF9G

matlabってMac版あったんか？

0067名称未設定

03/11/23 13:53ID:TjFs8ApE

＞なんでもdouble(64bit)で変数を用意してしまう
　
結局なかに入る数値が4ケタぐらいで済む処理はまったくかわらんな。
MPEGのエンコとかフォトショのフィルタなんかは恩恵を被りそうだけど
そのほかは何も無さそうだ

0068名称未設定

03/11/23 13:57ID:s+7zguL1

コンピュータに詳しい人達なら、64bitになっても大した差は無い、と言うかもしれませんが、

そうでない人たちにWindowsは32bit、MacOS X はハードを含めて64bit
なんて言われると、MacOS X ってスゴイんだと良い意味で思いこみます。

決して悪いことではないとおもいます＞64bit化

0069名称未設定

03/11/23 14:00ID:TjFs8ApE

だいたい「64bit化」しちゃったらポリタンクやiMacで動かんやん

0070名称未設定

03/11/23 14:04ID:G932wXtn

>>66
x11だがあるよ。

0071名称未設定

03/11/23 14:14ID:V5bF4782

ま、パーソナルユースには必要ないかモナー。
こんなスレ立ててるからエンタープライズOSとしては認識されないんだヨ。

0072名称未設定

03/11/23 14:17ID:E7u0ARL0

>>68
>MacOS X はハードを含めて64bitなんて言われると
OS Xは32bitなんだが。
ハゲはOS Xの64bit化なんかしないといってるんだが。
こういう嘘デタラメと妄想をばら撒くからなあ、アホマカーは。

0073名称未設定

03/11/23 14:19ID:d5wVtxb3

>>72
>OS Xの64bit化なんかしないといってるんだが
またこうやって正確に書かずに流言を流布するからなあ、馬鹿ドザは

0074名称未設定

03/11/23 14:38ID:E7u0ARL0

>>73
ヌケマカーくん、その根拠を示したらどうかね。
コロコロとハードの互換性を変えるMacが64bit化されたOSなんか搭載するのは何年も先だよ。
OS Xですらまともに普及してないのに64bit化OSなんぞは夢の夢。

0075名称未設定

03/11/23 15:03ID:d5wVtxb3

人に根拠を求めるなら、自分から「64bit化なんかしないといってる」根拠を示してくださいね
ほんと寝言は寝てから言うもんですよ'`,､(｀∀´) '`,､

0076名称未設定

03/11/23 15:17ID:ooUJpXAb

しかし、>>68の前にマク＝デザイン＆印刷用、ていう世間の認識を何とかせねう゛ぁ

0077名称未設定

03/11/23 16:57ID:MVap2Sag

>>74
＞まともに普及してないのに

普及してないからこそ出来ることもあるでしょうね
...中途半端に普及してるのが現状だろうか。

0078名称未設定

03/11/25 23:13ID:ZI4XmwoN

なんだか根本的に違う議論（？）が続いてる気がするんですけど・・・

64bit化って言うのは、64bitのアドレス空間を64bitポインタで
フラットに使えるようにする、という事です。

G5対応のOS XはOSの基幹部分は64bit化しますが、
各アプリケーションは32bitまでしか利用できないので、主な利点は
Mac本体に32bit分(4GB)以上のメモリを搭載できる事くらいです。

0079名称未設定

03/11/26 00:37ID:OwBz3OOP

>>78
おめ、そんな事いったらスレのタイトル自体間違ってるよ。#誰か指摘してたけど
OSの64bit化の議論だろ。
32と64じゃ扱えるデータセット、仮想メモリ空間、ファイルシステムの大きさが全然ちがう。
そんな屁理屈こねてるから、何時まで経ってもパーソナルOSなんだよ。

0080名称未設定

03/11/26 01:03ID:rUTSFLIh

>>79
いや、作業用の変数のサイズが64bitだからどうとか、
OS Xが32bit OSだ、とかって話が続いてたので。

0081名称未設定

03/12/20 13:59ID:1b3YMxUQ

よくわかんねーなぁ。
JAVAとか日曜プログラマしてた時期があった程度の厨なんですが、
これまでと桁違いのメモリ空間にアクセスできるっていう事だけな訳？

64bit化してそのまま互換性保つ事が難しいのか、
OS作り直しの手間が偉いことになるのかが見えない。
手間の割にメリットが少ないというふうに受け取ってOK？

0082名称未設定

03/12/20 15:55ID:uz/1F/13

>>81
16bitから32bitのような大幅書き直しは無い。
64bit化自体よりも製造元がIBMになったことと
アーキテクチャが最新になったことで
未来が明るくなったという点に置いてG5のアドバンテージは大きい

0083名称未設定

03/12/28 06:49ID:jaOr7/3q

馬鹿だな、お前ら。32bitより64bitの方が速いのは当たり前だろうに。
常識ってものがないのかね、君らには。

0084名称未設定

03/12/28 07:58ID:1A8twt9D

まぁ餅付け

0085名称未設定

03/12/28 08:47ID:OgYvX1Gu

祝！OS9没後６０１日！(w
9erは６０１日も経過してる古い環境よく使っていられるな(w
64bit化できない9erの僻みスレですか(w
一般的なアプリでは32bitな香具師のことも考えてやらなきゃいけないし現状ではクロック向上の将来性とメモリバンド幅増大がメリットだろ。
G5用最適化オプション付きでコンパイルすれば64bit専用アプリになるから32bitよりも高速だぞ！

0086名称未設定

03/12/28 13:34ID:Of7VVdZS

>>83
何倍速いか教えてください！お願いします！

0087名称未設定

03/12/28 13:36ID:LYv1TMAT

赤く塗ると3倍って落ちはもう飽きた。

0088名称未設定

03/12/29 11:29ID:oUYNMWAI

Dual G5 versus Dual Opteron
http://www.barefeats.com/g5op.html

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