intel

Intel 對於在 E-cores 上面可以跑 AVX-512 指令集的計畫：AVX10.2

看到「Intel AVX10.2 ISA to enable AVX-512 capabilities on E-cores」這篇提到了 Intel 的技術文件「The Converged Vector ISA: Intel® Advanced Vector Extensions 10」，裡面提到了 Intel 後續對 AVX-512 的計畫。

主要是這張，可以看到在 AVX10.2 的規劃中會支援 E-cores：

不過目前還要等，這邊只放了一個 future 的說明：

目前的傳言是 2024 或 2025 會有 AVX10.1 在 Xeon 上出來：

Intel says that version 1 of the AVX10 vector ISA (AVX10.1) will first be implemented on Intel Xeon “Granite Rapids” processors that, according to some media reports, are expected to launch by 2024 or 2025, so it will likely take a long while before AVX10.2 is implemented on processors with E-cores.

但 AVX10.1 還沒有在 E-cores 上面執行 AVX512 的能力，所以 AVX10.2 應該是更後面...

Intel Arc 顯卡在 Machine Learning 上的運算

前面提到「AMD 平台上的 LLM 計算」，在「Testing Intel’s Arc A770 GPU for Deep Learning Pt. 2」這邊看到另外一家也在追趕的 Intel 對於自家顯卡 Intel Arc 在 ML 上的運算。

文章裡面是透過 Intel 自家的 OpenVINO 以及微軟的 DirectML 在存取顯卡資源。

這張最大記憶體是 16GB，對於 ML 訓練算是堪用？

話說 Intel N100 主機把 OpenCL 弄好後也可以跑 KataGo，當然速度沒有獨立顯卡那麼快，但比起純粹用 CPU 計算的速度還是快不少...

Amazon EC2 推出新世代 Intel CPU，以及奇怪的 Flex 產品

Jeff Barr 公告了 Amazon EC2 推出了新的 Intel CPU 產品線：「New Seventh-Generation General Purpose Amazon EC2 Instances (M7i-Flex and M7i)」。

先講 m7i，這個比較好理解，就是 Intel 新的 CPU，然後很隱晦的只宣稱了「比其他雲端廠商的 Intel CPU 快 15%」：

Today we are launching Amazon Elastic Compute Cloud (Amazon EC2) M7i-Flex and M7i instances powered by custom 4th generation Intel Xeon Scalable processors available only on AWS, that offer the best performance among comparable Intel processors in the cloud – up to 15% faster than Intel processors utilized by other cloud providers.

而與前一代的 Intel 機種相比 (應該是 m6i？) 則是高了 15% 的 CP 值：

The M7i instances are available in nine sizes (with two size of bare metal instances in the works), and offer 15% better price/performance than the previous generation of Intel-powered instances.

另外這次最有趣 (但未必好用) 的是推出了 m7i-flex，宣稱再「很多情境下」比 m6i 的 CP 值高了 19%：

M7i-Flex instances are available in the five most common sizes, and are designed to give you up to 19% better price/performance than M6i instances for many workloads.

這邊有提到 m7i-flex 是把 m7i 砍了 5% 價錢：

The M7i-Flex instances are a lower-cost variant of the M7i instances, with 5% better price/performance and 5% lower prices. They are great for applications that don’t fully utilize all compute resources. The M7i-Flex instances deliver a baseline of 40% CPU performance, and can scale up to full CPU performance 95% of the time.

但在「General purpose instances」這邊比較清楚，但可以跑超過 40% CPU 的時間限制在 24 小時內的 95%：

For times when workloads need more performance, M7i-flex instances provide the ability to exceed baseline CPU and deliver up to 100 percent CPU for 95 percent of the time over a 24-hour window.

這個設計頗微妙的，旁邊 ARM-based 的 t4g 就先不提了，至少不是 drop-in replacement...

看 m7i.large (2 vCPU + 8GB RAM) 在 us-east-1 的價錢是 $0.1008/hr，你可以完全沒有阻礙的用他 100% 的 CPU。

而 m7i-flex.large 是 $0.09576/hr，剛好省 5%，代價是有 5% 的時間必須壓在 40% 以下。

而拿 t3 系列的機器來比較，t3.large 也是有 2 vCPU + 8GB RAM，但他內建的 baseline CPU 是 30%，價錢則是 $0.0832/hr。

