X

FreeBSDを語れ Part44 [無断転載禁止]©2ch.net

■ このスレッドは過去ログ倉庫に格納されています
1名無しさん＠お腹いっぱい。
垢版 |
2017/05/31(水) 01:15:53.99
The FreeBSD Project
http://www.freebsd.org/ja/

FreeBSDを語れ Part43 [無断転載禁止]
http://echo.2ch.net/test/read.cgi/unix/1472042132/

関連スレ
初心者もOK! FreeBSD質問スレッド その121
http://echo.2ch.net/test/read.cgi/unix/1437276192/
2017/08/11(金) 12:40:31.18
>>377
とっとと尼券払って教えてもらえや知障ゴキブリ
2017/08/11(金) 12:41:03.73
>>378
この流れになったｒ、もうお前の乞食的目的は達成できないぞ

> -m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
本当は嘘だから一部の理由しか出てこない

> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ？
本当は滅多にないから答えられない

こういう事だろ？
2017/08/11(金) 12:41:16.80
>>370
それが一番重要なのだ。NT4システムが未だ残ってるのは何十億とかけて導入したシステムは易々とリプレースできない。
これはi386のFreeBSDサーバを使ったシステムでも同じこと。

i386排除厨は開発者の発想ではない。
古いからいらない、新しいほうがいいという、無責任、無思慮のガキんちょの発想。
2017/08/11(金) 12:41:27.77
>>379
とっとと尼券払って教えてもらえや知障ゴキブリ
2017/08/11(金) 12:43:12.32
おまえらさ、FreeBSD全く関係ない話をここでする意味ないだろ。
2017/08/11(金) 12:43:23.81
>>380
未だにi386のって本当に動いてんのかね？
コンデンサまだ大丈夫なの？
空港のWin3.1とかは知ってるけど、ちょくちょく技術者の手を入れながら
別の機体に入れ替わってる筈だが
2017/08/11(金) 12:44:20.58
>>382
知ってるけど、俺様専用i386の4G以上使えるの作れって乞食がウザいから叩いてるだけ
385名無しさん＠お腹いっぱい。
垢版 |
2017/08/11(金) 12:45:56.61
>>383
最新CPUでi386OSを必要としているという意味すら分からんクソガキはすっこんでな
2017/08/11(金) 12:46:46.34
>>384
荒らしのお前が一匹フルボッコにされてるだけだってそろそろ気づいたほうがいい
2017/08/11(金) 12:47:39.27
>>385
Win3.1を必要としてるとこがある事くらい知ってるわ文盲
最新の機体で問題が出るから技術者の手が入るんだろ
2017/08/11(金) 12:48:31.51
>>386
> -m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
本当は嘘だから一部の理由しか出てこない

> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ？
本当は滅多にないから答えられない

おまえこいつか？
2017/08/11(金) 12:50:25.38
>>388
とっとと尼券払って教えてもらえや知障ゴキブリ
2017/08/11(金) 12:50:59.74
>>387
クソガキすぎるぞお前
-m32の意味でも答えてみろや小坊
2017/08/11(金) 12:51:02.03
話がいつの間にかi386のみって話になってんな
既存のシステム動けばいいならそのままi386使えばいいよな

なんでi386で4G以上使えるのを今更必要とするんだ？って話だった筈だが？
2017/08/11(金) 12:51:42.85
>>390
ttp://a4dosanddos.hatenablog.com/entry/2015/09/19/131052

で
> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ？
2017/08/11(金) 12:52:06.06
さっさと答えろよ
魔女狩りより楽だろ？
2017/08/11(金) 13:00:39.11
>>391
騒いでいるのはそういう技術論を真面目にしたい訳じゃ無く
単に場を荒らしたいだけのちょっと精神を病んでる人だからね。
それに付き合う方も御同類さ。
2017/08/11(金) 13:03:43.01
URL出しただけで黙っちゃった・・・マジで>>394なんだな

> -m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
本当は嘘だから一部の理由しか出てこない

> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ？
本当は滅多にないから答えられない

今更i386を改造して4G以上使える様になんて、誰もやらんわ
2017/08/11(金) 13:04:14.01
>>395
とっとと尼券払って教えてもらえや知障ゴキブリ
2017/08/11(金) 13:05:54.11
>>395
礼儀知らずのお前がダダこねてるガキ丸出しで連呼したところで
永久に教えてもらえることはないってまだ気づかないのか？
そんなことだからいつまでたってもど素人のアホなままなんだろ
2017/08/11(金) 13:09:36.87
>>397
教えて貰う迄も無い

今更i386インスコする気はないから試さないけど、
32bit gccと64bit gcc -m32には、違いがあるにしても定義済みマクロだとか
細かい所程度で、殆ど差異はない
2017/08/11(金) 13:09:40.16
>>392
まずは自分の言葉で話す能力から身に付けたほうがいいぞ
何ひとつ理解できてないのもバレバレでみっともないだけだしな
2017/08/11(金) 13:11:57.41
>>398
妄想はチラシの裏にでも書いとけ
2017/08/11(金) 13:13:58.27
>>399
>>302>>311辺りは俺だぞ

>>400
ttp://a4dosanddos.hatenablog.com/entry/2015/09/19/131052
この-m32でいいんだよな？違うのか？
2017/08/11(金) 13:16:30.04
引用馬鹿しつけー
いちいち見ねえよ10円ハゲ
403名無しさん＠お腹いっぱい。
垢版 |
2017/08/11(金) 13:18:38.04
おまえ程度のものが思いつく32bit→64bitの解決策なんか設計者はとっくに思いついてると思うの
2017/08/11(金) 13:20:09.43
誰が32bit→64bitの解決策の話をしてるのかシランケド、
今更i386を改造して4G以上使える様になんて、誰もやらん
素直にバイトでもしてPC買い替えろ
2017/08/11(金) 13:26:00.57
まだハードの話とOSの話をごっちゃにしてる学習能力ゼロのアホが居るのか
2017/08/11(金) 13:27:08.76
>>403
実現できてねえから議論になってんだろタコ坊主
2017/08/11(金) 13:27:43.30
こんなとこで暴れてても誰も作らんから自分で作れ
2017/08/11(金) 13:28:25.39
暴れてんのはお前だ馬鹿
2017/08/11(金) 13:33:30.83
実現できてない欲しい物があるならどっかに金払って作って貰えよ
それで解決だろ
2017/08/11(金) 13:37:15.75
何が合理的か語る場で古事記だの作って貰えだの馬鹿にも程があるな
何度言われても覚えられないとか脳みそに虫湧いてんじゃねえのコイツ
2017/08/11(金) 13:39:52.25
64bitOSで32bitアプリ動かせばいいんでねーの？
2017/08/11(金) 13:45:25.81
またループ
2017/08/11(金) 14:05:34.03
当面は32-bitも必要だけど組込のためだよね。
2017/08/11(金) 14:09:35.59
またループ
2017/08/11(金) 14:29:12.89
x64使えないCPUで4G以上乗せられるMBなんてE3xx0とかそんな時代限定だよな
現状x64で速度あがるってんで大きさは放置なんだから
後はCPUがメモリだけ３２ビットのメモリモデルをサポートするのを祈るだけ
サポートせんだろうけど
2017/08/11(金) 14:32:19.27
x64使えないCPUの話なんて誰ひとりとしてしてないのに突然どうした？
2017/08/11(金) 14:33:53.83
x64で速度あがるとか言ってるバカは放置の方向で
2017/08/11(金) 14:57:22.83
夏休みは2chが捗るな
2017/08/11(金) 17:44:57.84
>>287
kernel spaceじゃん
2017/08/11(金) 21:08:43.72
>>337
> 64bitなんて街乗りしかしないのにエンジンだけバカでかくて燃費悪い車買うようなものだわな
こういう話って、8bit → 16bit移行期や16bit → 32bit移行期も同じような意見が繰り返し出たけど、
結局、歴史は古いものを残さず新しいものが生き残るようにできてんだよね。
32bit機はもう製造してないから中古で延命図るしかないし、時間の問題で消えてしまう。
2017/08/11(金) 22:00:23.43
>>404
誰もやらないというのはおまえの妄想、期待でしかない。
そもそもPAEは32bitCPUで4GB以上の物理メモリを扱うために作られた仕様で、amd64では必須機能となった。
今では32bitOSの多くがPAE必須である。
2017/08/11(金) 22:06:34.56
>>420
おまえの環境のintは64bitなのか？
64bitは人が扱う数字としてはでかすぎるんだよ。だから多くの環境でintは32bitで止まったんだよ。
おまえはもう少し社会で働け。歴史を知らなさ過ぎる。
2017/08/11(金) 22:08:23.22
ROMを知らないとか、組み込みは32bitとかド素人はROMってろよ。
2017/08/11(金) 22:24:18.72
>>420
マシンの話なんかしてないって何度言われも理解できないんだな
バカとかアホとか超越した知能障害だぞお前
2017/08/11(金) 22:27:47.00
位取り記数法は対数のオーダーの計算量の増加だから、滅多に使いそうにない大きな数を扱えるようにしといても、コストはそれほど発散しないんと違う？
2017/08/11(金) 22:33:38.95
CPUキャッシュ消耗してヒット率激減だわ
2017/08/11(金) 23:11:10.16
なるほど高速CPU売りつけたいCPUメーカ工作員が暴れてたってわけだな
意味もなくソケット互換性失わせて強引な儲け方してきたものの
特に日本ではPCIに拘る特殊事情のお陰で完全に裏目に出てるからな
あとは32bitOSより遅くなる64bitOS強要してみようってところか
i5とi7の違いなんてほとんどキャッシュの差だけだし滑稽だわ
2017/08/11(金) 23:13:30.55
>>422
ばーか。32bitのintなんて小さいだろ。
頭悪いくせに書き込むなよ。
2017/08/11(金) 23:18:23.99
64bitになって遅くなるって、例えばどんなアプリだ？
実測値出そうぜ
2017/08/11(金) 23:18:49.53
>>422
> 64bitは人が扱う数字としてはでかすぎるんだよ。だから多くの環境でintは32bitで止まったんだよ。

