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/13(日) 10:33:49.47
32bit厨　Win!!
2017/08/13(日) 11:26:34.33
iPhone並のPCで勝利宣言する俺カコイイ
2017/08/13(日) 11:48:16.33
iPhoneは64bit化しました。メモリ2GBですけどね!!!
2017/08/13(日) 12:08:27.35
iPhoneは32bit化すれば速くなるのにアホやな
ユーザのことより儲けることしか考えてない守銭奴企業丸出し
パナソニック顔負けだな
2017/08/13(日) 12:14:59.96
(ﾟдﾟ)
2017/08/13(日) 12:19:11.89
昔iPhone持ってたけどガッチガチな上にクソパスワードいちいちウザくて捨てたわ
回線契約解除してリセットしたら起動させなくするランサムウェア仕込んでるし
そもそもアップルは個人情報悪用企業で言わなきゃ不具合対応すら拒否するだろ
番号通知しないと電話取らないパナソニックもユーザより保身第一だけどな
2017/08/13(日) 12:31:55.41
何で4Gもメモリ積んでないようなスマホまで64bit化されていってるかわかってるか？
2017/08/13(日) 12:50:36.77
BSDが糞だから。
2017/08/13(日) 12:55:20.57
>>715
コイツ本気でそう思ってそうで笑える
2017/08/13(日) 12:58:24.88
>>716
昨日、PAEも知らなかった馬鹿だろ、おまえw
2017/08/13(日) 13:06:24.50
>>717
コイツ本気でそう思ってそうで笑える
2017/08/13(日) 13:11:51.29
図星のようだw
2017/08/13(日) 13:13:40.19
> 何で4Gもメモリ積んでないようなスマホまで64bit化されていってるかわかってるか？

64bit厨は質問ばかりで自らは決して説明しないからすぐ分る。また無知がバレるからなw
2017/08/13(日) 13:17:12.53
> いまどきのATOMですら64bit命令実行できる現在、PAEなんて必要あるか？

> どうせPAEが無くてもユーザランドのメモリ空間事情は変わらん

笑えるw
2017/08/13(日) 13:43:09.25
２４時間以上貼り付いた後、１２時間寝たのか・・・ご苦労なこった
2017/08/13(日) 15:12:32.86
>>720
ttp://www.computingcompendium.com/p/arm-vs-intel-benchmarks.html
64bitの方が速いからに決まってるだろ
2017/08/13(日) 16:26:11.92
わざわざリンク貼ってバカ披露してる奴初めて見たｗ
2017/08/13(日) 17:08:21.20
今時swap outなんてしないって
page out だよ
2017/08/13(日) 17:58:36.43
>>719 コイツ本気でそう思ってそうで笑える
2017/08/13(日) 17:59:04.01
>>720 コイツ本気でそう思ってそうで笑える
2017/08/13(日) 17:59:22.96
>>721 コイツ本気でそう思ってそうで笑える
2017/08/13(日) 17:59:42.74
>>724 コイツ本気でそう思ってそうで笑える
2017/08/13(日) 21:30:02.36
>>723
まあ、今だと32bitか64bitかよりも、64bitマルチコアが当たり前だから
マルチコアでどれだけパフォーマンスが出るかのほうが重要だわな。
2017/08/13(日) 22:05:30.96
32bitでマルチコアなら64bitよりパフォーマンス出るわ
せめて-m32くらい満足に通せっつのな
やりたいことやってる奴ばかりで互換性にまで手が回らんのだろうがな
2017/08/13(日) 22:10:15.40
-m32で何のエラーが出るんだ？
2017/08/13(日) 22:16:08.00
11でも/usr/local/lib32ないしもう切り捨てくさいな
2017/08/13(日) 22:28:19.43
>>733
FreeBSD i386版ならLIBも当然32bitだろ
2017/08/13(日) 22:31:46.34
バカとキチガイが３人なのか４人なのかよくわからないが、とにかくにぎわってる。
2017/08/13(日) 22:33:30.89
>>735
呼んだ？
2017/08/13(日) 22:44:38.17
>>734
話の流れを読めないお前はバカ
2017/08/13(日) 22:52:15.42
分かってるのは64bit厨がすげー無知ということだけ。
2017/08/13(日) 23:05:47.76
>>732
多分libが足りないだのヘッダが無いだののコンパイルエラーを解決する能力もない
2017/08/13(日) 23:06:35.81
>>730
そのURL、Single-Coreのベンチ結果も貼ってある
2017/08/13(日) 23:14:30.66
>>731
半導体メーカーorシリコン基板のマスクを発注するメーカーはそんな無駄な事は出来ない
分厚いルネサスのマスクですら１０年前で１枚２億とかしたぞ
少しでも速いなら64bitにする
2017/08/13(日) 23:17:22.38
>>739
いやお前の知能が足りないから問題の本質を理解できないだけ
2017/08/13(日) 23:18:42.00
なんか遥か昔にAMDが286は386より速いキリッした広告思い出した。