從這邊可以看出來，大多數的小應用還是會往 t3 甚至是 t3a 丟。

只有 24 小時的平均 loading 超過 40%，但又不是 24 小時都超過 40% 的應用，也就是現在應該是在 m6a 或 m6i 上面跑的，才有可能會評估 m7i-flex？

更不用說 AWS 上 m6a 的收費比 Intel 的 m6i 少了 10% 啊，這個產品定位在細算後很微妙：應該是有他可以出現的地方，但怎麼算都不多... 有點像是 AWS 跟 Intel 交代的產品？

但順著邏輯，這個方法其實是 billing-based 的方案，跟技術沒有太多關係，如果 Intel 可以做，那麼 AMD 與 ARM 應該也遲早會出現？

看起來像是 t 系列產品的延伸，但好像可以再等等，看會不會在 AMD 與 ARM 的產品線上推出類似的東西？

華碩接手 Intel NUC 的維護與後續研發

Intel 發新聞稿，說跟 ASUS 簽了約，讓 ASUS 接手 Intel NUC 的維護與產品研發了：「Intel and ASUS Agree to Term Sheet to Take Intel NUC Systems Product Line Forward」。

Today, Intel announced it has agreed to a term sheet with ASUS, a global technology solution provider, for an agreement to manufacture, sell and support the Next Unit of Compute (NUC) 10th to 13th generations systems product line, and to develop future NUC systems designs.

不過 ASUS 這邊網站上還沒看到新聞稿...

前幾天 Intel 宣佈要停止 Intel NUC 產品線，但當時沒看到接手的消息：「Intel Exiting the PC Business as it Stops Investment in the Intel NUC」。

有可能是消息出來後 ASUS 才去談的？或是一開始 Intel 就有找 partner 談，但談到一半消息先走漏了，但外面只聽到 Intel 不做？

Anyway，這樣 ASUS 算是官方指名的繼承人，讓後續要買的人可以過去看看；以 ASUS 本來就有自己的便當盒產品線 (像是 PChome 24h 上面的「ASUS－特規/改機專區品牌館」)，就是讓現有的團隊接手一個知名的產品線，不過本來跟精英 & 和碩的代工不知道會出現什麼變化...

在 Intel 內顯上面直接跑 CUDA 程式的 ZLUDA

Hacker News 首頁上看到的有趣東西：「Zluda: Run CUDA code on Intel GPUs, unmodified (github.com/vosen)」，專案在「CUDA on Intel GPUs」這邊，這是個最後更新在 2021 年的專案。

這個專案的想法可以猜得出來，想要吃 CUDA 的 ecosystem，把現有用 CUDA 的應用程式直接跑在 Intel 的 GPU 上面，這樣對於一些只有 CUDA 卻沒有 OpenCL 的實作就有機會拿來用。

一開始本來以為是給 Intel 新的獨立顯卡 Arc，結果發現是 2021 年就停更的專案，是以內顯來測試的：

ZLUDA performance has been measured with GeekBench 5.2.3 on Intel UHD 630.

從 benchmark 的結果看起來，大多數的功能應該都有 porting 上去，所以至少測試是能跑的，而不是 crash：

不過 Hacker News 的討論上可以看到似乎還是有問題，而且大多數的 AI 應用還是會回頭支援 OpenCL，似乎沒有那麼好用...

Intel 也出了字型

Hacker News 上看到「Intel One Mono Typeface (github.com/intel)」這個，Intel 也出了字型，以 open source license 釋出，GitHub 頁面在「Intel One Mono Typeface」這邊。

這次被拿到 Hacker News 上講的是 monospace font，官方提供的 sample 長這樣：

先前 Intel 有出過 Clear Sans，是以 Apache License, Version 2.0 釋出，不過從業面上可以看到已經不再繼續維護了。

蠻多廠商都有出自己品牌的字型，像是 IBM 的 Plex 系列，或是 Red Hat 的「Red Hat Typeface Files」。自己有做 OS 的廠商就更多了 (像是 Microsoft、Apple 以及 Ubuntu)。

現在換字型算是看心情的，一段時間就換一個...

Intel 用 AVX-512 加速 NumPy 的排序演算法被整合進主線了

