calloc() 與 malloc() 的差異

前陣子在 Hacker News Daily 上看到的,原文是 2016 的文章:「Why does calloc exist?」,裡面講的東西包括了 implementation dependent 的項目,所以要注意一下他的結論未必適用於所有的平台與情境。

malloc()calloc() 的用法是這樣,其中 calloc() 會申請 countsize 的空間:

void* buffer1 = malloc(size);
void* buffer2 = calloc(count, size);

第一個差異是,count * size 可能會 overflow (而 integer overflow 在 C 裡面是 undefined behavior),這點除非你在乘法時有檢查,不然大多數的行為都還是會生一個值出來。

calloc() 則是會幫你檢查,如果會發生 overflow 的時候就不會真的去要一塊記憶體用。

第二個差異是 calloc() 保證會將內容都設定為 0,這點在 POSIX 的標準裡面是這樣寫的:

The calloc() function shall allocate unused space for an array of nelem elements each of whose size in bytes is elsize. The space shall be initialized to all bits 0.

但作者就發現 malloc() + memset() + free() 還是比 calloc() + free() 慢很多:

~$ gcc calloc-1GiB-demo.c -o calloc-1GiB-demo
~$ ./calloc-1GiB-demo
calloc+free 1 GiB: 3.44 ms
malloc+memset+free 1 GiB: 365.00 ms

研究發現是 calloc() 用了 copy-on-write 的技巧,先把所有的 page 都指到同一塊完全被塞 0 的記憶體,只有在真的寫到該段記憶體時,系統才會要一塊空間來用:

Instead, it fakes it, using virtual memory: it takes a single 4 KiB page of memory that is already full of zeros (which it keeps around for just this purpose), and maps 1 GiB / 4 KiB = 262144 copy-on-write copies of it into our process's address space. So the first time we actually write to each of those 262144 pages, then at that point the kernel has to go and find a real page of RAM, write zeros to it, and then quickly swap it in place of the "virtual" page that was there before. But this happens lazily, on a page-by-page basis.

但畢竟這是 implementation dependent,看看有個印象就好。

為線上環境而最佳化的 Ruby:Fullstaq Ruby

最近看到的「Fullstaq Ruby」,專為線上環境最佳化的 Ruby

Fullstaq Ruby is an MRI-based Ruby distribution that's optimized for server production use cases.

目前主要是使用 jemalloc (超萬用) 以及 malloc_trim patch:

It is compiled with the Jemalloc and malloc_trim patches, allowing lower memory usage and higher performance.

其中看了一下 malloc_trim patch 的介紹還蠻有趣的:「What causes Ruby memory bloat?」,這篇主要是在討論記憶體用量的問題,以及目前常見的 workaround。

這個 patch 是針對 Ruby 在 full mark GC 的情境後,增加呼叫 malloc_trim(0); 以釋放記憶體,作者發現這樣可以省下了大量的記憶體空間:

然後作者預期效能應該會有影響 (畢竟多做了一些事情),所以找了有在做 Rails benchmark 的人幫忙測試,結果發現反而變快了:

這樣看起來有可能官方會考慮把這個 patch 直接包進去?不過這看起來是在使用 jemalloc 的前提下?不知道如果使用標準的 glibc 會怎麼樣...

Microsoft 釋出一個效能極佳的 Malloc Library

Hacker News 上看到的:「Mimalloc – A compact general purpose allocator with excellent performance (github.com)」,專案網站在 GitHub 上:「mimalloc is a compact general purpose allocator with excellent performance.」。

現代伺服器軟體比較常用的應該是 jemalloc,許多軟體也直接把 jemalloc 包進去 (像是 Firefox),所以各種測試主要就是看與 jemalloc 的差異。

測試的機器有點怪,既然都是在 AWS 上測試,卻不是選目前主流的 Intel,而且就算是 AMD 也不是選最大台的 r5a.24xlarge (都是在去年 2018 年十一月發表的):

Testing on a big Amazon EC2 instance (r5a.4xlarge) consisting of a 16-core AMD EPYC 7000 at 2.5GHz with 128GB ECC memory, running Ubuntu 18.04.1 with LibC 2.27 and GCC 7.3.0.

尋著留言有看到 daanx/mimalloc-bench 這邊有使用 Intel 平台的測試,也有類似的結果,所以應該是還 ok...

Anyway,依據目前官方給的的效能測試,看起來頗不賴:

而且實際的記憶體用量也比以前少,這邊在看資料時官方有附註,有些測試在這邊因為執行方式所以不會準:

(note: the xmalloc-testN memory usage should be disregarded is it allocates more the faster the program runs).

至於實際上是不是真的在 general purpose 都可以提昇效能,應該會等著比較大的社群玩看看... 尤其是 Percona 對只要換個 library 就能提昇效能的東西,他們基本上都不會放棄嘗試...

兩個 gperf...

翻資料的時候覺得怎麼跟印象中的不太一樣,多花些時間翻了一下,發現原來有兩個東西同名...

一個是 GNUgperf,給定字串集合,產生 C 或 C++ 的 perfect hash function (i.e. no collision):

GNU gperf is a perfect hash function generator. For a given list of strings, it produces a hash function and hash table, in form of C or C++ code, for looking up a value depending on the input string. The hash function is perfect, which means that the hash table has no collisions, and the hash table lookup needs a single string comparison only.

另外一個是 Google 弄出來的 gperftoolsmalloc() 的替代品以及效能分析工具:

gperftools is a collection of a high-performance multi-threaded malloc() implementation, plus some pretty nifty performance analysis tools.

curl 的 refactor 減少 malloc() 的次數

curl 的作者 Daniel Stenberg 寫了一篇關於他 refactor 大幅改善了 curl 的效能:「Fewer mallocs in curl」。

藉由大幅減少 malloc() 次數,在抓大檔案時會有明顯的改善:

7.54.1-DEV repeatedly performed 30% faster! The 2200MB/sec in my build of the earlier release increased to over 2900 MB/sec with the current version.

另外如果對 localhost 抓 80GB 的話,可以看到時間大幅縮短:

Old code:

real    0m36.705s
user    0m20.176s
sys     0m16.072s

New code:

real    0m29.032s
user    0m12.196s
sys     0m12.820s

Percona Server 5.5.30-30.2 (based on MySQL 5.5.30) 的改善

Percona 在前幾天推出基於 MySQL 5.5.30 的 Percona Server 5.5.30-30.2:「Percona Server for MySQL 5.5.30-30.2 now available」。

5.5.30-30.2 這個版本引入了 jemalloc

Percona Server for MySQL will now be shipped with the libjemalloc library. Benchmark showing the impact of memory allocators on MySQL performance can be found in this blogpost. (Ignacio Nin)

在去年 (2012 年) 七月 Percona 就有分析過 glibc 與 jemalloc 對效能的差異:「Impact of memory allocators on MySQL performance」,可以看到在 concurrent active connection 數量愈高,jemalloc 的優勢愈明顯。

預設總算把 jemalloc 包進去了,等好久了...

另外一個是「trx descriptors: MySQL performance improvements in Percona Server 5.5.30-30.2」,針對 transaction lock 問題的改善。

這邊比較時都用 jemalloc,是因為 Percona Server 5.5.30-30.2 是用 jemalloc,比較時必須盡可能維持一樣的條件。

圖表可以看到 Percona 把 5.6 的改善方式再改善,然後 backport 回 5.5,使得沒有被飆為 read only transaction 的 query 也能受益。