2008年11月25日 星期二

挑戰自己的能力極限 - 寫出最好的程式

Standard
寫出漂亮的程式碼,是每個寫程式成痴的 Coder 所追求的,對這些人來說,每次的寫作都是在追求自己能力的極限。常耳聞,有人面對自己寫出的程式碼,可獨自欣賞久久不能自己,飲茶配酒又吟時作對以讚嘆那數十行的程式,撇清自戀成份不談,其中面對那追求頂尖的程式碼之美的渴望,可想而知。

就有一些 Online Judge 網站,提供大量的程式題目,讓高手們痛快的挑戰自己的極限,其中有人追求的是程式碼長度,有的則是追求程式的效能,網站內的評分項目雖不盡相同,卻同是追求各種程式撰寫的極限。此外,排名機制和資料庫可以讓我們清楚看到,自己在面對世界各地的高手時的程度差距,更進一步相互交流。深思『為什麼可以寫出這樣的程式?』以提升自我。

在此推薦一個網站:

http://www.spoj.pl/

對程式痴人來說,在閒暇時挑戰寫程式的極限,也真是不錯的休閒活動。而想要精進自己寫程式能力的人,由此緞練一番,確也是很好的方法。

後記

慚愧

2008年11月24日 星期一

實作 Print Binary

Standard
經常做二進位的運算在 Debug 時也常會需要檢視一下二進位形式的數值內容可以自己寫一個函式去 Print 出來,因此筆記在這以後隨時可以 Copy & Paste :P

void print_binary(int type)
{
int size = sizeof(int) * 8; /* 1 Byte = 8 bits */
int i = size - 1;
char s[size+1];

while (i+1) {
s[i--] = (1 & type) ? '1' : '0';
type >>= 1;
}
s[size] = '\0';

printf("%s\n", s);
}

2008年11月10日 星期一

快速開機實作瓶頸簡記

Standard
最近Fast Boot』、『快速開機』、『5 秒開機』、『XPUD』這些關鍵字紅到爆炸經常在快速開機的討論話題中所聽到。自從 EeePC 的推出自豪的標榜 15 秒開機後快速開機的話題越來越熱門,然後 Aspire One 驚人的 11 秒開機,讓開機的速度』一時間變成了各家研究的首要方向。不久前由知名 Penk 所發展的 7 秒開機 XPUD,直到最近 Intel Moblin 所展示的 5 秒開機,都著實讓人感到不可思議

接下來呢?難道 5 秒開機真的已經是極限了嗎?

由於到處打工,也碰到許多與相關的案子,近來更被許多老闆們要求進行加快開機的速度。進行加速的過程中從開始幾秒鐘為單位的計較,到最後連小數位以下的時間都要精精算計,每一次都證明了5 秒鐘似乎真的是極限

一個開機速度所會碰到的瓶頸大致上如下:
  1. Kernel Initializing
  2. Driver Initializing
  3. Filesystem Initializing
  4. I/O
通常 Kernel + Driver + Filesystem 使用 2 秒(經過數不清的調較和修改 kernel 後),Userspace Initializing + Xorg + Desktop Environment 用 2.x 秒,整個估算大概會是 5 到 6 秒鐘。經過測試其實應該有可以再加速的空間

仔細觀察了 KernelSynaptic Touchpad 就吃了 0.5 秒,IDE 的 probe 也吃了 0.6 秒,單是這兩支 driver 就吃掉了近五分之一的開機時間實在是慢的驚人。其中有趣的是,通常在 netbook 上ide1 沒有 Device,但在這部份卻要花上 0.16 秒,讓人很想要 dirty hack 接讓 kernel 閃過 ide1 的 scan。 :P

其實在整個開機流程中,最大的瓶頸在於 I/O,Userspace 的程式都伴隨著大量的 config file、Font、Library,如何提升載入速度是很重要的課題。這部份Moblin 的 Super Readahead 作法的確很暴力利用多引線平行榨乾 I/O,使重要的檔案預先載入。另外由於 SSD 讀取速度極快,一般來說將每個 block 加大,或也是個提升速度的方法,不過這部份還要待測

Xorg 現在很聰明不吃 config file 一樣自己跑得很開心,原因是他將自動偵測的機制放在裡面了,這樣讓 User 們不再需要了解痛苦的 X 設定,但確讓 X 的啟動速度拖慢了,在這部份,雖然已經有人再著手改進,如: Fedora OneSecondX,但目前還是要花點時間啟動 Xorg,想必還是需要再研究看看

在 netbook 上,一般的 Desktop Environment 已經被所謂的 Application Launcher 所慢慢取代,但無論如何,他們都有很多的 *.desktop 和 Icons 需要被載入,如何改進並加入 cache 機制就是一個很重要的方向,與其使用 Readahead 的方式去增進這部份的速度,還不如直接使用 cache 去解決

後記

將最近研究『Fastboot』的筆記大致隨筆了一下,許多想法還待實作,希望有朝一日能做到1 秒開機,不過現在看來真的是天方夜談。(笑!光 Kernel 都跑不完了)

咦!?要是把 Userspace 的東西強行植入 Kernel,會不會是一個可行的方法呢?反正這年頭就是要髒,髒才有錢賺不是嗎?

2008年11月6日 星期四

使用 inotify 監視某資料夾的一舉一動

Standard
在 Linux 下監視某個資料夾的變化,有很多種方法,可以土法煉鋼的定時去掃描、檢查修改時間,也可以去將檔案一一開啟比對,不過往往這些過程,都伴隨著大量且多餘的 IO 存取。對此,使用 inotify 就顯得比較方便且有效率。自從 hal 的出現後,我們已經可以使用 inotify 去攔截某個檔案或資料夾一舉一動的 event,若是整合 GLib ,短短數行即可實作出來。
#include <glib.h>
#include <sys/inotify.h>
#include <sys/types.h>
#include <errno.h>

void inotify_events_io_func(GIOChannel *channel, GIOCondition condition, gpointer data)
{
char buf[1024];
struct inotify_event *event;
gint index = 0;
gint len = 0;
gint fd = g_io_channel_unix_get_fd(channel);

while(((len = read(fd, &buf, sizeof(buf))) < 0) && (errno == EINTR));

while(index<len) {
event = (struct inotify_event*)(buf+index);

/* read events */
switch(event->mask)
{
case IN_MODIFY:
printf("MODIFY\n");
break;
case IN_CREATE
printf("CREATE\n");
break;
case IN_DELETE:
printf("DELETE\n");
break;
}

index += sizeof(struct inotify_event) + event->len;
}
}

int main(int argc, char* argv[])
{
GMainLoop *loop;
GIOChannel *channel;
gint ino_fd = 0;
gint ino_wd = 0;

/* inotify */
ino_fd = inotify_init();
ino_wd = inotify_add_watch(ino_fd, "/usr/share/applications", IN_MODIFY | IN_CREATE | IN_DELETE);
channel = g_io_channel_unix_new(ino_fd);
g_io_add_watch(channel, G_IO_IN, (GIOFunc)inotify_events_io_func, (gpointer)NULL);

loop = g_main_loop_new(NULL, FALSE);
g_main_loop_run(loop);
}

該範例將會監聽 /usr/share/applications 資料夾內的檔案更動 event ,並印出來。因為該資料夾是 FreeDesktop.org Spec 中用來記錄桌面 application 資訊的,當安裝或是刪除軟體時,即會收到檔案新增或刪除的 event。