09/12/18 08:32:19 DHzcJH+R
気持ち悪いからさっさと死んでくれ
219:Socket774
09/12/18 11:23:31 O9VdWM88
integer unit間にはレジスタやTLB等をコピー・転送する同期インターフェイスがある
他のinterger unitのキャッシュも参照して同期を取る
ってな感じで、integer unit間はかなり密接につながってる
220:Socket774
09/12/18 12:32:15 NkXMiIQY
>>215
K8からK10に戻すことと、"Bulldozer"となんか関係あるの？
K8からK10に戻して何をどーするの？
221:Socket774
09/12/18 14:18:32 hd+ymEMW
パフォーマンスコアは1%の改良を積み上げるしかない時代だと思うがな。
222:Socket774
09/12/18 19:33:15 2YTj2uX0
むしろK10が妙に遅いのが不思議だよな。ブロック図や構造を見るとかなり贅沢で
速そうなんだけど。実際はCore2とさして変わらない。というかcore2の速さが不思議なのか。
やっぱ、バカ正直に作りすぎなんじゃないのかね？全ての命令をまんべんなく
速くする、っていう思想なんだよなAMDのCPUって。
それよりコンパイラがよく使う命令順序パターンに最適化したパス回路を組んで、
ある組み合わせで命令が並んでいた場合に高速に処理できる、みたいな
仕組みを入れたほうが、効果的なんじゃﾈｰﾉ
特に最内周ループだとコンペアして条件分岐とか殆ど入ってくるし。
223:Socket774
09/12/18 19:38:06 DHzcJH+R
そこで>28でしょ
224:Socket774
09/12/18 19:49:57 ndTS7Umq
>>196
どういう事？
>>219
デコーダ共有により、その同期ユニットを使って純粋なシングルスレッドではなく
似非シングルスレッドができるって事かな。
ピークパフォーマンスは参照+時間差命令発行によるペナルティを考慮すると
純粋なシングルスレッドには劣るんだろうな、多分。
こんな事するなら、パイプライン据え置きのコアをたくさん積んで
デコーダーを共有構成にした方が良かったんじゃないのかな
それとも一定量のジョブを定量的に送り、各コアをアイドルにさせず常時に近いビジー状態にもっていけるからなのかな
ピークになる時はそうそう無いとの記事インタビューだから、絶対値となるピークパワーを捨て平均値の底上げを狙った一物なんだろうか
それでも、Bulldozerからみた前世代になる筈のK10よりはシングルスレッドは上げてくるんだろうけど
225:Socket774
09/12/18 21:24:17 2iDdF5/z
URLﾘﾝｸ(www.brightsideofnews.com)
Intel then designed its compiler and libraries in or about 2003 to
generate software that runs slower on non-Intel x86 CPUs, such as
[AMD] Opteron. This decrease in the efficiency of Opteron and other
non-Intel x86 CPUs harmed competition in the relevant CPU markets.
This imposes a severe performance handicap for all non-Intel CPUs.
This would not be an issue if Intel's compilers were rarely used,
but Intel's compilers very often produce the fastest binaries, particularly
on Intel parts, so many performance sensitive applications use them."
Worse, a number of benchmarks exhibit performance boosts
if the CPUID vendor name string is changed to "GenuineIntel"
226:Socket774
09/12/18 22:09:22 w1KsIt5l
>>222
演算ユニットか潤沢な分スケジューラ・リザベーションユニットが貧弱で逆に
決まったパターンでしか速くならない。
逆にIntelはスケジューラが強力（集中管理型）でその分ユニットを巧みにケチっている。
どこかとどこかのGPUと設計思想が似てるな。
227:Socket774
09/12/18 23:01:50 BDqmeyK2
,,・´∀｀・,,）っ-○○○さんへ
あなたのHPはどこですか？
228:Socket774
09/12/18 23:15:47 KK2nw2KI
これじゃね？
URLﾘﾝｸ(www.google.co.jp)
URLﾘﾝｸ(www.google.co.jp)
229:Socket774
09/12/18 23:19:07 WDLOtZGl
>>226
微妙に嘘混じりの適当なことぶっこいているな。さすが。
230:Socket774
09/12/18 23:27:42 WDLOtZGl
>>225
つーか。意訳書いとけよ。訳して読むの面倒…。
よーはするに、Intel様ではないと性能が出ないコンパイラの話か。
ソフトの提供は昔からAMDが弱い部分として指摘されていた部分だな。
Intelのやったことは確かに酷い部分も含まれるが、
自社製コンパイラを他社製CPU使用時まで最適化させるのは、
開発費やその他諸々を考えると、致し方ない部分もあると思うんだが…。
そもそも他社製CPU時の完全動作検証を誰がやるんだ？
231:Socket774
09/12/18 23:36:28 w1KsIt5l
>>229
お前はアドレス生成ユニットが3つもあるのは何故だと思うね？
LSUの個数（2基）より多くしないといけないほどスケジューラが貧弱だからだよ。
232:Socket774
09/12/18 23:44:28 YKjXJfMw
>>230
URLﾘﾝｸ(www.4gamer.net)
> コンパイラを秘密裏に再設計し，AMD製プロセッサでパフォーマンスが
> 出ないよう仕向けたうえで，その事実を隠したまま「競合よりもIntel製プ
> ロセッサのほうが高速」と消費者に説明した
自社に有利なバイナリを吐かせるだけなら問題なかったんじゃないかな。
233:Socket774
09/12/18 23:45:02 BDqmeyK2
ほへ～
Second Garageの人だったのね
ちょっと納得
↓だんごさんへ↓
HPとか結構楽しんで読んでるんで
がんばってください
234:Socket774
09/12/19 00:00:55 gZLOPnT1
K8はデコードの段階でも依存関係の解消はしてるから
スケジューラだけ見て貧弱ってのもどうかと思う
235:,,・´∀｀・,,）っ-○○○
09/12/19 00:07:21 3i+jMY02
スケジューリングなんて簡単に乱れるよ。相手がキャッシュである以上。
236:Socket774
09/12/19 02:58:03 9Hw/adNg
逆に聞きたいんだけどintelが自社製コンパイラでAMD製CPUに最適化する義務(というか保証?)って
どこが担保してんの?
AMDが金払ってるのならいざ知らず、そうでないのならどんな結果出されても文句言えないと思うのだが
相手が巨大企業だと問題になるのかね…
無論intelのそういう小細工が精神的に汚いという点に於いては異論はない
でも汚いけどビジネスとしては正当化できると思う
237:Socket774
09/12/19 03:04:23 NdqIVbbn
AMDがうちのコンパイラではintelもAMD良い成績なのにintelのコンパイラは性能低いんじゃないですか？
って皮肉を言えばいいのにね。
238:Socket774
09/12/19 03:06:25 9Hw/adNg
それはカッコイイ
239:Socket774
09/12/19 03:29:13 MTNmnj8o
>>236
独占企業には何かと手かせ足かせが付くから仕方ない。
それも含めてビジネスだからな。
Intelが弱小なら相手が不利になることもある程度は容認される。
240:Socket774
09/12/19 03:35:09 wX5tcobB
詳細知らないから詳しい人いたら聞きたいが
そこを細工してもIntelCPUじゃ変化なし、AMD CPUだと遅くなる
Intelはこれをやっちゃったんじゃないの？
そこを最適化してもIntelCPUじゃ変化なし、AMD CPUだと速くなる
これをやる義務はIntelにはないと思うがなー
241:Socket774
09/12/19 03:41:51 msyNTOSJ
AMDのCPUを調べて、パフォーマンスが出ないようにわざわざ書き換えた
そうして得られた不正な性能評価を消費者への自社製品の宣伝に利用した
この辺がコンパイラ関連の問題点
誰も「AMDに最適化しないのはけしからん」などとは言っていない
242:Socket774
09/12/19 03:42:50 xDckNe18
何にしても言いがかりだろ
AMDに高速コード吐いてやる義理も義務もねー
243:Socket774
09/12/19 03:50:52 9Hw/adNg
>そこを細工してもIntelCPUじゃ変化なし、AMD CPUだと遅くなる
それをintelがやってはいけない理由が疑問という話なんだよ
AMD製CPUでもコンパイルが通るのは罠だと感じる
244:Socket774
09/12/19 03:53:37 msyNTOSJ
わざわざ遅くなるように書き換えたらまずいだろｗ
自動車会社がライバルの自動車を改造して性能を落として
「わが社のクルマと乗り比べてください」って言ってるようなもんだ
要は、詐欺
245:Socket774
09/12/19 04:01:14 /mz1h+0x
インテルのコンパイラはSSEの使用促進が目的で
当初AMDのCPUではコンパイル不可だったんだよ。
当然出来たバイナリは走るが。
AMDでコンパイル可なオプションが付いたのは10.0からだったかな。
インテル太っ腹じゃんと思って、おいらも有難く使わせていただいた。
246:Socket774
09/12/19 04:19:38 MTNmnj8o
>>243
> そこを細工してもIntelCPUじゃ変化なし、AMD CPUだと遅くなる
> それをintelがやってはいけない理由が疑問という話なんだよ
> AMD製CPUでもコンパイルが通るのは罠だと感じる
意図的に悪意を持ってやるのがダメだと言っている。
基本は自分の得になることは問題なし、相手の損になることは問題ありがルール。
AMDのCPUの特徴の理解は難しくないし、最適化の目安も難しくはないだろう。
パイプラインやデコーダやキャッシュとかの大まかな構造は公開されてるしね。
つまり意図しない限りは滅多に苦手なコードを生成することはないだろうということ。
247:Socket774
09/12/19 04:56:51 9Hw/adNg
どうやらSSE2を使うか使わないかでもめてるみたいだし
互換SSE上の動作は我々の保証によるものではないので除外した(ｷﾘｯ
とでもintelが発言してしまえばそれで終わってしまうじゃない
故意にウェイトを入れる的な、意図的な悪意のあるコードを入れてるわけではないようだ
実際にダメとなればAMD製CPUでの動作は出来ないようにするでやはり収束
結論
自己資本コンパイラが必要
248:Socket774
09/12/19 05:48:56 msyNTOSJ
除外するならするでそれをきちっと言わないとな
249:Socket774
09/12/19 05:59:37 HqXYjLrv
プリンタの互換カートリッジ封じってアメリカではダメなんだっけ？
250:Socket774
09/12/19 06:23:01 NdqIVbbn
>>248
（本当かどうかは知らんが）遅いとは言えAMDでも使えるコードを吐いてくれるとも言えるからな。
やはりAMDが両陣営の最適コードを吐けるコンパイラを作ってintelのコンパイラ開発技術のダメさを皮肉るのが一番いいと思うよ。
251:Socket774
09/12/19 10:25:10 E6GeZaRp
まあ仮にAMDがコンパイラを作って
わざとIntel製CPUで性能がでないようにして
比較広告したら、全然無問題だからな。
消費者が見抜けるかの問題。
iccなんて誰が見ても自社製品拡販のためのコンパイラなのにね。
他社のコンパイラメーカーに圧力かけて性能ださせないようにした
とかだったら問題だが。
252:Socket774
09/12/19 10:33:12 xEtC4M9/
>>247
「最適化」コンパイラだからな。
IntelがIntelチューンするのは当然。
逆に他社の互換命令まで面倒見なきゃいけない義務も義理も無い。
253:Socket774
09/12/19 11:17:28 w0iRktq8
もうAMDの手を離れてんだからどうでもいいことじゃないか
254:Socket774
09/12/19 13:05:41 QF0Fi6jf
> コンパイラを秘密裏に再設計し，AMD製プロセッサでパフォーマンスが
> 出ないよう仕向けたうえで，その事実を隠したまま「競合よりもIntel製プ
> ロセッサのほうが高速」と消費者に説明した
>>252
わざわざ遅くなるようにチューンして、宣伝に使ったら不味いでしょ。
255:Socket774
09/12/19 13:15:18 E6GeZaRp
iccで計測したと書いてあれば何の問題もない。
書いて無くてもあまり問題はない。よくある比較広告だよ。
256:Socket774
09/12/19 14:14:09 81Iu+BpR
>>252
今回の問題は「わざと遅くしていた」点が問題。
最適化は好きにしてくれてかまわない。
257:Socket774
09/12/19 14:15:09 81Iu+BpR
>>252
ついでに言うと「他社の互換命令」まで面倒観る義務もないが、
SSE2は「他社の互換命令」ではない。
258:Socket774
09/12/19 14:54:34 McUZ37R8
アルゴリズムがインテルに最適化されていて、インテルのCPUだと速いってんなら問題ない。
AMDのCPUを検出したらわざと遅くする仕掛けを入れるなら、
そのコンパイラは独禁法にかかるかも。
WINDOWSがFIREFOXを検出して、わざと遅くするような事したら大変な事になるよ。
259:Socket774
09/12/19 15:00:05 r9aGhV7D
シェアNo.1のIntelチップ向けに最適化されたコードを効率よく実行出来ないなら
互換チップメーカーなんか辞めてしまえ。
自分の会社のチップ向けに独自バイナリを作ってくれるところと商売をすればよい。
260:Socket774
09/12/19 15:02:55 UMBHpZVw
効率よく実効出来ない＝AMDのCPUを検知するとわざと遅くするよう細工する
261:Socket774
09/12/19 15:17:40 1qiMwDwd
>>258
つまり最初からintel CPUでの動作だけを保証して他社では動きませんとしてれば問題はなかったと。
たしかに他社製では遅くなるという警告なしで遅くなるようにしてたら問題にもなるわな。
262:Socket774
09/12/19 15:26:10 3qC7YVg3
>>259
だーかーらー…AMDがソフトウェアに力入れていないのも悪いし、
Intel製のコンパイラだから"Intel製CPU用に特化している"のは問題はないわけ。
Intel製CPUと他社製CPUで、最適化されたコードと他社CPUコードを吐くのも問題ない。
だけど「わざと遅くするコードを吐き出すのは問題だろ？」って話をしているんだよ。
263:Socket774
09/12/19 15:44:03 vK17cABW
x86コンパイラなんて、VC++とgccとiccの3強でしょ
Windows用の商用バイナリを作るのに限ればVC++とiccの2強
（VC++が圧倒的なのはともかく）
x86 CPUの2強の片方とコンパイラの2強の片方が同じ会社で
かつ「1つの会社であることが消費者にとってマイナス」ならそれを問題とし
分社すべきではないか検討するパターンがアメリカじゃない
icc部門が分社化して、AMD最適化オプションとか
AMDとIntelブレンドコードオプションとかついているのを出してくれたほうが
消費者的にうれしいわけだしょ
Bolandの転落を見る限り、コンパイラで食っていける可能性は低いけどさ
264:Socket774
09/12/19 15:46:26 Kc8jhZii
llvm頑張れェ…
265:Socket774
09/12/19 15:53:18 FWcXBU1a
ここにいる連中はAMDの陳述書すら読んでないバカ揃いなのかよ
INTEL以外のCPUを検知すると意図的に遅いコードを吐くってのがコンパイラ問題だっての
266:Socket774
09/12/19 16:12:04 +cjsUxx2
Intelの遣り方は「まずCPUを検出すると遅いコードを吐く」
「そこからIntelCPUだけ最適化させる」なんでしょ
そんなんだから会社もハードもソフトもバグだらけなんだよｗ
267:Socket774
09/12/19 16:21:12 UN9hKF/o
>>265
AMDは遅いコードと言ってるが実態は自動ベクトル化を等の最適化を行わないだけ
268:Socket774
09/12/19 16:31:57 Vs9GPWCA
>>267
AMDだけではなくて、FTCもその点は言及しているけどな。
269:Socket774
09/12/19 16:47:54 5hc9mcdm
>>255
>iccで計測したと書いてあれば何の問題もない。
俺もそれで終わりなネタだと思うけどね。
Intelが作ってるコンパイラを
Intelが秘密裏に（？）再設計して
AMD製プロセッサでパフォーマンスが出ないよう仕向けたところで
それはIntelの勝手。
文句があるならACC(AMD C++ Compiler)作れって話。
270:Socket774
09/12/19 16:54:54 UN9hKF/o
>>268
っで？
271:Socket774
09/12/19 16:57:50 X18TCFMS
AMDのCPUに最適化してくれないことがケシカランなのか？
AMDのCPUIDか何かを検知してWait命令のようなものを追加してるのか？
本質はどっち？
272:Socket774
09/12/19 17:14:57 Hz6nzWQW
普通に非ｉｎｔｅｌｃｐｕだとわざと遅くなるコード吐いてるのが問題の本質でしょ
そのことを明記していればそれでも問題なかったかも
273:Socket774
09/12/19 17:23:15 X18TCFMS
そのわざと遅くなるコードと言うのが、単に最適化されていなくて遅いのか余分な命令を追加しているのか？
どっちと言う話し。
274:Socket774
09/12/19 17:24:47 X18TCFMS
遅くなるようなコードと言うのは後者であり、前者の場合は遅いと言うよりは速くならないと言ったほうが良いと思う。
275:Socket774
09/12/19 17:24:52 6ZXWGuw+
>>269
インテルが弱小企業ならそれでもおｋ
276:Socket774
09/12/19 17:40:06 r9aGhV7D
そろそろ印象と憶測ではなく実際のコードを見て話すべき頃かと。
本家スラッシュドットあたりで検証されていないかい?
277:Socket774
09/12/19 17:57:20 +cjsUxx2
>>276
その辺不透明なままでここまで盛り上がる不思議
278:Socket774
09/12/19 18:19:41 LHtZ4dMu
両方持ってる奴がプログラム書くなり見つけるなりして比較すればええ
279:Socket774
09/12/19 18:48:32 FWcXBU1a
>>267
だから陳述書を読もうな
お前みたいなワナビーが「実態」とかヘソ茶で噴飯な妄想は良いから
280:Socket774
09/12/19 18:49:07 QBHpTbtV
>>273
コンパイル自体はどこのCPUでも普通にやる。
CPUIDでIntel製じゃないのが分かると
SSE使ったコードを吐かない、という事っぽい。
「遅くしてる」というより「速くしない」と言う方が正解。
281:Socket774
09/12/19 20:10:23 Y6c/Fb8Y
>>280
どっちを基準に取るかでその表現はどっちにでもなる。
インテル側はSSEを使わないことは「早くしない」だろうし、
AMD側から見れば意図的にSSEを使わないようにして「遅くしてる」となる。
が
> コンパイラを秘密裏に再設計し
再設計とあることから、今まではしっかりSSE使ってたものを、使わなくしてる
わけだから、「遅くしてる」と言うのが妥当だな。
282:Socket774
09/12/19 20:17:59 UN9hKF/o
SSE使う方が遅いCPUだってありうるわな
自社製以外は眼中に無かったで終了
283:Socket774
09/12/19 20:32:56 iLdJkbaJ
>>281
なるわけないだろ。
intelCPUではないという理由だけで存在する機能を使わせないコードを吐くのは
明らかにインチキ。
だったらintelもSSEを使わないコードで勝負するべき。
284:Socket774
09/12/19 20:37:49 UTOoG8fX
>283
言ってることがわけわかんねーんで日本語で頼む
285:Socket774
09/12/19 20:59:19 iLdJkbaJ
ニトロ入れる機能があるんだからどっちともニトロ入れて比べるか、
もしくはどっちともニトロ抜きで競走しろ
286:Socket774
09/12/19 20:59:59 E6GeZaRp
>>256
>今回の問題は「わざと遅くしていた」点が問題。
わざと遅くしてないぞ。PC Watchの記事の書き方が糞。
Intel純正かどうかを判別して純正以外では最適化をしなかっただけ。
純正品でもアーキテクチャは異なるし、他社の最適化なんてやってやる義理もないだろ。
記事書いてる奴のレベルそのものが低い。
287:Socket774
09/12/19 21:04:01 E6GeZaRp
そもそもSSEはなくても同じ計算が実行できる拡張機能なわけで、
他社製のCPUが同じ命令セットをサポートしているかどうかは完全にIntel純正コンパイラのサポート対象外。
サポートしていない互換品までむしろ面倒見ている方がむしろおかしい。
288:Socket774
09/12/19 21:12:17 rVKb8JMP
SSEはライセンスはIntelがAMDにライセンス供与しているから、
ライセンス料金が発生していたら、Intelのやり方は、
「金だけ奪い取って仕事をしなかった」事でもあるよな。
どこのやくざ企業だよ。
289:Socket774
09/12/19 21:18:33 E6GeZaRp
AMDのCPUでSSEの自動最適化を行う場合は、
AMDのCPUであることを確認し、
さらにSSEをサポートしている世代であることを確認し、
さらにその世代がどんなSSEユニットの構成仕様なのかに合わせた最適化をしなければならない。
従ってコンパイラがAMDのCPUについて既知じゃなきゃいけない。
ICCが勝手にSSEに最適化するっても、対象のCPUがIntel以外であれば何がベストなのかICCにはわかりようがない。
AMDがIntelに対して全ての情報を提供しているわけでもないのにIntelがAMDのCPUの内部を
詳細に知っていてベストな最適化ができるはずもない。もちろん競合だからしてやるだけ損。
そしてIntelからすればユーザが安全に自動最適化の効果を享受できるようにするなら、
Intel純正以外では最適化コードを実行できないことにするのがあたりまえの対策の一つ。
290:Socket774
09/12/19 21:20:40 E6GeZaRp
という単純な問題をうまく
コンピュータに無知な層を相手に騙して
利用しているのがAMDの法務サイドの戦略だと思うね。
Intelからすれば他社に合わせて純正コンパイラの拡張命令をサポートなんて土台無理な話なんだが。
291:Socket774
09/12/19 21:24:59 lN7er3pr
それを隠してが問題なんじゃね？
292:Socket774
09/12/19 21:25:08 gZLOPnT1
この話題って昔この噂が流れたときに散々やっただろ
ループしすぎ
293:Socket774
09/12/19 21:26:53 E6GeZaRp
ソフトウエアをかいたりハードでも製品開発したことあるやつなら
サードパーティの製品をサポートするということがどれだけ馬鹿で無謀な取り組みかは
理解できるはずだが。他社製品というのはサポートしようがないんだよ。
自社でもサポートの範囲は企画の段階で厳密に決めてメンテナンスしていくわけで。
まったく話がばかげている。
294:Socket774
09/12/19 21:27:53 QBHpTbtV
>ライセンス料金が発生していたら、Intelのやり方は、
>「金だけ奪い取って仕事をしなかった」事でもあるよな。
ワケ分からん。
仮にSSEにライセンス料があったとしてもそれは使用料であって
自社製コンパイラでAMDのCPUをサポート対象にするかは関係ないわけだが。
つかAMDもコンパイラ作ればいいじゃん
自社CPUだけガリガリに最適化するやつ
全くめんどくせえ。
295:Socket774
09/12/19 21:36:40 Y6c/Fb8Y
>>293
その場合は、動作保証対象外と明記すればいい。
そんなもので、性能比べてるから問題になってるんでしょ？
296:Socket774
09/12/19 21:43:27 E6GeZaRp
>>295
あのさ動作保証外なんて表記にはほとんど意味ないんだが。
わかってないやつがうける。
例えばAMD製のCPUで殆ど最適化コードの動作検証もしていないのに
たまたまバグやエラッタでICCでコンパイルしたSSEのコードをAMD製CPUでユーザが
動作保証外なのに勝手に実行したら、現実問題としてクレームになって
無駄なコストが発生するんだよ。
Intelは趣味で最適化コンパイラつくってるわけじゃないし、
AMD製CPUに対しては余計な不具合をださないことが先決なの。
というか企業の製品ってのはそういう考えの集合。
297:Socket774
09/12/19 21:45:53 E6GeZaRp
具体的に性能を比べていたっていうソースはあるのかねぇ…。
どうせある程度CPU事情を知っている側からするとお笑いレベルの言いがかりなんだろうけど。
298:Socket774
09/12/19 21:46:26 +cjsUxx2
Intel「AMDのほうが速くなってしまうエラッタが見付かったので潰して再設計しました」
299:Socket774
09/12/19 21:59:58 LHtZ4dMu
Intel以外のCPUを見つけると…
1,拡張命令を使わせない2,意図的に処理速度を下げる
1は言い訳できるけど、ここで問題になってる2はいかんでしょ～
思いのほかはやかったから細工したのか？
300:Socket774
09/12/19 22:01:47 iLdJkbaJ
どっちも言い訳できねーよ。
比較にならんじゃないか。
301:Socket774
09/12/19 22:02:04 OTs+bpNv
でも、今回のは独禁法絡みでの主張だから、intelとAMDが互角の状態なら問題ない行為が、
問題になるってことなんじゃないの？
この主張が法廷で認められるかはわからないが。
302:Socket774
09/12/19 22:08:32 kIPyuZLI
ともかく決着がついてから判断したほうがいいね
素人がどうこう言っても仕方ない
そんなことより早くブルドーザー出してくれないかなー
32nmプロセスのＣＰＵで1年遅れるのはやはり痛い
303:Socket774
09/12/19 22:30:49 FWcXBU1a
いつまで経っても「コンパイラが最適化しないだけ！」と強弁するワナビーが減らないようなので
AMDの訴状から引用しておくが
>（「CPUID」と呼ばれるコンピュータのマイクロプロセッサーの特定する機能を利用して，
>プログラムが起動された時にコード・パスが決定される。）
>その設計上，コード・パスが公平に作成されていないのである。プログラムが「Genuine Intel」の
>マイクロプロセッサーを検知した場合，プログラムは完全に最適化されたコード・パスを実行し，
>最高効率で稼動する。しかし，プログラムが「AuthenticAMD」のマイクロプロセッサーを検知した
>場合は，プログラムは別のコード・パスを実行し，プログラムのパフォーマンスを下げるか
>クラッシュを引き起こす。
これのどこが最適化してないだけなんだ？
304:Socket774
09/12/19 22:33:24 MTNmnj8o
MSですら他社のブラウザに配慮して平等に選択するようにしているのに、Intelときたら…。
何をやってもIntelはイチャモンつけられるくらいの独占企業だからな、
いい加減おとなしく従ってろボケと言いたい。
それと淫厨はいい加減ウザイからvsスレに篭ってろハゲ。
305:Socket774
09/12/19 22:34:22 E6GeZaRp
絶妙な文章で吹いたw
まさに自分の書いたことが内容は損ねずに、
全くそれが悪いものであるようにかかれているな。
306:Socket774
09/12/19 22:37:43 E6GeZaRp
>>303はよくよめばその通りの動作だよ。
CPUIDという機能をもちいて動作が保証できないCPUでは最適化コードをとばす必要があるんだ。
それをパフォーマンスの低下させるとか、クラッシュさせるとか表現は
ユーザサイドの主観から見た超解釈によるものだからな。
307:Socket774
09/12/19 22:40:39 UMBHpZVw
Intelだと使う、AMDだと使わないって場合でも相対的に性能に差はでるね
308:Socket774
09/12/19 22:42:17 F92XbU75
>>302
45nmでは15ヶ月くらいだったんだからこれでもまだマシ
309:Socket774
09/12/19 22:47:06 FWcXBU1a
>>306
いいかげんにしろこのキチガイ
310:Socket774
09/12/19 22:48:40 E6GeZaRp
まあここの馬鹿なアム厨達には理解できないだろうけど、
もう一度かいてあげよう。
IntelはAMDのCPUは知らないから、AMD向け最適化コードなんてものはそもそも生成しようとおもっても
できないんだよ。だから仕様がわかっていてどう最適化すればよいかもわかるIntel純正のCPU以外では、
殆どのx86で問題なく動く最適化のほとんど入っていないないコードを実行するか、
警告をはっするなりして抜けるしかないの。
>プログラムは完全に最適化されたコード・パスを実行し，
>最高効率で稼動する。しかし，プログラムが「AuthenticAMD」のマイクロプロセッサーを検知した
>場合は，プログラムは別のコード・パスを実行し，プログラムのパフォーマンスを下げるか
>クラッシュを引き起こす。
この文はIntelコンパイラが悪者であるかのようなトーンでかかれているけど、
内容だけをつみとればなるほどあたりまえのことだよ。
311:Socket774
09/12/19 22:50:42 E6GeZaRp
まあ5年、10年あとにわかってくれればいいや。
今までもそうやってAMDのスレの内容は改善してきたわけだし。
312:Socket774
09/12/19 22:50:56 pIpITatL
ここってVSスレですか？
313:Socket774
09/12/19 22:51:02 X18TCFMS
>>309
AMDが両陣営対応の最適コードを吐くコンパイラを開発すれば万事解決するしイニシアチブが取れると思わない？
314:Socket774
09/12/19 22:51:23 1qiMwDwd
つーかさ、AMDがCPUIDでGenuinIntel返すようにすればいいだけじゃね
315:Socket774
09/12/19 22:51:32 HWPlBSWa
AMDの次世代CPUについて語ろう
316:Socket774
09/12/19 22:53:22 E6GeZaRp
コンピュータをわかってない人たちをうまく騙す、
大嘘は書いてないっていう、
いかにもな面白い文章だな。
317:Socket774
09/12/19 22:54:06 FWcXBU1a
>>310はID:E6GeZaRpは真性キチガイのインテル信者かよ
まあキチガイに分かるかどうか定かではないが>>303を言い換えてやろう
あくまでも問題なのは「INTELじゃないとわざわざ遅くなったり不安定になるプログラムを吐くコンパイラ」であって
「INTELに最適化されたコードを吐くコンパイラ」ではない
キチガイワナビーの脳内では等価なのかもしれないが、世間一般では等価ではない
理解できるか？
真性キチガイに言っても無駄かもしれないが連投すんな
書きたいことは一回で書け
318:Socket774
09/12/19 22:54:16 SFJAr/cZ
その他社製品が動かなくてもインテル的には当たり前な状態で
製品比較してうちの方が優秀なのだ、って比較になってないし
なんかちょっとおかしくね？って話なんじゃないのかね。
319:Socket774
09/12/19 22:54:21 iLdJkbaJ
>>313
必要ないな。
AMDがAMDに最適コードを吐くコンパイラを開発すれば事足りるだろ。
インテル最適コードvsAMD最適コードで比べれば性能は一目瞭然だ。
320:Socket774
09/12/19 22:57:09 d1EHxmWS
>>298
むしろ普通にコンパイルしただけだとAMD CPUの方が早かったので、
腹いせに"プログラムのパフォーマンスを下げるかクラッシュを引き起こす"ような
プログラムをはき出すことによって、ようやくいまの性能差を引き出せたのかもしれない。
321:Socket774
09/12/19 22:59:29 X18TCFMS
よくわからないがAMDが自社の製品に対する最適化コンパイラを出してないのか？
322:Socket774
09/12/19 23:03:34 E6GeZaRp
各アーキで有効なコードをコンパイル時に複数生成しておく。
そして、実行時にCPUIDで判別してそのCPUに最適なコードへジャンプするようにする。
当たり前のことが書いてあるだけ。
つーか、一気にアム厨がわいて出てきたな。
323:Socket774
09/12/19 23:06:58 FWcXBU1a
INTELコンパイラを使うと「元のソースには存在しない」CPUIDチェックルーチンと
非INTEL環境だと遅く不安定になるコードが含まれるプログラムが生成されます
これがガチキチインテル信者(>>322=ID:E6GeZaRp)のフィルターを通すと「最適化してないだけ」となります
おそらく日付が変わっても、壊れたオルゴールのように同じことを叫び続けることでしょう
324:Socket774
09/12/19 23:07:00 pIpITatL
>>322
つ スレタイ
325:Socket774
09/12/19 23:08:10 E6GeZaRp
このスレの最古参級であるが
未だにこんなコテコテのアム厨達が生き残っているとは予想してなかったな。
大分レベルがあがって現実的になってきたとおもってたのに…。
>>324 Intelのスレもそうであるが、このスレも別にマンセーするスレではないんだが。
326:Socket774
09/12/19 23:08:36 +cjsUxx2
どこでも馬鹿にされる可哀想なﾃﾍ権田
327:Socket774
09/12/19 23:10:05 E6GeZaRp
>>323
>これがガチキチインテル信者(>>322=ID:E6GeZaRp)のフィルターを通すと「最適化してないだけ」となります
君のような無知・無能のお馬鹿くんが、最適化していないだけなのを誤解するようにわざとかかれてるんだが。
328:Socket774
09/12/19 23:11:54 FWcXBU1a
ID:E6GeZaRpはテヘゴンだと白状したので通常の措置を実施しました
327 名前： あぼ～ん [あぼ～ん] 投稿日： あぼ～ん
あぼ～ん
329:Socket774
09/12/19 23:13:15 E6GeZaRp
ああ厨スレから
馬鹿が大量流入しているのか。
なるほどどおりでいきなり馬鹿度があがったきがしたぞ。
馬鹿がうつるからこっちくんなw
330:Socket774
09/12/19 23:17:12 pIpITatL
ﾃﾍはもっさりスレに帰りなさい
331:Socket774
09/12/19 23:18:29 MTNmnj8o
>>321
どうせどこも使わないから、MSやPGIに実機と情報渡して最適化させてるだけだと思う。
332:Socket774
09/12/19 23:37:48 W0d987ko
SSEが有効なCPUならSSEを使うようにすれば良かったのに、
CPUの名前だけで分けたのがまずいんじゃないの？
CPUにSSEが有効なbitが立っているかだけ確認してSSE使用の有無を決めるのでは無くて、
CPUの製造元で判断するのがおかしいと言う。
以前どこかでCPUの製造元をIntelに変えたら性能が上がった(SSE等の命令が使われるようになった)と言うのを見たことがあるから、
CPUの製造元を見てからSSE等の判断をしていたのだろう。
333:Socket774
09/12/19 23:53:27 msyNTOSJ
まあほんとに「最適化してない」程度なら世界中の公取が動いたりしないわけでｗ
インテルに最適化したコードでいいから普通に使わせろ
意図的に使わせないようにしといて性能比較とかふざけんな
ってことでしょ
334:Socket774
09/12/20 00:03:02 LHtZ4dMu
CPUIDで判断してんなら拡張命令とか関係なくね
最適化がどうとかちゃんちゃらおかしくね
335:Socket774
09/12/20 00:42:51 gJEgO+pg
自分にチューンが悪いんじゃなくて相手にデチューンが悪い
という話を曲解してまでインテル擁護するのはどうかと。
336:232
09/12/20 01:12:34 SdCZZrWx
>>314
それ、やったらまずくね？ｗ
自分は、どちらかというと
iccが出力するコードは、普遍的なCPU性能を測るのには適しませんよ。
特殊な条件下での出来事を、普遍的なことのように錯誤させたらダメですからね。
ということが論点なんだろうと思ってたけど、よく分からなくなってきた。
337:Socket774
09/12/20 01:21:34 GPDO+Uzn
その相手にデチューンという話が個人で割れてる印象
もちろんAMDやintelの間でも
intel曰く互換CPUの互換命令にまで最適化する必要はない
AMD曰くSSE2使ったコード吐けよおらぁぁぁぁぁ
要らないwaitやら故意にクラッシュを引き起こすコードなんてすぐにでも
ソースとして引用できそうなものだけど上がらないね
これをAMDが証拠としてきちんと提出すべき
338:Socket774
09/12/20 01:24:16 9INdnQEo
なんで和解した現在、AMDが証拠を広布せにゃならんのかね
アホだろ貴様
339:Socket774
09/12/20 01:27:20 55133RIL
抽出 ID:E6GeZaRp (18回)
340:Socket774
09/12/20 01:36:12 GPDO+Uzn
あぁそうか、FTCが提訴という前提を忘れてた
悪意のあるコードが上がると良いね
341:Socket774
09/12/20 01:40:50 X02A7bXq
URLﾘﾝｸ(yro.slashdot.org)
金を取ってる商品の割には頭の悪いコードだが、
サポート対象外のチップ向けにgenericに書いていると言われればそれまで。
誰も悪意は証明できまいよ。
342:Socket774
09/12/20 01:43:39 GPDO+Uzn
いやさすがにwaitやらは悪意があるだろう…
クラッシュを引き起こすと主張するに値するコードにも興味がある
343:Socket774
09/12/20 01:53:10 X02A7bXq
waitとかクラッシュ云々は妄想じゃないの?
ソースきぼんぬ。
344:Socket774
09/12/20 01:54:57 buw2TH6j
>>331
intel謹製コンパイラが問題だという以上、つかわなくったって出すべきだと思うんだけどな。
345:Socket774
09/12/20 02:08:09 gJEgO+pg
iccって今時 rep movsdなんてコードを吐くのか。
プリフィックスつきループ命令使うよりコンペアブランチの
ほうが早いはずなんだがな。
346:Socket774
09/12/20 02:11:07 clYNpsbw
SSEあるかどうかもわからん他社のCPUに
SSEコード実行させるほうがおかしいだろw
故意に最適化してないってのは最適化コード動作させられる
保証がないからだろ。
347:Socket774
09/12/20 02:12:06 clYNpsbw
>>345
iccはキャッシュサイズなどを重視して最適化するから
目先の所要クロックとかで判断しちゃいかんよ。
348:Socket774
09/12/20 02:15:06 gJEgO+pg
rep プリフィックスつきループ命令ははキャッシュサイズに
関係ありませんから。
いってみれば旧世代のCISC命令で、デコードと実行に時間
がかかる。x86アセンブラで書くならほとんど使わないよ。
349:Socket774
09/12/20 02:18:11 clYNpsbw
Pentium III向けにも同じコードを吐くようだから
特に他社を意識したわけじゃなさそうだな。Pentium 4向けには最適化したようだが。
350:Socket774
09/12/20 02:22:28 clYNpsbw
>>348
ぶっちゃけ今時前後のコードをみていかないと何が最適かはわからん。
iccの全力よりも常に早いコードを書けるというやつが実際に
証明しながら論じるなら説得力があるが、いままでに
2ちゃんねるでそんなやつは見たことがないからな。
351:Socket774
09/12/20 02:30:57 clYNpsbw
結局のところ、
別の会社のコンパイラに他社のCPUで性能がでないように
圧力をかけた、とかでないかぎりあくまでも自社のコンパイラで
どう作ろうが自由なんだよな。
論点は比較の方だと思う。
会社で開発とかやってりゃ、他社を助けるようなものは排除する
って考えは当たり前にやることだし。
352:Socket774
09/12/20 02:35:43 NZqdpCLc
>>345
シンプルな命令の組み合わせの方が速かったのは初代 pentium のみ
pentium pro 以降は素直に便利な命令を使ったほうが速くなるよ
レジスタの消費を抑えやすい点でも有利だし
>>348
rep 系の命令は専用の回路があったりするから速いこと多いよ
一度デコードしてしまえばループが終わるまでデコーダに負担かけずに
実行し続けられるから
353:Socket774
09/12/20 02:47:04 9INdnQEo
連投してインテル擁護してるところを見るにID:clYNpsbwはテヘだな
354:Socket774
09/12/20 02:48:20 clYNpsbw
テヘじゃないよ。
信者の脳内ではインテル擁護すればみんなテヘなの?
355:Socket774
09/12/20 02:50:35 dWylhE6S
>>351
だったらそもそもAMDだと動かないか、動くにしても警告でも出す
ようにすれば筋が通るんじゃない？
356:Socket774
09/12/20 02:50:37 9INdnQEo
いやテヘだろ
1回で書けないまとまりのない脳構造だし
357:Socket774
09/12/20 02:52:24 clYNpsbw
>だったらそもそもAMDだと動かないか、動くにしても警告でも出す
>ようにすれば筋が通るんじゃない？
それもいいが、
それはそれで故意に動かさないようにしたとかいわれるの必至だろw
これでもいれわてんのに。
358:Socket774
09/12/20 02:54:48 Jadok6OA
AMDが最適コンパイラ出せばいいのにね。
359:Socket774
09/12/20 02:54:57 clYNpsbw
2言目にはテヘとかいう妄想馬鹿はいい加減AMDスレから消えてくれないか?
脳内テヘと一人で闘ってろよ。書き込みすんな、クズが。
360:Socket774
09/12/20 03:04:50 dWylhE6S
>>357
これでも、というかどう考えても今の状態の方が悪質でしょ。
361:Socket774
09/12/20 03:12:16 28rPprP0
pen4は特性上repを好んで多用する
phenomでは、ブロックサイズがpage-size～half of L1ならrep使え、ってことになってるな
362:Socket774
09/12/20 04:06:41 hBB2TKaA
>>332
> CPUにSSEが有効なbitが立っているかだけ確認してSSE使用の有無を決めるのでは無くて、
> CPUの製造元で判断するのがおかしいと言う。
そもそもCPUID命令は仕様上、製造元固有の実装という事になっている。
CPUIDの機能ビットでSSEの有無を判断する場合は、
その前に必ずCPUIDが返すベンダーストリングが
"GenuineIntel"であることを確認する必要がある。
ベンダーを識別せずにCPUIDの機能ビットを利用する事は仕様違反。
363:Socket774
09/12/20 04:20:23 GPDO+Uzn
クラッシュ云々は上の方で出てた訴状の内容の主張ですね
waitに関しては妄想かも
スレッド間の同期のためのものだとしたら笑い話だけど
ネット探索してたらAMD製CPUでもgccでコンパイルした物より
iccでコンパイルした物の方が早かったなんて例も報告されてるみたい
intelと同等に最適化しないと今後も同じ流れが繰り返されるんじゃないかな
少なくともこのスレでは
364:Socket774
09/12/20 04:24:05 RmT2YTc2
まずベンダーを識別してもいいが、それはあくまでベンダー名の識別であって
機能の実装をそこで判断するのは仕様に則った判別方法なの？
もしそれがOKだとしたらSSEのビットなんて最初からいらないでしょｗ
365:Socket774
09/12/20 07:49:18 OfF3uNVF
和解したから
良いじゃないどちらでも
AMDもインテルも納得してんだろ
366:Socket774
09/12/20 08:23:09 hBJ92r5O
GMPで円周率を計算すればよろしい
367:Socket774
09/12/20 08:26:20 NXkZ4ZSN
つーかチップセットで閉め出されたNVIDIAが腹いせになんか要らん事言ったんじゃねー過？
368:Socket774
09/12/20 08:39:47 Vd9HABwc
訴訟のことはもういいやと思うわけだが
BobcatがどうやってTDP抑えるのか気になるなあ
369:Socket774
09/12/20 09:27:50 xoTAYVvt
>>367
仕返しにチップセット不要にされるな
370:Socket774
09/12/20 09:36:44 TiSd8wB1
BobcatコアとRV830改あたりを使ったFusionが楽しみだ
Atomはマーケティングの都合で性能を上げられないみたいだし
371:Socket774
09/12/20 09:37:08 GLWlpwpP
>>369
仕返し以前にその予定じゃん
IntelプラットフォームのマザボからPCIEｘ16が消えたら笑えるんだが
372:Socket774
09/12/20 09:40:31 GPDO+Uzn
そんな高リスクな真似は無いんじゃ?
熱密度的な観点からGPUを内蔵する世代でも
ディスクリートは止められないと思う
その際に上手く協調できるかが課題
その点AMDはリスク低そう&強調するテクニックkの開発スピード上がりそう
373:Socket774
09/12/20 09:42:47 TiSd8wB1
QPI直結Larrabee vs HT直結Radeonの対決になるとか
374:Socket774
09/12/20 09:43:22 GLWlpwpP
ディスクリート廃止っつーか
「うちにはﾗﾗﾋﾞがあるんだもん！」とか言ってそれしか着けられなくなる可能性も無くは無いｗ
375:Socket774
09/12/20 09:44:09 GLWlpwpP
かぶった
376:Socket774
09/12/20 09:46:27 19tOD29S
確か過去にはAMDでも適切な拡張命令に即して実行可能なコードを吐くように設計されてたはず
いつからかそれがなくなったからたたかれてたはず
377:Socket774
09/12/20 09:51:23 TOTgZl/m
>>358
ホントその一行で終わる話。
378:Socket774
09/12/20 09:56:33 1jsHi0kL
pgiが出してただろACML最適化を謳ってたものの
だれも使わなかったんだろ
シェアが小さいから
379:Socket774
09/12/20 10:04:08 miyweSWO
>>373
拡張スロットは実質GPU専用になりつつあるし
スロット削ってGPU専用ソケットつけても良いような気がしないでもない
380:Socket774
09/12/20 10:06:09 5d20IGfg
SSEやSSE2はAMD64(互換のIntel 64)の基本命令なんだから、存在の有無なんて…という理由は苦しいと思うが?
ICCが出たのはいつで、AMD64が出たのはいつよ。
381:Socket774
09/12/20 10:30:34 GLWlpwpP
URLﾘﾝｸ(ja.wikipedia.org)
＞実行に必要なライブラリやリンカなどは付属していないため、他のコンパイラの環境に寄生した形で実行される。
何だただのマルウェアか
382:Socket774
09/12/20 11:06:34 Rnz+EWvf
>>362
x86命令自体が製造元でほぼ固有の実装になっているが…。
>>377
そうもいかないんだよ。コンパイラが二つあってもソフトウェアベンダー側が、
IntelコンパイラとAMDコンパイラ双方で動作確認しなければならない。
手間が二重にかかりるという最大の欠点がある。
「ソース書いた。コンパイラで書き出した。ではそのまま出荷！」
こうはならないんだよ。ベンダー側の手間暇も考えると独自コンパイラを提供しても、
シェア率の低いメーカー側のコンパイラはやはり使われないか、
やっぱりIntelコンパイラだけしか使われないという状況が生まれてしまう。
そのためにはAMDがシェアを上げなければならないが、Intelはそれを邪魔している。
様々な意味で今回の「Intelの悪意」は影響しているんだよ。
つか。CPU固有で最適化される鯖向け市場でのOpteronの頑張り様を観れば、
一般向けであそこまで差がつくのはありえないってーの。
383:Socket774
09/12/20 11:20:37 X02A7bXq
> つか。CPU固有で最適化される鯖向け市場でのOpteronの頑張り様を観れば、
> 一般向けであそこまで差がつくのはありえないってーの。
このへんが信者は現実が見えてないと言われる所以。
一般消費者は(一番売れてるメーカーの製品で用が足りるなら)
わざわざ安かろう悪かろうなマイナーメーカーは選ばない。
384:Socket774
09/12/20 11:24:37 clYNpsbw
ICCはIntelの製品だしどう作ろうがIntelの自由だろ。
AMDの製品で動かしたときの動作に文句だれる信者は
頭がおかしいw
385:Socket774
09/12/20 11:34:10 clYNpsbw
こんなくだらない電波論が独禁で仕方なく取り扱われるあたり、
実際Intelは独占企業のわりにMSなどとくらべてあまり悪いことはやってない馬鹿正直なメーカー
だったんだろうな。
386:Socket774
09/12/20 11:45:28 hBJ92r5O
Pentium4、D時代に細工、妨害なんてしなけりゃあ提訴なんてされずに済んだものを
387:Socket774
09/12/20 11:49:59 P+ES/a7K
>>382
OpteronってQ3で10%切ってPC向けよりシェア低いけど、頑張っているの？
388:Socket774
09/12/20 11:59:23 5d20IGfg
>>387
シェアしか見てないの?
389:Socket774
09/12/20 12:07:40 clYNpsbw
５．米FTCがIntelを提訴
URLﾘﾝｸ(www.geocities.jp)
390:Socket774
09/12/20 12:11:11 P+ES/a7K
>>388
シェア下がっているのに頑張っているというのは、スパコンでTOP500で上位占めてるから？
391:Socket774
09/12/20 12:11:40 GLWlpwpP
SSE最適化のためだけの寄生ソフトからAMDを邪魔するためだけのマルウェアへと進化しました
392:Socket774
09/12/20 12:15:42 clYNpsbw
ICCは実際あまりつかわれていないないから、AMDに不利なコードをいくら吐くようにつくっても
AMDの邪魔は宣伝効果以外では殆ど無理。
393:Socket774
09/12/20 12:22:35 9INdnQEo
言い逃れは無理と見てトーンダウンするテヘであった
394:Socket774
09/12/20 12:28:29 clYNpsbw
ICCはあくまでもIntel CPUの世代や機能の有無にあわせて最適化コードを生成するだけ。
AMDがIntelに自社CPUの情報を提供してICCで最適化コードを実行するような契約を取り交わしてるわけじゃないのに、
AMD向けの最適化コードを生成するのなんて論理的に無理なの。
リバースエンジニアリングしてライバルCPUを引き立てるなんてするわけもないだろ。
今まではIntel CPU向けに最適化したコードがたまたまAMDのCPUでも速いってだけで、
AMDのCPUはAMDが自由に設計しているのだから、Intelにとってはそんなのコントロールの範疇外。
その辺の事情を、プログラム書いたこともない馬鹿が理解できないで世界中でさわいでいるだけ。
Atomの話題と比較してもそうだがAMD周辺からはなぜか昔から電波論がでやすい。
世界中にアホな信者が散在している証拠。これは改善されるべきw
テヘ認定厨きたな。
テヘ認定厨は存在そのものが荒らし。
ここは君のような低レベルがくるスレではないぞ。
395:Socket774
09/12/20 12:30:28 WwOKGFmI
SPEC CPU2000の時代ではAMDが登録する結果でさえicc使っていたからiccによる嫌がらせは
アーキテクチャを超えて比較しようとする専門家に対してちょっとだけ有効だったりする
396:Socket774
09/12/20 12:32:34 PNwg/XQZ
＞AMDが登録する結果でさえicc使っていた
ほかに使えるコンパイラがなかったの
397:Socket774
09/12/20 12:41:39 NtcWttsz
>>383
ﾜﾛﾀｗ 現実観てねぇｗ
一般消費者はCPUなんてみてねぇよｗ
システム構成が理解できるならば、
安物Celeron機+糞オンボードVGAマシーンが売れる理由がねぇｗ
398:Socket774
09/12/20 12:52:11 clYNpsbw
いやむしろ一般消費者はCPUはおろか
速さにそんな執着ないだろ。
廉価版CPU+オンボードVGA
で不都合がある奴の方が今時珍しい。
つか上位はコストパフォーマンス悪いから。
399:Socket774
09/12/20 13:00:17 5d20IGfg
>>390
シェアだけで全てが見えてるの?
400:Socket774
09/12/20 13:07:12 5d20IGfg
AMDがコンパイラ出せって言うのも一理あるけれど、
AMDのプロセッサが自分で最適化させやすいというのもあるんだけれど。
しっかし、なんで「AMDのプロセッサを含めて最適化」論が出てるの?
前の書き込み見てないの?
401:Socket774
09/12/20 13:10:57 wnbDqYLm
>>383
>わざわざ安かろう悪かろうなマイナーメーカーは選ばない。
思ったがその「安かろう悪かろう」のメーカーに負けそうだから、
コンパイラに細工して、負けないようにしているIntel様ってことでOk？
402:Socket774
09/12/20 13:15:38 P+ES/a7K
>>399
シェアだけとは思ってないが、他の部分でOpteron頑張っているというなら教えてくれよ。
俺はスパコンTOP500で上位占めているくらいしかぱっと思い浮かばないが。
403:Socket774
09/12/20 13:27:57 5d20IGfg
Opteronがクライアント用プロセッサなら話がわかるんだけれど、サーバー用プロセッサを用いる必要がある他の分野っていくつあるの?
404:Socket774
09/12/20 13:28:23 GPDO+Uzn
>コンパイラに細工して、負けないようにしているIntel様ってことでOk？
FTAやAMD fanboyの認識はそれであってると思うよ?
当のAMDは今どう思ってるかは知らない
事実がどうなのかも知らない
405:Socket774
09/12/20 13:45:20 hBJ92r5O
URLﾘﾝｸ(h2np.net)
別にどっちだろうが速度はでるんだよ
406:Socket774
09/12/20 14:11:18 hAX1aBsE
まだ同じことガタガタいってんのか
407:,,・´∀｀・,,）っ-○○○
09/12/20 14:26:06 Zm+GEAOX
>>341
これは流石に・・・
つーか、__intel_fast_memcpyのコードのスループットはガチ
>>352
ストリング命令は流石に今時使わないでしょ。
408:Socket774
09/12/20 14:32:02 xRFyceV5
とりあえずAMDとINtelのシェア差は性能じゃなくIntelの悪質な嫌がらせによる差ということだね。
409:,,・´∀｀・,,）っ-○○○
09/12/20 14:36:02 Zm+GEAOX
ICCってそんなに速くないよ。SIMD周りだけは速いケースが多いけど。
410:Socket774
09/12/20 14:39:55 clYNpsbw
ホラ吹き団子登場か。
411:,,・´∀｀・,,）っ-○○○
09/12/20 14:41:15 Zm+GEAOX
Bulldozerに関してはAMD独自命令使わないと半分程度しか性能発揮できないような設計になってるから
そういう意味で言いがかりは通用しない
412:Socket774
09/12/20 14:47:42 clYNpsbw
BulldozerはSSE5をやめてAVXにした。
つまりICCの批判をした一方で、AMDはIntelのインフラにまたしても便乗しようとしているわけで
やってることが矛盾しているだろ。
それとも好き勝手SSE5でっちあげてり、AVXに急遽変更してみたり勝手にやってるのに
ICCが最適化に対応しなかったらまた信者さん達は批判するのだろうか。
AMDはAMDのアーキテクチャを勝手に決めることができるし、
Intelは自社のコンパイラの仕様を勝手に決めることができる。当たり前のことだ。
BulldozerのクラスタードアーキテクチャはIntel CPUの設計からかけはなれているから
さすがに自社開発でコンパイラを用意するか、協力者をつのらないかぎりはまともに性能でないからな。
IntelはICCでAMD CPUではAVXコードを実行させないこともできる。もともとSSE5かAVXかって気まぐれで
勝手に決められているものだからな。
413:,,・´∀｀・,,）っ-○○○
09/12/20 14:53:22 Zm+GEAOX
読む価値無し
414:Socket774
09/12/20 14:53:45 hBJ92r5O
＞IntelはICCでAMD CPUではAVXコードを実行させないこともできる。
ん？CPUIDで判別して？