系统技术非业余研究

即将发布的R14B01要支持ets的压缩，更大程度的提高内存的利用率。
在github上可以看到这个分支，有兴趣的同学可以下载下来看看。

压缩的时候只压缩value, key是不压缩的。 value特别简单类型的eterm也是不压缩的，因为zip压缩需要一定长度的内容，而且压缩本身也要加入一点的overload.

以下是sverker (author)的提交log.

ETS ‘compressed’ option.

The compressed format is using a slighty modified variant of the extern format
(term_to_binary). To not worsen key lookup’s too much, the top tuple itself
and the key element are not compressed. Table objects with only immediate
non-key elements will therefor not gain anything (but actually consume one
extra word for “alloc_size”).

我们来试验下吧：
Read more…

前端时间看到JVM的 64 pointer compress技术，蛮多感慨的。具体的可以 google
64位 pointer compress 来了解更多。

好不容易从32位系统中逃脱，解决了4G内存的问题，而且64位的cpu更多的寄存器，可以带来更好的性能。但是怎么又碰到问题了。64位的系统，64位的指针，意味着更多的数据访问， cpu速度是提高了，但是内存的带宽和访问速度没有大的提高。而且内存的访问速度和cpu的cycle差几个数量级别，所以对于普通的网络程序来讲，大部分是处理信息的变形，也就是说是把内存里面的数据从一个形式变成另外一个形式。 cpu性能的提高对这种程序来讲 影响不是很大。倒是因为数据的量加大了1倍， 导致整体的性能降低了百分几十。实际的硬件系统也没有那么多内存，一般都是16G以下，所以才有人去想在64位系统下，用36位的指针，减少内存的访问。

erlang的系统基本上是个网络程序，所以这个问题就非常突出。 目前没看到otp vm的这方面的打算， 我还是乖乖的用我的32位系统