X

MacのCPUをARMに！ Part 9

■ このスレッドは過去ログ倉庫に格納されています
0001名称未設定 (４段) (ﾜｯﾁｮｲW 87ea-6LJk)
垢版 |
2020/06/22(月) 21:04:33.52ID:o4xuL55O0

今はパソコンやサーバーにもシビアに省電力が求められている時代。
MacもiPhoneと同じARMをCPUに採用して
時代を先取りした低消費電力マシンを実現すべき。

そもそもMacがIntelに移行したのは、
G5よりもIntel Coreの方が電力効率が優れていることがその理由。
しかし、それならiPhoneをはじめ携帯電話では主流になっている
ARMアーキテクチャのCPUの方が数段電力効率がいい。

MacOSXは、Windowsほど互換性のしがらみに縛られないから
最も電力効率の良いCPUアーキテクチャを選べる。
アップル製品のCPUをARMに統一すれば、iPodからMac Proまで
同じアーキテクチャで揃えられる。

今のアップルなら、買収したP.A.Semiの技術を使って、
自社で高性能なARMベースのマルチコアプロセッサを設計できる。
アップルはOSも自社開発しているのだから、 GPUの活用と徹底したマルチコアへの最適化を行えば、
Intelベースのマシンに負けない性能が期待できるのでは？

前スレ
MacのCPUをARMに！ Part8
https://egg.5ch.net/test/read.cgi/mac/1592253901/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
0004名称未設定 (ｱｳｱｳｸｰ MM7b-f3e5)
垢版 |
2020/06/22(月) 21:20:58.32ID:LX+HqheKM
ハゲの勝利か
0007名称未設定 (ﾜｯﾁｮｲW b7fa-Uctr)
垢版 |
2020/06/22(月) 23:58:28.07ID:vfOovsxC0
ここでiMacのARM版が出たら度肝抜かれるな。つまりプロ版以外は全部ARM化させるっていうのはなかなか面白いかも。
0010名称未設定 (ｵｲｺﾗﾐﾈｵ MM93-nUCM)
垢版 |
2020/06/24(水) 17:34:47.19ID:OdVXemi4M
https://egg.5ch.net/test/read.cgi/mac/1592827404/991
>>991
> Appleはそんな企業じゃねえぞボケ、歴史を知らんのけ？

よし！歴史を振り返ろう！


Mac OS X 10.4 (Tiger)編
2005年4月29日発売
2006年以降の新製品には、インテル対応版

Mac OS X 10.5 (Leopard)
発表当初は2007年春のリリースを目指して開発されていたが、
2007年10月26日発売
最新安定版：10.5.8 (9L31a)
 2009年8月13日

Mac OS X 10.6 (Snow Leopard)
2009年8月28日発売
インテル製プロセッサを搭載したMacintosh専用となり、PowerPCプロセッサを搭載した Macintoshでは動作しない


発表(WWDC2005)から４年間だな
0013名称未設定 (ﾜｯﾁｮｲW 4f58-jwjG)
垢版 |
2020/06/24(水) 18:13:01.00ID:5j9GCJov0
iBookG4が2004年 Macbookアルミが2008年 自分もPPC intelは4年だわ
今回は所得減だから4年で買い替えできるか iPhone iPadたくさんあるからね
当時はipodしかなかったから
0014名称未設定 (ｵｲｺﾗﾐﾈｵ MM93-nUCM)
垢版 |
2020/06/24(水) 19:05:46.54ID:OdVXemi4M
>>11
バージョン基準なのか、リリース期間なのか？

毎年リリースが不具合の元凶なんだから止めたらいいのにね

intel macはbootcampのサポート切れが以外と早くて「余生をWindowsで」が難しいのがなあ
0015名称未設定 (ｵｲｺﾗﾐﾈｵ MM93-nUCM)
垢版 |
2020/06/24(水) 19:09:13.06ID:OdVXemi4M
電子機器としての話なら、こっち

ビンテージ製品とオブソリート製品 - Apple サポート - Apple Support
https://support.apple.com/ja-jp/HT201624


iPhone、iPad、iPod、Mac 製品をお持ちのお客様は、製品の販売中止後 5 年間 (法で定められている場合はそれ以上) は Apple や Apple サービスプロバイダから修理サービスや部品を入手できます。
Apple は、特定の技術的なオブソリート製品のサポートをすでに終了しています。

ビンテージ製品とは、販売中止から 5 年以上 7 年未満の製品です。
Mac、iPhone、iPad、iPod、Apple TV のビンテージ製品については、Apple Store 直営店を含む Apple のサービスプロバイダからハードウェアの修理サービスを引き続き受けることができますが、在庫状況や、法律の定めるところによります。
フランスで購入された製品については、販売者とスペアパーツの法定保証をご確認ください。

オブソリート製品とは、販売中止から 7 年以上が経過した製品です。
Monster ブランドの Beats 製品は、ご購入時期にかかわらず、オブソリート製品の扱いになります。
Apple では、例外なく、オブソリート製品に対するハードウェアサービスを終了しています。サービスプロバイダでも、オブソリート製品の部品は発注いただけません。
0016名称未設定 (ﾜｯﾁｮｲ cfba-l6Fe)
垢版 |
2020/06/24(水) 19:13:19.78ID:m5qaP+cr0
miniベースの筐体を開発者に用意してるからminiも早いかもな
これが新Macだというパッケージ感があるのはMacBookだからそっちが先だろうが
0018名称未設定 (ﾜｯﾁｮｲ 7fc0-Xpnd)
垢版 |
2020/06/24(水) 19:36:56.18ID:l/IWx8Yv0
>>17
知識がない一般人ならその程度の認識しかないでしょう
このスレにも沢山いる

数字は嘘つかないからベンチマーク結果ぐぐればいいのに
それすらせずイメージだけで語る輩は日本人に特に多い

ふんわりしたものが大好きだからな
0019名称未設定 (ｵｯﾍﾟｹ Sra3-zrpJ)
垢版 |
2020/06/24(水) 19:46:36.43ID:B+gf1Vpwr
Leopard最後のセキュリティアップデートが2012年、発売から7年のサポートだな。

2年後発売のintel macから7年だとすると2029年まではサポート受けられる。
0020名称未設定 (ﾜｯﾁｮｲ 0f03-6K9K)
垢版 |
2020/06/24(水) 21:09:19.92ID:fTbb7Kbn0
>>17
知識のない人は、印象だけで言うからね。
相手するのは無駄。

x86/64とくらべて、arm/64は汎用レジスタ数が2倍なのだから、
同じ技術で作ったら、arm/64のほうが高性能になる。
CPUアーキテクチャに優位性があるので、高速化を目指して作ったら抜いて当然。
高速化を目指さないiPhone11に搭載されたファン無しのA13が、
デスクトップを含む全Macよりも、シングルコアのスコアが上回ってる。
arm/64の優位性が、単純に現れた結果でしかない。

これからAppleは、ノート向けとデスクトップ向けのAシリーズを本気で作る。
それが実際に出て速さを実感するまで、遅いと言われるだろうね。
0023名称未設定 (ﾜｯﾁｮｲW 4fcf-jwjG)
垢版 |
2020/06/24(水) 23:18:54.05ID:wCiQy55T0
>>20
ずーっと誰も突っ込まないからそろそろ言うけどさ
arm64のレジスタ数云々はARM謹製純正品の話で、ライセンスだけ貰ってきて好き勝手に設計して作ってる各社のARM互換プロセッサにはあまり関係ない話だぞ
0024名称未設定 (ﾜｯﾁｮｲ 7fca-1R+Z)
垢版 |
2020/06/24(水) 23:31:03.43ID:PODGxyzB0
>>23
みんな知ってると思ってたけど？
さすがに富岳やAmazonのサーバー用で
Macが動くとか思ってるバカはいないでしょう。

え？いる？
0028名称未設定 (ﾜｯﾁｮｲW 7fb5-rgmO)
垢版 |
2020/06/25(木) 13:50:47.75ID:l+l87ros0
テスト機は貸出のルールに
分解禁止
ベンチマークの測定禁止
SNS等での情報共有禁止
があるのね
まあ当然か
0030名称未設定 (ﾜｯﾁｮｲ 0f03-6K9K)
垢版 |
2020/06/25(木) 14:53:16.00ID:Hqt7m0pf0
Amazon設計のARMプロセッサ「Graviton 2」の性能はIntel製CPUにどれほど迫っているのか？
https://gigazine.net/news/20200616-intel-vs-graviton2/

>AWSがGraviton 2を導入したことにより、ARMプロセッサはIntelのCPUとの差を縮めるどころか、
>マルチコアに至ってはIntelを超えているとWessels氏は指摘。
>また、Wessels氏はAmazonと同じくサーバー用ARMプロセッサを開発しているAmpereも話題に取り上げ、
>ARMに注目しているのはAmazonだけではないとコメントしています。

>マルチコアに至ってはIntelを超えている
>マルチコアに至ってはIntelを超えている
>マルチコアに至ってはIntelを超えている
>マルチコアに至ってはIntelを超えている
0031名称未設定 (ﾜｯﾁｮｲW 4fcf-jwjG)
垢版 |
2020/06/25(木) 14:57:13.78ID:yhD3ozZV0
そりゃわざわざサーバ向け（AWS向け）に設計して作ったプロセッサが、Intelの汎用プロセッサに肝心のマルチスレッド性能で負けてちゃ話にならないだろ

いい加減GIGAZINEを引っ張ってくるのやめろってw
技術系に関して、そこはほんとにどーしようもない記事か、超絶悪徳業者と組んでの提灯記事しかないぞ
どれが悪徳業者関連かはググればわかる
0032名称未設定 (ﾜﾝﾄﾝｷﾝ MM93-wfPp)
垢版 |
2020/06/25(木) 17:04:30.59ID:HZ0FdtaKM
何度でも何度でも言ってやる
俺は予言するぞ
2022年にIntel MacはmacOSのアップデート対象から外される
サードパーティのソフトもARM Macのみの対応になる
お前ら負け組は買い替えを余儀なくされる

開発ツールも当然ARM Macでしか動かなくなるので自然とIntel Mac火対応のソフトが増えてくる
さぁ、その後どうなるよ？
Intel Macは2年後完全にゴミになるよ
俺は言ったからな
0034名称未設定 (ｽﾌﾟｯｯ Sddf-o1NG)
垢版 |
2020/06/25(木) 17:16:18.31ID:5yNA7Zjld
なら買い替えればよくね？？
お金ないのかな？
0035名称未設定 (ﾜﾝﾄﾝｷﾝ MM9f-wfPp)
垢版 |
2020/06/25(木) 17:17:30.55ID:7F93tnjWM
iMacはIntelベースでもう一度進化を残してるが
このモデル買う人いるかねぇ？www
来年初頭に出るとしてたった1年でサポート切られるんだよ？

こんなの信者中のガチ信者しか買わねえよwww
クッソワロタwww 1年でゴミと化すMac(笑)www

俺はお前らと違って賢いからARM Macを待つぞ
AppleはARM Macに注力すると決めたんだからもうIntel Macを買う理由はない！はい以上ぉwww
0037名称未設定 (ﾜｯﾁｮｲW 4f81-XJnI)
垢版 |
2020/06/25(木) 17:54:21.42ID:L0mUsvu/0
金がないと心が卑屈になるってのが分かるよな
2年ごみごみ騒ぎ続けながら頑張って金貯めて、ARM Mac買えるくらい金が貯まるといいねw
0038名称未設定 (ﾜﾝﾄﾝｷﾝ MM9f-wfPp)
垢版 |
2020/06/25(木) 17:57:42.33ID:7F93tnjWM
俺の忠告聞いておいた方がいいぞ
MacBook Air/Pro 2020年モデルを買った奴は買取価格が高いうちに売りに出せ
そして半年後のARM Mac発売に備えろ
傷が浅いうちに売却の決断をしたほうがいいぞ

1〜2年後にはIntel Macなんて最上位モデルだろうが5〜6万にまで下がってるぞwww

ご自慢のリセールバリューもARM Mac発売後は崩壊しちゃうね！www
0039名称未設定 (ﾜｯﾁｮｲ 0f11-0Hhk)
垢版 |
2020/06/25(木) 18:05:07.35ID:SeUr1EZd0
PowerPCからx86になったときは
旧モデルのほうが売値高いっていう逆転現象もあったけどね
今回はどうなるかな
0040名称未設定 (ﾜｯﾁｮｲW 4f81-XJnI)
垢版 |
2020/06/25(木) 18:30:53.44ID:L0mUsvu/0
それよりもOS9が動くかどうか？ってところにフォーカスが当たってた気がするけど
高くなっていたのも一部のモデルだけだったと思う
iMacやMacBook系はそんなことは起きてなかったような
かなり昔の話でもう忘れた
0041名称未設定 (ﾜｯﾁｮｲ cf02-FKcX)
垢版 |
2020/06/25(木) 19:41:02.15ID:yWfB0j1H0
開発者目線で見るとARM版Macは今と同じ環境が構築できるまではスルーになるので(特にx64イメージが動くDocker)、
さっさとIntel版Macがディスコンになったら、逆にリセールバリュー上がりそうだけどな。
「今まで使ってたMacが壊れてしまったけど、ARM版Macしか新品がないので、中古のIntel版Macで場を繋ぐ」っていう人が出てきそう
0043名称未設定 (ﾜｯﾁｮｲ 7fc0-Xpnd)
垢版 |
2020/06/25(木) 20:42:21.03ID:K9xou5Ow0
https://dev.classmethod.jp/articles/build-dokcer-image-for-arm-architecture/
＞Docker Hubで公開されている公式イメージの多くは「マルチCPUアーキテクチャ」に対応しています。
＞公開されているイメージが「マルチCPUアーキテクチャ」に対応している場合、通常は、Docker Hubから
＞プルを行うと自動的に適切なアーキテクチャのイメージがダウンロードされます。

わかったか？詳しくないのに知ったかぶるなよってことだ
何が開発者目線だよ
本当に開発したことあんのか
0044名称未設定 (ﾜｯﾁｮｲ cf02-FKcX)
垢版 |
2020/06/25(木) 20:48:31.01ID:yWfB0j1H0
>>43
そりゃ公式イメージをpullして手元で動かすときの話じゃろ…
やりたいのはx64のイメージをビルド&デプロイすることだよ
サーバがx64なんだからこれは必須
0046名称未設定 (ﾜｯﾁｮｲ 7fc0-Xpnd)
垢版 |
2020/06/25(木) 20:54:43.94ID:K9xou5Ow0
>>44
ARMアーキのCPUだとx64イメージビルド出来ないと思ってんの？
何のためにDockerがGo言語採用したか、そこから説明しないと駄目？
0047名称未設定 (ﾜｯﾁｮｲ cf02-FKcX)
垢版 |
2020/06/25(木) 20:57:33.90ID:yWfB0j1H0
>>46
イメージのビルドと、Dockerのコンポーネントを構成するGoがどう関係するのかわからんが…
で、どうやったらARMホスト上でx64のイメージをデバッグすればいいのか教えてください。
ちなみにmultiarchイメージを作る方法は知ってるので言わなくていいです。デバッグのために同じアーキテクチャで動かしたいんです。
0049名称未設定 (ﾜｯﾁｮｲW 7fb5-rgmO)
垢版 |
2020/06/25(木) 21:55:58.53ID:l+l87ros0
>>36
評判良さげだったらとりあえずarm版のmini辺りを買おうかなとは思うわ
まあサードまで含めての環境が安定するのは数年かかるだろうからなぁ
0050名称未設定 (ﾜｯﾁｮｲW 0f4e-h9M3)
垢版 |
2020/06/26(金) 00:19:16.26ID:RJX5TO0y0
>>43
ほんとに開発したことあるのか？をそっくりそのまま返したいw
クロスコンパイルなんて出来て当たり前だよ。
iOSアプリのビルドはみんなそうやって出来てるのだから。
ただし、(QEMUがそうだが)違うアーキテクチャのバイナリを動かそうとしたら、マシン語レベルでインタプリタを動かさなきゃいけなくなるのでめちゃくちゃ遅くなる。
ターゲット環境がx64なのだとしたらデバッグは実用的にはx64上でしか出来ないよ。