Intel 用 AVX-512 加速 NumPy 排序的實做被整合進主線了：「「Intel Publishes Blazing Fast AVX-512 Sorting Library, Numpy Switching To It For 10~17x Faster Sorts」」。

GitHub 的 PR 在「ENH: Vectorize quicksort for 16-bit and 64-bit dtype using AVX512 #22315」這邊，可以看到相關的留言：

This patch adds AVX512 based 64-bit on AVX512-SKX and 16-bit sorting on AVX512-ICL. All the AVX512 sorting code has been reformatted as a separate header files and put in a separate folder. The AVX512 64-bit sorting is nearly 10x faster and AVX512 16-bit sorting is nearly 16x faster when compared to std::sort. ~~Still working on running NumPy benchmarks to get exact benchmark numbers~~

16-bit int sped up by 17x and float64 by nearly 10x for random arrays. Benchmarked on a 11th Gen Tigerlake i7-1165G7.

有點「有趣」的情況是，AVX-512 在新的 Intel 消費級 CPU 被拔掉了，只有伺服器工作站的 CPU 有保留。而 AMD 的 Zen 4 則是跳下去支援 AVX-512...

另外在「Intel Publishes Fast AVX-512 Sorting Library, 10~17x Faster Sorts in NumPy (phoronix.com)」這邊當然也有人提到，如果用更廣泛的 AVX2 (寬度是 256bits) 加速的話應該也會有很大的進步才對？幾乎這十年的 CPU 都有 AVX2 了... 不過看起來沒有什麼深入的討論？

幾個其他 Teams 的替代方案 (但還是連到 Teams 伺服器)

這邊講的替代方案不是換掉 Teams，而是找其他的方法連上 Teams 伺服器，畢竟用 Teams 的人大多都沒得選...

在「Teams is killing my Mac every day (microsoft.com)」這邊看到的一些資料可以嘗試，裡面有很多抱怨 Teams 的問題，但還是有些人有給出一些 workaround。

大家主要遇到的問題除了 CPU 吃很兇以外，另外就是記憶體這塊。

一種方法是是用 Edge 瀏覽器的 extension 來跑，我本來想看看 Linux 上的 Brave 能不能裝，但沒有看到對應的安裝連結，大概是 Edge 限定：

If you don't want to use the Microsoft Teams app (which uses a lot of resources), you can:

1. Install the Microsoft Edge Web browser on your Mac

2. Log into https://teams.microsoft.com

3. Click ... > Apps > Install this site as an app

This will create an Edge app for Teams that uses almost no resources but has feature parity with the regular Microsoft Teams app.

We tell all of our students to do this, and it has solved all Microsoft Teams performance issues on student Macs (both Intel and Apple Silicon).

另外有人提到其實官方是有放 M1 的 preview 版本的，雖然不是正式版，但總是比 Intel 版本會好一些：

If you're running an Apple Silicon Mac you can get an early build of Teams osx-arm64 from the exploration build link listed here.[0]

I've been running a daily build for a few weeks and it's noticeably better than the Intel build on an M1 Pro. It launches in half the time and feels far more responsive (probably due to not needing to use the Rosetta JIT for Electron). That said it's still a daily "exploration" build so YMMV.

[0] https://raw.githubusercontent.com/ItzLevvie/MicrosoftTeams-msinternal/master/defconfig

據說會少吃一點點記憶體，就真的大概一點點：

Can confirm it is snappier on a M1 Macbook Pro and using *less* RAM, maybe about 10% less.

但據說這個 preview 版本在自我更新時會跳到 Intel 版本，還要再找一下 workaround 關掉自動更新：

How do you prevent it from automatically updating to the Intel version? I keep downloading the preview builds and they keep getting updated.

後面還有看到有人說他直接實體隔離，把這些肥滋滋的 app 跑在另外一台 Mac 上，然後透過 Universal Control 使用，大多數的情況下都夠用，真的有需要分享畫面時再跑在自己機器上，用完就可以關掉：

Thanks for the tip. I'll give this a try!

For work, I have to run Microsoft Teams, Slack, and Discord. Of those 3, Slack surprisingly uses the least amount of memory (~700 MB), and Teams uses the most (~1.5 GB). I dusted off an old Intel Mac (literally) and interact with it using Universal Control. It only runs those 3 chat apps + mail. It's turned out to be a great way to offload resource hogs and as an added benefit, it minimizes distractions. I'll occasionally glance at the dock to see if there are any notification badges, whereas on my main Mac, I'd feel compelled to deal with notifications immediately.

