トップページ > Linux > 2012年05月01日 > rS076r0O

書き込み順位&時間帯一覧

18 位/222 ID中時間01234567891011121314151617181920212223Total
書き込み数0000000002000000101000004



使用した名前一覧書き込んだスレッド一覧
login:Penguin
【deb系】Ubuntu Linux 57【ディストリ】

書き込みレス一覧

【deb系】Ubuntu Linux 57【ディストリ】
850 :login:Penguin[sage]:2012/05/01(火) 09:20:33.67 ID:rS076r0O
x86-64に準拠したCPUを載せてるのなら、64bitで使わないと損。

まず、x86-64だと、CPUの計算の基本単位であるレジスターが、2倍の16本もある。
計算途中データの一時保存を、メモリーではなくレジスターへ行える余地が2倍になるということ。
詳細は省くが、レジスターの数が多いことは、処理速度の最適化に非常に有利となる。

しかもx86-64だと、ベクトル演算用のXMMレジスターまでもが、2倍の16本ある!
これも同様の理由で、最適化に非常に有利となる。

つまり、理論上は、x86-64としてCPUを動作させれば、処理速度を向上させられる。
この機能を使わずに眠らせた状態なのが、32bitモードで使うということ。これはさながら昔のDOSが32bitCPUを、16bitCPUとして使い続けてた状態に似てる。

ただし、複数アプリを同時に動かしてる状態だと、各アプリへのCPU切り替えの際に、前のアプリが使ってたレジスターの状態を毎回保存する必要がある。
これに関して考えると、レジスター数の増加が、必ずしも単純に性能向上へは繋がらないケースも考えられる。とくにXMMレジスターを駆使した場合は顕著。
(XMMレジスターを使う場合、なるべく使うXMMレジスター本数を少なくした方が、逆に高速動作するケースがある)

同じCPUでも、x86-64として動かす方が全体的には高速になるので、メモリーが4ギガ以下の環境でも64bitへ移項すべき。
【deb系】Ubuntu Linux 57【ディストリ】
851 :login:Penguin[sage]:2012/05/01(火) 09:36:29.41 ID:rS076r0O
また、x86-64では、SSE搭載である前提が成り立つので、
バイナリーのビルドにも、SSE有りを前提としたビルドを行える。

一方、32bitの場合は、必ずしもSSE搭載を前提とはできないので、
SSE無しを想定したバイナリーが提供される。

この点から考えても、x86-64のCPUを、32bitとして使いつづけるのは
せっかくのCPU性能の大部分を、スイッチOFFにして眠らせてる状態。単純にもったいない。
【deb系】Ubuntu Linux 57【ディストリ】
917 :login:Penguin[]:2012/05/01(火) 16:08:12.56 ID:rS076r0O
日本語remixCDだと、開発者のエゴ(宗教?)によって64bit選択不可能という謎制限が課されるw
一方、本家版ではユーザーが自由に64bitを選択でき、また日本語も問題無く使える。
【deb系】Ubuntu Linux 57【ディストリ】
954 :login:Penguin[sage]:2012/05/01(火) 18:54:28.83 ID:rS076r0O
>>936
意外と実際は伽藍とバザール言う所の、オープンなバザール型開発が行われてるプロジェクトは少ない。
実際は、表向きにはバザール型開発でも、その実態は閉鎖的な伽藍型開発で、身内からのパッチしか採用しないのが大多数。
部外者からのパッチは基本的に却下されるのがデフォだと思っていい。

どんなに有用なパッチを投稿しても、プロジェクトのコミュニティー内での人間関係を上手く構築できなければ、
基本的にパッチは採用されない。ここが非常に面倒くさい。
(単純に技術的に優秀なソースを書けば、それでオールOK・採用。というほど単純ではない。実際はもっと泥臭く人間臭い)

人間臭い側面を如実に現してる例の一つが、ハンス・レイザーのファイルシステムの件。
ソースコード内のコメントに憎まれ口や皮肉を書いたりしてたので、感情的な反発を猛烈に受けて、結局いまだに採用されてない。(おそらくこのまま消えてしまうだろう)

オープンソース開発は、実際には意外と泥臭い側面が強い。
バグを見つけたら、バグのパッチを書く。ここまでは簡単なのだが、ここから先が難しい。コミュニティーに取り入って、コミュニティーの人間と仲良いフリして、信用を買わねばならない。
その後、やっとパッチ投稿する事実上の権利を得られて、まともにパッチレビューされて採用されるようになる。

よく簡単に「文句があるならパッチを送ればいいだろ」という台詞を聞くが、パッチ書くのなんてワケない。問題は、コミュニティーに取り入って人間関係を構築し信用を得る作業。ここがとにかく面倒というか泥臭い。
だから、実際はパッチを書いたら、勝手にフォークして勝手に個人でパッチ充てて個人的に使うという人が大多数となってしまい、多数の人間が似たようなパッチを重複して書くという無駄な自体が起こりがちになる。


※このページは、『2ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の2ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。