Tag: core

CPU Core 之間溝通的時間成本

在 Hacker News 上看到「Measuring CPU core-to-core latency (github.com/nviennot)」這篇，專案在「Measuring CPU core-to-core latency」這裡，看起來是個有趣的研究，測試許多不同 CPU 內，跨 core 之間溝通的時間花費。

依照專案的說明，測試的方式是利用 cache coherence 來來量測：

We measure the latency it takes for a CPU to send a message to another CPU via its cache coherence protocol.

By pinning two threads on two different CPU cores, we can get them to do a bunch of compare-exchange operation, and measure the latency.

裡面已經測了很多不同的 CPU，然後可以看到一些有趣的結果。

像是第一張圖片的「Intel Core i9-12900K @ 8+8 Cores (Alder Lake, 12th gen) 2021-Q4」這組，大家還蠻好奇 CPU #8 到底是怎麼一回事，跨 core 溝通的 latency 特別低，還特別找了 CPU 的 die 圖片看看：

另外一個是 AWS 上的 c6a.metal，機種是「AMD EPYC 7R13 @ 48 Cores (Milan, 3rd gen) 2021-Q1」，可以看到被分成了六個區塊：

接下來在 ARM 平台，在更多 CPU core 的 c7g.16xlarge 上，機種「AWS Graviton3 @ 64 Cores (Arm Neoverse, 3rd gen) 2021-Q4」，會看到更多不平均的現象：

早一點的 c6gd.metal 雖然也還是 ARM 的 64 cores 機種「AWS Graviton2 @ 64 Cores (Arm Neoverse, 2nd gen) 2020-Q1」，但可以看到很不一樣的 latency pattern：

大致上可以感覺到當 core 數愈多就會有很多技術上的瓶頸，導致不同 core 之間的溝通成本不一樣... 這個感覺跟當初學到 NUMA 的情況有點像。

Google Cloud 宣佈明年關閉 IoT Core Services

Hacker News 上的「Google IoT Core will be discontinued on Aug. 16, 2023」這篇，大家在討論 Google Cloud 宣佈明年關閉 IoT Core Services 的事情，基本上討論的內容大概都想的到...

AWS 這邊的話，最近比較有印象的就是要淘汰 EC2 Classic (EC2-Classic 的狀態)，但到現在還是在跑。

另外一個是把 Xen 架構 porting 到 Nitro 上 (AWS 將新的 Nitro 架構回過投來支援以前 Xen 的機種)，讓原有的 Xen 應用可以繼續用。

久一點以前的 SimpleDB 到現在也還是活著，官方現在應該是主力在推 DynamoDB。

兩種完全不同的作法...

獨立遊戲創作者推出 Linux 版的好處

標題不知道怎麼下，大概就是這樣...

從 Hacker News 首頁上翻到的，以這個 upvote 數量來看，應該會收到今天的 Hacker News Daily 上：「Despite having just 5.8% sales, over 38% of bug reports come from Linux (reddit.com)」。

作者是一位獨立遊戲開發者，在兩年前推出了「ΔV: Rings of Saturn」這款遊戲，並且也發佈了 Linux 版。

作者先就數字來比較，他賣出了 12000 套，其中 700 套是 Linux 玩家；另外他收到了 1040 個 bug report，其中大約 400 個是從 Linux 玩家回報的：

As of today, I sold a little over 12,000 units of ΔV in total. 700 of these units were bought by Linux players. That’s 5.8%. I got 1040 bug reports in total, out of which roughly 400 are made by Linux players.

That’s one report per 11.5 users on average, and one report per 1.75 Linux players. That’s right, an average Linux player will get you 650% more bug reports.

看文章時可能會覺得「Linux 玩家真難伺候」，但實際上作者講到，這 400 個 bug 裡面只有 3 個 bug 是平台相關的 (只會發生在 Linux 上)，其他的 bug 其實是所有平台都會發生：

A lot of extra work for just 5.8% of extra units, right?