別に止まってはいない。今は32bit時代のソフトがまだ残っているので互換性を維持するためにint = 32bitで
コンパイルする場合が多いというだけ。いずれ64bitが当たり前になればint = 64bitが普通になる。
メモリモデルは以下の表のようにLP32からILP64まであるので、マシンに合わせてどれでも使える。

それに、C言語の仕様は、整数型char、short、int、long、long longの型はいずれもサイズまでは
指定されておらず、実装によってまちまちになっている。

[各変数と実際のビットサイズ表]
整数型　　LP32　ILP32　LLP64　LP64　ILP64
char　　　　8　　8　　　8　　　　8　　　8
short　　　16　　16　　16　　　16　　16
int　　　　16　　32　　32　　　32　　64
long　　　32　　32　　32　　　64　　64
long long　64　　64　　64　　　64　　64

今は64bitレジスタが普通に使えるのに、ソースが古くて64bitでコンパイルが通らないから
32bitのままコンパイルしとこう、というものぐさなことをする人が多いだけだと思う。
まあソースが山ほどあって直すのが面倒だという気持ちもわからなくはないが。
2017/08/11(金) 23:25:21.42
amd64はそもそもlongモードで32bitコードをそのまま動かすために作ったもの。
その仕様のおかげてMSはamd64を選んだ。

にもかかわらずFreeBSDユーザはそんなことどうでもいいのだ。
64bitOSは64bitコード使え、32bitOSは32bitコード使えだ。

