[Unix] Debug method

No matter what kind of language you use, this method can provide a way to debug. At first you need to set run the command “ulimit -c unlimited”. Then just run your program, onece it segmentation fault it will generate core-dump file. And then you can run gdb to start debug!!!

[bike] 2009/07/05 三峽之旅

久違了的腳踏車之行阿~~~

今天從南港—->公館—–>新店溪8.5km—->大漢溪—–>台三線—->三峽土城

total大約70km

雖然很熱, 但是偶而騎還是不錯, 不過我還是比較喜歡騎山路那種讓你心跳快暴掉的感覺, 上坡很累, 但是下坡很爽很有快感XDD

[python] Singleton pattern

This is what I found from internet, when you need singleton object in global.



class Singleton(object):

    _singletons = {  }

    def __new__(cls, *args, **kwds):

        if not cls._singletons.has_key(cls):

            cls._singletons[cls] = object.__new__(cls)

        return cls._singletons[cls]


So this is how to use this.


class SingletonQueue(Singleton):

    def __init__(self, queue=None):

        if queue != None:

            self._queue = queue

    def get(self):

        return self._queue.get()

    def put(self, item):

        return  self._queue.put(item)

    def size(self):

        return self._queue.qsize()

t = SingletonQueue()

a = SingletonQueue() # a == t

2009/04/31-05/04 嘉明湖+栗松溫泉 (part 2)

經過昨天在小屋算是相當充足的睡眠後, 今天我們就準備要下山了! 在山屋看著雲海上的日出, 一邊吃著早餐一邊享受山上最後的時光, 下山的路應該會比較輕鬆吧? 我想

今天的行程我們準備攻向陽山頂, 標高36xx, 不過路不是很遠, 所以大家很輕鬆就爬上去了, 我心中的雀躍, 這是我第三座百岳, 雖然才第三座, 但是我會慢慢增加的! 從這邊可以看到玉山山頂(OS: 我會認了!!), 這時愛國的阿里巴巴又開始國旗護身了XD, 我看著四周的高山, 一一詢問山名, 這時有一座山引起我的興趣, 就是北大武, 為什麼呢? 因為山下就是萬巒豬腳!! 爬完山後的大吃是我非常期待的:p, 有機會應該要去挑戰一下!

下山的路有點漫長跟無趣, 尤其太陽很大, 就這樣一步一步慢慢走, 就算戴著墨鏡我還是覺得陽光刺眼, 好不容易經過近五個小時的路程, 我們終於到達入口~

路上聽到小安曾經跟藏獒搏鬥過, 原來是他曾經為了論文獨自去溯溪, 然後走到一個很偏僻的地方, 那邊都是非法的養鳟場, 有人養藏獒來看門, 所以他就被狗咬, 不過也用岩鎚還擊了(OS: 果然是用生命寫的論文阿…)

這時候我們就分成兩批人, 一批人要回台北, 另一批人就是加碼栗松溫泉的:p, 由於時間的關係, 我們決定明天早上再去溫泉, 今天就好好休息

我們在南橫摩天農場休息, 我只能說這裡的老闆娘蠻有趣的(OS: 斯斯30年後的樣子?!), 這裡的環境真的不錯, 晚上吃著老闆娘準備的大餐~ 有溪蝦、山豬皮、高山高麗菜!

隔天一大早, 看到一抹陽光灑在雲上跟山上, 超漂亮的! 往溫泉的路不是說很好走(OS: 相對於嘉明湖), 到了下面還要涉水爬石頭(OS: 超冰的>”<), 路不是很明顯, 不過一切都是值得的, 景色真的很漂亮, 因為礦物質而綠色的山壁, 加上超碧綠清澈的溪水, 一整個就是人間仙境阿~~~~~ 特別是身處其中, 又可以泡溫泉喝脾酒~, 難怪泡完會軟腳XD

就這樣我這次的旅途結束了, 我們從東部回去, 我就這樣繞了台灣一圈了~

