applem1編譯速度
1. m1和5800h編程哪個快
5800h
我們將比較Apple M1 Pro (10-core)和AMD 銳龍7 5800H，Apple M1 Pro (10-core)的Cinebench 20多核跑分達到了(2721分)，而AMD 銳龍7 5800H的Cinebench 20多核跑分達到了(5214分)。兩者分別採用了Apple M1 Pro架構和Zen 3架構。Apple M1 Pro (10-core)使用了5 nm製程工藝，AMD 銳龍7 5800H使用了7 nm製程工藝。
2. 蘋果推出首款自主研發的晶元M1，它有多強
蘋果推出首款自主研發的晶元M1有以下強大的功能：一、它並不是簡單的A14馬甲 ；二、實現了低功耗和多幹活，計算能力超強；三、更長的電池壽命。
一、對於蘋果的新處理器，很多人猜測是一個手機和平板上的A14加強版，類似於A12Z，A12X和A12的關系。增加幾個大核心，增加幾個GPU的加強版A14。但是，蘋果M1並不是這么簡單的產品。
蘋果的晶元有時被稱為基於Arm的晶元，因為它從總部位於英國的Arm公司獲得了指令集的許可，這些指令集決定了處理器如何處理命令。但是核心處理器電路是這家美國公司自己設計的。蘋果的優勢之一是可以控制要包含的加速器。這些是特殊部分，專門處理某些任務，例如機器學習或密碼學。它還可以將內存和其他功能集成到一個封裝中，而不是使用其他專業晶元，這應該有助於提高性能。
3. 蘋果m1比a14強多少
蘋果m1比a14強50%左右。與 A14 相比，M1 的 DDR 介面數量是 A14 的 2 倍，高性能 CPU 核心數量是 A14 的 2 倍，GPU 核心數量是 A14 的 2 倍，支持蘋果 Firestorm 核心的 L2 緩存是 A14 的 1.5 倍。更小的 IceStorm 核心在 A14 和 M1 中都使用了相同大小的 L2。兩款晶元的 NPU 也完全相同。
M1 的整體系統緩存比 A14 少了 25%，其整體裸片尺寸比 A14 大了 37%。裸片尺寸的增加主要由兩個因素驅動。首先，M1 增加了 CPU 和 GPU 核心的數量、L2 緩存以及 DDR 介面的數量。其次，M1 集成了 A14 沒有的硅，比如蘋果 T2 安全處理器，以及對 PCIe 等標準的支持。
M1晶元的性能特點。
M1具有較大的CPU緩存可加快指令和數據訪問速度並減少延遲，但系統緩存小於A14的。此外M1還具有更多的CPU和GPU核心，以及DDR高速內存介面(8對4)。包括了更多專用模塊，可針對節能要求不高的桌面應用進行優化。與A14相比，M1的裸片尺寸增加了37%，當然M1作為新品相較而言是要優於A14的。
4. 蘋果m1筆記本測評
M1晶元是蘋果首款採用5納米製程打造的個人電腦晶元，封裝了160億個晶體管，為Apple所有晶元之最；相較於最新的攜帶型WindowsPC晶元，M1晶元擁有2倍的CPU運行速度，以及25％的能耗節省。
M1晶元還支持蘋果的神經網路引擎，顯著加快了機器學習（ML）任務的處理速度。M1晶元中的神經網路引擎使用16核架構，可以每秒執行11萬億次計算，將機器學習速度提高了15倍。
(4)applem1編譯速度擴展閱讀：
M1晶元配備了一個八核中央處理器，包括四個高性能核心和四個節能核心，總體上允許開發人員以比以往快近三倍的速度構建應用程序。
M1晶元還有8個GPU內核，可以同時運行近2．5萬個線程，從流暢地流媒體多個4K視頻流到渲染復雜的3D場景，數據處理能力可達每秒2．6萬億次浮點運算。
5. M1 設備的 Xcode 編譯問題深究
在Apple發布M1晶元之前，一直使用Intel的晶元，沒有出現什麼問題。發布M1晶元後，由於兩者架構的不同（M1是arm64架構，Intel是x86_64的架構），導致很多軟體運行出現了問題。我們在M1機型中使用Xcode編譯模擬器時，可能會碰到如下報錯：
或
這些報錯，都是是由於項目中存在.a或.framework靜態庫導致的。以前，我們創建靜態庫時，會分別打包出一份針對真機（arm64）和模擬器的（x86_64），然後將這兩份合並成一個包後引入項目中進行使用。在Intel機型上，真機上使用arm64指令，模擬器（x86_64）中使用x86_64指令，所以不存在問題。但是在M1機型上，模擬器是以arm64運行的，顯然再以x86_64運行就會出現問題。
對於這類架構報錯問題，網上的資料一般會告訴你兩個解決方案：
以Rosetta模式運行Xcode。
修改Build Settings -> Excluded Architectures選項，添加Any iOS Simulator SDK選項，並設置值為arm64。圖示如下：
這兩種方案都能解決編譯問題，但是也都存在問題。
以Rosetta模式運行是M1機器上x86軟體無法運行的解決方案，它會將x86指令轉譯成ARM指令運行，這種轉譯顯然是存在性能損耗的，損耗大概在20%～30%，不到萬不得已，不推薦使用這種方案。
Excluded Architectures方案說明
修改Excluded Architectures選項也有它的問題。字面意思是排除架構的意思，我們設置在模擬器中排除arm64就能解決模擬器無法編譯arm64的問題。
這樣的設置能生效會讓人有點費解，我們知道，在intel機型上，模擬器本來就是以x86方式運行的，排除arm64毫無影響。但是在M1機型上，模擬器是以arm64方式運行的，排除了arm64反而能跑，這不是把我的智商摁在地上摩擦么？，但是蘋果就是這樣乾的，當在M1機型上，排除了模擬器的arm64架構後，模擬器還是會以arm64的方式運行，但是模擬器中的app是以x86的方式運行的，對蘋果的這個騷操作我們不得不服。圖示如下：
有時候在Excluded Architectures選項中排除了模擬器的arm64指令，依然無法編譯通過，那麼一般是項目設置和cocoapods的設置不一致導致，設置為一致後一般可以解決問題。可以通過在Podfile中添加如下內容來解決：
通過上述內容，我們知道了問題的由來，它是由於項目中存在.a或.framework，它們提供的指令集不完整導致的。Apple對於這類問題，也提供了解決方案，請由我細細道來。
以Xcode13為例，在我們創建靜態庫時，選擇真機編譯出來的包只包含arm64指令，選擇模擬器編譯出來的會同時包含arm64和x86_64指令。我看一些網上的教程，教別人將模擬器部分的arm64移除，其實大可不必。因為要支持M1機器正常跑模擬器，模擬器必須同時包含arm64和x86_64指令。
2019年的WWDC，apple提供了一種新的框架封裝格式XCFramework。簡單理解就是以前使用lipo合並不同指令集的包，現在則使用新的指令合並成XCFramework格式
打包成framework，格式如下：
打包成XCFramework後，格式如下：
從上述可以看出，XCFramework就是把兩個不同指令集的framework放入了同一個文件夾(.xcframework)，並生成了一個配置文件Info.plist。這樣生成的XCFramework就可以完美的解決M1機器無法編譯模擬器的問題。
XCFramework的創建指令也很簡單：
以現在的情況，很多第三方框架，並沒有使用XCFramework，而項目中只要有一個框架沒有支持模擬器的arm64指令，那麼在M1機器上，模擬器只能以Rosetta模式運行應用，對這一塊的普遍支持估計要等M1普及以後了。
蘋果換芯，成了開發者們的噩夢？
armv6、armv7、armv7s、armv8、armv64及其i386、x86_64區別
細說iOS靜態庫和動態庫
關於Xcode11的XCFrameworks框架
6. m1pro編譯android要多久
30分鍾。m1pro蘋果手機是一款可以進行編譯的手機，其中編譯Android需要30分鍾。Android是一種基於Linux內核（不包含GNU組件）的自由及開放源代碼的操作系統。