なぜそんなアップルみたいな切捨てができるかというと継承するソフト資産が皆無だから。
2017/08/11(金) 23:28:23.70
>>430
真剣にILP64採用してるとしたら脳みそが足りない技術者。
2017/08/11(金) 23:32:56.62
>>429
キャッシュの小さなCeleron機でベンチ比較すれば顕著に出るだろうよ
2017/08/11(金) 23:34:58.07
画像フィルタの類で1〜4000000000の数値を2〜3999999999に
浮動小数点数を使わずに四捨五入で厳密に補正する事を考えてみようか
ans=(((val-1)*(3999999999-2))/(4000000000-1))+2
32bitしか扱わなくても64bitが使えるだけで一発で終わる様になる
マが確保する自動変数が32bitで間に合うかどうかだけが全てじゃない

32bitは小さいぞ
2017/08/11(金) 23:38:22.93
>>433
計ろうぜ
ちなみにうちだとE3300機で32bitよりも64bitバイナリの方が速かった
ソースはKali linuxでのWPAキーのkey/secの表示だとか辞書の生成速度や
別パーティションのwinのaviutlでのエンコ速度
2017/08/11(金) 23:39:16.96
>>429
別OSだがこんな結果がゴロゴロしてんだ。間違いない。諦めろ。
http://ascii.jp/elem/000/000/641/641476/img.html
2017/08/11(金) 23:42:37.36
>>436
そのグラフの32bit4Gと64bit4Gを比べて言ってるの？
64bitGの方が若干早い項目多いし、64bit2Gがあったら青のバーがもっと短くなるんじゃない？
2017/08/11(金) 23:43:39.26
>>431
あんたの考えをそのまま進めていくと、世の中に64bit PCしかなくなっても
ソフトだけは32bitで動き続けるという変な状況になる。
新規で作るソフトや、大きな改修をするソフト、頻繁に使うソフトはいずれ64bitをフルに使うように手直し
されていくはず。16 -> 32bitのときも同じことが起きて、古い16bitソフトはだんだんサポート外になったし。
2017/08/11(金) 23:50:34.51
別に変でもなんでもない
long long使えばOSが64bitコードに変換すればいいし、
128bitCPUが出ても特殊オプションなど使わせずにOSがすべて吸収すればいい
2017/08/11(金) 23:55:22.72
>>438
おまえが変な状況と思うのはおまえが社会に出てないからで、むしろそれが普通なんだよ。
しかも、8->16、16->32のときとは明らかに64bitに対する需要が異なる。
8->16、16->32と違って速度が倍増しないのだ。incentiveがないのだ。理由は明白だ。
当の昔に32bitCPUのデータバスは256bit超えてんだ。32bitから64bitにしたら実質データ帯域が半減するんだ。
実測すれば分る。

MOV r32, imm32 L: 0.06ns= 0.3c T: 0.06ns= 0.25c
MOV r64, imm64 L: 0.24ns= 1.0c T: 0.15ns= 0.64c
2017/08/11(金) 23:55:25.57
i80386が出てしばらくはMS-DOSで16bitのコードを延々動かし続けてた
64bitのOSで32bitのアプリを動かそうと、x264のexeだけ64bitにしてエンコだけ高速にしようと
メーカーやユーザーの自由だろう
2017/08/12(土) 00:05:43.76
>>440
それってポインタの定数の命令だけの話だよね？
64bit化したバイナリが一律32bitの倍のコードサイズになる訳じゃないぞ
2017/08/12(土) 00:27:19.64
アセンブラ出力眺めてみた
64bitのイミディエイトのオペコードからのロードなんてループの外でしかやらんな
ループ突入前の１回、ポインタが４バイトから８バイトになって「遅い！」なんて体感できる奴はいないだろう
しかもamd64だとレジスタの本数増えてるからループの中でポインタをレジスタに云々なんて滅多に起きない