隨著一些旅行, 我發現了很多不一樣的事物, 也感受到我以前的無知, 人生, 還有很多美好的事物! 台灣, 這個彈丸大的小島, 其實我應該有超過50%的地方未曾去過吧, 所以何必出國呢? 或許是我曾在歐洲念過書, 旅行過一陣子, 生活過一段時間, 台灣的美好一點也不輸外國, 在山野中的這幾天, 我感受到人的渺小, 這大自然的一切, 是需要我們愛惜的, 希冀能夠讓更多的人體會到台灣的美!

2009/04/31-05/04 嘉明湖+栗松溫泉 (part 1)

第一天晚上在經過漫長的車程,我們就直接殺到嘉明湖的入口處睡覺, 車上果然不是很好睡>”<, 一大早在吃過簡單的早餐後, 我們30個人就浩浩蕩蕩的出發!

這次我的行李比起上次玉山行, 實在是輕很多, 加上也比較有經驗了, 步伐跟呼吸的調整, 所以走起來蠻輕鬆的~ 早晨的山中, 雲氣裊繞, 還可以看到漂亮的雲海! 中途發生了點小插曲, 原來是賴桑好像事前沒溝通清楚, 搞錯住宿地點, 結果小安直接衝下山去問清楚, 我們就在向陽小屋休息。

第二天我們走的不是很快, 到了避難小屋後, 大家也有點累了, 就沒直接攻向陽山頂, 結果沒想到, 還是出了問題, 我們的住宿跟吃飯都不夠, 趕緊又搭了好幾座帳蓬, 可是還是有點擠, 加上晚上蠻冷又吹風, 頭就蠻痛的(輕微的高山症…), 而且前一天打網球的小水泡也變的很大= =, 走起路來都不敢太用力QQ, 晚上我們睡著睡著就把帳蓬睡垮了…差點就掉到下面了XD

第三天一大早三點多, 我們就準備出發到嘉明湖去了, 在黑暗中出發, 風真的很大, 冷的我手幾乎沒感覺, 中間看到了抹了一片陽光的雲海, 那感覺很棒~ 我們途中就先登頂三叉山–3494高, 原來三叉山曾經發生過台灣最大的空難, 讓我十分驚訝, 是在日據時代的事情, 不過到了這邊, 嘉明湖也就近在咫尺了!

嘉明湖是由隕石坑所形成的, 所以它是死水, 但是跟松蘿湖不同, 當我到達的瞬間, 我覺得它的水蠻清澈的! 從山坡上往下俯瞰湖, 真的就像草原中的一滴眼淚, 不知道為什麼它讓我想到新疆那邊的湖, 就是被整個大草原所包圍, 然後應該有很多牛羊在這邊放牧XD, 不過在這邊也還算可以, 有水鹿會在這邊棲息(OS: 無緣一見阿T_T), 整個湖面在陽光反射跟風吹引起的水波下, 變的很漂亮! 這時候阿里巴巴帶的排球終於有用武之地了! 我們在這邊用湖水煮泡麵(OS: 真是人間美味…), 其實要不是大家用這邊的水煮東西, 我第一時間真想泡腳XD, 不過這水的溫度十分的低…下去游泳會抽筋吧XD

這時候以安突然說要解放, 我們幾個人就繞到稜線後面, 大家自己找位置, 不是我在說, 我從來沒有這種體驗, 一開始面對廣闊的山, 有點緊張, 後來慢慢放鬆後, 就覺得超爽的, 整個view超棒的!! 會讓人愛上這種感覺XD

吃飽喝足後, 享受完太陽浴, 我們就往回走~ 回程的路感覺很遠, 而且也很熱, 這時我的水泡讓我走起來更辛苦, 不過秉持著一步一腳印, 我們還是回到避難小屋了! 不過這時天空起霧了, 我們大家決定明天在去攻向陽山頂, 所以一下子, 我們就變的很悠閒了~ 整個下午就聊聊天等吃飯, 這次有了昨天的經驗, 大家一早就去排隊等吃飯(OS: 怕吃不到飯吧XD)