Wrong. Bugs exist whenever you know about them, or not.

Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. The rest of them were affecting everyone[.]

原因是 Linux 社群在參與各種 open source project 養成的習慣，會盡可能把各種資訊講清楚，並且找出可以重製問題的方式：

The thing is, the Linux community is exceptionally well trained in reporting bugs. That is just the open-source way. This 5.8% of players found 38% of all the bugs that affected everyone. Just like having your own 700-person strong QA team. That was not 38% extra work for me, that was just free QA!

But that’s not all. The report quality is stellar.

與一般玩家的回報方式完全不同，Linux 玩家很習慣就會附上基本的環境資訊，系統紀錄，甚至有時候還會包括 core dump 與 reproducible steps：

I mean we have all seen bug reports like: “it crashes for me after a few hours”. Do you know what a developer can do with such a report? Feel sorry at best. You can’t really fix any bug unless you can replicate it, see it with your own eyes, peek inside and finally see that it’s fixed.

And with bug reports from Linux players is just something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps. Sometimes I got with the player over discord and we quickly iterated a few versions with progressive fixes to isolate the problem. You just don’t get that kind of engagement from anyone else.

不知道有沒有遇到回報 GDB 資訊的...

很特別的分享 XDDD

EnterpriseDB 買下 2ndQuadrant

算是 PostgreSQL 社群裡面的大事情，看到大老在討論 EnterpriseDB (EDB) 買下 2ndQuadrant 的事情：「Community Impact of 2nd Quadrant Purchase」，這兩家公司都是 PostgreSQL 社群裡面重量級的台柱。

先翻了一下新聞稿，兩邊的官方新聞稿分別是「How EDB Became the Leader in the Postgres Market」與「How EDB Became the Leader in the Postgres Market」。

回到原來的文章，裡面提到了 core team 的不成文規定，這個部份可以從 Contributor Profiles 這邊看到目前 core team 有五位成員，Peter Eisentraut 來自 2ndQuadrant，而 Bruce Momjian (這是文章作者自己) 與 Dave Page 則是來自 EnterpriseDB：

First, there is an unwritten rule that the Postgres core team should not have over half of its members from a single company, and the acquisition causes edb's representation in the core team to be 60% — the core team is working on a solution for this.

裡面有提到目前正在找辦法解決中，但不知道目前會怎麼解決，讓出位置可能是一個方法，加到七個人應該也是個方法，反正方法不算少，就等著看...

另外他提出來的兩個問題我覺得都還好，就是併購本來就會發生的事情。

這次的併購算是 PostgreSQL 社群裡面蠻熱鬧的事情，雖然是商業公司之間的併購，但社群這邊應該也會有不少變化...

AMD Ryzen Threadripper 3990X 在 Windows 上的效能

John Carmack 注意到在 AMD Ryzen Threadripper 3990X 上因為 Windows 的 group limit 限制而造成效能問題：

但這點可以透過打散到兩個 group 改善 (workaround) 而提昇速度：

然後順便看了一下目前 CPU Benchmark 網站上對於高階 CPU 的跑分數據「PassMark - CPU Mark High End CPUs)」，可以看到 AMD 最近真是香噴噴的，用 3950X (16C/32T，105W) 殺 Intel 目前最高分的 W-3275M (28C/56T，205W)，然後那個價差：

Intel 的 14nm 牙膏繼續擠...

Amazon EC2 推出 G4 系列機器

這次 Amazon EC2 更新了 G 系列的機器，其實會特地寫文章主要是在複習 P 系列與 G 系列的差異 (每次都記不起來到底哪個是給科學運算用的)：「Now Available – EC2 Instances (G4) with NVIDIA T4 Tensor Core GPUs」。

EC2 上的 GPU Instances 分成兩條線在發展，一條是 P 系列，另外一條是 G 系列，都是使用 Nvidia 的產品線。