ただそれ言い出すと386は486より乗算が速いとかあるんだわ。
2017/08/13(日) 23:20:42.89
>>741
一昨日あたりからのレスを読みもせずに書き込んでんのか？
頓珍漢でブザマだからすっこんでろよ
2017/08/13(日) 23:21:30.03
>>743
ttps://ja.wikipedia.org/wiki/Intel486
41クロックが42クロックになったところで誰もきにせんｗ
しかも486になってからクロック逓倍技術（当時はクロックダブラーとか呼ばれてたんだっけ）が
軌道に乗り出したから仮に１．５倍とかになっても大差はなかった
2017/08/13(日) 23:22:50.92
ベンチでわかる程度の速度差ならどう考えてもI/Oの遅さで紛れるような気がするなぁ。
時間的に有用な差が出るほどの時間がかかる作業なら別の何か特定の環境でやる必要ないし。

合理性？速度語るなら札束で殴る方が早いと思うけど。
2017/08/13(日) 23:26:54.76
速度もコスパも度外視していいなら上位互換の64bitでいい
何を騒いでるんだ？
2017/08/13(日) 23:28:47.41
i5とi7の違いってキャッシュだけであれだけのパフォーマンス差があるわけよ
わざわざ意味もなく64bitでキャッシュ無駄にして何が楽しいんだって話だろ
１プロセスで4GB以上使う必要のある奴を否定するつもりはないがな
2017/08/13(日) 23:30:54.71
本当に６４ビット化で著しいキャッシュミスヒット率増加があるならこんな結果は出ない
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
2017/08/13(日) 23:33:24.05
６４ビットになったオペランドからイミディエイトでアドレス（ポインタ）ロードするのなんて
ループの外くらいだぞ
ループに入る前のポインタ関連の命令だけ４バイト増えたとして
初回のミスヒットなんてそんなにペナルティありゃせんわ
2017/08/13(日) 23:34:44.90
>>749
だから64ビット演算の恩恵だろうが
それ以外はボロ負けだろ
ほとんどのアプリは64ビット演算なんかいらない
バカのお前には理解できんだろうがな
2017/08/13(日) 23:35:59.05
>>751
それ以外の”ボロ負け”と言える程の大差で32bitが速いっていうベンチのソースは？
ちなみにブラウザはChromeなんかは64bitの方が速いからな
2017/08/13(日) 23:37:50.83
何度も貼られてるだろ
コピペ馬鹿のお前と同じことしろって？
大差とも誰も言ってない
2017/08/13(日) 23:38:52.20
>>745
だからくだらない話だって事さ、
まあ、普通にお金の計算したって平然とプラスマイナス21億なんて軽く超えてる時代に32bitに固執する理由なんて全くないわ。
2017/08/13(日) 23:40:29.28
>>754
じゃあ互換性破壊してまで64bitに盲進する必要もないだろ
2017/08/13(日) 23:44:24.99
>>755
DOSや16ビット時代のソフトなら自作も含めてVirtualBoxに任せてるわ俺w
2017/08/13(日) 23:47:19.89
>>755
互換性取れてるだろ
i386で動かしたきゃi386で動かせ
他の最新PC買える人は64bitで快適に作業してるからさ
2017/08/13(日) 23:47:25.19
>>750
ほんとamd64の仕様を知らないんだな。ポインタ関連だけとか、無知な64bit厨の妄想。
amd64は、32bitレジスタpush命令ねーぞ。int32をpushしたら、push raxされる。
しかもイミディエイトでアドレスロードってなんだよ？　単なる即値ならキュッシュヒット率関係ねーわ。
この前からおまえは知ったかが過ぎる。
2017/08/13(日) 23:48:52.02
>ほとんどのアプリは64ビット演算なんかいらない

