FreeBSDを語れ Part44 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
速度もコスパも度外視していいなら上位互換の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を呼び出してると思ってるのか・・・? 思ってないから「思っているのか・・・?」って書いてあるんだろうが 言葉尻だけとらえて「思ってる」とか決め付けるなヴォケ氏ね > 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に加えて32bitの外部プラグインも検索したりして > 64ビットプロセスから直接32ビットのプラグインのDLLを呼び出してると思ってるのか・・・? こんなアホレス続けておいてシラを切る気か。とんでもない糞野郎だ。 >>836 検索しに行ってるから32bit64bit両方のアドオンが表示されてんだよ 実行時にどっちが実行されるか実行できないかなんて知らんわ 1つの項目で両方に対応してるアドオンの事まで面倒見切れるかよ 揚げ足取りもいい加減にしろようぜえ氏ね しかし、まぁ、64bit厨ってほんと無知だったな。とにかく64bit以前の歴史を知らない。 仕様書やソースを読んでる相手に対して、〜と思ってるのか?っていちいち質問形式。 ここまで無知ってゆとり学生だろうな。これがデジタルネイィティブの実力。中身なし。 突っ込みどころが無くなると唐突な勝利宣言 > 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以上使えるなんてどこに書いてあんだよ > 寝言は寝て言えどあほ 大ウソつきの32bit厨土下座しろ氏ね知ったかぶり ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html ブラウザのベンチマークサイト ttp://peacekeeper.futuremark.com/ >>840 他人のレスを貼っておれを叩いても意味ないよ。 無知な64bit厨は複数人いることは明らかだから。それはおまえの仲間じゃないのかw >>842 無知の根拠を引用できない32bit厨みじめ > 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以上使えるなんてどこに書いてあんだよ > 寝言は寝て言えどあほ 大ウソつきの32bit厨土下座しろ氏ね知ったかぶり PAEを有効にしたカーネルで int main( void ) { void * pv; pv = malloc( 0x3fffffff ); while( 1 ) { memset( pv, 0, 0x3fffffff ); printf( "BABEL " ); } } clang test.c ./a.out ← ctrl+alt+F1〜F4のttyで実行 F5のttyでvmstat いや、おまえらいつまで気狂いに付き合ってスレ潰しに協力してんの? 64bit使ってるおれ最先端かっこいいみたいな 実は仕組みを何も知らない馬鹿でした。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる