Re: [閒聊] 蘋果A14性能初測，基於GB5 & GFXBench

看板MobileComm作者 (kkcity)時間3年前 (2020/11/02 05:20), 3年前編輯推噓36(36推 0噓 17→)
留言53則, 35人參與, 3年前最新討論串2/2 (看更多)
> 小扁藍超威:蘋果A14性能初測：基於Geekbench＆GFXBench > https://www.bilibili.com/read/cv8105271 --
推
10/28 01:56,
iPhone 4k 編輯遠比865快多，CPU就是猛。
10/28 01:56
這一次關於A14效能部分的測試似乎蠻少的。可能再等完全體pro max吧 其實小弟只是想討論這個一直讓大家覺得很迷的問題 就是iPhone在premiere的轉檔測試，常可以看到一些非常驚人的成績 小弟已經也曾經覺得很誇張，所以大概研究了一下，說一下自己心得 因為這裡面其實有一些誤解 一般轉檔大概就是import進檔extracting 再來重新rendering後export到存檔完成 蘋果版本的Premiere，在你點選檔案時就開始預做importing了 這個需要的時間看你的檔案大小，大檔的話就需要耗時比較久 你按下render後iPhone只會繼續做完剩下兩個動作 可是安卓版本的premiere是把這三個動作一次同時完成的 很多youtuber計時是從按下render那個時間開始算 iPhone並沒有計算到importing的時間，所以會快非常多 甚至檔案大一點比安卓快各兩三倍都有可能 這就是iPhone轉4K超級快說是CPU超強的由來 舉各例子來說吧，XEETECHCARE測試premiere，中間剪接了一下 因為編輯者把iPhone在load時就直接需要importing的段落跳過了 https://youtu.be/VQaXo9wS-ew?t=417
所以你看到一個非常驚人的結果，iPhone約花對手1/3時間就完成了 這邊用TechNick的測試影片來說明上面到底是怎麼回事會比較清楚 https://youtu.be/AQ8GjodOoEc?t=201
你可以看到premiere裡點選檔案時1+8T是瞬間預覽就出現馬上可以開始轉了 可是iPhone12點開檔案後，幾乎有整整8-9秒的呆滯時間 作者其實這時候有說1+8T打開Project比iPhone快 真正狀況是程式正在importing這個檔案，所以得花費一段時間 這也是XEETECHCARE用剪接去掉沒呈現的部分 當編輯按下rendering時，iPhone12用2-3秒神極速度完成了工作 1+8T大概比iPhone慢了5-6秒才render-export完成 原因就是在於1+8T還得同時把還沒進行的import先做完 因為作者沒有計時，你只能自己去看這段下面時間讀數來大概計一下 作者自己也並不瞭解這個問題，所以說iPhone是ridiculous faster 但真正如果計入iPhone12一開始選取檔案一整段呆掉的8-9秒 再計算1+8T在render時慢的5-6秒，1+8T其實轉檔的時間還比iPhone12快 所以你說轉檔這件事情iPhone真的有那麼厲害嗎？ 來看看Phonebuff放了premiere rush連續完整的歷程 https://youtu.be/tqxA222ljFc?t=139
只是他選用的檔案比較小，所以import時間不會花這麼久 但是也可以明顯看出點選檔案時iPhone有段呆滯的時間正在importing Phonebuff編輯也自己說這個iPhone這時候正在stuttering（口吃） 這樣去計算premiere總共開啟程式轉檔存檔到離開的時間 從最後時間條來看，Note 10+其實還比iPhone XS Max快了約20%-30% https://youtu.be/tqxA222ljFc?t=278
或者我們看iPhone11 pro max跟Note20 Ultra 這時iPhone 11有比較快，但看時間條差距應該也是在10%左右 https://youtu.be/H1PdBJlTl6I?t=200
我想很多人神話iPhone的4K轉檔 因為是很多youtuber不知道iPhone在load project時已經在import檔案了 所以得要花很長的時間預覽圖才跳出來，安卓版就是直接跳出來預覽 只單單計算按下render後的時間，iPhone的import時間是完全沒被計算進去的 所以計算總時間，iPhone比安卓快也不是那種兩三倍的差距 甚至在同世代機種時，安卓有時候還比較快也不奇怪 至於為什麼iOS版 premiere要這樣做？我不知道..... 因為這樣做根本沒有好處，尤其你有大量截圖相似的影片要編輯時 你弄不清楚哪個是哪個時，光是選取每個不同檔案間切換都會浪費很多時間 還不如安卓這樣乾脆先給你預覽後再說 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.161.125.244 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/MobileComm/M.1604265640.A.57D.html
推
11/02 05:27, 3年前 , 1F
推專業
11/02 05:27, 1F
→
11/02 05:46, 3年前 , 2F
有好處，但apple這段code寫的不好，寫的好你不會查
11/02 05:46, 2F
→
11/02 05:46, 3年前 , 3F
覺到有卡頓的現象
11/02 05:46, 3F
瞭解了，是ios版的Premiere寫的不好的關係 這樣整體看起來以後4K轉檔是不是其實選擇安卓機種還比較好 我原本猜想是i/o的關係啦，因為這種或許得借用Flash上容量來工作
→
11/02 06:44, 3年前 , 4F
跟我想的一樣 0.0
11/02 06:44, 4F
※ 編輯: kkcity59 (1.161.125.244 臺灣), 11/02/2020 06:51:16
推
11/02 07:15, 3年前 , 5F
推專業解說
11/02 07:15, 5F
推
11/02 07:30, 3年前 , 6F
A14完全體如果用在ipad上面 應該會很猛
11/02 07:30, 6F
→
11/02 07:55, 3年前 , 7F
完全體不就a14x ，ipad pro 才會用
11/02 07:55, 7F
推
11/02 08:06, 3年前 , 8F
推 測試人員也不懂吧 所以只計算按render後時間
11/02 08:06, 8F
推
11/02 08:09, 3年前 , 9F
推
11/02 08:09, 9F
推
11/02 08:18, 3年前 , 10F
有趣推推推
11/02 08:18, 10F
推
11/02 08:35, 3年前 , 11F
推專業
11/02 08:35, 11F
推
11/02 08:36, 3年前 , 12F
新ipad air已經用a14了啊 國外都上市了
11/02 08:36, 12F
推
11/02 08:36, 3年前 , 13F
推
11/02 08:36, 13F
推
11/02 08:41, 3年前 , 14F
原來如此，神話破碎了
11/02 08:41, 14F
推
11/02 08:45, 3年前 , 15F
11/02 08:45, 15F
→
11/02 08:45, 3年前 , 16F
我在想有沒有可能是像Mac上的FCPX一樣的關係，蘋果
11/02 08:45, 16F
→
11/02 08:45, 3年前 , 17F
做法是先讓素材完全導入完全，這樣剪輯過程就會很
11/02 08:45, 17F
→
11/02 08:45, 3年前 , 18F
順暢也能即時預覽？
11/02 08:45, 18F
推
11/02 08:46, 3年前 , 19F
推
11/02 08:46, 19F
推
11/02 08:49, 3年前 , 20F
是這個原因沒錯啊，可是那要比效能就得把這段時間一
11/02 08:49, 20F
→
11/02 08:49, 3年前 , 21F
併計算吧。安卓機種繁雜adobe這樣設計，應該是保證
11/02 08:49, 21F
→
11/02 08:49, 3年前 , 22F
在記憶體容量小的機種上也能運作吧
11/02 08:49, 22F
→
11/02 08:51, 3年前 , 23F
重點是安卓旗艦的效能跟蘋果並不存在什麼巨大差異啊
11/02 08:51, 23F
推
11/02 08:59, 3年前 , 24F
推
11/02 08:59, 24F
推
11/02 09:06, 3年前 , 25F
推專業
11/02 09:06, 25F
推
11/02 09:20, 3年前 , 26F
推專業
11/02 09:20, 26F
推
11/02 09:30, 3年前 , 27F
看來以後不能說用iphone轉檔了，code寫的不好，綜
11/02 09:30, 27F
→
11/02 09:30, 3年前 , 28F
合時間還比較長
11/02 09:30, 28F
推
11/02 09:38, 3年前 , 29F
難以置信的工程創舉。
11/02 09:38, 29F
推
11/02 10:01, 3年前 , 30F
漲知識
11/02 10:01, 30F
推
11/02 10:24, 3年前 , 31F
推知識文
11/02 10:24, 31F
推
11/02 10:24, 3年前 , 32F
看的這篇也是想到之前極客灣那篇FCP的比較
11/02 10:24, 32F
推
11/02 10:32, 3年前 , 33F
看來是用FCP那招，閒置的時候預先轉
11/02 10:32, 33F
其實不是預先轉，應該說是預先把素材給解壓恢復成資料了 而安卓是你確定要export的時候才做這一個動作
推
11/02 10:33, 3年前 , 34F
推
11/02 10:33, 34F
推
11/02 11:06, 3年前 , 35F
完全不覺得預轉是好事，命中率低的話，浪費電啊…
11/02 11:06, 35F
→
11/02 11:06, 3年前 , 36F
而且還搞到前台有感卡頓的話，根本不對
11/02 11:06, 36F
推
11/02 11:46, 3年前 , 37F
推專業
11/02 11:46, 37F
推
11/02 12:11, 3年前 , 38F
難以置信的工程創舉。
11/02 12:11, 38F
推
11/02 12:11, 3年前 , 39F
推詳細解說，很多youtuber真的完全忽視這一點
11/02 12:11, 39F
推
11/02 12:19, 3年前 , 40F
老實說這種東西在一向就很有在這方面下功夫的蘋果
11/02 12:19, 40F
→
11/02 12:19, 3年前 , 41F
、或幾乎每天都要使用相關工具的專業人士不太可能
11/02 12:19, 41F
→
11/02 12:19, 3年前 , 42F
不知情，但還是會拿來去吹噓，這講白了就是一場騙
11/02 12:19, 42F
→
11/02 12:19, 3年前 , 43F
局
11/02 12:19, 43F
推
11/02 13:29, 3年前 , 44F
推專業
11/02 13:29, 44F
推
11/02 13:40, 3年前 , 45F
推專業
11/02 13:40, 45F
推
11/02 13:46, 3年前 , 46F
推專業解說
11/02 13:46, 46F
推
11/02 14:05, 3年前 , 47F
就是瞎吹 這個族群非常正常
11/02 14:05, 47F
我是覺得這些Youtuber不一定知道這個狀況啦 但像是Phonebuff就有提到iPhone在Load project時都會stuttering 而Phonebuff用完整的歷程計時，就可以發覺兩者沒有太大差異 但如果只去看按下export的話iPhone就會出現神級的效能
推
11/02 16:05, 3年前 , 48F
就是adobe程式寫的差，我大果果來背鍋啦
11/02 16:05, 48F
嗯，其實結論就是安卓高通與蘋果同世代的處理器效能看起來差不多 說adobe對蘋果的部分優化差也有點怪
推
11/03 01:43, 3年前 , 49F
如果這有人要解讀成對蘋果的系統寫得差的話，看來開
11/03 01:43, 49F
→
11/03 01:43, 3年前 , 50F
發商蘋果優先的時代也過去囉(?)
11/03 01:43, 50F
嚴格來說SOC方面蘋果跟安卓的CPU是非常接近 事實上他們都是完全吃arm v8.x的指令集，也就是如果說特別去優化 通常兩邊都可以受惠，如果沒什麼優化code寫很爛，兩邊也一起受害 GPU部分的優化就差距比較大，光架構不同不說 早期兩間還可以說用通用的Open GL ES當成與底層溝通的API 後來一個去搞Metal，另外一個還在Open GL裡面，雖然弄出了Vulkan 但似乎也都沒很積極去讓Vulkan變得更通用與成熟
推
11/03 10:13, 3年前 , 51F
感謝耐心詳細解析說明！
11/03 10:13, 51F
推
11/03 10:16, 3年前 , 52F
看來雙方其實效能真的差不多，只是有某一方取巧或
11/03 10:16, 52F
→
11/03 10:16, 3年前 , 53F
疏忽了某一個環節，卻被拿來造神
11/03 10:16, 53F
我只能解釋說這是長期以來對蘋果轉檔的誤解吧 其實蘋果跟安卓的轉檔效率是差不多的 但是因為這個誤解讓很多人覺得轉檔時蘋果快了兩三倍 可是事實完全不是這樣。甚至很多時候其實都是安卓轉檔反而比較快。 這很大一部份原因是轉檔時importing-exporting都很吃記憶體 而安卓旗艦的記憶體通常都比iPhone大很多 就像是上面1+8T vs iPhone12的轉檔比對，如果仔細看幾次後就會發覺 事實是1+8T比iPhone 12來得快一些的 可是不了解事實的朋友很可能跟你說iPhone明明快了兩三倍啊 ※ 編輯: kkcity59 (111.248.21.234 臺灣), 11/06/2020 00:32:28
‣ 更多 kkcity59 的文章
文章代碼(AID): #1VdoQeLz (MobileComm)
‣ 更多 kkcity59 的文章
文章代碼(AID): #1VdoQeLz (MobileComm)