アカウント名:
パスワード:
これって、32bitの話でしょ。ブートドライブに2TBの壁がある32bit Windowsっていまどき少数派なんじゃないかな。
64bitは確かVistaから未署名ドライバは禁止されていたから、未署名ドライバを使うには「bcdedit /set TESTSIGNING ON」っていうのは常識化されていると思う。
だいたいWindows10で32bitOSを標準サポート継続した意図が不明。もはや32bit限定のシステムって化石だろうに
確かに対応システムとしてはそうかもしれませんが、メモリを4GBくらいしか積んでいないのに64bitOSを積むと、32bitとくらべてメモリ消費量が多くなるという現実があります。
なのでメモリ積載量の少ないタブレットなんかは、下手に64bitOSを積むよりは32bitを使ったほうがパフォーマンスとしては良くなります。
メモリ4GBと言ってもGPUがそれを共有してる関係で3GB+αくらいしか割り当てられないですし、4GBで64bitだと有り難みはないんですよね。x86に限れば64bit化の際に増設されたレジスタ使おうとするとプレフィックスが付くせいで命令長が長くなって、デコーダーに送り込める命令数が減るからちっとも速くならないですし。
オンボードとかでないGPUはメモリを共有しているのではなくアドレス空間を共有しているだけです。# アドレス空間の方は確か逃がす方法もあったような……
それと、64bitで一番美味しいのは仮想メモリ空間が広くなることな気がします。Windowsでは32bit用ソフトは下位2GB(オプション使っても3GB)しか使えませんし、この中でバラバラにメモリを確保するので連続して確保できる容量は更に減ります。メモリを大量に使うソフト開発者から見たら、実メモリが2GBであっても64bitの有り難みがあります。
Windowsの2GBの壁は存在は忘れてました。指摘ありがとうございます。なのですが、頑張っても4GBしか積めないタブレットなりスティックなり古いノートなマシンで単独で2GB以上を確保するソフトウェアはどのみち実用上使い物にならないので気にしなくても良いような。
あと、GPUという書き方は大変まずかったです。CPU内蔵の、というのを入れたつもりが抜けてました。申し訳ない。
アプリは32bitのがまだ大勢でこれはAPIで32→64の変換が入りながら実行されて効率悪いデバイスは64bitのDMAできないものもままあって、iommuあるやつはいいけどbounce buffer経由になったりとかそもそもレジスタ増えたせいでコンテキストスイッチのコスト増えたりとかまあ、デメリットはバカにならない程度にはあるよね
つい数年前のAtomとかx64非対応なんだぜ。まぁそれ積んでるのほとんどがタブレットだろうけど、MiniITXの超省スペースPCとかもあるしそれほど化石ってわけでもない
Atomがあるからだろ...
未だにMS-DOSのプログラムまでバッチファイルに組み込んで製造テストに利用してるところがあります。そういう環境だと単に64bitにというわけにはいかないわけで・・・
# あ、でもオフラインにしてXPで動かしてるな、うちの会社(ﾏﾃ)
## だからソースもない、どこから拾ってきたのかわからんようなソフトは使わんでくれぇ## 環境を構築した人はとっとと辞めちまうし、ドキュメントも残してないしorz
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
64bitはとっくの昔に… (スコア:0)
これって、32bitの話でしょ。ブートドライブに2TBの壁がある32bit Windowsっていまどき少数派なんじゃないかな。
64bitは確かVistaから未署名ドライバは禁止されていたから、未署名ドライバを使うには「bcdedit /set TESTSIGNING ON」っていうのは常識化されていると思う。
Re:64bitはとっくの昔に… (スコア:0)
だいたいWindows10で32bitOSを標準サポート継続した意図が不明。
もはや32bit限定のシステムって化石だろうに
Re:64bitはとっくの昔に… (スコア:1)
確かに対応システムとしてはそうかもしれませんが、
メモリを4GBくらいしか積んでいないのに64bitOSを積むと、32bitとくらべてメモリ消費量が多くなるという現実があります。
なのでメモリ積載量の少ないタブレットなんかは、下手に64bitOSを積むよりは32bitを使ったほうがパフォーマンスとしては良くなります。
Re:64bitはとっくの昔に… (スコア:1)
メモリ4GBと言ってもGPUがそれを共有してる関係で3GB+αくらいしか割り当てられないですし、4GBで64bitだと有り難みはないんですよね。
x86に限れば64bit化の際に増設されたレジスタ使おうとするとプレフィックスが付くせいで命令長が長くなって、デコーダーに送り込める命令数が減るからちっとも速くならないですし。
Re:64bitはとっくの昔に… (スコア:1)
オンボードとかでないGPUはメモリを共有しているのではなくアドレス空間を共有しているだけです。
# アドレス空間の方は確か逃がす方法もあったような……
それと、64bitで一番美味しいのは仮想メモリ空間が広くなることな気がします。
Windowsでは32bit用ソフトは下位2GB(オプション使っても3GB)しか使えませんし、
この中でバラバラにメモリを確保するので連続して確保できる容量は更に減ります。
メモリを大量に使うソフト開発者から見たら、
実メモリが2GBであっても64bitの有り難みがあります。
Re: (スコア:0)
Windowsの2GBの壁は存在は忘れてました。
指摘ありがとうございます。
なのですが、頑張っても4GBしか積めないタブレットなりスティックなり古いノートなマシンで単独で2GB以上を確保するソフトウェアはどのみち実用上使い物にならないので気にしなくても良いような。
あと、GPUという書き方は大変まずかったです。CPU内蔵の、というのを入れたつもりが抜けてました。申し訳ない。
Re:64bitはとっくの昔に… (スコア:1)
アプリは32bitのがまだ大勢でこれはAPIで32→64の変換が入りながら実行されて効率悪い
デバイスは64bitのDMAできないものもままあって、iommuあるやつはいいけどbounce buffer経由になったりとか
そもそもレジスタ増えたせいでコンテキストスイッチのコスト増えたりとか
まあ、デメリットはバカにならない程度にはあるよね
Re: (スコア:0)
つい数年前のAtomとかx64非対応なんだぜ。
まぁそれ積んでるのほとんどがタブレットだろうけど、MiniITXの超省スペースPCとかもあるし
それほど化石ってわけでもない
Re: (スコア:0)
Atomがあるからだろ...
Re: (スコア:0)
未だにMS-DOSのプログラムまでバッチファイルに組み込んで製造テストに利用してるところがあります。
そういう環境だと単に64bitにというわけにはいかないわけで・・・
# あ、でもオフラインにしてXPで動かしてるな、うちの会社(ﾏﾃ)
## だからソースもない、どこから拾ってきたのかわからんようなソフトは使わんでくれぇ
## 環境を構築した人はとっとと辞めちまうし、ドキュメントも残してないしorz