いやほとんどのアプリは32bitだろうと64bitだろうと動けば正義、が正しいだろう。
8bitから16bitや32bitにいたる劇的な速度の向上とか存在しないのだから
どっちでビルドしても人の反応を待つようなアプリじゃ誤差だろう。
2017/08/13(日) 23:50:46.51
>>758
pushpopとか関数呼び出しで遅くなったからって何だよ？
intの類の自動変数もpushpopで一つ一つ確保してると思ってるのか？
それに主処理のループになんの影響がある？
2017/08/13(日) 23:54:20.87
>>758
なるほど、コードのポインタのサイズ増加は関係ない、そう仮定してる訳ね？
じゃあ、データだけで語ろうか
64bitだとレジスタの本数が増えて、自動変数のポインタ類は
32bitよりもスタックの中にポインタが実際に確保される可能性は低くなるんだぞ
2017/08/13(日) 23:55:21.88
>>760
何だよじゃねーよ。嘘ついてごめんなさいと言え。
2017/08/13(日) 23:55:56.92
>>762
intの類の自動変数もpushpopで一つ一つ確保してると思ってるのか？
2017/08/14(月) 00:00:18.47
>>762
そのpushpopでパフォーマンスの低下がネックになるのは
callと呼び出し規約で保存しなきゃならないと規定されてるレジスタの保存と、他にはどこがある？
2017/08/14(月) 00:03:46.53
64bit厨はアセンブラレベルになるといつも質問ばかりだな。
amd64を知らないことはもうバレてんだからごめんなさいしろよ。
思ってるのか!!っておれにいちいち仕様を確認すんな。自分でコード読め。
gccはこういうバイナリ吐くんだと断言してみろ。
2017/08/14(月) 00:04:49.27
>>765
じゃあ答えてやるわ
自動変数はSPに直接値を加減算して一気に確保／巻き戻しする
push/popで速度低下なんて殆ど無い
2017/08/14(月) 00:19:44.94
速度の低下がないなら、なんでアスキー調査でPCmarkやWebBrowsingの一般用途で負けてんだよw

レジスタ増加、64bit演算可、SSE2標準化、4GB超のメモリアクセス可とこれでもかと有利なのにw

キュッシュ馬鹿食い以外で負ける要素がない。
2017/08/14(月) 00:22:56.87
>>767
http://ascii.jp/elem/000/000/641/641476/img.html
これの事言ってるなら過渡期の、それもスポンサーの意向でベンチ内容を選ぶ様な出版社の
独自調査、しかも64bitで速度低下って誤差レベルじゃねえか
後方互換だとか64bitに加えて32bitの外部プラグインも検索したりしてて時間掛かってるとか
そんな下らないオチだろ

http://www.phoronix.com/scan.php?page=article&;item=ubuntu_1310_3264&num=3
http://www.phoronix.com/scan.php?page=article&;item=ubuntu_1310_3264&num=4
こういう実運用の実測値で語れよ
2017/08/14(月) 00:25:45.38
>>767
おまえ頑なにChrome６４ビットの方が速いって事実を無視しようとしてるよな
2017/08/14(月) 00:29:52.34
> 64bitに加えて32bitの外部プラグインも検索したりして