納得できないのなら、お手元のマシンでQEMUで別アーキテクチャのOSを動かしてみ？とんでもなく遅いから。

90年代にゲーム機のエミュレーターが流行ったころにエミュレーターで遊んでた世代なら体感で知ってることなんだけどなあ。
0051名称未設定 (ﾜｯﾁｮｲ 0fea-UmiM)
垢版 |
2020/06/26(金) 00:24:05.32ID:rVIDR/ql0
docker使って開発するようなシステムでx86でしか再現しないバグをCPUレベルでデバッグするという状況が想像できない
0053名称未設定 (ﾜｯﾁｮｲW 0f4e-h9M3)
垢版 |
2020/06/26(金) 00:32:39.07ID:RJX5TO0y0
>>52
ほーん、で、その老害のジジイが言っていることで、
知識が古すぎて間違っている内容はあるのかな？

ないのならジジイかどうかは関係ないよね。
まだ30代なんだけどな。
0059名称未設定 (ﾜｯﾁｮｲW 0f4e-h9M3)
垢版 |
2020/06/26(金) 07:08:15.20ID:RJX5TO0y0
>>58
ARMのLinuxはな。
ただLinuxをVMで動かして開発している人にとってARMのLinuxが動くことに価値があるのかは現状では結構疑問
0060名称未設定 (ﾜｯﾁｮｲW 0f4e-h9M3)
垢版 |
2020/06/26(金) 07:31:58.14ID:RJX5TO0y0
>>51
構造体のサイズが違うなんてのは容易に起こりうると思うけど。
そんなこと気にしながら色んなライブラリ使うのは嫌だな。
スクリプト言語なら気にしなくてもいいかもしれないけど。
0061名称未設定 (ﾜｯﾁｮｲW 8f58-XJnI)
垢版 |
2020/06/26(金) 09:44:54.48ID:/KtxkQjd0
>>43
とにかく面倒くさいなw
暇人しかやらないよ、こんなこと
業務で使うのは今はメリットほとんどないどころかデメリットだらけだ
時間が解決してくれる問題ならいいけど
0062名称未設定 (ﾜｯﾁｮｲW 4fcf-jwjG)
垢版 |
2020/06/26(金) 11:28:39.75ID:ZlaJG/0b0
>>59
x64で走るLinuxがいるひとは、素直に別PCでも用意するか、レンタル鯖で環境作るしかないなー
レンタル鯖で仮想環境幾つも用意して検証に使うの一時期やってたけど、意外と使いやすかったよ
0063名称未設定 (ﾜｯﾁｮｲ 0fea-UmiM)
垢版 |
2020/06/26(金) 11:45:06.20ID:rVIDR/ql0
>>60
x86_64とaarch64で構造体のサイズが違うとして(多分違わないけど)、何が問題なの？
i386からx86_64への移行では確実に構造体のサイズが変わったけど、それでなにか困った？
0070名称未設定 (ﾌﾞｰｲﾓ MM0f-h9M3)
垢版 |
2020/06/26(金) 14:02:43.68ID:wp5W5OuTM
>>63
構造体のpack/unpackとかしないの？
レイアウト変わって困らないなら、困らないんじゃない？
自分は同じコンパイラだけど違うアーキテクチャだからって、
いちいちレイアウトを確認して開発するのは御免だね。
0073名称未設定 (ﾜｯﾁｮｲW 0f4e-h9M3)
垢版 |
2020/06/26(金) 16:28:17.37ID:RJX5TO0y0
自分の場合は、他の言語から呼び出されるライブラリをC/C++で書くことも間々あるし、C/C++のライブラリを他の言語から呼ぶことも多々あるな。
そういうのがレアケースだと思う人が困らないのはわかるよ。
DockerとかVMで細かくライブラリやコンパイラ、カーネルまでターゲット環境と合わせて開発している人ならそこまでレアケースじゃないんじゃないかな？と思っただけ。
ABIの一致を求めての場合もそれなりにありそうだから。
色々面倒いから誰かが熟成したDockerfileに乗っかっとこう、という人も少なくないだろうけど。
0074名称未設定 (ﾜｯﾁｮｲ 0fea-UmiM)
垢版 |
2020/06/26(金) 17:26:49.49ID:rVIDR/ql0
>>73
> 他の言語から呼び出されるライブラリをC/C++で書く
それはコンパイラがよしなにしてくれるでしょ
「直接」呼ぶ(Pythonで言うとctypes)のはレアケースであって環境依存なのは承知でやってるはず
0075名称未設定 (ﾜｯﾁｮｲW 0f4e-h9M3)
垢版 |
2020/06/26(金) 17:54:44.38ID:RJX5TO0y0
>>74
構造体の配列をそのままfwriteして持ち回すとかせずパーサーを必ず書くならいいんじゃない？
バイナリレベルでの一致に興味がないのなら要らないんだろうね、とあなたの部分的に主張を認めてるでしょ？
でもそれが全ての要求を満たすわけではない、とわからない？
0076名称未設定 (ﾜｯﾁｮｲ 0fea-UmiM)
垢版 |
2020/06/26(金) 18:36:18.18ID:rVIDR/ql0
>>75
> でもそれが全ての要求を満たすわけではない、とわからない？
いやわかってるよ