64bitが遅いってんならWinMacLinuxFreeBSD未だに一律32bitのままだった事だろう
2017/08/12(土) 00:52:25.56
>>442
もちろんデータバスの差が顕著に出る例だ。
amd64が仮想メモリ空間、レジスタだけのなんちゃって64bit化である以上、
足回り、エンジンは同じままだということだ。
2017/08/12(土) 00:59:31.66
>>443
そもそもほとんどの64bit環境のコンパイラはintは32bitだ。
仕様上必要でないかぎりわざわざ64bit longなんて使わない。
2017/08/12(土) 01:09:53.71
主張がわからん
>>444みたいな顕著に出る例なんて>>443で、殆ど速度低下はないだろうし、
なんちゃって64bitだろうと64bitのレジスタ同士での演算は可能
そのなんちゃって64bitってのはなんちゃってじゃない64bitと何が違う？

32bitの数値しか使わなくても、乗算除算が必要になれば>>434で64bitの恩恵はあるだろ
今普及してるx64否定して何がしたい？目的は何だ？
2017/08/12(土) 01:19:33.54
x86とamd64の技術的なメリットをデメリットを述べただけで、x64を否定したと感じるのは
おまえが、i386排除連呼してるカルト宗教だからだろう。
2017/08/12(土) 01:26:26.64
>>434
最近の画像はRGB各色32bitなのか？
2017/08/12(土) 01:28:03.81
なんちゃって64bitってのはなんちゃってじゃない64bitと何が違う？
会話する気がないならamd64とi386どっちを使おうと個々の勝手だからもう黙ろうな
スレ違いもいいところだ
2017/08/12(土) 01:29:42.92
>>448
動き補正だとかFFTだとかの計算内容知ってるか？
RGBの各値を四則演算でぼかせたノイズ消えただの喜んでる様な計算じゃ済まないんだぞ
2017/08/12(土) 01:30:18.33
何度も説明してるだろう。
これだけ説明して理解できないなら自分でamd64の仕様書読め。

それでも理解できない馬鹿なのだから諦めろ。
2017/08/12(土) 01:31:07.91
>>450
知らん。
2017/08/12(土) 01:32:17.69
SSE案件。例が稚拙。
2017/08/12(土) 01:35:12.32
64bit至上主義者はまた完全論破されたのか。
2017/08/12(土) 01:38:00.87
16bitのときもCP/Mを引きずり、32bitのときもDOSを引きずりという歴史を知っていれば
i386がいらないなんて話は出てこないはずなんだが。

32bit排除厨はおそらくマカーなのだろう。
2017/08/12(土) 01:46:21.32
http://ascii.jp/elem/000/000/641/641476/img.html
で明らかだな。

image manipulationは僅かに64bitが有利。だからここで勝負したいのだろう。
しかし、web browsingの圧倒的な差。

あたなの用途は2chですか？　PhotoShopですか？

FreeBSD用のPhotshopはありませんけどね!!
2017/08/12(土) 01:48:41.68
>>453
【Intel】OpenCV総合スレ 5画素目【画像処理】
ttp://mevius.2ch.net/test/read.cgi/tech/1382689696/

>>454-455
i386を排斥してる事にするなよ

ループの外でのポインタのイミディエイトのロードのオペランドが
４バイトから８バイトになった僅かな速度低下なんて誰も気にせんだろ
x64を過剰にディスって名無しや開発陣に何がさせたいんだよ
2017/08/12(土) 01:54:09.20
>>456
ブラウザは64bitかどうかってよりOSの実装の問題じゃね？
６４ビットと３２ビットのモジュールの両方を使えるように検索しに行ってるとか
2017/08/12(土) 01:54:57.52
平均的な用途のベンチってつまりPC MARKでしょ。答えでてるじゃん。
2017/08/12(土) 02:03:35.71
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html

おまえらの大好きそうなOSSのベンチですら引っ張り出さずに６４ビット遅いとか言っちゃうんだもんな
救いようがねえ
2017/08/12(土) 02:06:40.95
> インストール済みのUbuntu 32bit版をUbuntu 64bit版へそのまま移行するような手段は提供されていないため

