FreeBSDを語れ Part44 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
10月かぁ
10.4待つか11.1に行くかどうしよう
10.3 採用のサーバがあるなw@こことか
でもまもなく11.0-p1なサーバに移転します 2chは今でもfreebsdなのか
どういう環境で動いてるのか気になる
そんなごたいそうな環境でもありません
nginx+Apacheって感じのご尤もな構成です 12.0、ino64 したんで念のため
portupgrade -fa 中
多分今日中には終わるだろう
mevius.2ch.net移転記念w
FreeBSD 11.0-p1になりましたw >>13
-p10 に update してね(はぁと
USERLAND_VERSION="11.0-RELEASE-p10"
って書き換えておいたw そっかー
/bin/freebsd-version をごにょごにょすればいいのかー
これはいい話を聞いた へぇ。FreeBSDで動いとるんだ。
Linuxだとカーネル調整なしにコネクション数を捌けないだろうからな
これは窓鯖もなんだが freebsdのサポート短いのにfreebsdでサーバ組む理由が分からない >>19
パッチなら月1回くらいupdateかけてればいいだけだと思うが。バージョン上がったときでもfreebsd-updateすればいいし。
Ubuntuは5年のもあるけど結局パッチ出れば当てるから似たようなもん。 etc絡みのチェックがウザいんだろ
通信ソフトさえupdateしとけばOSのupdateなんかしなくて問題ない
lib絡みで泣きごと言われたらシンボリックリンクでも張っとけ
3年も持てばいい方なのでw athでhostapd作ろうとするとtcpdump -i wlan0した時だけつながる不思議な現象
athの代わりに転がってたrun使うとあっさり接続
iwnなアダプタ発注したけど、動くと良いなあ >>24
関係ない話かもしれんが
無線インターフェースがpromiscuous modeじゃないと稼働しない物がある
とかどっかで聞いたことがある 自宅は同じ構成(wlan on ath)でhostapd運用しているが、そんな現象はないな。
athのチップ毎に特有のパラ指定が漏れているとかじゃないかな。 試行錯誤して調べるするよりaliで300円のアダプタ買った方が良いや とすっかりじじいモード
猫じゃあるまいし観測されて動作変えるなと言いたい
強制promiscは試したけどダメだった -11.1-BEAT1
+11.1-BETA1
Sorry currentも以前のような、立ち上がらないかも
と言うドキドキ感が無くなってきた lxqt の pkg 来たよ
http://lxqt-freebsd.schmitz.computer/
lxde 使ってる人なら、試してもいいかも >>35
幾ら何でも出て来るのが遅すぎって感はある。 ついでに言うと現状舞の海が欲しいのに朝青龍が必要とか言うふざけた状態だからな。lxqt on FreeBSD 11.0で10.3のカーネルビルドは出来ないの?
GENERICカーネルでもエラー出まくりなんですが。
clangのバージョンを合わせればおk? iwnが来たけど、hostapはnot supportedだと texliveのportsが2015からアップデートされてないのは何か事情があるんですかね?
それとも手が回ってないだけ? 宣伝が足りない
FreeBSDで彼女ができました
FreeBSDを始めてからケンカも負けたことありません
こういうのが大事
2ちゃんねるはいまだにFreeBSDで動いています FreeBSDはニッチだからいいんだよ
リナ糞の二の舞は御免だ お前、ニッチって言いたいだけで意味分かってないだろ
FSはウンコ、pkgもウンコ、日本語関係もウンコじゃ2chくらいでしか使い物にならん Debian GNU/kFreeBSD って使ってる人いる? SoftetherVPNを導入するためにbhyveを導入してみたが割り当てメモリ256MBで全く問題なく動くのは感動した。
BE環境が使えることにさらににっこり。 BETA3が出るということは
開発に少し手間取っているということか。 loader.confが動いてないっ?♪
nvidiaドライバーが読み込まれてなーい♪
pkg install でインスコしたfirefoxがセグメント違反でキドウシナーイ♪
あばばっばbsbdjdkfjろえおおfwじゅついちろえpr ifconfigに-vオプションがあるというのを今日初めて知りました。
wlan0に対してやると、なんか色々と出てくるのね。 core i7 のノートPCで 4スレッド OpenMP の計算しても変な結果は出てないけどなぁと思ったら、うちのは Ivy Bridge だったよ。 Skype(4.3以前)が来月以降使えなくなるの困るなぁ え?なんで来月以降?今も使えないのでは?
まぁ、HT off にすれば良い見たいだけど。
FreeBSDでもBIOSの設定とか反映するんだっけ? ハイパースレッディングをオフにするくらいなら
初めからi5を買った方が幸せになれる たいていの用途でHTはいらんがL2、L3キャッシュは多いほどいい。 10.3-RELEASE -> 11.0-RELEASE で↓と同じ現象が。
https://lists.freebsd.org/pipermail/freebsd-bugs/2015-September/063883.html
11.0-RELEASE -> 10.3-STABLE では問題なし。11(and12?) 系固有の問題らしい。
10.3-STABLE -> 11.1-RC1 でもやはり発生。
11.1-RC1 -> 10.3-RELEASE ← 今ここ
10.4-RELEASE を待つ事にしました。
10.4 の EOL の頃には 11.x で直っていますように。 だからメジャーバージョンが偶数のものにしろと
あれほど 第105回 FreeBSD 12で登場が予定される新機能は?
http://gihyo.jp/admin/serial/01/bsd-yomoyama/0105
実際問題、恩靴の彼が書く新機能ってほとんどまともに動かないんだよ。
それがFreeBSDのダメさ加減を象徴している。 >>71
ダメって言うだけならお前ですらできるわ。 rpi2でwifiトングル使えるようになったんだろうか
rtl8192cuドライバの問題かもしれんが
pkgのgccがgcc5に改名したのか btトングルも問題ありだな
移植もbtpandだけぶっつけ程度で繋がらない機器とかあるし
どんだけ人居ないんだか 某LTE搭載ノートPCがFreeBSDで使えたらなあ… Windowsの上に仮想マシン載せてFreeBSD動かうほうが楽だろ。 ウインなにがしみたいなインターネットを危険に陥れる脆弱性だらけのバグバグOSもどき使ってる知恵遅れってまだいたんか
裏でどんだけ不気味な通信してることか 今ではウインなにがしの方が
はるかに安全であることを知らない知恵遅れが
まだいたとは。>>80は珍獣だな。 はるかに安全(笑)
乗っ取られまくってる現実すら知らないとか
>>81は知障丸出しで哀れすぎるな >>83
わざわざ松沢病院から書き込まなくていいよ。 SA-17:05.heimdal
EN-17:06.hyperv releng/10.3/crypto/heimdal/lib/krb5/ticket.c 直すの忘れてるよね 久しぶりに1年前使ってきたマシンをメンテしてたら
portsnap updateしたら
portsが
"/usr/ports/Mk/bsd.port.mk", line 1042: Unknown directive
みたいなエラー吐いて使えない
portsを丸ごと入れ替えてもダメ
ググった結果使っていた9.3Rは、去年の12月にサポート切れてたらしい
それでおかしくなったみたい
バージョンアップするしかないかな
現役マシンの10.3のサポート期限は2018年04月30日だけど、すぐだよな(汗 >>91
makeだけ新しいのを持ってきたらなんとかならんかな? >>93
9.3から10.3へのアップグレードは、ライブラリとか色々おかしくて
結局、11Rを新規インストールした!
まあその方が安心だよね >>98
公式ホームページの予定表通りだけど
それ以外でその手の告知ってどこ見ればわかる? 俺はお盆で実家に帰ったら、Ryzenでパソコン組んで11.1をインスコするんだ コアばっか増やすベンチ詐欺CPUとかよく買うわ
エンジニアはSingle Thread Ratingでしか比較しねえっつの
Single Thread Ratingあたり消費電力最低CPUとか紹介して欲しいわ FreeBSDは計算に向いてないから
計算するんならLinuxの方がいい
GotoBLASを作った後藤氏が
> ページカラーリングとかは当然行っていると思うのですが、
> 最近の巨大なキャッシュに対応させるようなことはしてい
> ないと思います。Linux もまだまだですが BSD 系列はメモリ管理の
> 粒度が小さすぎて、物理アドレスでの連続性があまり得られません。
> さらに、プロセスのスケジューリングでも同一のコアに固定した
> スケジューリングではなくて、コロコロと移動させてしまいます。
> ま、ベンチマークをとってみれば一目瞭然
という事で、ベンチを取ると、マルチコアでSIMD命令(SSE2やAVX)を使うような計算の場合
Linuxは理論値の90%以上を出せるけど
FreeBSDは70%程度だとか FreeBSDは高負荷中のスレッドをコロコロとコア移動するの? >>100
自分も公式ページしか知らないし見てない(´・ω・`)
MLかIRCで流れてるんじゃないかしら。 10.4 待ちで 11.1 なんかどーでもいい者としては手持無沙汰なんで
r321371 を 10.3 に持ってきたりして遊んでます。 もうコア単体での速度上昇は限界なのかもな
消費電力を犠牲にすれば別だが クロック数を語る時代はもう過ぎたからなあ
かと言って単位クロックあたりの演算能力が劇的に向上するわけでもないし
それでいて製造プロセスの技術向上によりシリコン面積あたりのCPU実装部分は年々小さくなっている
この減った部分を埋めるためにGPUやノースブリッジどころかサウスブリッジまで乗せるようになったのは当然の流れ
まだ隙間がある?CPUコアを増やそうか 14nmで足踏みしてるのはなぜだろうか
10nmのCoffee Lakeがキャンセルされ
新規発表されるのは14nmプロセスのものばかり
一方で7nmが製造成功し、5nmも視野に入っているという 分子的に倍数にならないタイミングとか解明されてない理由があるんだよ >>101
Ryzenは
まだサポートされてない。 >>116
Performance per watt TDPで比較して
M3-6Y30が4.5W
i3-5010Uとi5-4300Uが15W
Performanc per wattは
消費電力が低いM3-6Y30(7.6)が他の2つ(5.8)より高いスコアなのは妥当でないかい M3-6Y30...31.04pt/W
i3-5010U...48.64pt/W
i3-5010Uのほうがワットあたりパフォーマンスが高いって意味じゃないの? M3はクロックの低さをキャッシュで補っているから
処理が重くなるほど効率が悪くなるように見えるな
レイテンシも低いだろうしバランス悪いよね キャッシュはワンパ処理のベンチによく効くからな
pt/Wでの比較はかなり重要だろう Atom系は今のApollo Lakeで各コア2MBで
次のGemini Lakeから3MBになる
Gemini の次はMercury Lakeかな レイテンシが悪いって言いたいんだろ
そのくらい解釈できずにくだらないレスするお前は脳タリン 悪いってのもいわなくね?
普通大きい小さい。せめて長い短い。 要するにクロックが低すぎると電力効率が悪いってことでFA? キャッシュのレイテンシが低いのがバランスが悪いんだってさ。
dramのレイテンシが高いから間にsramを設けて、少ないsramで効率よくレイテンシ下げるのがキャッシュなのにね。 そんなこと議論してないだろ
救いようのないアホだなお前 >>129
線形ではないのだからそういう言い方はよくない。
高すぎても低すぎても電力効率は落ちるということ。
モバイルで要件がまず消費電力なら効率落としても消費電力を下げるのはあり。 でもさ、何かを処理するのに余計にバッテリ食うんだろ
ほんとにありなのか? >>137
夏場だと美味そうだな。>冷点心
どこのコンビニ出撃ってるか教えてくれくれ。 Intel "Gemini Lake" Low-power Architecture Features Wider Instruction Decode
ttps://www.techpowerup.com/235514/intel-gemini-lake-low-power-architecture-features-wider-instruction-decode
次期AtomのGemini Lakeが4デコード・4パイプらしい なんか*lake世代って*well世代に比べてPerformance per watt落ちてるよな
萎えるわ 11.1-Rに更新完了。
更新用のBEを現環境から作って/mntにマウント、chrootで閉じたら/usr/srcを11.1にして
再起動無しでカーネルのインストールからpkgの更新、不要ライブラリの削除まで全部やってから
更新用BEをアクティベートして再起動。
えらく簡単になりましたね。
特にBEをマウントしていじれるのでトラブルシュートがすごく楽。 11.1Rのクリーンインストールで、xorg 7.7_3 入れたけど、Xorg -configure が segmentation fault でエラーになるね。
まぁ、xorg.conf なしで動かすから良いんだけどね。 このように不具合は誰も報告しないので一向に枯れないオープンソース。
逆にクローズドで金払ってると動かんぞ、ゴラァって言ってくれるんだよね。 じゃあウインなにがしはなんでバグの数がうなぎ上りなんだよ? 多機能な上にユーザ数多いからじゃない?
BSDに限らずLinuxも、ユーザ数増えたら今の比じゃない程ぼろぼろ致命的な穴が出てくると思う
てか古いAndroidとか、Googleも匙投げて問題放置だっけ? >>148
セキュリティホール報告数はFreeBSDより少ないだろう。
デスクトップに関しては未だBSDはまともに使えない。キミは一体何を基準にバグの数を数えたんだ。 >>148
ウインなにがしはダダのハードウェアチェッカーだろ
例えるなら付属電池みたいなもの
脳みそある奴が使うような代物じゃない ブザマなれいさ製スクリプトウイルスに感染してないFreeBSDは最高やね ウインなにがしってPC買うたび消し去る前に一応動作チェックするけどさ
7あたりでUNIX系に追いつかれて以降わざとか思うほどGUI自滅し続けてるよな ttp://i.imgur.com/yuvPGGh.png
追い付かれ・・・ん??? >>146
>11.1Rのクリーンインストールで、xorg 7.7_3 入れたけど、Xorg -configure が segmentation fault でエラーになるね。
>まぁ、xorg.conf なしで動かすから良いんだけどね。
この場合はどこへ報告なのか悩む。
segmentstion fault でcore吐いて落ちるは明らかにバグだし、報告すべきなのは分かってるんだが。 結局のところ、11.1RでApollo Lakeはサポートされてるの?
(eMMCの問題の件) >>157
バカかどうかに関係なく、ユーザが多いといろんな環境で使われるからバグが発見されやすいんですよ。 発見されようと直せる人間が毛ほどしかいないんだから無意味だろ
つかこのアホはバグの酷さについてちょっとググることすらできんのか
ソース公開されてんだからその気になりゃ自分で直せるしな どっちがどっちのこと言ってるのかアホだと理解できんかも >>161
じゃあ>>146のバグもその気になって直してくださいな
直せる人間が毛ほどしかいないのがわかってるんならそれくらい協力できるでしょ そもそも直してまで使わなくても他に選択肢が腐るほどある パナソニックあたりの守銭奴経由して相続利権の社会的寄生虫を儲けさせるために協力するとか奇特すぎるだろw
まあ月30万程度のベーシックインカム制度でも始まれば何だって直してやらんでもないけどな 折角、直すって言ってるのに、
何で直してまで使わなくてもいい
みたいな言い方するんだよ。 >>146
ログを見てエラーの出ているライブラリなりアプリケーションをpkg removeで削除すれば
動くよ。 そんなバカな。ちなみに、エラーログは下。
--------
[ 226.174] (EE) Backtrace:
[ 226.176] (EE) 0: /usr/local/bin/Xorg (OsInit+0x38a) [0x5abfba]
[ 226.177] (EE) 1: /lib/libthr.so.3 (_pthread_sigmask+0x544) [0x8025cbd94]
[ 226.179] (EE) 2: /lib/libthr.so.3 (_pthread_getspecific+0xe5f) [0x8025cbbef]
[ 226.180] (EE) 3: ? (?+0xe5f) [0x7ffffffffff2]
[ 226.182] (EE) 4: ? (?+0xe5f) [0xe5f]
[ 226.184] (EE) 5: /usr/local/bin/Xorg (InitOutput+0x11ea) [0x47faca]
[ 226.185] (EE) 6: /usr/local/bin/Xorg (remove_fs_handlers+0x38b) [0x43b48b]
[ 226.187] (EE) 7: /usr/local/bin/Xorg (_start+0x17f) [0x42506f]
[ 226.188] (EE) 8: ? (?+0x17f) [0x80083417f]
[ 226.189] (EE)
[ 226.189] (EE) Segmentation fault at address 0x0
[ 226.189] (EE)
Fatal server error:
----------------------- そのすぐ上に下もあるが、関係ないかな。
-----------
[ 226.174] (EE) open /dev/dri/card0: No such file or directory
[ 226.174] (WW) Falling back to old probe method for modesetting
[ 226.174] (EE) open /dev/dri/card0: No such file or directory
--------------- >>163
ハ、ハゲとらんわ、フッサフッサやねん! llvmの古いバージョンにリンクされていることによる有名なエラーだな。
pkg info |grep llvm
でllvmの複数のバージョンがインストールされてないか確認。
あったら古いバージョンを削除してrebootでおk。 risa/ asirのports ってなくなっちゃったんですか?
pkg search しても見つからないんですけど packageで提供して無いだけでよ。
portsにはあるよ。 >>176
そういうことなんですね.
ありがとうございます.
最近は仮想マシンがメインだからports は展開しないことが多かったもので… >>160
だな、とあるフリーソフトの極めて単純なバグ見つけてレポートしたけど使う奴が少ないのか今までレポートされてなかったという恐ろしい事実に戦慄したよ。 オープンソースは安全とか盲信してるのもどうかと思うが OpenSSLとかいい例だったな
オプソだから安心と連呼しておきながら、読んでる奴は殆ど居なかった >>181
変更に次ぐ変更でスパゲッティ状態だったのでそう簡単にいじれなかった。 >>174
サンクス。 llvm は llvm40-4.0.1 しか入ってないなぁ。
クリーンインストールだからね。pkg のバグで入ったかもと思って確認したけど入ってなかった。
startx では問題ないから -configure オプション付いたときに実行する何がおかしいのかな。
最近は -configure する人も少ないだろうし、直らないまま残りそう。 >>179
むしろOSSじゃないものを優先して使う >>184
それお前がソースも読めない馬鹿なだけやん OSSは裏で意図的な通信をするのを阻止できることが大きいよな
ウインなにがしとかいうOSもどきなんて金取っておきながら裏で通信しまくりだしな
Linuxでも任意の通信を要求してモジュールやらダウンロードしまくった挙げ句、
rootでの実行を強要するお察しとしか言いようがない某キチガイスクリプトが叩かれてたりするけど OSSでもやる奴はやる
それに泥みたいな、OSSの上に乗ってる物が情報収集って例もある >>189
それお前がソースも書換えられない馬鹿なだけやん >>190
なら泥の上に乗ってる物がgoogleに送るデータ完全に止めるパッチでも作ってみてくれ OSSの話してんじゃねえのかよ
そんなことだから馬鹿とか言われるんじゃねーの? >>192
泥のカーネルの上に乗ってる泥専用のツールキット類やGUI以外は
ほどんどBSDやMITのOSSだぞ >>194
データ送る制御もそこで行われてますか? >>195
データ収集やら送信やらを静的ライブラリでいちいちストアのアプリ類に
リンクさせてるとでも思っているのか? >>194
言うならもうちょっと具体的に言ってくれない?
ライセンス違反って言いたいのかな? >>197
論点はOSSならデータ収集が可能か不可能かじゃねえの?
Android データ収集 でggr
GoogleみたいにMSみたいな利用規約に同意させてOSSでもデータ収集するところはある お前が何が言いたいのかよく分からん
OSSと泥の関係性についての認識から語ってくれ >>199
泥の下地は殆どOSSだろ
OSSならデータ収集だの送信だのしないとか神話に縋って馬鹿じゃねえのかと
ちょいとマイナーなライブラリに読みづらいコードを何かの大規模修正に紛れ込ませたら
CIAだかFBIだかの仕込みみたいに年単位で気づかれねえよ
OSSのバイナリ実行する前に隅から隅までコードを検証してからじゃないと
怖くてバイナリ実行できない><とか言って全部コード読む奴なんているのか? OSSでもやる奴はやる
OSSだから安全とか言ってる奴の方が馬鹿だろう
googleだってやってる >>202
それお前がソースも書換えられない馬鹿なだけやん >>203
お前もだろ?
お前はGIMPだとかFireFoxだとかを数週間掛けて隅々までコードを読んで
安全だとかわかってからじゃないと使わないのか?
個人で修正なんか入れた後アプデ入ったらまたパッチ当て直しだぞ
OSSのソース書き換えて運用してるって言うなら具体的に何をどう書き換えてるか書いてみろ >>204
パケット監視する知能すらないアフォが偉そうにしてんな >>206
パケットモニタで情報収集やら送信してるかやら判断するなら
OSSかどうかなんて関係ないだろ >>207
だから使い続けたいなら自分で該当コード削除した上、喧伝すりゃいいだろうが
救いようのないアホだなお前 >>209
その削除した奴が世の中にどれだけ居る?
おまえだってやらないだろ?そもそもCIAのとか年単位で気付かれなかったし
OSSだから安全とか、自分でそういうの即座に喧伝してから言え
できる人が殆どいないのに、それできない相手を罵倒するとか誰でもできる OSSという時点でそんなバレバレなことしない
OSSじゃないからバレないと思って裏で通信しまくってんだろうが
そんな取って付けたような通信、1行やそこらコメントアウトする程度だろ
お前ができない低脳だからって人様に難癖付けてんなや >>211
ならおまえはAndroidとか片っ端から修正して使ってんのか?
具体的にどんなアプリのどこのソースをコメントアウトして運用してる?
具体的に名前出せよ Androidの話はスレチ
どのアプリがOSSだって言いたいのかもサッパリ分からんなお前 他人に「おまえはできない」連呼する前に、自分ができる事を証明すべき
まぁOSSだからって絶対安全なんて説はOpenSSLとOpenBSDのスパゲティで崩壊済み だからそんな説馬鹿なお前が言ってるだけだろ
危険極まりない非OSSに対して、OSSは比較にならないレベルで安全
ただしお前のような無能な馬鹿にとってはOSSだろうと変わりはないというだけの話 さもOSSのコードを利用者の多くが隅々まで読んでるかの様ないいまわしばっかり
その前提が崩れたらお前のいってる事は妄言にしか過ぎない
OSSも非OSSも今や規模が肥大化して、怪しいコード埋め込まれたって
気付ける奴なんざそうはいない お前がアホだからその様ないいまわしに聞こえるだけ
ギャーギャー意味不明なこと喚いてるだけの小学生丸出し OSSだろうとそうでなかろうと、全域を読める奴、読む奴が殆どいなきゃ大差はない ゲーム機なんかにLinuxとか使われて、ハックされて違法コピーが流行って以降、
軒並みソース公開しなくていいBSD系に移行したな
OSSが危険な事も多々ある
ソースから簡単に改変カーネル類作れるんだから、ハックしやすいのは当然 OpenSSLはやっつけレベルのコードが何年も放置だったからな。あれは酷かった。
悪意あるHackerは除いて誰一人も何年も確認しなかったのだ。これはほぼすべてのコードに対して誰も確認してないと同義だ。
動かないと確認するが動いているものは誰一人確認しないのがオープスソース。 >>223
おまえ、別人だってわからないのか?
>>222
ほんとそれな
それらしく動いてたら何か仕込まれてるかも知れなくても殆どの人は読まないからな OSSと非OSSどちらのほうが危険かという話を無理矢理大差ないということにして
OSSは危険というレッテルを張れたつもりでいる救いようのない馬鹿でしょ >>224
ここまで頭の悪いキチガイお前しかいねえよw 守銭奴パナソニックあたりの盆暗従業員でも迷い込んできたんじゃね
休日だし 普通に使ってて非OSSが危険だってんなら、もうPCどころかインターネッツとか崩壊してるだろ
OSS安全とか、自分はソース修正どころかソース読めない癖に誇張し過ぎなんだよ ソース読むのはバグに当たった気がした時くらいかなぁ >>228
そういう飛躍したこと平気で言うからお前は馬鹿だアホだと言われんだよ
このスレでソース読めないのってお前くらいなもんじゃね? コーディングできる上に、他人のコードが読めても、せいぜい>>229が殆どだな
使うソフトのコードをいちいち安全かどうか調べる時間があるとか、失業者かニートくらいなもんだ OSSだから悪さできないって何度言われても覚えられないのなアホだから 非OSSが意図的に裏で通信しまくってるソフトだらけだという現実すら知らない馬鹿 パナソニックの糞UIテレビもLAN線に繋げた途端に謎の通信するしな
ぶっ壊すわけじゃないからどんな通信しても自由だとか勘違いしてるソフト大杉
OSSでそんなことやったら、晒し上げられて、あっさり分岐だわ >>234-235
それが大問題なら訴訟起こせばいい
些細なデータ収集された程度で目くじら立てる様な奴なんて、
マイナーなOSをちょっと使いこなせる程度で存在意義を見いだせるとか勘違いしてる様なキモオタくらいだ ソフトがどんな情報を裏で通信しているのか、について開示しなくてもいいの? 利用規約だとかマニュアルだとかに書いてある
書いてある情報以外を通信してるのを見つけたら訴えてお金持ち
ギャーギャー騒いでる奴は訴えてこい 訴訟(笑)
どこになんて書いてあんだよ
お前がギャーギャー寝言ほざいてるようにしか見えんわ >>237
お金持ちにワロタ
お前はギリギリ知的生命体の範疇に入る程度で存在意義を見いだせるとか勘違いすんなよ 利用規約だとかプライバシーのポリシーだとかMSGoogle林檎軒並み明示してる
ないって本気で思ってるなら訴えてこい基地害
一般人も企業でもデータ収集で危険だとか言いながら非OSS排斥なんて殆どしてねえよ
ttp://i.imgur.com/yuvPGGh.png
おまえらみたいなキモいのがいるから余計敬遠されるんじゃないのか? キチガイは訴えてこいとか言ってる知能障害野郎だろ
2chで訴えようとどこで訴えようと自由
それに難癖付けようとする粘着>>242が一番キモい >>146
>>147
20年くらい前だと、フリーソフトはそういうの当たり前にあった。
C言語始めたばかりの俺でもわかるバグとかあって、
当時のUNIXメールで報告したら、Ooops とかメール返事が来たりしてた。
UNITテストも結合テストもしないで、ちょっと動かしたらリリースしていた時代だから
仕方ないけど。 バグの数なら有料ソフトのほうが圧倒的に多いだろ
ウインなにがしなんてバグ売りつけてるようなものだしな バグの数は品質に直結だけども、
バグ報告とかパッチの数はそのまま品質には直結しないと思うな。
たくさん使われてるからバグ報告が上がる。
製作者が直してるからパッチが出る。 今後も金取りたいから意図的に直さないのが有料ソフトの特徴
詐欺なしにソフトウェアで直接儲けるのはもはや不可能な時代だと気づくべきだな
パナソニックなんて自分で作れないからOSSパクってテレビに乗せて儲けておいて何一つ還元しないだろ
公共事業だの補助金だの企業ではなく、OSSに血税使うほうがよっぽど経済にはプラス まだH3、HDMI出せんのか
動いてんのか分かんねえよ 自分で修正できない盆暗僻み野郎しつこい
守銭奴パナソニックの糞UIテレビがOSSならどれだけ素晴らしいテレビになって売れてることか もしかして、ソフトで金稼いでる奴許せん!とかいう嫌儲か貧乏学生が
1人紛れ込んで暴れてるのか
非OSSこきおろしてOSSマンセーしたところでおまえ同様、ボランティアになる奴はいない
他人が自分の為にボランティアして当然とか勘違いすんなよ?
おまえが死んだところで社会には何の影響もないし、むしろいなくなった方が社会の為になる ずっと暴れてんのはお前一匹だろ
最後の一行、まさにお前こそが噛みしめるべきだといい加減気づけ無能 驚愕の事実
このスレには俺とおまえの二人しかいない! H3HDMI対応の11.2マダ━━━━(゚∀゚)━━━━?? 10にしたら合計1ギガを軽く超えるmallocが失敗するようになった
なんか実装変わった? 搭載メモリ10G超えが当たり前の時代、
プロセス上限が2Gやそこらってどうよ? 1GBのmallocなんてそもそも設計おかしいだろ。一度に使う分だけ細かく取って使えよ。 今時、フラットな1GBのメモリを欲しいことだってあるでしょ。 mmap直接使えばいいんじゃないの?それともこれが制限されてるの? 1G超って・・・std::dequeとか
ポインタの配列持って多次元配列を1次元配列に見せるとかじゃダメなん? > 6623 user 1 20 0 1024G 1652K ttyin 0 0:00 0.00% a.out
何これ…いや理屈はわかるんだけど。 いまどきのATOMですら64bit命令実行できる現在、PAEなんて必要あるか? 4G超マシンにi386入れたい人は少なくないだろう 確か、オーバーライドプレフィクス抜きで
レジスタデフォルト64bit、アドレッシングデフォルト32bitとかできないんだよな
64bitのバイナリのアドレス定数の上位32bitが大抵0だらけで容量無駄にでかい つか、物理アドレスなんて変換されて見えないんだから
i386 OSが64bit空間管理して何が問題なわけ? >>280
i386の時代に64bit空間というものはなかったので、「メモリアドレッシングは32bit内にあるはず」という前提でOSや
チップセットの設計などをしていたからだと思いますね。64bitが当たり前になった今ではおかしく見えるかも知れませんが。
i386で64bitメモリをアクセスするには、そういう構成のPCをわざわざ作らないといけないし、i386 OSを拡張して
64bitアクセスできるようにしないといけませんが、メーカーとしては今さらそんなことをしても売れないと判断して作らないと思いますね。 amd64で-m32やってもmake通らなかったりするわけで EN-17:07.vnet
EN-17:08.pf >>280
またリアルモードとか仮想86モードの時みたいに、セグメントディスクリプタに
リニアアドレスの上位を代入して、32bitしかないレジスタでオフセット指定とかすんの?
今度はセグメントレジスタはインデックス値だから、余計めんどうな事になるぞw >>278
なんかこだわりあるならともかく64bit使いたいだけなけならマシン買い換えろよ ほんの少しわかってきた気がする
乱暴な計算だけど、8G積んだ32bit機で、4Gを必要とする32bitアプリを2つ同時に動かす、
みたいなニッチな用途に特化したOSが欲しいって事?
だとすると、アドレッシングだけ32bit、レジスタだけデフォルト64bitみたいな構成ができるモードを
CPUが構成できるようにならないと、せっかくの64bitCPUの意味が薄れる 64bitアクセスするのはOSだけでいいやんって話
プロセスからアクセスしたけりゃamd64使えばいいけど、
その気になればプロセス分けるなりで済む話であまり意味がない
-m32オプションが仮想的な扱いになってることが理解に苦しむ MMU辺りのアドレス指定だけ64bit、32bitアプリは何もかも32bitでって事?
64bitレジスタで大分高速化できる分野もあるのに無駄じゃん
ニッチな用途の為だけにi386とamd64に加えて、
更にOSだけ64bitのアプリだけ32bitのビルドとかメンテの手間に見合わないだろう windowsはwin32アプリが多くていいよね、って話? i386進化させるだけでいいし、64bitレジスタで高速化できる分野こそニッチじゃね
むしろ無駄に64bit使うことで帯域にメモリにと無駄にして低速化させているのが
大部分のアプリの現実だと思うが 進化させたら過去のx86機どうすんだよ 実行時に32bitか64bitか判断して分岐すんの?
レジスタが64bitになったところで結局上位32bitと下位32bitに定数読み込まなきゃならんなら
結局8バイト分のメモリ帯域使うのは同じ事だぞ
むしろ64ビットの定数を1命令で読み込める分、64bitの方が帯域食わなくて済む
あと64bitとか、aircrack、データマイニング、レンジコーダー、その他諸々
同クロックの32bit比で優に2割以上はパフォーマンス上がる
パフォーマンスが上がる分野はそこまで少なくはないぞ 32bit OSだってのになんで64bitコード動かす前提になるんだよ
単に複数プロセス合計で4GB超の物理メモリが使えればいいってだけの話だろ >>295
それが>>389って事でしょ?
そんな事の為に3つのバイナリのインスコセットを準備する訳?
それともx86のみの過去の機体切り捨て?実行時に判断?
まぁ、ソースあるんだし、ないなら自分で構成すればって話なんだが そんなに欲しけりゃ自分で改造しろ
用意されてない上に誰も要望を上げてないって事はそういう事だ 32bitウインなにがしなんかだと、4GB超にramdisk作れるな それ、アプリがOSに無断でPAE使ってるだけだし、
他のアプリまで使い出したら競合してぶっ壊れるからな。
アプリにメモリ割り当てられる訳じゃないし、ごねてないでいっぺん自分で作ってみろ。 会話能力以前に、レジスタが64bitになって帯域どうこうとか、
Win32bitの4GB超領域にramdiskが作れるだの
(たった1つのアプリだけなら64bitレジスタも使えるが、複数アプリが使い始めたら飛ぶ)
技術的な事がなんにもわかってない素人がクレクレ乞食すんなっての いきなりramdiskとか言い出す奴は真性のアホだから 会話能力が欠如しているほうが人として終わってるだろw
複数アプリが使い始めたら飛ぶから素人だとか
飛んでるのは言ってること何もかも支離滅裂のお前の頭だけだろ ramdiskとか言い出す奴は真性のアホとか完全に頭ぶっ飛んでるわな >>304
会話能力欠如してるのはアプリへのリニアアドレス空間の提供とかに関するOSの話から
突然ramdiskとか言い出す方だろ
何言ってんだこの古事記は・・・俺様の為に他人が特別ビルド提供して当然とか思ってるのか? ramdiskであろうと使えるに越したことはないわ >>306
そんな風にしか解釈できないから頭が飛んでるとか言われるんだろ
相当頭悪いだろお前 ならi386の方で4G使って、そっから上はramdiskに使ってりゃいい
終冬 64bitモードと32bitモードの行き来だけでものすごい性能ペナルティくらいそうだけど
CPUにそういうモードが実装されないとどっちにしろ絵に描いた餅だよね。
話は変わるがバンクメモリとかEMSとかHMAとかセグメントレジスタとか
懐かしいが二度と関わりたくないよな >>310
おまけにセグメントの内容変えないと64Kの範囲内でしかメモリアクセスできなかったしな
CのEMSメモリやらハイメモリやらのライブラリ使っても煩雑だったし
多少遅くても大きくても64bitでいいよ 1プロセス2GBで足りないってか?
結局、物理アドレス変換するんだから性能差なんて大差なかろう >>277
longモードってPAE必須なんだけど何を言ってるんだ?
amd64では拡張したPAE使ってんだけど。 > 64bitレジスタで高速化できる分野こそニッチじゃね
64bitになって、レジスタ数も倍増したのにほとんど高速化してないしな。
アプリによって数%速くなるだけ。 >> 293
> 64bitレジスタで高速化できる分野こそニッチじゃね
ちょっとアセンブラで組んでみるとわかるけど、32bitでは汎用レジスタが4本しかないので一時的に記憶
しておきたい値でもスタックに積まないといけないけど、そうするとPUSH/POPを頻繁に行わないといけなくなる。
繰り返し処理の中でこんなことをしていたら当然遅くなる。
64bitなら汎用レジスタが15本あるので、サブルーチン内で必要な一時変数を全部レジスタだけで
済ますこともできる。Cコンパイラなら汎用レジスタに一時変数を自動的に割り振ってくれるので、
同じ処理でもレジスタだけで処理できてしまう場合が多くなり、全体に速度が上がる。 >>314
アプリによるだろ
表計算ネット閲覧文字列処理くらいしかしない様なのには恩恵ないだろうけど
エンコレンダリングブルートフォースとか、64bitになるとえっらい速くなるぞ
レジスタの本数が増えただけじゃなくて、一時的に128bitの値のスケーリングとか
32bit時代は4つのintで騙し騙しスケーリングしてたのが、
2つの変数での自前の乗算除算で済む様になる RISCでコード書いたことあるなら分ると思うが32個レジスタあってもちょっししたコードでも瞬殺で使い尽くす。全く足りない。
しかし、今時のIntelのPush、Popのスループットは1clock、0.5clock。つまりL1データキャッシュ32KBがレジスタの代用として使えるレベル。
だから単純にレジスタ数を倍増してもわずかしか速度が上がらない。とっくの昔にPush/Popの遅さは隠蔽されてるから。 自動変数にアクセスする度にpushpopなんてしとらんぞ
32ビット時代ですらBPにSP入れて相対のアドレッシングで直接読み書き演算しとる 加算が1回とかメモリに対してやれば1clockでやってくれるが、
複雑な計算だとレジスタに移したほうが速くなる。 4本の汎用レジスタと2+1本のインデックスレジスタで事足りる用途じゃ早くならんが
複雑な計算し出したらx64の方が圧倒的に高速になる
ブラウザやらエクセルやらでx64速度上がらないとか言ってるようなのは何なんだろうな
4G以上使えるだけの32ビットCPUしか持ってない貧乏人が作れ作れわめいてるだけか? ieやexcelはポインタこねくりまわすから64bit幅アドレスがキャッシュを倍の早さで食い尽くす。
今のところ圧倒例がエンコだけ。x264で10%程度。
しかし時代はエンコードもデコードもハード、GPUの時代。
IntelはAltera買収したからさらにハードでの処理が加速する。 WPAのクラックとかBFとかレンダリングとか、他にもいっぱいあるだろ。
しかも全員が全員、コーダー積んでるハード持ってる訳じゃないんだぞ。
んなニッチなもん誰も作らんわ 自分で作れ 作れないなら諦めろ。 >>317
PUSH/POPの命令発行クロックが小さくても、外部メモリへの読み書きはレジスタ内の読み書きに比べはるかに遅い。
命令を発行してからバスを通って読み出し、またバスを通ってレジスタにデータを得るまでの経路も長い。
レジスタ内で処理できればバスは関係なくなるし、外部メモリのクロックの遅さにも影響されずに処理できる。
確かにL1キャッシュにデータが入っている間は遅延は少なくて済むが、32個のレジスタで足りないほど多くの
データを扱うとなればL1キャッシュから外れるものも出てくる。プログラムの規模が大きくなればなるほどキャッシュに
ヒットしない場合が出てくる。そうなれば途端に遅くなる。 pushpopもクロック数の横に+nとか書いてある筈
レジスタ類にしか影響しないオペコードとオペランドの組み合わせの場合は
理論値通りのクロックで命令が終了するけど、
メモリアクセスが発生するオペコードだったりオペランドがメモリを指してたりする場合は
L1〜L3ヒット/ミスヒットでnの数値はどんくらいとか、
メモリがSDRAMの場合はキャッシュのライン読み込み完了まではストールとか、
別のデータ書き込み中に更にライトバックになったら終わるまで動けんとか、
詳細に計算式とか備考欄に書いてある筈だぞ
pushpopは必ずメモリアクセスが発生するから、L1にヒットするから1クロックとか
簡単に見積もれる話じゃないし、そもそもヒットするからって条件が付く事自体がおかしい
読み込みしかしない訳じゃないぞ gdgd荒らしている様だが、要するに一生懸命「32bitでも64bitに対してそれほど
遅くない」ってだけで肝心のメリットが殆どないってのに、今さら誰が欲しがるかって。
下らないわ。 要するに
古事記<古いCPUでメモリいっぱいの旧型機に特化したビルドを俺様の為に作れ!
↑の為にx64否定、x86マンセーの嘘を垂れ流す
その他<うぜぇ
だろ 何が合理的か語る場で古事記だの作れだの馬鹿にも程があるな
-m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
反論できなくなると荒らすとか何もかもレベル低すぎるぞお前 ×「32bitでも64bitに対してそれほど 遅くない」
○「64bitでも32bitに対してそれほど 遅くない」 64bitは32bitに対して結構メモリ無駄にするけどな >>329
-m32通らないならamd64で動かすしかないんじゃないか?
てか今時i386入れたい理由って具体的になんだよ
俺も>>330に賛成だよ
CPUがアドレス32ビットレジスタ64ビットサポートしないなら普通に64でいい
多少でかくても困らんし、世間で騒いでる奴なんてそんなにいない 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ? -m32の意味も知らないのに賛成とか
ポインタが何かすら知らないんだろうな 64bitなんて街乗りしかしないのにエンジンだけバカでかくて燃費悪い車買うようなものだわな i386入れたい理由にも>>334にも答えない
ただの知ったかぶり貧乏学生と見た 仮想PC内でしか動かさんからショボい32bitOSぐらいが丁度いい。 山ほど理由があるんだろ?他には?>>334の答えは? さっきからなにに発狂してるか知らんがおれは別人だ。
おまえの妄想がハズレたからって絡むなよ。 教えてくん痛々しいな
人様への物の聞き方すら知らないとか救いようのないアホだな どうせ知ったかぶってるだけで、そんなもんないか、極一部のプリプロセッサ辺りの欠陥だろ
救いようのない知ったか学生失せろ > -m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
山ほど答えてみろ
> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ?
これに答えてやれ i386を排除しようとしてる奴はアホ。
そもそもamd64はx86を超互換性重視で作ったなんちゃって64bit。採用された経緯も知らんとか馬鹿杉。
おそらくコードも書かない社会を知らない学生だろう。 >答えてやれ
誰がお前みたいな礼儀知らずの知障に教えてやんだよw >>347
intelはIA-64に舵切ろうとしたのに、OpteronでAMDに先越されたから
慌ててintelが追従したんだろ
で、当時はAMDの皿とVIAやnForceのMBが飛ぶように売れてた
唯一AMDが輝いてた時期だ
>>348
教えてやらないんじゃないな、本当は滅多に存在しないから答えられないだけだ >>348
お前みたいな明らかな盆暗に説明したところで理解できるはずもないわ
対価でもよこせカス >>347
x86自体が糞なのはアセンブラが読める奴なら大半がわかっているだろう
それでも世の中はx86x64で動いている
おまえの下らない拘りなんて一般人は気にしない、動けばいい きっとゲーム機のCMでも見て64bitすげーみたいな浅はかなイメージしかないのだろう ×>>348
○>>349
アホな引用ばっかりするからミスったわ
お前と違って一度言われたことは記憶できるんでな
反論する能力がないからって無駄な引用やめろハゲ >>349
先を越されたんじゃない。MSがコード変更が面倒だからと互換性重視のamd64で行くと決めたのだ。
つまりMSがIA64で行くと言えば、amd64は市場から消えたアーキテクチャなのだ。
> CPUがアドレス32ビットレジスタ64ビットサポートしないなら普通に64でいい
> 多少でかくても困らんし、世間で騒いでる奴なんてそんなにいない
FreeBSDユーザの意見なんてこれっぽっちも影響力などないのだ。 >>354
MSが64bit版出したのはx64のCPUが広まって大分経った後だ
> -m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
本当は嘘だから一部の理由しか出てこない
> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ?
本当は滅多にないから答えられない
こういう事だろ
今更x86に戻りたいなんて奴殆どいねえ
消費者はx64選ぶだろ 頭の悪い奴ってのは言葉を作れないからすぐコピペに頼る
しかも連呼とか救いようのない頭の悪さ
とっとと対価でも払って教えてもらえよガイジ >>354,355
嘘はやめよう。
64bitのWindowsはAlphaからあった。
IteniumのWindowsもあった。
x86の64bit拡張を市場投入するのを
IntelはAMDよりも出遅れた。 >>351
糞と思ってるのはおまえの妄想で市場は技術者はRISCを糞と判断したのだ。
> それでも世の中はx86x64で動いている
これこそ妄想。スマホ使ってる奴はガラケーは絶滅したと思ってるが実際のシェアは10年かかってやっと半々なのだ。
学生で無知だから知らないんだろうが、x86資産は膨大で、且まだまだ健在だ。 >>355
じゃあ尼券コード書けよ
お得意の連呼で何度か書けばいつか対価で教えてくれる奴に当たるだろ >>357
64bitAlphaのNT4とNT5x64は全く別のアーキテクチャ。 >>357
それは全くの嘘。Intelの64bit拡張はMSがamd64でいくと決めた後。 >>357
その64bitじゃない・・・amd64の話をしてる
アスペは引っ込んでてくれよ話がややこしくなる
> -m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
本当は嘘だから一部の理由しか出てこない
> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ?
本当は滅多にないから答えられない
逃げるなよ
本当は口から出まかせで顔真っ赤なんだろ?
>>358
今やWin64bitは無数に出回ってる
x86x64の話から他のCPUの話に逃げるな >>363
顔真っ赤なのはお前だろ
教えてやるからとっとと尼券出せよ 逃げるな
> -m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
本当は嘘だから一部の理由しか出てこない
> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ?
本当は滅多にないから答えられない
こういう事だろ? 逃げてんのはお前だな
とっとと尼券出せや引用しかできないお猿さん >>363
今でもWin32bitも無数に出回ってる。16年前のXPですら未だに何億台も稼動しているのだ。いいかげん現実を認めろ。
何の影響力もないFreeBSD陣営はi386とamd64両方用意すればいいのだ。ガタガタ言うな。 逃げるな
> -m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
本当は嘘だから一部の理由しか出てこない
> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ?
本当は滅多にないから答えられない
こういう事だろ? 尼券で教えてくれるって言ってくれてんのに出さないとか
明らかに逃げてんのは連呼荒らしだわな >>367
それ出回ってるんじゃなくて、まだ残ってるってだけだよな
今更PC向けに32bitOS流通させようなんて企業あると思うか? >>369
しつけえよ乞食、逃げるな
> -m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
本当は嘘だから一部の理由しか出てこない
> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ?
本当は滅多にないから答えられない
こういう事だろ? >>374
乞食うぜえ、さっさと認めろよ知ったかぶり
> -m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
本当は嘘だから一部の理由しか出てこない
> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ?
本当は滅多にないから答えられない
こういう事だろ? >>375
お前みたいなゴキブリにタダで教えてやらねえっつてんだろ
救いようのないアホで超ウケルわ >>376
煽りしか返せない知ったかぶり、さっさと認めたらどうなんだ
> -m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
本当は嘘だから一部の理由しか出てこない
> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ?
本当は滅多にないから答えられない
こういう事だろ? >>377
とっとと尼券払って教えてもらえや知障ゴキブリ >>378
この流れになったr、もうお前の乞食的目的は達成できないぞ
> -m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
本当は嘘だから一部の理由しか出てこない
> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ?
本当は滅多にないから答えられない
こういう事だろ? >>370
それが一番重要なのだ。NT4システムが未だ残ってるのは何十億とかけて導入したシステムは易々とリプレースできない。
これはi386のFreeBSDサーバを使ったシステムでも同じこと。
i386排除厨は開発者の発想ではない。
古いからいらない、新しいほうがいいという、無責任、無思慮のガキんちょの発想。 >>379
とっとと尼券払って教えてもらえや知障ゴキブリ おまえらさ、FreeBSD全く関係ない話をここでする意味ないだろ。 >>380
未だにi386のって本当に動いてんのかね?
コンデンサまだ大丈夫なの?
空港のWin3.1とかは知ってるけど、ちょくちょく技術者の手を入れながら
別の機体に入れ替わってる筈だが >>382
知ってるけど、俺様専用i386の4G以上使えるの作れって乞食がウザいから叩いてるだけ >>383
最新CPUでi386OSを必要としているという意味すら分からんクソガキはすっこんでな >>384
荒らしのお前が一匹フルボッコにされてるだけだってそろそろ気づいたほうがいい >>385
Win3.1を必要としてるとこがある事くらい知ってるわ文盲
最新の機体で問題が出るから技術者の手が入るんだろ >>386
> -m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
本当は嘘だから一部の理由しか出てこない
> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ?
本当は滅多にないから答えられない
おまえこいつか? >>388
とっとと尼券払って教えてもらえや知障ゴキブリ >>387
クソガキすぎるぞお前
-m32の意味でも答えてみろや小坊 話がいつの間にかi386のみって話になってんな
既存のシステム動けばいいならそのままi386使えばいいよな
なんでi386で4G以上使えるのを今更必要とするんだ?って話だった筈だが? >>390
ttp://a4dosanddos.hatenablog.com/entry/2015/09/19/131052
で
> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ? >>391
騒いでいるのはそういう技術論を真面目にしたい訳じゃ無く
単に場を荒らしたいだけのちょっと精神を病んでる人だからね。
それに付き合う方も御同類さ。 URL出しただけで黙っちゃった・・・マジで>>394なんだな
> -m32通らないとか64CPUにi386入れたい理由なんて山ほどあるだろ
本当は嘘だから一部の理由しか出てこない
> 32bit gccでコンパイルに通って64bit gcc の -m32 に通らないコードって、どんなコードだ?
本当は滅多にないから答えられない
今更i386を改造して4G以上使える様になんて、誰もやらんわ >>395
とっとと尼券払って教えてもらえや知障ゴキブリ >>395
礼儀知らずのお前がダダこねてるガキ丸出しで連呼したところで
永久に教えてもらえることはないってまだ気づかないのか?
そんなことだからいつまでたってもど素人のアホなままなんだろ >>397
教えて貰う迄も無い
今更i386インスコする気はないから試さないけど、
32bit gccと64bit gcc -m32には、違いがあるにしても定義済みマクロだとか
細かい所程度で、殆ど差異はない >>392
まずは自分の言葉で話す能力から身に付けたほうがいいぞ
何ひとつ理解できてないのもバレバレでみっともないだけだしな >>399
>>302>>311辺りは俺だぞ
>>400
ttp://a4dosanddos.hatenablog.com/entry/2015/09/19/131052
この-m32でいいんだよな?違うのか? おまえ程度のものが思いつく32bit→64bitの解決策なんか設計者はとっくに思いついてると思うの 誰が32bit→64bitの解決策の話をしてるのかシランケド、
今更i386を改造して4G以上使える様になんて、誰もやらん
素直にバイトでもしてPC買い替えろ まだハードの話とOSの話をごっちゃにしてる学習能力ゼロのアホが居るのか >>403
実現できてねえから議論になってんだろタコ坊主 実現できてない欲しい物があるならどっかに金払って作って貰えよ
それで解決だろ 何が合理的か語る場で古事記だの作って貰えだの馬鹿にも程があるな
何度言われても覚えられないとか脳みそに虫湧いてんじゃねえのコイツ 64bitOSで32bitアプリ動かせばいいんでねーの? x64使えないCPUで4G以上乗せられるMBなんてE3xx0とかそんな時代限定だよな
現状x64で速度あがるってんで大きさは放置なんだから
後はCPUがメモリだけ32ビットのメモリモデルをサポートするのを祈るだけ
サポートせんだろうけど x64使えないCPUの話なんて誰ひとりとしてしてないのに突然どうした? >>337
> 64bitなんて街乗りしかしないのにエンジンだけバカでかくて燃費悪い車買うようなものだわな
こういう話って、8bit → 16bit移行期や16bit → 32bit移行期も同じような意見が繰り返し出たけど、
結局、歴史は古いものを残さず新しいものが生き残るようにできてんだよね。
32bit機はもう製造してないから中古で延命図るしかないし、時間の問題で消えてしまう。 >>404
誰もやらないというのはおまえの妄想、期待でしかない。
そもそもPAEは32bitCPUで4GB以上の物理メモリを扱うために作られた仕様で、amd64では必須機能となった。
今では32bitOSの多くがPAE必須である。 >>420
おまえの環境のintは64bitなのか?
64bitは人が扱う数字としてはでかすぎるんだよ。だから多くの環境でintは32bitで止まったんだよ。
おまえはもう少し社会で働け。歴史を知らなさ過ぎる。 ROMを知らないとか、組み込みは32bitとかド素人はROMってろよ。 >>420
マシンの話なんかしてないって何度言われも理解できないんだな
バカとかアホとか超越した知能障害だぞお前 位取り記数法は対数のオーダーの計算量の増加だから、滅多に使いそうにない大きな数を扱えるようにしといても、コストはそれほど発散しないんと違う? なるほど高速CPU売りつけたいCPUメーカ工作員が暴れてたってわけだな
意味もなくソケット互換性失わせて強引な儲け方してきたものの
特に日本ではPCIに拘る特殊事情のお陰で完全に裏目に出てるからな
あとは32bitOSより遅くなる64bitOS強要してみようってところか
i5とi7の違いなんてほとんどキャッシュの差だけだし滑稽だわ >>422
ばーか。32bitのintなんて小さいだろ。
頭悪いくせに書き込むなよ。 64bitになって遅くなるって、例えばどんなアプリだ?
実測値出そうぜ >>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のままコンパイルしとこう、というものぐさなことをする人が多いだけだと思う。
まあソースが山ほどあって直すのが面倒だという気持ちもわからなくはないが。 amd64はそもそもlongモードで32bitコードをそのまま動かすために作ったもの。
その仕様のおかげてMSはamd64を選んだ。
にもかかわらずFreeBSDユーザはそんなことどうでもいいのだ。
64bitOSは64bitコード使え、32bitOSは32bitコード使えだ。
なぜそんなアップルみたいな切捨てができるかというと継承するソフト資産が皆無だから。 >>430
真剣にILP64採用してるとしたら脳みそが足りない技術者。 >>429
キャッシュの小さなCeleron機でベンチ比較すれば顕著に出るだろうよ 画像フィルタの類で1〜4000000000の数値を2〜3999999999に
浮動小数点数を使わずに四捨五入で厳密に補正する事を考えてみようか
ans=(((val-1)*(3999999999-2))/(4000000000-1))+2
32bitしか扱わなくても64bitが使えるだけで一発で終わる様になる
マが確保する自動変数が32bitで間に合うかどうかだけが全てじゃない
32bitは小さいぞ >>433
計ろうぜ
ちなみにうちだとE3300機で32bitよりも64bitバイナリの方が速かった
ソースはKali linuxでのWPAキーのkey/secの表示だとか辞書の生成速度や
別パーティションのwinのaviutlでのエンコ速度 >>436
そのグラフの32bit4Gと64bit4Gを比べて言ってるの?
64bitGの方が若干早い項目多いし、64bit2Gがあったら青のバーがもっと短くなるんじゃない? >>431
あんたの考えをそのまま進めていくと、世の中に64bit PCしかなくなっても
ソフトだけは32bitで動き続けるという変な状況になる。
新規で作るソフトや、大きな改修をするソフト、頻繁に使うソフトはいずれ64bitをフルに使うように手直し
されていくはず。16 -> 32bitのときも同じことが起きて、古い16bitソフトはだんだんサポート外になったし。 別に変でもなんでもない
long long使えばOSが64bitコードに変換すればいいし、
128bitCPUが出ても特殊オプションなど使わせずにOSがすべて吸収すればいい >>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 i80386が出てしばらくはMS-DOSで16bitのコードを延々動かし続けてた
64bitのOSで32bitのアプリを動かそうと、x264のexeだけ64bitにしてエンコだけ高速にしようと
メーカーやユーザーの自由だろう >>440
それってポインタの定数の命令だけの話だよね?
64bit化したバイナリが一律32bitの倍のコードサイズになる訳じゃないぞ アセンブラ出力眺めてみた
64bitのイミディエイトのオペコードからのロードなんてループの外でしかやらんな
ループ突入前の1回、ポインタが4バイトから8バイトになって「遅い!」なんて体感できる奴はいないだろう
しかもamd64だとレジスタの本数増えてるからループの中でポインタをレジスタに云々なんて滅多に起きない
64bitが遅いってんならWinMacLinuxFreeBSD未だに一律32bitのままだった事だろう >>442
もちろんデータバスの差が顕著に出る例だ。
amd64が仮想メモリ空間、レジスタだけのなんちゃって64bit化である以上、
足回り、エンジンは同じままだということだ。 >>443
そもそもほとんどの64bit環境のコンパイラはintは32bitだ。
仕様上必要でないかぎりわざわざ64bit longなんて使わない。 主張がわからん
>>444みたいな顕著に出る例なんて>>443で、殆ど速度低下はないだろうし、
なんちゃって64bitだろうと64bitのレジスタ同士での演算は可能
そのなんちゃって64bitってのはなんちゃってじゃない64bitと何が違う?
32bitの数値しか使わなくても、乗算除算が必要になれば>>434で64bitの恩恵はあるだろ
今普及してるx64否定して何がしたい?目的は何だ? x86とamd64の技術的なメリットをデメリットを述べただけで、x64を否定したと感じるのは
おまえが、i386排除連呼してるカルト宗教だからだろう。 >>434
最近の画像はRGB各色32bitなのか? なんちゃって64bitってのはなんちゃってじゃない64bitと何が違う?
会話する気がないならamd64とi386どっちを使おうと個々の勝手だからもう黙ろうな
スレ違いもいいところだ >>448
動き補正だとかFFTだとかの計算内容知ってるか?
RGBの各値を四則演算でぼかせたノイズ消えただの喜んでる様な計算じゃ済まないんだぞ 何度も説明してるだろう。
これだけ説明して理解できないなら自分でamd64の仕様書読め。
それでも理解できない馬鹿なのだから諦めろ。 16bitのときもCP/Mを引きずり、32bitのときもDOSを引きずりという歴史を知っていれば
i386がいらないなんて話は出てこないはずなんだが。
32bit排除厨はおそらくマカーなのだろう。 http://ascii.jp/elem/000/000/641/641476/img.html
で明らかだな。
image manipulationは僅かに64bitが有利。だからここで勝負したいのだろう。
しかし、web browsingの圧倒的な差。
あたなの用途は2chですか? PhotoShopですか?
FreeBSD用のPhotshopはありませんけどね!! >>453
【Intel】OpenCV総合スレ 5画素目【画像処理】
ttp://mevius.2ch.net/test/read.cgi/tech/1382689696/
>>454-455
i386を排斥してる事にするなよ
ループの外でのポインタのイミディエイトのロードのオペランドが
4バイトから8バイトになった僅かな速度低下なんて誰も気にせんだろ
x64を過剰にディスって名無しや開発陣に何がさせたいんだよ >>456
ブラウザは64bitかどうかってよりOSの実装の問題じゃね?
64ビットと32ビットのモジュールの両方を使えるように検索しに行ってるとか 平均的な用途のベンチってつまりPC MARKでしょ。答えでてるじゃん。 ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
おまえらの大好きそうなOSSのベンチですら引っ張り出さずに64ビット遅いとか言っちゃうんだもんな
救いようがねえ > インストール済みのUbuntu 32bit版をUbuntu 64bit版へそのまま移行するような手段は提供されていないため
酷いな。普及しないはずだわ。 FreeBSDもLinuxも普及しない理由が分った。 > 最初から
ほんとこいつの脳みそは幼稚園児並だな。 なんでこんなに伸びてるの
FreeBSD来てるの? 俺様のしょぼい32bit機に最適なビルド作れってわめいてるのがいるだけ まだマシンの話してるとか思い込んでる知的障害ゴキが這いつくばってんのか >>465
張られたベンチはWinとlinuxだけ。もう分るな。
FreeBSDはベンチすらされない。つまりオワコン。 ウインなにがしみたいなインターネットを危険に陥れる脆弱性だらけのバグバグOSもどきは最初からオワコン
FreeBSDはサーバ用途 思い通りにならないとディスり始める
フリーウェア作者を奴隷か何かと勘違いしてるクレーマーと変わらん
>>460の通り、世は64ビットに移行しつつある
過去のものはi386で動かせ
Win95をMSに改良しろなんて言ったところで作らん i386でOSだけが64bit対応するのが合理的って話だろ
何度言われても飲み込めない盆暗だからCの基本すら理解できないんだろ 何も生み出せない奴ってのは崇拝することしかできないからな
頭が悪いものだから与えられたものに満足して思考停止に陥るわけだ
この手のキチガイがOSSを語るとか反吐が出るわ i386のままじゃ遅いバイナリが多いんだから合理的じゃないだろ i386のままのほうが速いバイナリが多い現実すら見ようとしないとか
救いようがないな ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
実測値のソース出せよ 日本語読めないのか?
>>1から100回読み直せ
それでも理解でなければお前はオワコン 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ワット程度の差がでています。 >>461
UNIX系最大派閥に躍り出たんだがubuntuは ttp://news.mynavi.jp/news/2013/07/29/120/
そのブログのソース、Phoronixのデータだぞ
更に付け加えると、PAEをONにするとアドレス変換のテーブルの参照が入ってパフォーマンスは若干落ちる 今時の32bitOSがPAE必須の理由さえ知らないとか、キミブロガー本人でしょ。 今時の32bitOSって何?w
具体的に名前とバージョンを挙げよう >>483
ところでさっきからおまえはなんでそういう幼稚園児みたないことばっか言ってんだ?
レベル低すぎるから話に入らないでROMってろよ。 >>483
むしろ、OSシェア順に上から順番に調べてPAEがいらないOSがあったら報告してくれ。
そしてキミのブログに調査結果を報告してくれ、現実が見えないブログ主さん。 >>483
おまえはもう引っ込んでろよ。どうせゆとり学生だろ。 i386に拘ってる貧乏人はUFOやらネッシーやら見たって言ってる嘘つきおじさんみたいだな
UFO見た事ない奴はROMってろ i386で動かしたいならi386で動かしてろ
どうせPAEが無くてもユーザランドのメモリ空間事情は変わらん
それでも4G以上使いたいならLinuxでも使え
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ワット程度の差がでています。 > どうせPAEが無くてもユーザランドのメモリ空間事情は変わらん
やはりこいつとんでもない無知だった。 PAE専用のAPIとか使い込むつもりか?64ビット化の時に困るぞ 32ビットの論理アドレス空間じゃ足りなくてPAE欲しいってんなら素直に64ビットで動かせば?
既存の32ビットの動かすだけなら既に動いてるんだからi386で動かせば?
64ビットの方がパフォーマンス出る事が多いのに何でごねてんの? ttps://ja.wikipedia.org/wiki/%E7%89%A9%E7%90%86%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E6%8B%A1%E5%BC%B5
必須な理由って何だよ
PAEがないi386機でもi386のバイナリは動くし、PAEがなくてもamd64機で動いてるだろ 64bitCPUなら事実上必須だけど、32bitって必須な理由って何だ? 64bitOSなら事実上必須だけど、32bitで必須な理由って何だ? > データ実行防止のため有効にされることがある。
そこに書いてあるじゃん。セキュリティのため。昔、散々言われたじゃん。
だから今ではwinでもubuntuでもPAE必須。まさか本気で知らないとか。 今度は必須の意味も分らないってか。まさに幼稚園児。 必須ならなんでPAEに対応してないFreeBSDのi386は動いてるんだよ 言いたくはないが、聞くなら仕方ない。答えよう。
FreeBSDは穴だらけのポンコツOSだから スタックオーバーフローだけを防げたところで安全になるって訳じゃないぞ
穴だらけなら使わない方がいい
Linux板にでもいっておいで スタックオーバーフローが防げるとか、大した機能じゃないし、
WinだってそれをONにすると動かなくなるコードあるぞ
全部に適用できる訳じゃない
システムのプロパティ→詳細設定タブ→パフォーマンス→データ実行防止タブ
詳細を表示しますのリンクでもクリック > 474 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 03:48:10.83
> i386のままのほうが速いバイナリが多い現実すら見ようとしないとか
> 救いようがないな
> 492 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 07:03:14.09
> PAE必須の理由を知らない馬鹿がいると聞いて
> 502 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 07:42:24.91
> 言いたくはないが、聞くなら仕方ない。答えよう。
> FreeBSDは穴だらけのポンコツOSだから
おまえは嘘が酷過ぎる > 474 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 03:48:10.83
> i386のままのほうが速いバイナリが多い現実すら見ようとしないとか
> 救いようがないな
> 492 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 07:03:14.09
> PAE必須の理由を知らない馬鹿がいると聞いて
> 502 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 07:42:24.91
> 言いたくはないが、聞くなら仕方ない。答えよう。
> FreeBSDは穴だらけのポンコツOSだから
永久保存 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ワット程度の差がでています。 相変わらずドモって言葉が出てこないキチガイがコピペ連投かよ
ここまで頭悪いと真っ当な日常生活送れてないだろ > i386のままのほうが速いバイナリが多い現実すら見ようとしないとか
> 救いようがないな
> PAE必須の理由を知らない馬鹿がいると聞いて
嘘を並べ立てて自分の都合のいい物を作らせようとする腐った根性に何の疑問も抱かないのか? フルボッコにされてることにすらマジで気づいてないのかコイツ
お前はその腐った頭に何の疑問も抱かないのか? >>429
64bitで設計してあるH/Wを32bitで動かそうとすると却って遅くなるってのはあるね。 >>458
↑
ねえ、これ何言ってんのか意味が分からんのだが?
ただのアフォなんだろうけど 確か最初のOpteronとか、32bitのコードの実行が10%か15%遅くなるんだっけ
今時のCPUも32bitのコードの実行は多少なりとも遅くなってるのかもね >>512
> i386のままのほうが速いバイナリが多い現実すら見ようとしないとか
嘘です
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
> PAE必須の理由を知らない馬鹿がいると聞いて
嘘です、64bit機でもPAEに対応してない32bitOSは動きます >>517
バカ披露してる暇があったら>>515に答えろよハゲ FreeBSDのi386にPAE実装して欲しいなら本家行ってくればいいのに
なんでここで次から次へと頓珍漢な事言って騒ぐの? とっくの昔に実装してるのにこいつ何頓珍漢なこと言ってんの? 対応してたんだ、知らなかった
で、問題は何?
> i386のままのほうが速いバイナリが多い現実すら見ようとしないとか
> PAE必須の理由を知らない馬鹿がいると聞いて
こんな嘘を垂れ流して何がしたい?目的は何? だれもFreeBSDについて語らないのにスレがのびてくよ。 >>522
バカ披露してる暇があったら>>515に答えろよゴキブリ >>524
おまえの主張はこれでいいの?
> i386のままのほうが速いバイナリが多い現実すら見ようとしないとか
> PAE必須の理由を知らない馬鹿がいると聞いて
主張か目的はっきりさせろよ
i386がPAE対応してるんだってよ、それでいいだろ? >>524
アドオンの設定みてるか?32bitと64bit両方対応のアドオンとかあるだろ
32bitのブラウザは32bitのアドオンしかないだろ
両方探しに行ったりしないだろ >>522
問題は無知なおまえが一人で暴れてること。 俺は
> i386のままのほうが速いバイナリが多い現実すら見ようとしないとか
これが嘘だと、64bitの方が早いバイナリの方が多い
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
> PAE必須の理由を知らない馬鹿がいると聞いて
これが嘘だと、昔のPAEに対応してない古いOSだって64bitCPUで4G以上メモリ積んでても動く
嘘をバラ撒くなといってるだけだ >>526
俺が書いたレスでもないのに知らねえよゴキブリ
お前の目的はFreeBSDの進化を止めてウインなにがしとかいうバグバグOSもどき売りつけることで
インターネットを危険に陥れてマッチポンプで儲けたいだけだろ
恥を知れ盆暗糞詐欺テロリスト営業 >>530
仮に別人だとして、>>527に答えた途端、レッテル貼り→罵倒のコンボか
おまえの場合、荒らすのが目的だろ 仮に(笑)
フルボッコにされて悔しがって荒らしてんのはお前一匹だろ >>530じゃなくて>>531だ
2ch.net見にくいな
.scみたいに戻してくれよ > 458 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 01:54:09.20
> >>456
> ブラウザは64bitかどうかってよりOSの実装の問題じゃね?
> 64ビットと32ビットのモジュールの両方を使えるように検索しに行ってるとか
”とか”と言った
断言はしていない そういや2ch.netはi386かamd64かどっちなんやろ 俺の目的は
> i386のままのほうが速いバイナリが多い現実すら見ようとしないとか
64bitの方が早いバイナリの方が多い
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
> PAE必須の理由を知らない馬鹿がいると聞いて
昔のPAEに対応してない古いOSだって64bitCPUで4G以上メモリ積んでても動く
嘘をバラ撒かせない事だ
おまえらの目的は何だよ?嘘バラ撒いてまで荒らす事か? >>535
> ブラウザは64bitかどうかってよりOSの実装の問題じゃね?
じゃあ、これについて説明しろよ 次はMMXとかの揚げ足取りが来るだろうから先に書いておく
ttp://echo.2ch.net/test/read.cgi/unix/1472042132/954
これと同じ様に単純なスケーリングで済む話じゃない
これは俺が書いた書き込みだ
例えばテンプレートマッチングの演算過程とかRGBの0〜0xffが3プレーン分ある訳じゃないからな
周波数空間で演算した結果を元に戻したら順位が入ってるんじゃなくて
どれだけ元の画像に近いかの値が入ってるんだからな >>539
> i386のままのほうが速いバイナリが多い現実すら見ようとしないとか
64bitの方が早いバイナリの方が多い
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
> PAE必須の理由を知らない馬鹿がいると聞いて
昔のPAEに対応してない古いOSだって64bitCPUで4G以上メモリ積んでても動く
どこに嘘がある、ソース出せ >>541
http://ascii.jp/elem/000/000/641/641476/img.html
何度も貼られてるのがなんで読めないの?
文盲なの?
お前が例に出してるのはこのグラフのvideo transcodingのことだろ
それで「64bitの方が早いバイナリの方が多い」とか寝言は寝て言えやガイジ >>543
都合のいいベンチだけ貼るな
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
大体エンコだとかKali linuxのairsnort-ngみたいなkey/secの値だとか見ても
64bitの方が遥かに高速だ
おまけにブラウザの速度なんてせいぜい1秒の表示が1.2秒程度になったところで
殆どの一般人は何とも思わん 思い出した
chrome 64bit 速度 でggr
ブラウザが64bitだと遅いとか、わざと64bitの方が遅いブラウザ選んだんじゃないか? >>544
エンコだって5096秒が5114秒になる程度の差だろうが
お前の解釈のほうがお前にとって都合がいいだけだろ
3秒でイライラすると言われているブラウザの表示で1.5秒が1.2秒になるってかなり大きいわ >>546
今やそんな小さな差じゃない
おまえが使ってるPCいつの時代のPCだよ?Exxxx以前のPCなのか? >>547
グラフを否定したいならasciiに言えカス なあなあ、なんかすごーく伸びてるけど
読むのメンドイから三行半でまとめてくれ >>548
ttp://www.phoronix.com/scan.php?page=article&item=ubuntu-1604-3264&num=3
これは否定できんだろ お前FreeBSDをデスクトップで使ってエンコとかしてるわけ? >>551
ttp://echo.2ch.net/test/read.cgi/unix/1472042132/954
詳しくは言わないけど、こういう事とか、OpenCVだとかでスタンドアロンで
ある程度ランダムな試験データ食わせてバグらないか耐久試験させたりしてる >>550
それ単位が書かれてないよな
アスキーと同じ結果を拡大してるだけじゃねえの >>553
Frames Per Second, More Is Better
とか書いてあるだろう
いい加減認めろよ、大抵64ビットの方が早えよ aircrack-ngで自宅の無線LANのWPAでもクラックしてみろ
32bitでなんてかったるくてやってられんぞ >>554
なんでエンコだけで大抵なんだよ
世の中FreeBSDは大抵エンコでしか使わないのかよ
いい加減、認めろよ、大抵32ビットの方が早えよ >>555
そこまで言うならクラックの詳細を64bitOSとの比較とともにうpしてもらおうか >>556
32bitが早いのってどれだよ
winのchromeでもphoronixのベンチでも32bitの方がおせえ >>557
Kali linux入れろ
key/secがリアルタイムに表示される エンコとか画像フィルタとかOpenCVとか今はGPU使うんだし言い訳にしか聞こえんわ。
PCmarkで負けた。これがすべて。64bitの優位性は4GB超のメモリを使うときだけ。 >>558
グラフを否定したいならasciiに言えカス
お前の妄想はイラナイ >>560
俺、自前の処理までGPUカツカツに使える様な、何でもできる、何でも知ってるエンジニアじゃねえし
てかテンプレートマッチングでGPU使うのか?
>>561
俺の妄想じゃない、Phoronixのベンチ結果だ >>562
データ満載で再インストールしたくない
light入れた時はこれ忘れんな
apt-get install rfkill
今kaliの備忘録引っ張り出してる、待て コケたらこれやれ
ifconfig wlan0 down
macchanger -m xx:xx:xx:xx:xx:xx wlan0
ifconfig wlan0 up
rfkill unblock all
# airmon-ng stop wlan0 # 必要なら停止させろ
# ifconfig wlan0mon down # モニタデバイスはwlan0じゃなくてwlan0monだ
macchanger -m xx:xx:xx:xx:xx:xx wlan0mon
macchanger -m xx:xx:xx:xx:xx:xx wlan0 # どっちかエラーになるが気にすんな
ifconfig wlan0 up
airmon-ng start wlan0
あとはairodump-ngでオプションと一緒にwlan0mon指定しろ
使い方がわからんならfern-wifi-cracker使え
python製のaircrack-ngのフロントエンドだ
簡単だろ? 話を戻すとi386OSとして64bit管理して必要に応じて変換する機能を否定する根拠にはならんわな
32bitでプロセス合計4GB超使えて-m32で通らないなんてこともなくなって、折衷的円満解決
これを否定するってんだから思考停止馬鹿かFreeBSDが進化すると困る連中の工作としか思えんな >>564
お前が言い出したことだろ
自分でケツ拭けないならクチバシ挟むな llvm32bitでコンパイルに通って、llvm64bit -m32通らないってどういう状況だよ? >>567
64bitの方が早いってのが信じられないならやれよ
俺は間違えて2016.1の32bit落として仕方なく32bitでやったけど以前より遅くて
64bitに戻して早くなったってのを経験したから64bitの方が遥かに速いと言った 64bit管理って事は32bitCPUで動かない32bitアプリの為のOSって事だろ?
誰得だよ >>571
それはない
3桁なんておかしいとすぐに気付いた >>572
32bitCPUなら64bit管理機能を使わなきゃいいだけのことだな 32bitCPUなら64bit管理機能って具体的に何だよ?
PAEでできねえのかよ? FreeBSDでPAE使ったらプロセス合計4GB超使えるって?
OSがdoubleやらを64bitコードに変換すればエンコとか限定的な用途も速くなるかもね PAE以外の64bit管理機能ってのは何だよ?誤魔化してないで会話しろよ 64ビット化って速度云々よりも利便性のためだよな
ちまちまファイルから読み込むよりも全体をメモリマップすれば面倒がなくなる ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
OpenSSLもaircrack-ngも相当早くなる ttps://www.aircrack-ng.org/
windowsのバイナリもある
UNIX機から吸い上げたダンプがあればWinの32bitと64bitの速度比較も一発 >>579
何度も書かれていることをお前が文盲だから理解できないだけだろ
OSが64bit、プロセスが32bitだ >>583
Windows64bit版でWIN32のexeしか実行できないバージョンって事?
Windows32bit版のPAE有効にしたバージョンと何が違う訳? 少し前のレスすら読めないお前は国語のお勉強しておいで OSの内部で64bit化して速くなるところってどんな処理だ? 32ビットのバイナリの方が速いんだったら、OSの内部も32ビットの方が速いんだろ?
言ってる事おかしいぞ 文盲のお前が言ってる事のほうがおかしい
とにかくお前とは会話が成立しないから出て逝ってくれ
これ以上は荒らし >>588
OSだけが64bitになると速くなって、アプリだけが32bitままだと速い訳? こいつが管理機能管理機能うるさいからFreeBSDのi386にPAEないのかと思ったんだけど
仮に64bitのバイナリ遅いと仮定して、OSを64bitに遅くして何がしたい訳?
矛盾だらけなんだよ お前、矛盾って言葉覚えて使ってみたかったのか?
バカまき散らしただけで残念でしたとさw >>590
矛盾とか本気で思ってるとしたらかなり頭が悪いことを自覚したほうがいい 仮に64bitのバイナリ遅いと仮定して、OSを64bitに遅くして何がしたい訳? OS64bitアプリ32bit
64bitは遅い → OS遅いアプリ速い → 素直に32bitOS使え
64bitは速い → OS速いアプリ遅い → 両方64bitでいいだろ >>549
気にする必要はない
>>>525
>> 夏の風物詩 速い遅いじゃなくて4GB超のメモリを使えて互換性維持が目的だと
何度言われても覚えられないのなアホだから >>596
今のi386のままで4G超のメモリ使えて互換性維持できるよな
下手にOS64bit化する必要ないよな OS64bitアプリ32bit
64bitは遅い → OS遅いアプリ速い → 素直に32bitOS使え
64bitは速い → OS速いアプリ遅い → 両方64bitでいいだろ
速い遅いじゃない → 素直に32bitOS使え じゃあ32ビット速い、64ビット遅いってのは何だったんだ 64bitのほうが速いとか嘘まき散らしてるお前がフルボッコにされてただけだろ >>600
嘘を撒き散らしてるのはおまえだ
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
OpenSSLもaircrack-ngも相当早くなる 馬鹿だからコイツまたループ
FreeBSDはエンコ以外に使い道はないというお前のエンコ環境晒してみろやクソガキ >>602
エンコだけじゃない
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
OpenSSLもaircrack-ngも相当早くなる
OS64bitアプリ32bitとか誰も喜ばん>>598
アホな事言ってんじゃねえよ >>599
何だったもクソもあらへん
それがOS64bitプロセス32bitに対する何らの否定根拠にもなっていない
否定する能力はお前には到底ないんだからくだらない難癖やめて諦めろ >>603
アホはお前一匹だと自覚したほうがいい
そのままオトナになったらお前一生ゴミクズだぞ そうだ、OS64bitアプリ32bitなんてバカな構成は諦めろ >>605
OS64bitアプリ32bitとか誰も喜ばん>>598
こんなゴミクズ構成思い付くお前は一生ゴミクズだな >>606
バカはお前一匹だと自覚したほうがいい
そのままオトナになったらお前一生ゴミクズだぞ OS64bitアプリ32bit
64bitは遅い → OS遅いアプリ速い → 素直に32bitOS使え
64bitは速い → OS速いアプリ遅い → 両方64bitでいいだろ
速い遅いじゃない → 素直に32bitOS使え
どの組み合わせでもOS64bitアプリ32bitに利点はない 結局否定できずにOS64bitプロセス32bit再論破 >>612
お前がi386で4GB超のメモリが使えて互換性維持できて嬉しくない理由を書けよ >>613
嬉しくないなんて一言も言った覚えはない
今のi386で4G超使えるならi386使えよ >>614
使えないから議論になってんだろ
真性はすっこんでろ >>615
i386はPAE対応してるんだろ?4G超使えるだろ >>616
じゃあお前PAEでプロセス合計4G超使ってみせろや >>617
それPAE対応してない機体で動くのかよ?互換性はどこいった?
32bitOSで1プロセスで4G超使いたいなら素直に64bitでいいだろ PAEの意味も理解してないタダのキチガイがわめいていただけだったとさ
==終了== ttps://ja.wikipedia.org/wiki/%E7%89%A9%E7%90%86%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E6%8B%A1%E5%BC%B5
PAEを使用した場合には、IA-32アーキテクチャのアドレスラインである32ビットを
36ビット以上のメモリ空間に拡張する。これにより、IA-32の標準では最大4GiBまでしか
使用できなかった物理メモリ空間を、最大64GiB以上使用できるようになる。
しかしながら、仮想アドレス空間は4GiBのままであり、ページテーブルのエントリを
32ビットから64ビットに拡張することによって物理メモリ空間にアクセスする事となる。
ページサイズは4KiBで、ページテーブルのサイズは1ページのままであるので、
ページテーブルのエントリの数が一段あたり1024から512になる。これを補うために、
PAEにおいては、4エントリを持ったページテーブルが最上位に1段追加される。 >>617
それってPAE専用ABI使わずに32bitOSの1プロセスで4G以上使いたいって意味? OS64bitアプリ32bit
64bitは遅い → OS遅いアプリ速い → 素直に32bitOS使え
64bitは速い → OS速いアプリ遅い → 両方64bitでいいだろ
速い遅いじゃない → 素直に32bitOS使え
どの組み合わせでもOS64bitアプリ32bitに利点はない
> しかしながら、仮想アドレス空間は4GiBのままであり、ページテーブルのエントリを
> 32ビットから64ビットに拡張することによって物理メモリ空間にアクセスする事となる。
PAE使ってもアドレス空間は4Gのまま
ページのエントリ書き換えてページングしない限り(PAEのシステムコール類を使用)
32bitOSでは与えられた4G以外の範囲にはアクセスできない(後方互換性なし) 1プロセスで4G以上なら64bit使うのが素直だろうけど
レガシーコードを含む複数プロセス合計で4G以上使いたいというニーズは少なくないわな OS64bitアプリ32bit
64bitは遅い → OS遅いアプリ速い →32bitOS使え
64bitは速い → OS速いアプリ遅い → 両方64bitでいいだろ
速い遅いじゃない → 32bitOS使え
32bitOS32bitアプリ互換1プロセス4G(3G)超えない → 32bitOS使え
32bitOS32bitアプリ互換1プロセス4G(3G)超える →
そのままじゃ無理 → 64bit化 or
32bitOSでPAE専用APIでEMSもどき(32bitPAE専用化)
PAEは32bitコードにとっての夢のアドレッシングを可能にする機能じゃない
どの組み合わせでもOS64bitアプリ32bitに利点はない おい真性の馬鹿、できるだろ?とか強気で来ておいてできねえんじゃねえかw
おい真性の盆暗、それを矛盾というんだ覚えたか? >>628
何ができないのかはっきりしろ
会話しろ OS64アプリ32って、アプリが32bitでもOSが64bitでPAEなら
1プロセス4G以上のメモリ空間を持てるとでも勘違いしたのか? 一連の32bitマンセーって、どうせ>>630で引っ込み付かなくて暴れてるだけだろ?
32bitコード専用64bitOSなんてどこも作らんだろ 馬鹿とか盆暗とか言われて涙目の3連投w
顔真っ赤にしちゃってみっともない 32bitより64bitのほうが速いとか鵜呑みにしてたバカさ加減が見事に剥がされて
ちっぽけなプライドで維持してきた精神が崩壊しちゃったんだろ >>630
スレに出てた言葉をくっつけてそれっぽく仕立ててみたの?
おまえ何ひとつ理解してないのがバレバレでかなーり痛いよ >>629
お前の馬鹿コピペでスレが掻き消されてるだけだろ
本当に本当に本当に馬鹿なんだなお前w >>635
「できるだろ?とか強気で来ておいてできねえ」みたいな事を言った事に仕立て上げたいだけだろ?
だから引用もできない 632 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 19:20:03.83
633 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 19:25:20.57
634 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 19:28:33.37
635 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 19:30:59.69 2chがi386で動いてると聞いてすっ飛んできますた
そりゃamd64じゃ効率悪い罠 OS64bitアプリ32bitとか言い出した知ったかぶりいい加減にしろよ
64bitは遅い → OS遅いアプリ速い →32bitOS使え
64bitは速い → OS速いアプリ遅い → 両方64bitでいいだろ
速い遅いじゃない → 32bitOS使え
32bitOS32bitアプリ互換1プロセス4G(3G)超えない → 32bitOS使え
32bitOS32bitアプリ互換1プロセス4G(3G)超える →
そのままじゃ無理 → 64bit化 or
32bitOSでPAE専用APIでEMSもどき(32bitPAE専用化)
PAEは32bitコードにとっての夢のアドレッシングを可能にする機能じゃない
どの組み合わせでもOS64bitアプリ32bitに利点はない こいつ完全論破されると悔しがってコピペで掻き消そうとするのがパターンだな
アホだからコレしかできない >>633
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
実測結果が物語ってる >>643
ねえねえアホってどんな気分?
生きててつらくない?
とりあえずアホってどんな気分か教えてよw >>642
間違ってると思うなら引用して指摘しろ
>>644
鏡に向かって聞いてみろ >>645
お前がブザマに悔しがってることだけはよくわかった >>646
レッテル貼りからの中傷にもなってない決め付け稚拙すぎ >>632で戻ってきたら
> OS64アプリ32って、アプリが32bitでもOSが64bitでPAEなら
> 1プロセス4G以上のメモリ空間を持てるとでも勘違いしたのか?
これで図星突かれて突然暴れ出したんだろ? >>648
>>648
何言ってんのか意味がわからない
具体的に説明してみろよ
お前ごときができるものならなw
風呂行くからはよしろ OSが64bitでPAEって言ちゃう馬鹿の説明
ちょっとだけ俺も聞いてみたくなったわw >>651
説明も何も、まんまだろ
> OS64アプリ32って、アプリが32bitでもOSが64bitでPAEなら
> 1プロセス4G以上のメモリ空間を持てるとでも勘違いしたのか?
おまえはこんなバカな勘違いしてたと考えれば、OS64bitアプリ32bitとか喚き散らす動機として筋が通る >OSが64bitでPAE
超ウケルよなーーーーwwwwwww >>653
「OSが64bitでPAE」
これだけでいいから説明してよボク OS64bitでアプリ32bitって言っちゃうくらいだからな
ウケルってか、呆れる いいか、64bitだとPAEビットは事実上常にONだ
OS64bitアプリ32bitとか言い出した知ったかぶりいい加減にしろよ
64bitは遅い → OS遅いアプリ速い →32bitOS使え
64bitは速い → OS速いアプリ遅い → 両方64bitでいいだろ
速い遅いじゃない → 32bitOS使え
32bitOS32bitアプリ互換1プロセス4G(3G)超えない → 32bitOS使え
32bitOS32bitアプリ互換1プロセス4G(3G)超える →
そのままじゃ無理 → 64bit化 or
32bitOSでPAE専用APIでEMSもどき(32bitPAE専用化)
PAEは32bitコードにとっての夢のアドレッシングを可能にする機能じゃない
どの組み合わせでもOS64bitアプリ32bitに利点はない >>658
アプリ32bitって多分お前しか言ってないと思うが、
知ったかぶりというよりプロセス32bitが合理的なのは確かだわな >>660
それ、サイズ的に合理的なだけで、速度的にもコールゲートの切り替え的にも
OS64bitプロセス32bitだと非合理的だよな? >>661
非合理的と思うなら根拠を示せよ
お前はコピペするだけで何ひとつ示せていない
doubleもポインタもプロセスも何も理解できなかった落ちこぼれのお前には無理だろうがな こいつ、OS64bitユーザーランドのプロセス32bit専用って>>310の前から延々言ってるけど、
1プロセス4G以上のメモリ空間を持てるとでも勘違いしたなら納得が行く お前、理系じゃないだろ?
それが根拠とか思ってるから何も身に付かなかったんだろ
諦めてドカタでもやったほうがいいと思うぞマジ >>664
残念ながら勘違いしてるのはお前一匹だけ >>666
ならOS64bitユーザーランドのプロセス32bit専用とか喚き出した動機は?
>>658 OS64bitユーザーランドのプロセス32bit専用とか喚き出した動機は? 一度書いたこと何度も何度もコピペし続けるのは馬鹿だけだからな
相手にする必要なし おまえは痛い所を突かれると煽って逃げるだけだろ
OS64bitユーザーランドのプロセス32bit専用とか喚き出した動機は? いいか、64bitだとPAEビットは事実上常にONだ
OS64bitアプリ32bitとか言い出した知ったかぶりいい加減にしろよ
64bitは遅い → OS遅いアプリ速い →32bitOS使え
64bitは速い → OS速いアプリ遅い → 両方64bitでいいだろ
速い遅いじゃない → 32bitOS使え
32bitOS32bitアプリ互換1プロセス4G(3G)超えない → 32bitOS使え
32bitOS32bitアプリ互換1プロセス4G(3G)超える →
そのままじゃ無理 → 64bit化 or
32bitOSでPAE専用APIでEMSもどき(32bitPAE専用化)
PAEは32bitコードにとっての夢のアドレッシングを可能にする機能じゃない
どの組み合わせでもOS64bitアプリ32bitに利点はない i386に64bitのコードとか入ってないだろ
誰も作ってないって事はOS64bitでi386とか意味がないと思っていい 指摘を煽ってるとか解釈するからいつまでたっても頭っ悪いままなんだろうな 世の中の動向が自分の価値観にできる奴って幸せなのかもよ
北朝鮮あたりから書き込んでたりしてな 674 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 20:35:00.82
675 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 20:35:52.96
俺はSoftalkWebで聞いてたけど、流石にこの貼り付き方はできんわw
指摘なら5W1Hはっきり、1レス内にまとめてみろ
OS64bitユーザーランドのプロセス32bit専用とか喚き出した動機は? 将軍様マンセー
与党マンセー
大企業マンセー
そういうキチガイなのだろう PAE使えるi386じゃダメで、OS64bitにしないとできないできない連呼してたのって、
OS64bitになれば1プロセス4G以上のメモリ空間を持てるとか勘違いしたからだろ? 訂正
PAE使えるi386じゃダメで、OS64bitにしないとできないできない連呼してたのって、
OS64bitになれば32bitの1プロセス4G以上のメモリ空間を持てるとか勘違いしたからだろ? >>681
相手すると飛び跳ねて嬉しがるからな
気色悪いったらありゃしない PAE使えるi386じゃダメで、OS64bitにしないとできないできない連呼してたのって、
OS64bitになれば32bitのプロセス1つ辺り4G以上のメモリ空間を持てるとか勘違いしたからだろ?
なんで答えない? >>436
Ubuntuだと386とx64では明らかにx64が早いと出てる。
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
Windowsの場合、古い32bit用ソフトを頑張って動かそうとして、64bit用に最適化してないだけだろう。 >>686
自演だと思ったんだ・・・そうだよな、おまえは自演してるから、他人もしてると思うんだろうな とにかくメモリバカぐいするプロセスうごかしたい普通のひとはx64いれとけということでいいのか。 >>688
コードによる
ポインタばかすか確保する様なおバカなコードは(ry ポインタばかすか確保する様なおバカなコードとやらをちょっと書いてみろよ >>685
アスキーのデータどおりじゃねーか。エンコ系は速い。これだけ。
それ見てすべて速いと思うならおまえはド素人。ここでレスするレベルじゃない。 >>692
> エンコ系は速い
速いならいいじゃないか。グラフィクス処理系が速ければ、ウィンドウ関係の表示やゲームなど全般に速くなるんだし。 GPU使えば終わる話。ほんとおまえはいつまでド素人馬鹿発言続ける気だ。 >>694
GPU使わずに速いなら低コストで済むんだからもっといいじゃないかw こいつ真性のアホだな。GPUついてないPCはない。使ったら何倍も速くなる。
何が低コストだよ。馬鹿にもほどがあるぞ。 >>696
バカはおまえ。CPUにGPU内蔵のものと別になってるものがあるだろ。
内蔵かそうでないかでコストは大きく変わってくる。バカにもほどがあるぞ。
メモリーは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 荒らしに構うのも荒らしだからな
テンプレに書いてあるぞ >>697
別になってるのは金出してもパワーアップしたい奴が追加してんだろ。ほんと馬鹿なのか。 64bit厨の特徴
・amd64の仕様を知らない
・アセンブラも分らない
・カーネルソースも読んだことがない
・ベンチ結果も読み取れない
・32bitを駆逐すべき敵だと思っている あれだろ、64bitCPUでメモリ1Gとか2Gとかしか積んでない骨董品しか持ってない俺の為に何とかしろって騒いでるんだろ? 64bitCPUで2GBメモリのBSDって・・・
それiPhoneや 32bit厨の特徴
・amd64の仕様を知らない
・アセンブラも分らない
・カーネルソースも読んだことがない
・ベンチ結果も読み取れない
・64bitを駆逐すべき敵だと思っている iPhoneは64bit化しました。メモリ2GBですけどね!!! iPhoneは32bit化すれば速くなるのにアホやな
ユーザのことより儲けることしか考えてない守銭奴企業丸出し
パナソニック顔負けだな 昔iPhone持ってたけどガッチガチな上にクソパスワードいちいちウザくて捨てたわ
回線契約解除してリセットしたら起動させなくするランサムウェア仕込んでるし
そもそもアップルは個人情報悪用企業で言わなきゃ不具合対応すら拒否するだろ
番号通知しないと電話取らないパナソニックもユーザより保身第一だけどな 何で4Gもメモリ積んでないようなスマホまで64bit化されていってるかわかってるか? >>716
昨日、PAEも知らなかった馬鹿だろ、おまえw > 何で4Gもメモリ積んでないようなスマホまで64bit化されていってるかわかってるか?
64bit厨は質問ばかりで自らは決して説明しないからすぐ分る。また無知がバレるからなw > いまどきのATOMですら64bit命令実行できる現在、PAEなんて必要あるか?
> どうせPAEが無くてもユーザランドのメモリ空間事情は変わらん
笑えるw 24時間以上貼り付いた後、12時間寝たのか・・・ご苦労なこった >>720
ttp://www.computingcompendium.com/p/arm-vs-intel-benchmarks.html
64bitの方が速いからに決まってるだろ 今時swap outなんてしないって
page out だよ >>723
まあ、今だと32bitか64bitかよりも、64bitマルチコアが当たり前だから
マルチコアでどれだけパフォーマンスが出るかのほうが重要だわな。 32bitでマルチコアなら64bitよりパフォーマンス出るわ
せめて-m32くらい満足に通せっつのな
やりたいことやってる奴ばかりで互換性にまで手が回らんのだろうがな 11でも/usr/local/lib32ないしもう切り捨てくさいな >>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を呼び出してると思ってるのか・・・?
思ってないから「思っているのか・・・?」って書いてあるんだろうが 言葉尻だけとらえて「思ってる」とか決め付けるなヴォケ氏ね > 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使ってるおれ最先端かっこいいみたいな
実は仕組みを何も知らない馬鹿でした。 >>846
根拠を示せない知ったかぶり32bit厨カコワルイ>>843 > 全プロセス合計4GB以上をi386で使えるってか?
> i386で全プロセス合計4GB以上使えるなんてどこに書いてあんだよ
どうみても64bit厨のレスだろ、これ。
x86、amd64の仕様知ってたらこんなアホな質問せず断言する。質問形式はいつも64bit厨だろ。
i386がPAE、nxbit実装してることすら知らなかったんだぞ、x64厨は。 >>848
そこのi386って、FreeBSD-11.1-RELEASE-i386-dvd1.isoのi386だろ
i80386の事じゃねえだろアスペ、いい加減にしろ >>848
下は知ったかぶり32bit厨の書き込みだな
> 808 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 01:27:05.50
> >>807
> i386で全プロセス合計4GB以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
i386で全プロセス合計4GB以上使える事を知らなかった32bit厨哀れ 今度は「プロセス32bit専用の64bitOSなんざ意味ねえ」の書き込みに
64bit厨のレッテルを貼って、自分の恥ずかしい書き込みの罪をなすり付け始めようってとこか > i386で全プロセス合計4GB以上使える事を知らなかった32bit厨
x86、amd64、PAEの仕様知ってる奴が知らないわけないだろ。
むしろPAEが何かを知らなかった、i386がPAEを実装してることすら知らなかった64bit厨以外考えられんレスだろ。 >>852
> 807 名前:名無しさん@お腹いっぱい。[sage] 投稿日: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
> > 使えるだろ
>
> それでも使えないってんならレポートしてこい
> 808 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 01:27:05.50
> >>807
> i386で全プロセス合計4GB以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
>>807は暗に使えると言っている
>>808は暗に使えると言っているレスを否定している > 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厨はRELEASE-i386で4GB以上使えないと断言している
>>808の主張
4GB以上使えるなんてどこにも書いてない→寝言
4GB以上使えない→寝言じゃない
32bit厨の主張と同じ
そして無知な知ったかぶり32bit厨は恐らく一匹 ID出ないからわからんだろうけど、>>719手前までの書き込み、恐らく全部別人だからな
64bit厨とか言って「プロセス32bit専用の64bitOS意味なし」の意味をねじ曲げるな >>853
おれ以外のレスをいくらおれに聞かれても知らんがな。
少なくともおれはずっとamd64、PAEの仕様を断言して書いてる。ハナから知ってるからな。
質問形式はいつも64bit厨だ。 >>856
うそこけ>>853 32bit厨も質問してるわ 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の方が合理的?速い?
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
ブラウザのベンチマークサイト
ttp://peacekeeper.futuremark.com/
寝言は寝て言え32bit厨の知ったかぶり無知どあほ能無し基地害 そろそろ32bit厨が取れる揚げ足がなくなってきたところ 64bit厨が論破されまくって警戒して質問しかしてこなくなった。 >>861
おまえみたいなkz32bit厨がどのレスで誰を論破したのか、安価くらい付けてみろ
>>843-844
32bit厨は嘘だらけで逃げ場が無くなって勝利宣言したり、
自分の恥ずかしい罪状を他人になすりつけるしかできなくなった 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以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
正解 → RELEASE-i386でPAE有効にすれば4GB以上使える
32bitの方が合理的?速い?
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
ブラウザのベンチマークサイト
ttp://peacekeeper.futuremark.com/
正解 → 64bitの方がサイズ微増のペナルティ以上にパフォーマンスが上がる
寝言は寝て言え32bit厨の知ったかぶり無知どあほ能無し基地害
くやしかったら1レス内でまとめてみろ >>862
まずはこれ。解説頼むわ。
> いまどきのATOMですら64bit命令実行できる現在、PAEなんて必要あるか?
> どうせPAEが無くてもユーザランドのメモリ空間事情は変わらん
> おまえ頑なにChrome64ビットの方が速いって事実を無視しようとしてるよな
> 64bitに加えて32bitの外部プラグインも検索したりして
> 外部プラグインを勝手にDLLにすり替えて嘘だって事にでっち上げたいだけだろ
> 64ビットプロセスから直接32ビットのプラグインのDLLを呼び出してると思ってるのか・・・?
> 全プロセス合計4GB以上をi386で使えるってか? >>864
文字列で検索して直後のレス読めアホ
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以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
正解 → RELEASE-i386でPAE有効にすれば4GB以上使える
32bitの方が合理的?速い?
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
ブラウザのベンチマークサイト
ttp://peacekeeper.futuremark.com/
正解 → 64bitの方がサイズ微増のペナルティ以上にパフォーマンスが上がる
寝言は寝て言え32bit厨の知ったかぶり無知どあほ能無し基地害
くやしかったら1レス内でまとめてみろ >>864
一部だけ抜き出して前後関係無視して揚げ足取ろうってか?
いい加減にしろ
一つ一つ追っていけば全部回答済みだろうが >>863
だからさ、それ論理的におかしいだろ。
x86、amd64、PAE、i386の仕様知ってるのに、
> 全プロセス合計4GB以上をi386で使えるってか?
なんてこと言うわけないだろ。それ以前のレスみても質問形式はいつも64bit厨じゃねーか。
i386のPAE実装を知らない人の発言。つまり、おまえの仲間のレスだろ、それ。仲間割れすんなよ。 >>867
> 789 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 01:09:12.08
> >>786
> 1プロセス4GB以下で全プロセス合計4GB以上 → i386使え
> プロセス合計4GB以上 → amd64使え
> 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
> 使えるだろ
それは明らかに無知で知ったかぶりなお前の書き込みだ
他人になすりつけるな >>868
他人のフリして32bit厨が全部論破した事にでっちあげるな >>870
論破どころか事実を突きつけられて論破宣言するしかなくなったのはみじめな32bit厨
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以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
正解 → RELEASE-i386でPAE有効にすれば4GB以上使える
32bitの方が合理的?速い?
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
ブラウザのベンチマークサイト
ttp://peacekeeper.futuremark.com/
正解 → 64bitの方がサイズ微増のペナルティ以上にパフォーマンスが上がる
寝言は寝て言え32bit厨の知ったかぶり無知どあほ能無し基地害
くやしかったら1レス内でまとめてみろ >>869
だいたい64bit厨はi386のnxbit実装全くしらなかったじゃないか。つまりソース全く見てないんだよ。
おれが知ってるのは当然としても、おまえらは絶対に知らないから絶対に断言しない、つまり質問形式なわけだ。
まさしくこれw
> 全プロセス合計4GB以上をi386で使えるってか? >>873
> 789 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 01:09:12.08
> >>786
> 1プロセス4GB以下で全プロセス合計4GB以上 → i386使え
> プロセス合計4GB以上 → amd64使え
> 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
> 使えるだろ
それは明らかに無知で知ったかぶりなお前の書き込みだ
他人になすりつけるな >>873
プロセス32bitのOS64bitなんて誰も要らんと言っている
なのに全プロセス合計4GB以上使えないから作れ作れ騒いでるのはおまえだけだ >>874
ここずっとamd64、PAEの仕様の解説してるのはおれ一人なのにおれのわけないだろ。
おまえが一度でもPAE、amd64の解説したことあんのか。アンカーつけてみろ。 >>876
>>620が全てだ
32bitプロセス専用64bitOSなんざ要らんと、お前以外がソース付きで解説してるわ >>875
しつこない。言ってないと言ってるだろう。 >>878
プロセス32bitのOS64bitなんてバカなものを考え付くのがそうそう居てたまるか 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以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
正解 → RELEASE-i386でPAE有効にすれば4GB以上使える
32bitの方が合理的?速い?
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
ブラウザのベンチマークサイト
ttp://peacekeeper.futuremark.com/
正解 → 64bitの方がサイズ微増のペナルティ以上にパフォーマンスが上がる
寝言は寝て言え32bit厨の知ったかぶり無知どあほ能無し基地害
くやしかったら1レス内でまとめてみろ >>877
ただの単発のwikipのコピペじゃねーか。
おれのレスを論破したおまえのPAE解説のアンカーつけろよ。 >>881
解説してるのはおまえだけじゃないと言っている
解説したかどうかと論破に何の因果関係がある? >>879
解説したはずだ。amd64はそもそもその目的で設計されたとな。
32bitコードを切捨てる設計ではなく共存する設計だ。だからMSが選んだとな。
おまえはいつも何の解説もなく歴史も知らず仕様も知らず全否定するだけ。恥を知れ。 32bit厨の嘘の主張
32bitは合理的、早い、i386のカーネルで全プロセス合計4G以上使えない
だから32bitプロセス専用64bitOS作れ
> 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以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
正解 → RELEASE-i386でPAE有効にすれば4GB以上使える
32bitの方が合理的?速い?
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
ブラウザのベンチマークサイト
ttp://peacekeeper.futuremark.com/
正解 → 64bitの方がサイズ微増のペナルティ以上にパフォーマンスが上がる
寝言は寝て言え32bit厨の知ったかぶり無知どあほ能無し基地害
くやしかったら1レス内でまとめてみろ >>884
お前こそ恥を知れ
解説しただけで何だってんだ >>882
おれのレスじゃないと何度言ったら分るのだ。真性の馬鹿なのか? >>884
仕様の解説なんざ>>620で十分だろ
>>887
仮に別人だとして目的はなんだよ?
暴れたって32bitプロセス専用64bitOSなんて誰も作らん >>887
> 867 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 09:32:55.86
> >>863
> だからさ、それ論理的におかしいだろ。
> x86、amd64、PAE、i386の仕様知ってるのに、
>
> > 全プロセス合計4GB以上をi386で使えるってか?
>
> なんてこと言うわけないだろ。それ以前のレスみても質問形式はいつも64bit厨じゃねーか。
> i386のPAE実装を知らない人の発言。つまり、おまえの仲間のレスだろ、それ。仲間割れすんなよ。
アンカー辿ってくとここだな?
>874 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 09:38:10.17
> >>873
> > 789 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/14(月) 01:09:12.08
> > >>786
> > 1プロセス4GB以下で全プロセス合計4GB以上 → i386使え
> > プロセス合計4GB以上 → amd64使え
>
> > 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
> > 使えるだろ
>
> それは明らかに無知で知ったかぶりなお前の書き込みだ
> 他人になすりつけるな
32bit厨確定 32bit厨の嘘の主張
32bitは合理的、早い、i386のカーネルで全プロセス合計4G以上使えない
だから32bitプロセス専用64bitOS作れ
> 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以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
正解 → RELEASE-i386でPAE有効にすれば4GB以上使える
32bitの方が合理的?速い?
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
ブラウザのベンチマークサイト
ttp://peacekeeper.futuremark.com/
正解 → 64bitの方がサイズ微増のペナルティ以上にパフォーマンスが上がる
寝言は寝て言え32bit厨の知ったかぶり無知どあほ能無し基地害
くやしかったら1レス内でまとめてみろ >>888
全く十分じゃない。それ読んでwikip引用した結論がこれだぜ。
> どうせPAEが無くてもユーザランドのメモリ空間事情は変わらん
セキュリティ上、nxbit使うときはPAE必須を知らなかった無知64bit厨。
で無知を指摘された反論がこれ。
> スタックオーバーフローだけを防げたところで安全になるって訳じゃないぞ
> 穴だらけなら使わない方がいい Linux板にでもいっておいで
> スタックオーバーフローが防げるとか、大した機能じゃないし、
今度はi386でnxbitが実装されてることすら知らなかった無知64bit厨。恥を知れと。 900超えてもこの流れなら次スレは一時的にID付けないか?
スレ立てする時一行目に
!extend:checked:verbose
とするとそのスレ全体でIDが表示されるようになる >>891
セキュリティ上とか勝手に言い訳増やし出すな
その後のおまえの捨て台詞
> 502 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2017/08/12(土) 07:42:24.91
> 言いたくはないが、聞くなら仕方ない。答えよう。
> FreeBSDは穴だらけのポンコツOSだから
なんでそんなポンコツOSにしがみついて、作れ作れ連呼してんの?バカなの? >>892
32bit厨いい加減にしろ
32bit厨の嘘の主張
32bitは合理的、早い、i386のカーネルで全プロセス合計4G以上使えない
だから32bitプロセス専用64bitOS作れ
> 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以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
正解 → RELEASE-i386でPAE有効にすれば4GB以上使える
32bitの方が合理的?速い?
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
ブラウザのベンチマークサイト
ttp://peacekeeper.futuremark.com/
正解 → 64bitの方がサイズ微増のペナルティ以上にパフォーマンスが上がる
寝言は寝て言え32bit厨の知ったかぶり無知どあほ能無し基地害
くやしかったら1レス内でまとめてみろ >>893
そもそも次スレに持ち越すなw
32bit vs 64bitスレでも立ててそっちでやれ >>894
おれは作れ作れなんて一言も言ってない。
PAEやnxbitが実装されてること知ってるのに言うわけがない。
いいかげん他人の言ったことでおれを批判するのはお門違い。 32bitだろうと64bitだろうとどうでもいい、他人をいいように扇動する為に嘘垂れ流すアホうぜえ
32bit厨の嘘の主張
32bitは合理的、早い、i386のカーネルで全プロセス合計4G以上使えない
だから32bitプロセス専用64bitOS作れ
> 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以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
正解 → RELEASE-i386でPAE有効にすれば4GB以上使える
32bitの方が合理的?速い?
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
ブラウザのベンチマークサイト
ttp://peacekeeper.futuremark.com/
正解 → 64bitの方がサイズ微増のペナルティ以上にパフォーマンスが上がる
寝言は寝て言え32bit厨の知ったかぶり無知どあほ能無し基地害 >>899
荒らしって論争をしたいんじゃなくて、ただ言いがかりをしたいだけだから
別スレ立ててもFreeBSDスレに居つくと思う
このスレの1-100はひと月半、さらに200まで二週間くらいの流れだから
一週間ほど荒らしがなければこれまで通りのスレ立てで構わないと思うけど War is Over. 64bit-boy Lose!! War is Over. 32bit-boy Lose!!
>>843-844 32bit厨の嘘の主張
32bitは合理的、早い、i386のカーネルで全プロセス合計4G以上使えない
だから32bitプロセス専用64bitOS作れ
答え → 自分で作れ
> 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以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
正解 → RELEASE-i386でPAE有効にすれば4GB以上使える
32bitの方が合理的?速い?
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
ブラウザのベンチマークサイト
ttp://peacekeeper.futuremark.com/
正解 → 64bitの方がサイズ微増のペナルティ以上にパフォーマンスが上がる
寝言は寝て言え32bit厨の知ったかぶり無知どあほ能無し基地害 相変わらず脳みそ空っぽ32bit厨のバカ丸出しコピペ荒らしが滑稽だな ああこのバカは32bit厨じゃなくて64bit厨っていうのか 内容に反論できないからコピペの一言で流そうとする32bit厨哀れ
32bit厨の嘘の主張
32bitは合理的、早い、i386のカーネルで全プロセス合計4G以上使えない
だから32bitプロセス専用64bitOS作れ
> 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以上使えるなんてどこに書いてあんだよ
> 寝言は寝て言えどあほ
正解 → RELEASE-i386でPAE有効にすれば4GB以上使える
32bitの方が合理的?速い?
ttps://kledgeb.blogspot.jp/2016/03/ubuntu-1604-20-ubuntu-32bitubuntu-64bit.html
ブラウザのベンチマークサイト
ttp://peacekeeper.futuremark.com/
正解 → 64bitの方がサイズ微増のペナルティ以上にパフォーマンスが上がる
寝言は寝て言え32bit厨の知ったかぶり無知どあほ能無し基地害 こんだけ賑わっててFreeBSDも安泰だな。
と思いました 夜中の駅前でおっさん二人が言い合いしてるだけじゃね? i386でプロセス合計4G以上使えるとか馬鹿まき散らしてる64bitマンセーの盆暗って、
HDD価格に右往左往スレでマーシャルマンセーしてるキチガイと同一人物だろ
あっちでもワッチョイ付ける目的で荒らしてるって言われてるな >>917
RELEASE-i386でPAEをONにしたカーネルにて、
3G以下のプロセス複数で全プロセス合計で4G以上のメモリを使えるかどうかを検査する方法
>>844 アホか。仮想メモリならPAEをOffにしても使えるわ。 >>919
「i386でプロセス合計4G以上使えるとか馬鹿まき散らしてる」
なら何が言いたい?
32bit速い、プロセス32bit専用64bitOS合理的とか言ってる奴らは
「3G以下のプロセス複数で全プロセス合計で4G以上のメモリを使えない」って
断言してるのを否定してるだけだぞ >>918
そんなこと知らない奴はこのスレに居ないと思われ
問題は実際にそれを試した奴がこのスレに居ないことだわ #vmstat
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr ad0 cd0 in sy cs us sy id
0 0 0 119M 4.8G 590 0 6 0 1196 4 0 0 27 3452 228 0 5 94
#top
last pid: 689; load averages: 0.38, 0.36, 0.17 up 0+00:02:48 21:31:15
21 processes: 2 running, 19 sleeping
CPU: % user, % nice, % system, % interrupt, % idle
Mem: 12M Active, 10M Inact, 30M Wired, 4332K Buf, 4951M Free
Swap:
PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
669 root 1 20 0 6800K 2952K ttyin 0:00 0.00% csh
674 root 1 20 0 13720K 6044K select 0:00 0.00% sshd
665 user 1 24 0 6800K 2968K pause 0:00 0.00% tcsh
657 root 1 21 0 6492K 2408K wait 0:00 0.00% login
668 user 1 20 0 6476K 2396K wait 0:00 0.00% su
677 user 1 20 0 13720K 6388K RUN 0:00 0.00% sshd
678 user 1 20 0 6800K 2984K pause 0:00 0.00% tcsh
416 root 1 20 0 5980K 1844K select 0:00 0.00% syslogd
689 user 1 20 0 7332K 2520K RUN 0:00 0.00% top
659 root 1 52 0 5964K 1748K ttyin 0:00 0.00% getty
664 root 1 52 0 5964K 1748K ttyin 0:00 0.00% getty
663 root 1 52 0 5964K 1748K ttyin 0:00 0.00% getty
662 root 1 52 0 5964K 1748K ttyin 0:00 0.00% getty
658 root 1 52 0 5964K 1748K ttyin 0:00 0.00% getty
661 root 1 52 0 5964K 1748K ttyin 0:00 0.00% getty
612 root 1 20 0 6012K 1940K nanslp 0:00 0.00% cron >>844じゃダメなのか?portsでもサンプルソースでも何でもいいぞ ssh経由でtop止めたから%の文字ぬけてんのか
疑うなら画像もうpするが >>844を5つ程並列に実行してよ
あとkldstatも >>926
5つは無理、余った4GBと割れた1GBのシングルチャネルで動かしてswap切ってるから 1G*4にカーネルで確実に4Gは超えてる
root@freebsd:/home/user # kldstat
Id Refs Address Size Name
1 4 0xc0200000 1843488 kernel
2 1 0xcac3e000 4000 uhid.ko makeoptions NO_MODULES=yes
が必須らしいからカーネル本体はでかい
conf/ の中に PAE ある筈だから自分で見てくれ
そこまでは知らん、ipfwじゃないんだよね
備忘録引っ張り出すからまってくれ ごめん、嘘吐いた
makeoptions NO_MODULES=yes
はもう見当たらない11.1RELEASE
root@freebsd:/home/user # kldload ipl
root@freebsd:/home/user # kldstat
Id Refs Address Size Name
1 6 0xc0200000 1843488 kernel
2 1 0xc6fff000 4000 uhid.ko
3 1 0xc70a6000 6c000 ipl.ko
root@freebsd:/home/user #
kldload iplの実行直後にエラー出力に
IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled
備忘録の通り実行してておかしいと思った
モジュール使えるわ ipf -Fa -Z -f /etc/ipf.rules 実行したらぶっ飛んだ
ちょっと待ってくれって言うか、遊ばせてくれ
ただ、これ、おまえらもやれるよな?
別に4G無くてもPAEカーネルで起動すりゃそんなに変わらないだろ? バカだった、ループバックまで全切断したらそりゃ飛ぶ
root@freebsd:/home/user # cat /etc/ipf.rules
block in quick on rl0(適当に) all
block out quick on rl0(適当に) all
pass in quick on lo0 all
pass out quick on lo0 all
↑を適当にblockとかpassとか変えたりして最低限の動作確認
ipf -Fa -Z -f /etc/ipf.rules
リセット
ipf -Fa
あとは自分でやってくれ 893だけどID表示の恒久化には消極的な反対
あとワッチョイ化したらスレを分裂させるから 俺がワッチョイ気にしなくても気にする人が多ければ反対
IDは最低でも次スレくらいは欲しい IPは嫌だけどワッチョイ程度は平気
一応その程度には発言に責任を持ってるつもりだし テンプレ改稿案だけどこんなんでいいかな?
ワッチョイ嫌なんで
!extend:checked:verbose
The FreeBSD Project
http://www.freebsd.org/ja/
次スレを立てる人は状況に応じてID表示を強制させて下さい
その場合はスレを立てる時、本文一行目に次の文を貼り付けます
!extend:checked:verbose
これ以外のBBS_SLIPコマンドは禁止
前スレ
FreeBSDを語れ Part44
http://mevius.2ch.net/test/read.cgi/unix/1496160953/
関連スレ
初心者もOK! FreeBSD質問スレッド その122
http://mevius.2ch.net/test/read.cgi/unix/1486758875/ ID表示は常にヤダとかワッチョイを常に付けろとか考えてる人の意見はないのかな? 俺はIP表示でなければ何でもいいよ
(固定IPアドレス環境から読み書きしてるので……それだけは勘弁) でさ、wnn8どうやってつかえばいい?
買って、すっかりわすれてたらFreeBSD版がでてて、もう。いまはjserverが無駄に動いてるのみ。 >>934
12GBはkstack allocation failedでブートできんかったけど、
2G+2Gまたは4G+4Gならブートして順調
real memory = 8589934592 (8192 MB)
avail memory = 8277651456 (7894 MB)
4Gで動いたって報告がなかったらメモリ抜いて試そうなんて発想にはならなかったよ
しばらく様子見て問題なければamd64使うことは一生なさそう >>944
容量多過ぎるとダメなのかな?うちではあっさり試験できる環境がなくて試すのはきついな・・・
1G引っこ抜いて1G*3と512M*1確保してみた
スワップないから更に確保しようとすると、追加の512確保しに行った時固まる
けど、全プロセス動いてるし、4Gきっかりも大丈夫そうに見える
user@freebsd:~ % ./a1G.out &
[1] 676
user@freebsd:~ % allocated
./a1G.out &
[2] 677
user@freebsd:~ % allocated
./a1G.out &
[3] 678
user@freebsd:~ % allocated
./a.out
allocated
vmstat
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr ad0 cd0 in sy cs us sy id
5 0 0 3.6G 349M 6810 0 2 0 1359 904 0 0 13 1490 169 55 13 32 ちなみにちゃんとmemsetし続けてるからfreはきっちり減ってる >>944
32bit厨は12GBあってもわざわざ余らせて使うんだねw
そういう無駄は気にならないらしい >>945
ramdisk6G作ってファイル注入してみたけどこれも問題なし
これで運用できそうなら今度、4G+4G+4G+4Gで試してみるよ
そのうちmevius鯖の人が64Gで試してくれるに違いない >>949
16G or 64G でi386動かすのか・・・股間が熱くなるな
楽しみにしてる 昔はFreeBSDユーザ > Linuxユーザだったのにな。ド素人しかいない。 なんとか煽ろうと必死こいてみたものの頭っ弱くてカスりもしない超絶空振りワロタ >>952
386の仕様すら知らないからゆとり世代だろう。 98でFreeBSD動かしてた人はそりゃレベル高かっただろうけど
ゆとり世代じゃハード側の知識なんて皆無だろうな。
デジタルネイティブだと自称してるけどROMとRAMの区別さえなければ、仮想メモリと物理メモリの区別さえない。
このスレ見ても64bitの意味すら分ってないまま速いと言ってる。すべてがバーチャルなんだよ。 >>955
10年ぐらい前の週刊アスキーとかライトの雑誌の64bitの説明が滅茶苦茶だったからな。
そもそも記者が理解してない。あれで勘違いした奴が大量にいた。
ここにいる奴らはそれよりさらに頓珍漢なこと言ってるからさらに若いと思う。夏休みの中高生だろう。 デシタルネイティブw なにそれw 機械語ペラペラなの?w おじさんもペラペラだよw 最近のゆとりはマカーの発想に近い。新しいものが正義。
いくらじじぃどもがiOS、OSXを邪悪なBSDと呼ぼうと、
BSDはAppleにコードを丸パクリされるだけの存在。
そしてただのパクリ企業を革新的だと連呼するゆとり。 セキュリティホールもたくさん報告してくれた。
ここまでBSDが低品質だとはユーザも思ってなかった。 パクられるだけとか言ってる人を時折見かけるな
BSDライセンスの条件下だということが理解できないのか >>961
AppleのOSにセキュリティホールがあれば同じホールがBSDにあるからな。 ロクでもないライセンスだよな
そりゃLinuxに高速で抜かれて大差つけられるわ 脆弱性だらけのiOSはアップルが取っ付けたゴミコードのバグが大半だろ >>960
昔、emドライバど安定だったはずだが、FreeBSD10に刺したらちょこまかdownするんだが? >>963
それはひょっとしてギャグで言ってるのか 昔からBSDのNICドライバはバグ持ち。
ショップにNIC故障で持ち込まれて、OS聞くとたいていFreeBSD。
Windowsで試すと普通に動くから原因切り分けに難儀してるのを何度か目撃した。 ID付きでスレ立てしようとしたけど
ERROR: 使えません。(BBS_USE_VIPQ=0)
と出て駄目だった
で普通に立てようとしたら規制されてたので誰か頼みます
FreeBSDを語れ Part45
The FreeBSD Project
http://www.freebsd.org/ja/
前スレ
FreeBSDを語れ Part44
http://mevius.2ch.net/test/read.cgi/unix/1496160953/
関連スレ
初心者もOK! FreeBSD質問スレッド その122
http://mevius.2ch.net/test/read.cgi/unix/1486758875/ amd64のせいだろうな
はよi386PAEに移行せな 32bitプロセッサが出たときは、まさか4GiB越えて実装なんて思いつかなかったがな。 当時は速度ならTTLが常識、みたいな風潮だったししゃーない
この先どこで物理的に頭打ちになるか次第だろうけど、128bit越えする頃には
「64bitプロセッサが出たときは、まさか2^128B超えて実装なんて思い付かなかったがな」
なんて、匿名掲示板に書き込まれる日が来ないとは言い切れない
仮にVRとかの詳細なワールド、モデル〜モーションまでのデータの類を
脳波入力で自由自在に設定→自動生成して、モデルが返すリアクションまでをも
抽象的な入力からAI用のリアクションを多数生成してメディアの中にぶっこむとしたら
それ位の容量は使うかも知れない・・・夢物語だがな! unix time 問題回避するには64bit化が楽だけど、それ以上は当面考えなくていいからなあ。 128bit CPUが出てきたら32bit厨はなんて言うんだろうね 32bitの整数じゃ地球上の全部の人間の数を数えるのにも
小細工が必要 不細工なのが取り柄のお前がド素人自慢とかみっともないからやめとけ 毎度赤っ恥かいてることにすら気づけないある意味幸せなボク
人様煽ってないで小細工とやらを頑張って説明してみなよ >>950
KVA_PAGES=768で4G+4G+2G+2G認識したっす
real memory = 12884901888 (12288 MB)
avail memory = 12497358848 (11918 MB) >>990
へし折れて1枚になった1Gお届けしてみたいわ
メモリの容量の関係とかじゃなくて、多過ぎる空き容量で周囲がコケてる可能性もあるのか 11ではemがNICとして出てこねー
存在は認識しているようだが不安定なものは使わせねえよって姿勢に感動した
em0: <Intel(R) PRO/1000 Legacy Network Connection 1.1.0> at device 0.0 on pci4 VMWareだとemじゃなかったっけ?
認識する時としない時があるってんならハードの問題じゃ? このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 79日 2時間 27分 15秒 2ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 2ちゃんねる専用ブラウザからの広告除去
★ 2ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.2ch.net/
▼ 浪人ログインはこちら ▼
https://login.2ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。