> 構造体の配列をそのままfwriteして持ち回す
とかPythonのctypesみたいのはそもそも環境依存で昔から推奨されない手法であって、レアケースだよねって言ってるだけ
0077名称未設定 (ﾜｯﾁｮｲW 0f4e-h9M3)
垢版 |
2020/06/26(金) 18:46:32.85ID:RJX5TO0y0
>>76
ポータブルなCのコードを書いているなら「推奨されない」だろうけど、
ポータブルなことよりも性能を重視してCを書くのも想像に難くないと思わない？
それこそ性能度外視のポータブルなコードを書きたいのならばもっと高級な言語を使えばいいのだから。
Cの規格書レベルで推奨されていないものならともかく、ある用途でのみ推奨されないものだからといってレアケースだとは思えないなあ。
それこそ、わざわざDockerを使ってリンクされるライブラリやコンパイラをターゲット環境と一致させたいと思っているわけなのだから。

clangで開発して本番はgccとかいうケースだったらアーキテクチャの違いはさほど重要ではないコードだというのはわかるけど、そういう開発スタイルだったら逆に、Dockerなんか使う？
0083名称未設定 (ﾜｯﾁｮｲW 8fb1-vNYL)
垢版 |
2020/06/28(日) 13:58:48.58ID:OcZPkJ2w0
開発機のベンチマーク禁止した上でほぼ同じプロセッサ積んでるipadpro買わせるというセコい戦術だったら笑う
0086名称未設定 (ﾜｯﾁｮｲW 0f0c-ro0E)
垢版 |
2020/06/28(日) 20:25:35.87ID:LmDnkVRJ0
mac OS Big Surから、未発表のAMD GPU（RDNA 3?）が
見つかる
https://www.mac4ever.com/actu/154929_de-nouvelles-references-amd-navi22-navi23-navi31-cezanne-dans-macos-big-sur