When I have to share my screen or focus on a conversation, I'll fire up one of those 3 apps on my main (M1) Mac and quit it when I'm done.

Universal Control still feels rough around the edges, but it has saved me from ditching my Macbook Air and shelling out for an M1 Macbook Pro. Sometimes there are issues with reconnecting to the Intel Mac, but it seems to resolve itself if I wait a bit or turn off/on wifi.

大家都在找方法 XDDD

這次 OpenSSL 的兩個 CVE

難得在 Hacker News 首頁上看到 OpenSSL 的 CVE：「OpenSSL Security Advisory [5 July 2022]」，相關的討論在「OpenSSL Security Advisory (openssl.org)」。

第一個 CVE 是 RCE 等級，但觸發條件有點多：

首先是 RSA 2048bits，這個條件應該算容易發生的。

第二個是，因為這個安全問題是因為 OpenSSL 3.0.4 才引入的程式碼，而 OpenSSL 3.0.4 是 2022/06/21 發表的，未必有很多人有升級。

第三個是，因為這次出包的段落是用到了 AVX-512 指令集，一定要 Intel 或是 Centaur 的 CPU，後面這家公司前身就是威盛 (VIA) 的一員，去年賣給了 Intel (然後發現連官網用的 domain 都沒續約...)。

而 AMD 雖然在 Zen 4 架構上支援 AVX-512，但還沒推出產品，所以直接閃避 XD

另外第三個還有額外的限制，因為這次用到的是 IFMA 指令集，所以也不是所有有支援 AVX-512 的 CPU 都會中獎：

只看 Intel 的部份，第一個支援 IFMA 的是 2018 年推出的 Cannon Lake，這個架構只有一顆行動版的 Intel® Core™ i3-8121U Processor。

真正大量支援 IFMA 的是 2019 後的 Intel CPU 了，但到了去年推出的 Alder Lake 因為 E-core 不支援 AVX-512 的關係 (但 P-core 支援)，預設又關掉了。

所以如果問這個 bug 嚴不嚴重，當然是很嚴重，但影響範圍就有點微妙了。

接下來講第二個 CVE，是 AES OCB 的實做問題，比較有趣的地方是 Hacker News 上的討論引出了 Mosh 的作者跳出來說明，他居然提到他們在二月的時候試著換到 OpenSSL 的 AES OCB 時有測出這個 bug，被 test case 擋下來了：

Mosh uses AES-OCB (and has since 2011), and we found this bug when we tried to switch over to the OpenSSL implementation (away from our own ocb.cc taken from the original authors) and Launchpad ran it through our CI testsuite as part of the Mosh dev PPA build for i686 Ubuntu. (It wasn't caught by GitHub Actions because it only happens on 32-bit x86.) https://github.com/mobile-shell/mosh/issues/1174 for more.

So I would say (a) OCB is widely used, at least by the ~million Mosh users on various platforms, and (b) this episode somewhat reinforces my (perhaps overweight already) paranoia about depending on other people's code or the blast radius of even well-meaning pull requests. (We really wanted to switch over to the OpenSSL implementation rather than shipping our own, in part because ours was depending on some OpenSSL AES primitives that OpenSSL recently deprecated for external users.)

Maybe one lesson here is that many people believe in the benefits of unit tests for their own code, but we're not as thorough or experienced in writing acceptance tests for our dependencies.

Mosh got lucky this time that we had pretty good tests that exercised the library enough to find this bug, and we run them as part of the package build, but it's not that farfetched to imagine that we might have users on a platform that we don't build a package for (and therefore don't run our testsuite on).

這有點有趣 XDDD

Brendan Gregg 加入 Intel

先前有提到 Brendan Gregg 離開了 Netflix 的事情：「Brendan Gregg 離開 Netflix」，剛剛看到他發表他去 Intel 的消息：「Brendan@Intel.com」。

看起來是任何跟 performance 有關的都可以碰，但主力會放在跟 cloud 相關的產品線上：

I'm thrilled to be joining Intel to work on the performance of everything, apps to metal, with a focus on cloud computing.

不知道起頭會碰什麼東西，也許先花幾個月熟悉？