吃完跑去串一下門子, 玩了很白癡的心臟病, 小安跟小毛大PK~ 兩個在比反應慢的…整個帳篷大概擠滿了人吧XD, 不過本來是想要觀星看水鹿, 可惜天氣不好, 後來就睡覺去了, 這次我睡室內, 睡的比前兩天好太多了, 隔天精神也比較好!

(待續…)

相簿

[book] 搞定一切,還有時間玩

對於我這個時間管理十分糟糕的人, 這本書提供了一些方法, 讓我有機會改進, 我十分不能專心, 常常做某件事心理就想著別件事>”<

我列出幾點書中提到, 然後我覺得對我應該會有幫助的方法

  • 給自己一點思考時間
  • 限制每件工作的時間
  • 先做你心中最抗拒的事情 (完全說到心坎裡去了…)

不過目前的我, 做什麼事情都沒什麼時間壓力, 難怪效率十分不張阿…

[Erlang] priority message passing notes

在Erlang User Conference 2006上, 看到一篇關於Erlang message passing的slide, 覺得蠻有趣的

Ref: http://www.duomark.com/erlang/briefings/euc2006/index.html

這篇slide分成3個部份

第1部份是講基本語法

第2部份就是我比較感興趣的地方, 他提到一個有趣的問題

問題描述:
在利用Erlang接受message的時候, 如果有一種priority message, 只要一接收到這種message, 就要先執行相對應的工作, 但是在Erlang的message model中, 他有一個message queue, 所有的message都會被丟到這個queue裡面, 照順序接收,他並不保證有某些message接收的順序是比較高的, 所以我們應該要怎麼解決這個問題?

解法:
其實這個問題並不是很好解決, 他先提出兩種polling的方法, 但是都不是很好, 而且一個process當中最好不要有兩個以上的receive message statement, 可能會有memory performance的問題, 所以他給出利用protocol溝通的方式:

分成router, high process, low process and data store 4個process, 簡單來說router會控制現在是要讓high process還是讓low process去access data store, 所以利用protocol來判斷兩個process當中的message queue, 一旦high process有要處理的message, 就擋掉low process!

flow-chart

第3部份:

介紹一種(event programming) pattern, 來避免利用一大堆State machine來實作(以後更改太困難…).

Description:
central event loop will call associate method according to the message. After the method executed, it will return the control to main loop. The main loop will dispatch messages for multiple process instance which is not blocking! Central event loop can detect asynchronous process message!!

Code:

