FreeBSDを語れ Part44 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>733
FreeBSD i386版ならLIBも当然32bitだろ バカとキチガイが3人なのか4人なのかよくわからないが、とにかくにぎわってる。 分かってるのは64bit厨がすげー無知ということだけ。 >>732
多分libが足りないだのヘッダが無いだののコンパイルエラーを解決する能力もない >>730
そのURL、Single-Coreのベンチ結果も貼ってある >>731
半導体メーカーorシリコン基板のマスクを発注するメーカーはそんな無駄な事は出来ない
分厚いルネサスのマスクですら10年前で1枚2億とかしたぞ
少しでも速いなら64bitにする >>739
いやお前の知能が足りないから問題の本質を理解できないだけ なんか遥か昔にAMDが286は386より速いキリッした広告思い出した。
ただそれ言い出すと386は486より乗算が速いとかあるんだわ。 >>741
一昨日あたりからのレスを読みもせずに書き込んでんのか?
頓珍漢でブザマだからすっこんでろよ >>743
ttps://ja.wikipedia.org/wiki/Intel486
41クロックが42クロックになったところで誰もきにせんw
しかも486になってからクロック逓倍技術(当時はクロックダブラーとか呼ばれてたんだっけ)が
軌道に乗り出したから仮に1.5倍とかになっても大差はなかった ベンチでわかる程度の速度差ならどう考えてもI/Oの遅さで紛れるような気がするなぁ。
時間的に有用な差が出るほどの時間がかかる作業なら別の何か特定の環境でやる必要ないし。
合理性?速度語るなら札束で殴る方が早いと思うけど。 速度もコスパも度外視していいなら上位互換の64bitでいい
何を騒いでるんだ? i5とi7の違いってキャッシュだけであれだけのパフォーマンス差があるわけよ
わざわざ意味もなく64bitでキャッシュ無駄にして何が楽しいんだって話だろ
1プロセスで4GB以上使う必要のある奴を否定するつもりはないがな 本当に64ビット化で著しいキャッシュミスヒット率増加があるならこんな結果は出ない
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html 64ビットになったオペランドからイミディエイトでアドレス(ポインタ)ロードするのなんて
ループの外くらいだぞ
ループに入る前のポインタ関連の命令だけ4バイト増えたとして
初回のミスヒットなんてそんなにペナルティありゃせんわ >>749
だから64ビット演算の恩恵だろうが
それ以外はボロ負けだろ
ほとんどのアプリは64ビット演算なんかいらない
バカのお前には理解できんだろうがな >>751
それ以外の”ボロ負け”と言える程の大差で32bitが速いっていうベンチのソースは?
ちなみにブラウザはChromeなんかは64bitの方が速いからな 何度も貼られてるだろ
コピペ馬鹿のお前と同じことしろって?
大差とも誰も言ってない >>745
だからくだらない話だって事さ、
まあ、普通にお金の計算したって平然とプラスマイナス21億なんて軽く超えてる時代に32bitに固執する理由なんて全くないわ。 >>754
じゃあ互換性破壊してまで64bitに盲進する必要もないだろ >>755
DOSや16ビット時代のソフトなら自作も含めてVirtualBoxに任せてるわ俺w >>755
互換性取れてるだろ
i386で動かしたきゃi386で動かせ
他の最新PC買える人は64bitで快適に作業してるからさ >>750
ほんとamd64の仕様を知らないんだな。ポインタ関連だけとか、無知な64bit厨の妄想。
amd64は、32bitレジスタpush命令ねーぞ。int32をpushしたら、push raxされる。
しかもイミディエイトでアドレスロードってなんだよ? 単なる即値ならキュッシュヒット率関係ねーわ。
この前からおまえは知ったかが過ぎる。 >ほとんどのアプリは64ビット演算なんかいらない
いやほとんどのアプリは32bitだろうと64bitだろうと動けば正義、が正しいだろう。
8bitから16bitや32bitにいたる劇的な速度の向上とか存在しないのだから
どっちでビルドしても人の反応を待つようなアプリじゃ誤差だろう。 >>758
pushpopとか関数呼び出しで遅くなったからって何だよ?
intの類の自動変数もpushpopで一つ一つ確保してると思ってるのか?
それに主処理のループになんの影響がある? >>758
なるほど、コードのポインタのサイズ増加は関係ない、そう仮定してる訳ね?
じゃあ、データだけで語ろうか
64bitだとレジスタの本数が増えて、自動変数のポインタ類は
32bitよりもスタックの中にポインタが実際に確保される可能性は低くなるんだぞ >>760
何だよじゃねーよ。嘘ついてごめんなさいと言え。 >>762
intの類の自動変数もpushpopで一つ一つ確保してると思ってるのか? >>762
そのpushpopでパフォーマンスの低下がネックになるのは
callと呼び出し規約で保存しなきゃならないと規定されてるレジスタの保存と、他にはどこがある? 64bit厨はアセンブラレベルになるといつも質問ばかりだな。
amd64を知らないことはもうバレてんだからごめんなさいしろよ。
思ってるのか!!っておれにいちいち仕様を確認すんな。自分でコード読め。
gccはこういうバイナリ吐くんだと断言してみろ。 >>765
じゃあ答えてやるわ
自動変数はSPに直接値を加減算して一気に確保/巻き戻しする
push/popで速度低下なんて殆ど無い 速度の低下がないなら、なんでアスキー調査でPCmarkやWebBrowsingの一般用途で負けてんだよw
レジスタ増加、64bit演算可、SSE2標準化、4GB超のメモリアクセス可とこれでもかと有利なのにw
キュッシュ馬鹿食い以外で負ける要素がない。 >>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
こういう実運用の実測値で語れよ >>767
おまえ頑なにChrome64ビットの方が速いって事実を無視しようとしてるよな > 64bitに加えて32bitの外部プラグインも検索したりして
また知ったかか。64bitプロセスから32bitDLLなんか呼べんわ。今度はちゃんと謝罪しろよ。 >>770
エッジじゃなくてエクスプローラーの歯車マーク
↓
アドオンの管理
の、アーキテクチャの欄を参照な
DLLだなんて一言も言ってないし、
Winの中じゃコーデックだって32bit64bitは完全に独立して管理されてんたぞ わかってきた
OS64bit プロセス32bit バージョン作れとか言い出した奴、
64bitのOSろくに動かせないからその辺りの事情、全然しらないんだろ >>757
longモードはv86モードとかサポートしてないんだわ。
ただ、32bit固執の馬鹿はそんな事は知らなかったらしい、それで互換性とかw >>769
その事実を知らなかったのでググって最初のブログ見た。
http://blog.livedoor.jp/blackwingcat/archives/1898136.html
> スパゲッティーを小鍋から大鍋に移したに過ぎないんだよ…。スパゲッティーはスパゲッティーだ。
たしかにChromeは64bitが速くて当然である。 >>771
まずは嘘ついてごめんなさいだろ、おまえは。 そもそもChromeの時点で窓から投げすてろよ。
それにスレ的にはChromeじゃないだろ。 >>775
先ずは O64bit プロセス32bit とかバカな話の為に嘘を垂れ流し始めたお前が土下座だろ? >>775
外部プラグインを勝手にDLLにすり替えて嘘だって事にでっち上げたいだけだろ Windowsの外部プラグインはDLLで提供するものやで。
いくらなんでも無知すぎや。
ファイル: AdblockPlus32.dll
ファイル: wmpdxm.dll
ファイル: PDFXCviewIEPlugin.dll >>772
お前ごとき盆暗が何をわかったてんだ?
その辺りの事情とやらを説明してみろよ
64bitのOSろくに動かせないって明らかにm32すら知らなかったお前だろうが >>780
64ビットプロセスから直接32ビットのプラグインのDLLを呼び出してると思ってるのか・・・? >>784
結局逃げ惑うんだから巣から這い出てくんなやゴキブリ 膨大なコード資産を生かしたままプロセス合計4GB以上を実現するには
amd64とi386を融合して一本化、OS64bitプロセス32bitが合理的だわな
人もいないのに二足の草鞋とかやってるからどっちも中途半端なんだろうが >>785
ヘッダライブラリが足りない以外で、m32でコンパイルリンクに通らないって、どんな状況?
ttp://a4dosanddos.hatenablog.com/entry/2015/09/19/131052
>>786
「OS64bitプロセス32bitが合理的」「プロセス合計4GB以上を実現」
どうやって? >>783
また質問で仕様の確認すんなよ。答えろよ。ズバっとよ、ズバーとだ。
でなきゃ嘘ついてごめんなさいと謝れ。 >>786
1プロセス4GB以下で全プロセス合計4GB以上 → i386使え
プロセス合計4GB以上 → amd64使え >>787
教えてやるから尼券よこせって何度も書かれてるわけだが >>790
ヘッダライブラリが足りない以外で、m32でコンパイルリンクに通らないなんて口から出まかせだろ
ttp://a4dosanddos.hatenablog.com/entry/2015/09/19/131052 >>789
全プロセス合計4GB以上をi386で使えるってか? >>792
ttps://www.freebsd.org/doc/ja_JP.eucJP/books/handbook/bsdinstall-hardware.html
使えるだろ >>791
尼券払いたくないからって人様に難癖付けてんなや貧乏教えてくん >>794
ヘッダライブラリが足りない以外で、m32でコンパイルリンクに通らないなんて口から出まかせだろ
ttp://a4dosanddos.hatenablog.com/entry/2015/09/19/131052
どうせコンパイルエラー見て、どのライブラリが足りないか調べる能力もないとかそんなオチだ またみっともないコピペゴキブリが顔真っ赤で荒らしだしたw
アホだから自分で言葉も作れない > 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
> 使えるだろ
これで以降、揚げ足取りしかしなくなったら笑う >>792
はぁ? おまえは一体何を言ってるんだ。まさか知らないで暴れてたのか。
そういやi386でPAEが実装されてること知らない馬鹿いたよな。同一人物かよ? >>797
自分でプロセス合計4GB以上使ってから言え >>798
それは俺だな
全プロセス合計4GB以上をi386で使えない使えないうるさいから、
FreeBSDのi386は本気でPAE未対応なのかと思い込んだ Chromeとかいうスパゲッテイをいくつも起動したら合計4GBなんて簡単に超えるんちゃうか。 >>799
動かない様子をtopのSSと一緒に晒せ >PAE対応=プロセス合計4GB以上使える
頭大丈夫か? >>803
1プロセス4GB以下、全プロセス合計4GBなのか
1プロセス4GB以上なのか
はっきりしろ >>802
お前が言い出したことなんだから
お前が動いている様子を晒すのが道理だろ
できなかったって認めろよ >>804
突然どうした?
どっかに頭飛んでるのか? > 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
> 使えるだろ
それでも使えないってんならレポートしてこい >>807
i386で全プロセス合計4GB以上使えるなんてどこに書いてあんだよ
寝言は寝て言えどあほ >>801
ここはFreeBSDのスレだぞ、Chromeとか馬鹿言うんじゃねえ。 >>808
> 640 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 19:39:37.17
> 2chがi386で動いてると聞いてすっ飛んできますた
> そりゃamd64じゃ効率悪い罠
> 699 名前:Mango Mangüé ★ そうだ2ちゃんねるしよう!©2ch.net[agete] 投稿日:2017/08> /13(日) 00:52:54.63 ?S★(824724)
> http://img.2ch.net/premium/8409133.gif
> メモリーは64GB積んであるんでバカスカ使ってますw
>
> それでも20GB以上余るのでまだまだ甘いですw
> ここmevius鯖の場合
> last pid: 60030; load averages: 1.14, 1.08, 1.07 up 72+10:26:00 08:51:49
> 59 processes: 2 running, 56 sleeping, 1 zombie
> CPU: % user, % nice, % system, % interrupt, % idle
> Mem: 2966M Active, 31G Inact, 3044M Wired, 1591M Buf, 25G Free
> Swap: 64G Total, 64G Free
2chは使ってる >>812
俺が書いたわけでもないのに知らんがな
2chに鯖たくさんあるしな
そんなことよりi386で全プロセス合計4GB以上使えるとか
偉そうに言い放った馬鹿さ加減を謝罪しろよ >>813
今久しぶりにi386落としてる
で、FreeBSDのPAEで認識した4G以上って何に使ってるんだよ? 古い文献
> amd64版入れたら、普通に4GBメモリ認識しました。。。ちなみに、i386版で、4GB以上認識させるには、kernelオプションで、PAEってのを有効にしてビルドかけないといけないらすぃ。。
もちろんやったんだよな? i386でPAE有効にしてみたんだろ?
いつもの即レスどうしたんだよ お前がいつまでたっても謝罪しないから相手にしてくれないと思われ
つか、フルボッコにされてんのに即レス云々馬鹿丸出しだぞ 64bit厨が32bitに興味深々でワロタ
荒らさずもうちょっとシタテに出てれば色々と教えてもらえてただろうに >>820
興味なんかありゃしねえよ 実験終わったら捨てHDDなんざまた押入れの中だ
/usr/src/sys/i386/conf に PAE って最初から用意されてるよな
もちろんこれ使ったんだよな? > 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
> 使えるだろ
おまえはvmstatの出力の r b w av freの、freの値が4.0Gを超える事はないと、
mallocで1G-1バイトのメモリを確保するプロセスを4以上生成する事はできないと
そう言いたいんだな? 32bit厨敗走クソワロタ
荒らさずもうちょっとシタテに出て会話してれば色々と教えてもらえてただろうに > 64ビットプロセスから直接32ビットのプラグインのDLLを呼び出してると思ってるのか・・・?
質問じゃなくて説明しろよ。聞いたことねーぞ。 > 786 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 01:06:46.18
> 膨大なコード資産を生かしたままプロセス合計4GB以上を実現するには
> amd64とi386を融合して一本化、OS64bitプロセス32bitが合理的だわな
> 人もいないのに二足の草鞋とかやってるからどっちも中途半端なんだろうが
> 792 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 01:11:24.35
> >>789
> 全プロセス合計4GB以上をi386で使えるってか?
> 808 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 01:27:05.50
> >>807
> i386で全プロセス合計4GB以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
IEだとかのプラグインの先の実装とかもうどうでもいいから
OS64bitじゃないと何だって? i386用のカーネルで4G以上使えないって嘘が証明されたら、
今度は何が何でも64ビットの僅かな欠点だけをゴリ押しして、
64ビットの利点は何が何でも認めないって流れに戻るんだろ?
誰もおまえ専用の32ビットプロセス専用64ビットOSなんて誰も作らないし合理的でも何でもない > 64ビットプロセスから直接32ビットのプラグインのDLLを呼び出してると思ってるのか・・・?
とにかくおまえはこれを説明しろよ。 >>828
目的をはっきりさせろ
いつまでも揚げ足取りしてんじゃねえ
> 786 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 01:06:46.18
> 膨大なコード資産を生かしたままプロセス合計4GB以上を実現するには
> amd64とi386を融合して一本化、OS64bitプロセス32bitが合理的だわな
> 人もいないのに二足の草鞋とかやってるからどっちも中途半端なんだろうが
> 792 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 01:11:24.35
> >>789
> 全プロセス合計4GB以上をi386で使えるってか?
> 808 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 01:27:05.50
> >>807
> i386で全プロセス合計4GB以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
土下座しろ氏ね どこが揚げ足か。どうやって64bitプロセスから32bitDLL呼び出すか聞いてんだよ。
おまえができるみたいなことを言い出したから話がおかしくなってんだよ。
妄想で書いたなら嘘ついてごめんなさいと言え。次から次へと嘘ばかり並べやがって。 >>830
誰もDLLを直接呼び出してるだなんて言ってない
DLL呼び出してるなんて書き込みがあるなら引用してみろ
> 786 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 01:06:46.18
> 膨大なコード資産を生かしたままプロセス合計4GB以上を実現するには
> amd64とi386を融合して一本化、OS64bitプロセス32bitが合理的だわな
> 人もいないのに二足の草鞋とかやってるからどっちも中途半端なんだろうが
> 792 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 01:11:24.35
> >>789
> 全プロセス合計4GB以上をi386で使えるってか?
> 808 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 01:27:05.50
> >>807
> i386で全プロセス合計4GB以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
土下座しろ氏ね知ったかぶり >>831
おれ
> また知ったかか。64bitプロセスから32bitDLLなんか呼べんわ。
おまえ
> 64ビットプロセスから直接32ビットのプラグインのDLLを呼び出してると思ってるのか・・・?
引用してやったぞ。どうやって64bitプロセスから32bitDLL呼び出してるか説明しろ。 >>832
> 64ビットプロセスから直接32ビットのプラグインのDLLを呼び出してると思ってるのか・・・?
思ってないから「思っているのか・・・?」って書いてあるんだろうが ■ このスレッドは過去ログ倉庫に格納されています