2008年7月24日 星期四

Windows 好而 Linux 下不好的地方

Standard
活在 Linux 世界,若這樣大力稱讚 Windows ,應該會招來不少毒舌批評。但仍然不可抹滅的是, Windows 在許多地方的確比 Linux 優良,很多不是技術比較的問題,而是歷史演變所造成的既定結果。

相信許多人正在忙著解決 Linux 上,程式視窗太大而超出螢幕的問題。尤於低價電腦的風行,讓螢幕出現了許多不可思議的規格,如 800x480、1024x600 等等。所有的規格硬是比標準的短了點,因此造成許多原本在 800x600、1024x768 下運作正常的程式,都有視窗太大的問題。除了一些 GNOME 設定程式有此類問題之外,其中最嚴重的大概就是 evolution 的對話框。

Microsoft Windows 看起來就沒有這樣的問題,每一個對話框都好好的待在螢幕範圍內,絲毫未超出去。雖然無法保證所有軟體都正常,但至少 Microsoft 自家的程式都是沒問題的,令人不得不去誇讚一下,尤其在改完這麼多 Linux 下軟體的視窗大小之後呀。仔細想想,難道是 Windows 比較聰明?技術比較高超?為什麼可以在事先就想好這問題並避免掉它?

有一個很重要的原因,是因為所有的廠商,都是以 Windows 當基準來設計硬體,當然可以確保 Windows 是正常,而且不會有這種明顯的 Bug 存在。另一方面,是 Windows 打從娘胎起,就是針對 640x480 去設計所有的對話視窗,不僅 Win95 如此,Win98、WinME、WinXP等等皆是如此。當解析度調成 640x480 後,我們可以發現,還是可以正常使用 Windows 的所有功能。

對於不斷追求『效果』和『類 Mac』的 Linux ,可從來就沒想過這問題,大螢幕用慣了,都被寵壞了。一直到了現在,才發現有這樣的問題,不過也好,讓我這種不學無術的人有賺小錢活命的機會呀。 :-)

2008年7月8日 星期二

砍掉重練的 Bootchart

Standard
談到調校開機速度,就不免會提到運用『Bootchart』來分析開機狀況,這是一個將開機時的 CPU、IO、Process 等資訊畫成一張圖表的工具,在『Bootchart』的網站上就可以找到很多 Sample。其實,『Bootchart』的原理是利用一個在背景跑的 Daemon,每隔一段時間就取樣 CPU、IO 等系統資訊,等到開機完畢後,再將這些資訊畫成圖表。


在多數的電腦硬體中,Bootchart 都是可以正常運作的,可是在一些 Embedded System 下就會碰到不少麻煩,在『 elinux.org - Bootchart 』的 presentation 就有提到這一類的議題。其問題出在於取樣的 Daemon 是使用 shell script 所撰寫,不管是 sleep 等待下一次取樣、用 cat 讀取系統資訊或是使用 pidof 取得結束的 process,都會因為產生過多的 process 而造成可怕的系統資源消耗,其情況大致如圖:
在一些資源不多的 Embedded System 中,bootchart 會因為產生太多的 process 和 open IO,造成系統負荷過高,完全無法測得正確的開機狀況。所以,就有一些 clone 的專案,使用 C 語言將 bootchart 裡的 bootchartd 整個重新寫過一遍,『ubootchart』和『Bootchart-lite』就是因此而產生的專案。


這是利用『Bootchart-lite』在 OpenMoko Freerunner 上取樣並畫出來的圖表,因此發現其開機過程相當得可怕。 :P

2008年7月3日 星期四

Lilyterm 大躍進

Standard
前陣子提到各家 Terminal 和 VTE 的許多『問題和缺點』,其中提到,一個減少 VTE 用量的有效方法就是『多視窗共用 Process』。在當時,已知 gnome-terminal 、xfce4-terminal 和 Roxterm 等幾家 Terminal 有支援,而隨後 LXTerminal 也實作了出來該機制。方才瀏覽書籤,發現新版的『 Lilyterm 0.9.4』也實作出來了,在作者『Tetralet』的 blog 上提到。