event_loop(M, S) ->
    receive
        {From, Event} ->
            dispatch(From, Event, M, S);
        {From, Ref, Event} ->
            dispatch(From, Event, M, S);
        Other ->
            io:format(”Unknown msg: ~p~n", [Other]),
            exit({unknown_msg, Other})

    end.
% Recv will be the asynch process id
event_loop(M, S, Recv) ->
    receive
      {From, Event} when element(From, Recv) == [] ->
            dispatch(From, Event, M, S);
      {From, Ref, Event} when element(From, Recv) == Ref ->
            dispatch(From, Event, M, S);
      {From, Ref, Event} when element(From, Recv) == [] ->
            dispatch(From, Event, M, S)
    end.
% M:Event method can be asynchronous process
% which will return {ok, NewState, Recv}
dispatch(From, Event, M, S) when atom(Event) ->
    handle(M:Event(From, S), M);

dispatch(From, {Event, Arg}, M, S) ->
    handle(M:Event(From, Arg, S), M).
handle({ok, NewState}, M) ->
    event_loop(M, NewState);

handle({ok, NewState, Recv}, M) ->
    event_loop(M, NewState, Recv).

[bike] 2009/04/11-12 北橫二日遊

Day 1:

板橋->復興->巴陵

騎起來蠻累的>”<, 中間太陽也很大, 真是一場耐力的考驗…

Day 2:

巴陵->明池->宜蘭->市區

不得不誇讚明池到巴陵這段路真的很漂亮, 難以言喻, 有機會我要載妹來這附近的嘎拉賀溫泉洗野溪溫泉!!

結語:
其實機車真是個不錯的發明XD, 讓人不必這麼累就可以享受到不一樣的風景!

相簿:

http://picasaweb.google.com.tw/yuteh.shen/20090411Bike1st#

http://picasaweb.google.com.tw/yuteh.shen/20090412Bike2nd#

[bike] 2009/04/22 陽明山竹子湖

繼上次征服北橫後

這次在雨中從內湖->自強隧道->東吳大學->仰德大道->文化大學->竹子湖

Total 53.44 km, 算是半天行程

除了雨中騎起來別有一番滋味

上山一開始車子超多的

我還被一大群野狗追了50m…偏偏上坡騎不快T_T

看了一下文化大學的學生, 我真應該念文化大學的QQ (沒事跑去什麼宅男大學…)

到了竹子湖

跟我期望有點落差(OS: 我以為竹子湖是湖….)

吃了地瓜豆花~~蠻爽的

不過後來整個起霧, 能見度超低

騎起來也蠻特別的XD

回程就是連續的下坡

因為路面很差, 我不敢分心看時速表

有喵到最快是49km/hr

不過水就一直往臉上噴

害我不敢張嘴, 眼睛也是不看的很清楚

最後順利回到家

Song! 還是家裡最爽XDD~~

p.s 文化大學對面的牛肉麵是我吃過最難吃的…

    我自己煮都可以比她好吃…

[note] Multi-core & parallel programming knowledge

Ref: http://cgi.taiwan.cnet.com/referral/?uid=2000006303

今天看了以上關於parallel programming 和multi-core 的一系列影片, 才知道自己過去的錯誤認知XD

Why multi-core:
原來最跑出這東西的原因有三項

  • power
    在目前已經很高的CPU clock rate下, 為了增加13%的clock rate, 可能導致73%的功率消耗, 但如果我們把性能降到87%, 我們幾乎可以節省50%的功率消耗
  • instruction level parallel
    在提升CPU clock rate下, 從現行程式中找到可以並行的指令是越來越難
  • memory
    memory access的速度跟不上CPU clock rate增加的速度

以上都是造成目前往multi-core CPU方向走的原因之一

Parallel method:

  • Data parallel
    divide data into different part, and do the same work in each data part
  • Task parallel
    divide task into different task, and do the each task  separately

但是跟據Amdahl’s Law “速度的提升受程式中serial部分的限制,所謂serial部分,是指程式中不能並行執行的部分”, 所以無論怎麼增加CPU, 效率上的提升還是有所限制, 但是後來跑出一個人Gustafson, 他提出另一種看法, 我們可以讓電腦處理的資料提升, 就像有個程式需要跑500單位時間, 我們把並行的部分(ex: 200單位時間)增加一倍, 也就是在500單位時間內, 我們跑完700單位時間的工作, 那麼之前提到的serial 影響就會降到很低。

這就是超級電腦能夠成功運用並行技術的關鍵所在——我們不斷增加資料集,因為有了多核心處理器。

Key about parallel project:

  • scalibilty
    how to scale to 4-core, 8-core, 16-core
  • corresiton
    • race condition
    • dead lock
  • maintainability
    high abstraction

Abstraction Parallel programming

  • library
  • OpenMP (openmp.org) for c
  • threading building block (threadingbuildingblocks.org) for c++

最後他提到了MPI(Message Passing Interface) http://www.mpi-forum.org/, 目前的multi-core 是以shared memory為前提, 我在想既然現在memory這麼便宜, 或許我每個core都讓他有自己獨立的memory (4G?), 然後全部以message passing來做, 不知道這樣的架構可不可行XD