また知ったかか。64bitプロセスから32bitDLLなんか呼べんわ。今度はちゃんと謝罪しろよ。
2017/08/14(月) 00:31:36.75
>>770
エッジじゃなくてエクスプローラーの歯車マーク
↓
アドオンの管理

の、アーキテクチャの欄を参照な
DLLだなんて一言も言ってないし、
Winの中じゃコーデックだって32bit64bitは完全に独立して管理されてんたぞ
2017/08/14(月) 00:33:24.09
わかってきた
OS64bit プロセス32bit バージョン作れとか言い出した奴、
64bitのOSろくに動かせないからその辺りの事情、全然しらないんだろ
2017/08/14(月) 00:35:41.37
>>757
longモードはv86モードとかサポートしてないんだわ。
ただ、32bit固執の馬鹿はそんな事は知らなかったらしい、それで互換性とかw
2017/08/14(月) 00:37:08.32
>>769
その事実を知らなかったのでググって最初のブログ見た。
http://blog.livedoor.jp/blackwingcat/archives/1898136.html

> スパゲッティーを小鍋から大鍋に移したに過ぎないんだよ…。スパゲッティーはスパゲッティーだ。

たしかにChromeは64bitが速くて当然である。
2017/08/14(月) 00:39:48.65
>>771
まずは嘘ついてごめんなさいだろ、おまえは。
2017/08/14(月) 00:40:21.37
そもそもChromeの時点で窓から投げすてろよ。
それにスレ的にはChromeじゃないだろ。
2017/08/14(月) 00:41:36.47
>>775
逆じゃんw
2017/08/14(月) 00:41:51.05
>>775
先ずは O64bit プロセス32bit とかバカな話の為に嘘を垂れ流し始めたお前が土下座だろ？
2017/08/14(月) 00:42:49.29
>>775
外部プラグインを勝手にDLLにすり替えて嘘だって事にでっち上げたいだけだろ
2017/08/14(月) 00:58:46.97
Windowsの外部プラグインはDLLで提供するものやで。
いくらなんでも無知すぎや。

ファイル: AdblockPlus32.dll
ファイル: wmpdxm.dll
ファイル: PDFXCviewIEPlugin.dll
2017/08/14(月) 00:58:50.55
>>772
お前ごとき盆暗が何をわかったてんだ？
その辺りの事情とやらを説明してみろよ
64bitのOSろくに動かせないって明らかにm32すら知らなかったお前だろうが
2017/08/14(月) 01:00:36.12
32bit厨が苦しくなってまいりましたw
2017/08/14(月) 01:02:20.25
>>780
６４ビットプロセスから直接３２ビットのプラグインのDLLを呼び出してると思ってるのか・・・？
2017/08/14(月) 01:03:10.87
>>781
日本語で頼むｗｗｗ
2017/08/14(月) 01:04:47.65
>>784
結局逃げ惑うんだから巣から這い出てくんなやゴキブリ
2017/08/14(月) 01:06:46.18
膨大なコード資産を生かしたままプロセス合計4GB以上を実現するには
amd64とi386を融合して一本化、OS64bitプロセス32bitが合理的だわな
人もいないのに二足の草鞋とかやってるからどっちも中途半端なんだろうが
2017/08/14(月) 01:08:11.71
>>785
ヘッダライブラリが足りない以外で、m32でコンパイルリンクに通らないって、どんな状況？
ttp://a4dosanddos.hatenablog.com/entry/2015/09/19/131052

>>786
「OS64bitプロセス32bitが合理的」「プロセス合計4GB以上を実現」
どうやって？
2017/08/14(月) 01:08:36.07
>>783
また質問で仕様の確認すんなよ。答えろよ。ズバっとよ、ズバーとだ。