從「Amazon EC2 Instance Types」這邊的「Accelerated Computing」可以看到每條產品線用了哪些型號 (扣掉 FPGA 的 F1)：

  • P3：Up to 8 NVIDIA Tesla V100 GPUs, each pairing 5,120 CUDA Cores and 640 Tensor Cores
  • P2：High-performance NVIDIA K80 GPUs, each with 2,496 parallel processing cores and 12GiB of GPU memory
  • G4：NVIDIA T4 Tensor Core GPUs
  • G3：NVIDIA Tesla M60 GPUs, each with 2048 parallel processing cores and 8 GiB of video memory

查了資料發現雖然時間點不同，但這四個都列在「Nvidia Tesla」這邊，裡面也沒有太多說明，所以還是看不出來差異，之後要碰到的時候再來還這個知識債好了...

MySQL 8.0-rc 的效能測試

Oracle 的 Dimitri KRAVTCHUK (dim) 做了測試，整理出 MySQL 8.0-rc 與其他版本效能的比較：「MySQL Performance : 2.1M QPS on 8.0-rc」。

不過先不管 MySQL 8.0-rc，這個測試其實也在說 MySQL 在 5.6 到 5.7 的過程中，對於高階伺服器效能改善非常的多 (有非常多 CPU core 的機器)：

就更不用說 5.5 版 (甚至已經沒支援的 5.0 & 5.1)，差距就更大了...

Markdown 轉電子書 (以及實體書) 的工具

看到有人用 Markdown 寫電子書：「How I wrote and published my novel using only open source tools」。

電子書的部份主要是透過 Pandoc 轉換，然後用 Dublin Core Metadata Element Set 提供 metadata。

實體書的部份也還是用 Pandoc 轉換成 ODT，而後面還是拿出 LibreOffice 對 page format 調整：

LibreOffice has many page formatting options that are non-obvious but incredibly important. For example, I wanted the first page of each chapter to be a right page, and to exclude the page header. I defined my chapter heading style to have a “page break before” and set a page style of “first page” (which is a right page without a header), which is followed by “right page”, which is followed by “left page”, which goes back to “right page”.

主要還是 Pandoc 這個工具，找機會來轉些東西看看效果...

Percona 對 mysql_query_cache 的測試 (以 Magento 為例)

Percona 的人以現在的觀點來看 mysql_query_cache：「The MySQL query cache: Worst enemy or best friend?」。

起因主要也是懷疑 query cache 是 global mutex 在現在的硬體架構 (主要是 CPU 數量成長) 應該是個負面的影響，但不確定影響多少：

The query cache is well known for its contentions: a global mutex has to be acquired for any read or write operation, which means that any access is serialized. This was not an issue 15 years ago, but with today’s multi-core servers, such serialization is the best way to kill performance.

這邊就有點怪了，PK search 應該是個位數 ms 等級才對 (一般 EC 網站的資料量都應該可以 memory fit)，不知道他是怎麼測的：

However from a performance point of view, any query cache hit is served in a few tens of microseconds while the fastest access with InnoDB (primary lookup) still requires several hundreds of microseconds. Yes, the query cache is at least an order of magnitude faster than any query that goes to InnoDB.

anyway，他實際測試兩個不同的 configuration，首先是打開 query cache 的：

再來是關閉 query cache 的：

測試的方式在原文有提到，這邊就不抄過來了。測試的結果可以看到關閉 query cache 得到比較好的 thoughput：

Throughput scales well up to somewhere between 10 and 20 threads (for the record the server I was using had 16 cores). But more importantly, even at the higher concurrencies, the overall throughput continued to increase: at 20 concurrent threads, MySQL was able to serve nearly 3x more queries without the query cache.

跟預期的差不多，硬體的改變使得演算法也必須跟著改，不然就會遇到問題...

支援多 CPU 的 ab：wrk

在「wrk」這邊看到 wrk 這個工具：「Modern HTTP benchmarking tool」。

利用 multi-threading 與 epoll/kqueue 撐出效能：

wrk is a modern HTTP benchmarking tool capable of generating significant load when run on a single multi-core CPU. It combines a multithreaded design with scalable event notification systems such as epoll and kqueue.