另一項重點值得一提:在之前,大多數有同樣機制的 Terminal ,都是使用 D-bus 來達成 options 的傳送,這意味它們就必須要多一個 dependency ,而且在某些情況下, D-bus Launch 也會有一些額外的資源消耗〔太雞蛋裡挑骨頭啦!〕。所以,原生的 Unix Socket 是一個很好的替代方案,由於 Terminal 本來也並不太需要用到 D-bus 的特色,如此省下豈不樂哉。 :D

不過,目前在眾家 Terminal 之中,只有 Lilyterm 和 LXTerminal 鑽牛角尖,使用 Unix Socket。有興趣的人,或許可以參閱 source code。

2008年7月2日 星期三

張張沒特色,張張沒新奇

Standard
過去的鼠繪日子偷懶,連用 Photoshop 畫圖都模組化,畫給 MSN 用人物小圖裡,一張臉孔換髮型再加點料,就可以變成男、變成女,亦或變成各種心情。雖然張張平平無奇,但曾陪伴我在掛 MSN 的一些日子。



要是有是有人不嫌棄,就隨便拿去用好了,沒有任何使用限制條件。 :-)

2008年7月1日 星期二

使用 C 語言實作查表法取代 switch

Standard
就階層面來看, C 語言是個不高不低的語言,造成許多語法其實都可以有其他不凡的實作方式。尤其是一個看似基本且常用的方法,其實可能大量的暗藏玄機,值得我們惡搞。而對多數人來說,有一個一定不陌生的語法『 switch 』就相當有趣。在某些情況下,是否能利用『查表法』取代 switch,得到程式效能上的提升?此議題相當具有可探討性。

這是一個簡單使用 switch 語法的例子(switch_sample.c):
#include <stdio.h>

int main(int argc, char** argv)
{
int i;

if (argc<2)
return 1;

i = atoi(argv[1]);
switch(i) {
case 0:
printf("Hello! Mr. Zero\n");
break;
case 1:
printf("Hello! Mr. One\n");
break;
}

return 0;
}

編譯:
# gcc -o switch_sample switch_sample.c

實際執行:
# ./switch_sample 0
Hello! Mr. Zero
# ./switch_sample 1
Hello! Mr. One

仔細觀察該程式的內部運作,發現 switch 語法在編譯後實際執行時,是使用一連串的『比對』、『判斷』和『跳越』動作來達成任務,其實相當耗 CPU 的執行時間和寶貴的運算資源,若是 switch 的『設計龐大』,對 CPU 來說也是個相當可觀的負擔,尤其在許多 Embedded System 上會特別有明顯的影響。

由於 switch 的 CPU 時間消耗驚人,利用查表法來減少些比對判斷或許是個可行的方法。一般來說的查表法,是因為我們的資料需要『大量的運算』才能產生,所以『事先』計算好並建成一個數據表放在程式內部,以便程式在『真正執行』時直接快速提取其結果使用,而不必當場計算所需要的數據。又因查表的過程中,是直接對某個 pointer+N 去做存取資料,所以速度極快。

尋思,建表除了擺放一般數據之外,是否可以建立一個 function address 的表?並藉由表內的 address 直接 call function 執行動作?如此便可省下一大筆 CPU 判斷指令的執行時間。

經過實作(table_sample.c):
#include <stdio.h>

void switch_zero(void)
{
printf("Hello! Mr. Zero\n");
}

void switch_one(void)
{
printf("Hello! Mr. One\n");
}

int main(int argc, char** argv)
{
int i;
/* 定義一個表儲存函式位置 */
void (* switch_function[])() = { switch_zero, switch_one };

if (argc<2)
return 1;

i = atoi(argv[1]);
/* 直接 call 對應之函式 */
switch_function[i]();

return 0;
}

編譯:
# gcc -o table_sample table_sample.c

實際執行:
# ./table_sample 0
Hello! Mr. Zero
# ./table_sample 1
Hello! Mr. One

實作結果很順利,跑出了預期的結果。雖然分別寫成 function 時稍嫌麻煩,但若碰到大量 switch-case 的情況,相信效能會和辛苦成正比才是。