でなきゃ嘘ついてごめんなさいと謝れ。
2017/08/14(月) 01:09:12.08
>>786
１プロセス4GB以下で全プロセス合計4GB以上 → i386使え
プロセス合計4GB以上 → amd64使え
2017/08/14(月) 01:10:02.25
>>787
教えてやるから尼券よこせって何度も書かれてるわけだが
2017/08/14(月) 01:10:54.17
>>790
ヘッダライブラリが足りない以外で、m32でコンパイルリンクに通らないなんて口から出まかせだろ
ttp://a4dosanddos.hatenablog.com/entry/2015/09/19/131052
2017/08/14(月) 01:11:24.35
>>789
全プロセス合計4GB以上をi386で使えるってか？
2017/08/14(月) 01:12:19.39
>>792
ttps://www.freebsd.org/doc/ja_JP.eucJP/books/handbook/bsdinstall-hardware.html
使えるだろ
2017/08/14(月) 01:12:36.72
>>791
尼券払いたくないからって人様に難癖付けてんなや貧乏教えてくん
2017/08/14(月) 01:13:51.19
>>794
ヘッダライブラリが足りない以外で、m32でコンパイルリンクに通らないなんて口から出まかせだろ
ttp://a4dosanddos.hatenablog.com/entry/2015/09/19/131052

どうせコンパイルエラー見て、どのライブラリが足りないか調べる能力もないとかそんなオチだ
2017/08/14(月) 01:15:54.74
またみっともないコピペゴキブリが顔真っ赤で荒らしだしたｗ
アホだから自分で言葉も作れない
2017/08/14(月) 01:16:55.41
> 792 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2017/08/14(月) 01:11:24.35
> >>789
> 全プロセス合計4GB以上をi386で使えるってか？

> 793 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2017/08/14(月) 01:12:19.39
> >>792
> ttps://www.freebsd.org/doc/ja_JP.eucJP/books/handbook/bsdinstall-hardware.html
> 使えるだろ

これで以降、揚げ足取りしかしなくなったら笑う
2017/08/14(月) 01:17:46.00
>>792
はぁ？　おまえは一体何を言ってるんだ。まさか知らないで暴れてたのか。
そういやi386でPAEが実装されてること知らない馬鹿いたよな。同一人物かよ？
2017/08/14(月) 01:18:31.74
>>797
自分でプロセス合計4GB以上使ってから言え
2017/08/14(月) 01:19:15.23
>>798
それは俺だな

全プロセス合計4GB以上をi386で使えない使えないうるさいから、
FreeBSDのi386は本気でPAE未対応なのかと思い込んだ
2017/08/14(月) 01:19:53.88
Chromeとかいうスパゲッテイをいくつも起動したら合計4GBなんて簡単に超えるんちゃうか。
2017/08/14(月) 01:20:16.91
>>799
動かない様子をtopのSSと一緒に晒せ
2017/08/14(月) 01:21:10.83
＞PAE対応＝プロセス合計4GB以上使える
頭大丈夫か？
2017/08/14(月) 01:21:58.18
>>803
１プロセス4GB以下、全プロセス合計4GBなのか
１プロセス4GB以上なのか
はっきりしろ
2017/08/14(月) 01:23:04.98
>>802
お前が言い出したことなんだから
お前が動いている様子を晒すのが道理だろ
できなかったって認めろよ
2017/08/14(月) 01:24:40.66
>>804
突然どうした？
どっかに頭飛んでるのか？
2017/08/14(月) 01:25:57.60
> 792 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2017/08/14(月) 01:11:24.35
> >>789
> 全プロセス合計4GB以上をi386で使えるってか？

> 793 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2017/08/14(月) 01:12:19.39
> >>792
> ttps://www.freebsd.org/doc/ja_JP.eucJP/books/handbook/bsdinstall-hardware.html
> 使えるだろ

それでも使えないってんならレポートしてこい
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況