Author Archives: Claud

x32 ABI

kernel 3.4发布了,其中一个更新是加入对x32 ABI的支持。

与此前曾介绍的armel与armhf关系一样,x32并不是intel处理器的一种新架构,而是在intel 64位处理器上(也许将来也会用到ARM上?)的一种二进制程序调用规范。它的主要想法是:

在64位处理器上,所有的指针自然也应该是64位的,但很多应用程序在运行时并不需要超过4GB的内存,因此64位的指针是浪费的。这些浪费体现在程序大小上、程序运行后可执行代码占用的内存上,当然这些都是相对来说不必考虑的,但从CPU cache的角度考虑,64位的指针和32位的指针,对本来容量就很小的cache就意义重大了。从逻辑上,32位指针应该可以让cache缓存更多内容,并且在一致性维护上的开销更小。

但如果在64位CPU上纯粹地以兼容模式跑32位程序,又无法充分利用64位CPU的一些特性,例如更大的寄存器、更快的函数参数传递、更快的浮点运算、更快的syscall等。

因此,出现了x32这种折中。与armhf类似,它的改动也很简单:在x64 ABI基础上,将指针全部改为32位。

一份性能测试结果如下(完整介绍在这里):

On Core i7 2600K 3.40GHz:
Improved SPEC CPU 2K/2006 INT geomean by 7-10% over ia32 and 5-8% over Intel64.
Improved SPEC CPU 2K/2006 FP geomean by 5-11% over ia32.
Very little changes in SPEC CPU 2K/2006 FP geomean, comparing against Intel64.
Comparing against ia32 PIC, x32 PIC:
Improved SPEC CPU 2K INT by another 10%.
Improved SPEC CPU 2K FP by another 3%.
Improved SPEC CPU 2006 INT by another 6%
Improved SPEC CPU 2006 FP by another 2%.

作为一种独立于编译工具和应用程序的通用优化方法,这种改进的效果可以说是非常显著而有价值的。

虽然说起来简单,但实际要做的工作并不少。因为这两种调用约定在二进制级别并不能兼容,从armel到armhf迁移的经验来看,需要的工作应该是:开发工具链、内核支持和迁移、公用代码库迁移、常用软件迁移等。这一次kernel的更新,应该是指第二步已经完成了。

linux社区在armhf和x32这两种新的ABI上的动作,给我两种感觉:从小的来说,随着编译优化的不断前进,以往忽略的ABI可能是性能的瓶颈,在这方面是否还有进一步修改优化的余地?从大的看,ABI这种已经形成实施标准的东西,居然也是可以迁移和并存的,考虑另一些领域,例如网络、例如总线,在广泛应用的事实标准存在的情况下,有没有可能出现新的更优方案?以往总认为代价太大而不值得,但现在这两件事提供了参考。

当前的阅读方法和工具

阅读是获得知识的主要途径(另一个是交流),怎么样挑选要阅读的内容、怎么样高效地利用工具以保证阅读效果和效率,是值得花心思的。

我把阅读分为几类:资讯、论文、书籍、延伸。对这四类,分别用不同的方法和工具来管理。

资讯

资讯的特点是:来源很多,每天都有,绝大部分不重要,但也需要看。从聚合的角度,最好的方式是RSS;从筛选的角度,很可惜,我知道的范围内,目前还没有新闻推荐的服务或应用。

主要的平台是Google Reader。国内也有很多在线或者本地的RSS阅读工具,使用Google Reader只有两个理由,一是简洁,二是能抓取墙外博客(blogspot上有不少高质量内容)。

在本地,使用Reeder阅读器,它的主要优点有三个方面。一,良好的阅读效果,包括一致性的排版以及内嵌的webkit浏览器;二,与Google Reader的完美交互,包括双向的同步,同步内容则包括订阅源、新闻、用户习惯,这样可以保证在本地的点击情况依然会被Google统计,进一步形成阅读趋势统计数据;三,与Safari的完美结合,可以自动发现页面的RSS源,一键订阅到Reeder中(最后同步到Google Reader上)。另外,Reeder支持发送到Read It Later(Pocket),这个非常棒。

在手机上,使用网易阅读器。主要是到现在仍然老土地使用2G网络,流量很少,所以希望有离线阅读功能。网易的新闻和阅读两个app是近一年我见过体验最好的两个应用,除了支持完全的离线,使用起来也很舒服。用网易阅读器读Google Reader中内容比较麻烦,因为网易想搞自己的一套服务,直接与Google Reader为对手。两种方法,一是把Google Reader中订阅的源一条条再导入到网易阅读器中(不得不说,后者的功能还是比较缺乏的,比如批量导入导出,比如所有新闻放在一起看等,都是基本需求),因为网易阅读至今还不支持不同来源混合到一起显示,只能一个个源地看,所以很不推荐——如果订阅了100个博客,在这里就会有100个栏目。另一种方法是,在Google Reader里对这些源做成群组,然后公开,拿到公开的atom源,导入到网易阅读器。主要缺点是,经常抓取出错。