酷いな。普及しないはずだわ。
2017/08/12(土) 02:24:16.59
最初から６４ビット版入れときゃ先ず間違いはない
2017/08/12(土) 02:33:31.93
FreeBSDもLinuxも普及しない理由が分った。
2017/08/12(土) 02:48:03.94
> 最初から

ほんとこいつの脳みそは幼稚園児並だな。
465名無しさん＠お腹いっぱい。
垢版 |
2017/08/12(土) 02:57:39.52
なんでこんなに伸びてるの
FreeBSD来てるの？
2017/08/12(土) 03:05:23.10
俺様のしょぼい32bit機に最適なビルド作れってわめいてるのがいるだけ
2017/08/12(土) 03:17:19.03
まだマシンの話してるとか思い込んでる知的障害ゴキが這いつくばってんのか
2017/08/12(土) 03:27:21.86
>>465
張られたベンチはWinとlinuxだけ。もう分るな。

FreeBSDはベンチすらされない。つまりオワコン。
2017/08/12(土) 03:36:37.20
ウインなにがしみたいなインターネットを危険に陥れる脆弱性だらけのバグバグOSもどきは最初からオワコン
FreeBSDはサーバ用途
2017/08/12(土) 03:37:00.57
思い通りにならないとディスり始める
フリーウェア作者を奴隷か何かと勘違いしてるクレーマーと変わらん

>>460の通り、世は６４ビットに移行しつつある
過去のものはi386で動かせ
Win95をMSに改良しろなんて言ったところで作らん
2017/08/12(土) 03:41:48.04
i386でOSだけが64bit対応するのが合理的って話だろ
何度言われても飲み込めない盆暗だからCの基本すら理解できないんだろ
2017/08/12(土) 03:45:52.05
何も生み出せない奴ってのは崇拝することしかできないからな
頭が悪いものだから与えられたものに満足して思考停止に陥るわけだ
この手のキチガイがOSSを語るとか反吐が出るわ
2017/08/12(土) 03:46:29.86
i386のままじゃ遅いバイナリが多いんだから合理的じゃないだろ
2017/08/12(土) 03:48:10.83
i386のままのほうが速いバイナリが多い現実すら見ようとしないとか
救いようがないな
2017/08/12(土) 03:49:40.40
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
実測値のソース出せよ
2017/08/12(土) 03:55:51.10
日本語読めないのか？
>>1から100回読み直せ
それでも理解でなければお前はオワコン
2017/08/12(土) 03:58:46.78
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
> Linuxゲームのベンチマーク
> 　Linuxゲームのベンチマークでは、ほんの少しUbuntu 64bit版の方がパフォーマンスが良くなる傾向にありますが、ほとんど変わりません。
> 　このベンチマークでは、数値が大きいほど性能が良いということになります。
>
> 動画のエンコードとカーネルビルドのベンチマーク
> 　動画のエンコードとカーネルビルドのベンチマークでは、すべての項目においてUbuntu 64bit版の方がパフォーマンスが良いです。
> 　特に動画のエンコードでは、最大で1.4倍程度の差がでています。
> 　「More Is Better」と記述されているベンチマークでは、数値が大きいほど性能が良いということになります。
> 　一方、「Less Is Better」と記述されているベンチマークでは、数値が小さいほど性能が良いということになります。
>
> データ処理のベンチマーク
> 　データ処理のベンチマークでも、すべての項目においてUbuntu 64bit版の方がパフォーマンスが良いです。
> 　「OpenSSL v1.0.1gRSA 4096-bit Performance」では、4.4倍もの差がついています。
>
> 消費電力のベンチマーク
> 　消費電力のベンチマークでも、すべての項目においてUbuntu 64bit版の方が消費電力が小さくなる結果が出ています。
> 　各ベンチマークの「Min」が最小消費電力、「Avg」が平均消費電力、「Max」が最大消費電力です。
> 　平均消費電力で見ると、1ワットから5ワット程度の差がでています。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況