Performance

Finally, I got my strlen(3) [1] committed against -HEAD. This is a long story, to put it short, I had proposed assembly version of some string operations at the point of 2005, but these was never committed due to a hard disk failure, and as Bruce pointed out, having the hand optimized assembly code use a different algorithm is not good in general.

Therefore, I have take some time on it and reimplemented the idea in C, resulting in a portable (say, you can use it on any 32-bit or 64-bit processors, and it can be easily extended to 128-bit) version.

So, is it important for *YOU*?

Generally speaking, it should not. Performance sensitive programs should, by all means, avoid C style string operations. Think a 5x better strlen(3) would boost performance of your application since it uses strlen(3) in critical path? Think again!

However, I found it valuable. There is difference in worldstone, where I saw some minor improvements. Micro-benchmark indicates that this version is at most 2x slower when the string is very short, but 5x faster for strings that is at least word-length long.

[1] Note: the version has been further revised to provide better comment and match style(9).

上次在MeetBSD的时候Tim提到了一种处理大量静态页的办法。今天看Squid开发人员在NYC的BSD活动上的一个演讲里面也介绍了各种方法处理I/O的区别。

今天起了一个大早，9:00到了位于 1600 Amphitheatre Parkway 的 Google 总部。

手头没有精确的人数统计，不过目测来看，大概有120－150人。看到的第一个见过照片的人是著名的 Cameraman 同学， DragonFly 的 Matthew Dillon 老大！

由于今年是 FreeBSD 计划成立15周年，今年的 MeetBSD ‘08 California 很大程度上是一次 FreeBSD 的活动。

现代操作系统中，抢占式调度是一个很有意思的话题。

教科书对于抢占式调度的定义比较简单—-抢占式调度中，任务切换动作可以由于优先级变化而触发，而并非仅限于时间片用完或主动放弃CPU（当然，一般而言我们并不认为中断处理是一次严格意义上的抢占操作）。

从直觉上看，抢占式调度必然增加潜在的上下文切换次数，并因为增加了这些开销而降低系统吞吐量。那么，为什么要引入抢占式调度呢？

John Birrell正式引入了DTrace支持，感谢 Cisco 公司的大力支持！

[delphij@charlie] ~> uname -a
FreeBSD charlie.delphij.net 8.0-CURRENT FreeBSD 8.0-CURRENT #33: Sun May 25 18:05:10 PDT 2008 delphij@charlie.delphij.net:/download/obj/data/src/sys/CHARLIE amd64
[delphij@charlie] ~> dtrace -V
dtrace: Sun D 1.6.1

An elegant tool for analysis of your website regarding its appearance slowness. Why is it slow?

What you need are:

• Firefox browser;
• The “Firebug” plugin'
• “YSlow” plugin from Yahoo.

前几天有人问 FreeBSD 的 top(1) 如何能够显示不同 CPU 的占用情况。这是 patch 过之后的输出：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

last pid:  1773;  load averages:  0.43,  0.19,  0.16                                                                                        up 0+00:34:35  16:17:04
97 processes:  1 running, 96 sleeping
CPU 0: 20.8% user,  0.0% nice,  0.0% system,  0.0% interrupt, 79.2% idle
CPU 1:  3.1% user,  0.0% nice,  0.0% system,  0.0% interrupt, 96.9% idle
Mem: 517M Active, 21M Inact, 577M Wired, 11M Cache, 48K Buf, 810M Free
Swap: 2048M Total, 2048M Free

 PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND  
 1236 delphij 1 104 0 232M 143M select 1 4:37 37.06% Xorg  
 1768 delphij 1 8 0 164M 52704K nanslp 1 0:07 36.28% kicker  
 1771 delphij 1 8 0 6212K 1664K wait 0 0:00 3.17% sh  
 1772 delphij 1 45 0 8020K 1656K select 1 0:00 2.39% ksysguardd  
 1756 delphij 1 20 0 10648K 3596K pause 1 0:00 1.17% csh  
 1754 delphij 1 4 0 11764K 1588K sbwait 1 0:00 0.78% gnome-pty-helper  
 1751 delphij 2 -8 0 136M 25756K piperd 0 0:00 0.68% gnome-terminal  

FreeBSD 8 中已经包含了这个功能。

Kai Wang has announced today the BSD ar(1) is available for wider testing. This is amazing work, the creation and list speed are 5-20 times faster than GNU ar(1), and extraction speed is also slightly better than GNU ar(1).

It is also important to note that this version is completely BSD-licensed (yes, that means that you are free from the lair’s license), and is a piece of the vital parts of the FreeBSD DTrace work.

最近看到 OpenSolaris 上面的 ZFS 引入了将 ZIL 写到另一个 pool 的方法。这种做法非常类似于 FreeBSD 2005年的 Google SoC 项目—-GEOM Journal。

简单地说，这种做法的原理就是将准备写的数据（注意，不是元数据，而是数据）首先写到固态盘上，然后再将数据写回。这样做有很重要的好处，即先前必须同步写入的数据（例如fsync()、文件系统元数据更新等等），可以不必做完整的回写，而只需将 SSD 作为回写快取缓存 (Write-Back Cache) 了。

做了一个试验，导一个10万多revision的svn库进来到trac里面，结果整整一个上午过去了，才导了一半。估计得等到下班才能有结果了吧。。。