あれ、Navi 22とNavi 23とNavi 31を採用するなら
Apple siliconはGPU内蔵で全機種PS5みたいな
SoCになるかと思ったけどdGPUは継続されるのかな

そうなると下位機種がSoC、ミドルレンジモデルと
ハイエンドはSoC+dGPUなのか、やっぱりAppleも
全て自社製に置き換えるのはリスクが高いと判断した
のかね
0091名称未設定 (ﾆｸｸｴ 0fc1-94al)
垢版 |
2020/06/29(月) 22:13:00.62ID:oAGP+vbX0NIKU
>>86
GPU性能を100WのハイエンドdGPU並みに上げたければ
CPU性能を上げられない
80WのミドルレンジのdGPUですら同じ

万人に必要ないGPU性能はAMDのiGPU並に抑えて
CPU性能を高めたり消費電力を抑えるのは当たり前
0093名称未設定 (ﾆｸｸｴ 0fc1-94al)
垢版 |
2020/06/29(月) 22:18:44.70ID:oAGP+vbX0NIKU
>>92
で、お前にとってGPU性能がどう重要なの？

コンシューマーPCとして万人にどう必要なの？

GPGPUでAppleなんかより遥かに先行してるNvidiaですら
コンシューマー用での活用範囲は限定的
0095名称未設定 (ﾆｸｸｴ 0fc1-94al)
垢版 |
2020/06/29(月) 22:29:41.43ID:oAGP+vbX0NIKU
>>94
で、お前にとってGPU性能がどう重要なの？

コンシューマーPCとして万人にどう必要なの？

GPGPUでAppleなんかより遥かに先行してるNvidiaですら
コンシューマー用での活用範囲は限定的


普段使いで具体的にGPUの方がどう体感出来るの？CPU以上に
0096名称未設定 (ﾆｸｸｴW 8f63-vh/6)
垢版 |
2020/06/29(月) 22:33:08.40ID:hcKlA7Cm0NIKU
一般人の普段使いってOfficeとかスマホのバックアップ、ネット、YouTube等の動画再生、
あとは用途じゃないけど必然的に行うウイルスチェックとか？
GPU要るの動画くらい？
0097名称未設定 (ﾆｸｸｴ 0fc1-94al)
垢版 |
2020/06/29(月) 22:33:35.87ID:oAGP+vbX0NIKU
>>94
GPU性能よりCPU性能の方が重要なら

なんでIntelもAMDもAppleもQualcommも
内蔵GPUよりCPUの方にはるかに多く
トランジスタ数とダイサイズの割合を使ってるの？

ねえ？なんで？説明してみろよ低能
0099名称未設定 (ﾆｸｸｴW 4f73-h9M3)
垢版 |
2020/06/29(月) 22:36:39.59ID:wooCKuip0NIKU
>>95
俺の場合はメインで使うソフトがDavinci ResolveだからGPU貧弱だとお話しにならんって事情はあるけど
そうじゃなくたって普通にネットの動画見るだけでも
今時GPUのハードウェアデコード対応してる事が前提だろ？
これから2〜3年もしたら今より4K動画も増えるぜ
どんだけCPU性能高くてもGPU貧弱だと見られないぜ
ゲームするにもCPUなんかはi5でも充分だけど
それより大事なのはGPU

で、今時CPUがボトルネックになる作業って何？
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況