内容管理上,我把所有源归为四类,一是个人的收藏,以小众网站和博客为主;二是普通媒体,大量产出价值不高新闻为主,例如cnbeta这样的水站;三是下载更新类的,比如itpub或者皮皮书屋,更新很多但只用看标题;四是工作相关的资讯和网站等。以前是按来源类型分,最后分类基本没有意义了。这样分,对个人收藏的类别,一般都是精读;对普通媒体,时间很多的时候或者无聊的时候翻一翻;对第三类,定期排查,就可以了。

此外,关于前面提到的Read it later,可以把所有需要细读的文章离线下载到手机里或者本地,利用空闲时间来读。

论文

对论文和报告,最近开始用Papers2来读。这是个非常棒的本地科研管理平台,对阅读pdf来说,全文搜索、高亮标注、页内笔记等,都是很实用的功能。其他方面,包括论文管理、导入导出、检索等方面也很完美。只希望以后会出现论文推荐的功能。

书籍

目前用Kindle DXG。普通Kindle用来读非技术书已经足够了,而且便携。但是看里面有代码的,有图表的,还得是DXG。把系统升级到3.2.1,然后越狱刷中文字体后,无论是显示效果还是刷新速度,都已经可以接受。

关于在amazon买书,如果淘宝一下,会有意外的收获。

实体书依然无法替代。一是Kindle实在不适合随机翻;二是还是有一些中文书不错的。

大的打算是,希望把实体书逐渐电子化,用Papers2来管理和阅读。

延伸

与学习一样,阅读最大的问题不是没去看什么,而是不知道自己没看到什么。也就是说,依然存在如何扩宽视野,接受别人推荐的问题。

对书籍,现在用豆瓣来管理,然后用豆瓣的推荐功能,基本ok。

对资讯,目前用Reddit和Hacker News两个平台,看看相关topic下热门的话题是什么,看看别人推荐的东西。

再次可惜一下,我知道的范围内,还没有针对资讯和论文的个人阅读习惯的推荐服务。希望哪一天可以看到。

保护树木,无纸生活

在《Linux/Unix设计思想》中,提到“保护树木”原则。大概意思是,数据应该存储在内存、磁盘或者网络上;一旦将其打印到纸上,就无法再次移动、筛选、排序、修改、转换、检索、加密等。

看到这里,把“数据”缩小一下范围,变成书籍、论文和笔记这几样东西。发现以往的想法确实有些问题。

看实体书,如何快速查询某一个关键词?怎么摘录?怎么做笔记或者标记?做了笔记/标记以后又怎么提取它们进行分享?怎么再次查找?对论文、对写到笔记本上的笔记,也有同样的问题。

相反,如果用电子书、电子版论文、电子的笔记,上面的问题就都很好解决了。这也是一个数据处理的问题,当数据固化到纸面上,不论是打印下来的还是手写下来的,就无法再次处理了。而从Unix的观点看,无法再次数据的数据,价值为0。

把这些阅读和记录,从纸质媒介转到电子媒介,遇到的主要问题可能是工具。硬件上,笔记本、平板、手机是自然的选择,而且各有其用(但是感觉用MacBook Air的话,平板可以省掉)。软件上,阅读和笔记软件,最近在使用Papers、Evernote和FreeMind,感觉还不错。尤其是Papers中对PDF文件的管理、批注、高亮功能,非常棒。

另一个问题是电子的书从哪里来。目前的解决方案是,看amazon的kindle书。绝大部分值得读的书,都有出kindle版。最后的问题是国内的书,这个只能尽量采用图书馆共享的方式了。

从过去几个月的实践看,我对不用纸的阅读和记录很有信心。

评俄翻拍版《十二怒汉大审判》

57年美国的《十二怒汉》的经典程度是无需多言的,而2007年俄罗斯翻拍的《十二怒汉大审判》则让人非常无语。我的感觉是,《十二怒汉》就是为了体现陪审团制度,而《大审判》则是以这一名义,实际上映射俄罗斯的社会现状。这一目的很成功,但几乎把陪审团制度给完美的毁了,加上影片开头和结尾的两句“法律格言”,整体就显得不伦不类了。

Continue reading