2006年12月13日

LEGO樂高-維京城堡

之前看到這組城堡就很想買,今天下午剛好在在網路上找到了東東玩具,那裡大概是8折價還要再加80元運費,總共大概2479元,不過賣完了,缺貨。

於是我就花了一些時間搜尋新竹的玩具店,有人介紹奇新東西很多,價格也不錯。

下午便花了一點時間騎車去看看,不遠。東西的確不算少,新的好像都有個幾盒,不過沒有什麼夢幻逸品就是。所有的白標皆打85折,紅標據說是特價,沒有驗證便是。

那組城堡有貨,賣2549元,貴東東70元,嗯,要再考慮看看,叫老弟幫忙出錢好了,畢竟他也愛玩。可惜沒有滅星者戰艦。

Stack Allocation

之前曾經聽聞Java SE 6會支援stack allocation。但根據剛剛google的結果,似乎要到下一版(7)才會支援囉。

此最佳化簡單來說,就是透過分析(escape analysis),將建立於某函式中的所有物件,挑出那些當離開此函式後便不會被使用的,將之存放於stack上。當函式結束執行時,便可隨著stack一起被釋放。

相對於傳統的方式,所有的物件皆存放於heap,stack上只存放指到heap上物件的reference。物件的釋放統一由GC來管理。

stack allocation好處很多:減少GC時間、減少GC次數等。一些講求即時性的嵌入式Java環境,通常會大量(甚至只准)使用stack來存放物件,原因無他,GC通常是極難為預測的,不論是發生的時間點或延遲時間。

2006年12月12日

Java SE 6 released!!

剛剛再找一些關於JSR-292以及JSR-223的資料時,無意間發現Java SE 6正式版推出了!!

根據ijliaoSundararajan以及Danny Coward,SE 6已經正式支援JSR-223,包含Scripting API供scripting engine存取Java程式的資料,並內建由Mozilla's Rhino來的JavaScript engine。

scripting.dev.java.net列表來看,有一些似乎很熱門的語言都有對應的engine了,像是PythonRuby等等...

Nicholas提出一個有趣的構想,使用JSR-223內建的JavaScript來實做一個類似RoR的框架。

開發Java應用的語言看來會越來越多樣化,尤其是講求快速開發的類script語言,如何彌補彈性造成的效能問題,如何更容易的在JVM上實作各種語言特定的功能等,這些都將會是可以好好研究的議題,事實上,JSR-292就是為了這些問題而提出的,可惜目前還在制定的階段。

2006年12月7日

Keroro的秘密基地!!

今天在酷玩摩人→玩具人爆走看到這個好東西的介紹,其實上個月我在台北地下街就看到有人在展示,當時就很想用力敗下去,但是似乎沒有販賣。隔了兩星期後我和魚仔在新竹城隍廟附近逛玩具店時,在靠近門口的一堆特賣品上,赫然擺了這個秘密基地,當下我立刻殺去領錢,哈哈。

要推薦一下那家玩具店,可惜我忘了名字,他是靠近城隍廟的兩間玩具店中較遠、在小吃店旁的那家:p為什麼要推薦呢?因為我只花了450 coco,不是酷玩摩人說的500~700,也比奇摩購物的599便宜喔。

總之,真的是物超所值,好玩又便宜,那天我和魚仔可是組裝的挺開心呢,哈哈。

Blogger Beta

花了一點時間轉換到Blogger Beta,因為目前Google還沒提供簡便的轉換法,因此我就用手動的方式將舊站裡的文章和範本轉了過來,幸好資料不多。

Blogger Beta最大的不同點就是,所有的blog頁面不再是靜態產生的,而是採用動態網頁的方式,這提供了很多可能性,其中之一是權限控管。

另外就是Google帳號的整合了,現在同一個帳號可以使用的服務真是越來越多了,想必這是google霸業的一部份了吧?

操作上大致和原本的Blogger相同,只有一些微小的差異,文章多了類似Gmail貼標籤的功能,可惜沒有把Google Docs的功能整合進來,不過Google Docs本來就有支援Blog的編寫了。

另外最大差異就是網站範本的編輯功能了,多了類似Google Pages的所見即所得編輯方式,如下圖:
我目前還是使用舊的文字範本,因為新的編輯方式不相容舊的文字範本,等之後有空在仔細把玩新的系統。

比較麻煩的是,Picasa Web Albums不支援直接上傳PNG圖檔,而blogger的圖檔上傳功能有問題目前是暫時放在flickr

另外,Google各種服務似乎都有其獨特性,而且相似功能也都逐漸整合,不像Yahoo提供了三個相當相似的網路相簿功能:flickr、我的相簿、部落格相簿等...不知道是否有任何整合的計畫,否則可能會讓使用者相當困擾吧?

2006年12月6日

Compiling program targeting 32 bit on linux X86-64

沒想到,第二篇文章會這麼久時間才出來,懶惰的個性要改啊-.- 。

今天因為無聊,想在實驗室的電腦上跑一些程式,才發現有很大的問題。因為實驗室機器是安裝Ubnutu 6.06 X86-64版,gcc預設產生x86-64,glibc則是64位元版,更不用說其他的函式庫了。

直接將程式移植到64位元或許會省掉一些編譯上的麻煩,但是可能會有其他的問題產生,就拿我測試的程式(好吧,就是phoneME Advanced)來說好了,他包含了一些必要的組語檔案,這部份可能要以64位元的規範重新改寫。另外也不確定是否對於平台的data type有無任何假設(e.g long是32 bits, long long則是64 bits)。這些工作我暫時沒什麼興趣去作。

因此,方向就變成搞定編譯方式,經過一番google,檢閱許多不甚清楚的討論外加嘗試錯誤後,終於搞定。步驟如下:

1. 安裝32位元程式庫
apt-get install lib32gcc1 lib32stdc++6 libc6-i386 libc6-dev-i386 ia32-libs
可以看需求再安裝lib32xxx以及ia32-libs-xxx的套件

2. 修改編譯參數
以phoneME Advanced為例:
修改build/linux-x86-generic/GNUmakefile,在ASM_ARCH_FLAGSCC_ARCH_FLAGS之後加上-m32要求GCC產生32位元的程式碼。然後在LINK_ARCH_FLAGS加上-m32 -L/usr/lib32指示linker把輸入通通看成32位元(預設是64位元),並從/usr/lib32搜尋需要的函式庫,linker會去預設目錄(/usr/lib:/usr/lib32)搜尋32位元的shared library。

3. 編譯收工

這樣就可以編出可以執行的32位元版本囉,只是好像速度會比較慢喔?我只簡單的和64位元版的JamVM比較過。就我之前的經驗,JamVM本來就比較快,可是不會差很多。但64位元版的jamvm和32位元版的cvm(就是phoneME Advanced啦)速度卻差了不少。我猜想這和64位元的linux怎麼去執行32位元的程式有關吧,需要再做一些survey。

事實上是因為,之前CVM測試的編譯組態不盡相同,在x86上必須設CVM_INTERPRETER_LOOP=Split,將interpreter設定由兩個分開的小interpreter組成,分別直譯不同的bytecode。主要的好處就是減少register pressure、增進instruction cache的locality。效能可以增加不少,但是會帶來一些壞處(X86 JIT的速度會大幅下降,原因不明)。如果只看interpreter的效能,還是比不上JamVM,主要差別來自於JamVM實做了direct threaded dispatch等技術(有空再來介紹吧)。

另外,根據Wikipedia這篇這篇,64位元程式還有可能的優勢:
  1. 多了8個一般register及8個floating point register可用
  2. RIP addressing mode可以加速shared library的連結
  3. 較好的ABI(可用register傳遞參數)
  4. 較大的定址空間
目前來看,64位元的JamVM的確比32位元的JamVM快不少(尚未精確量測),值得玩味的是,在i386下因為register pressure所以預設關閉的stack caching,在x86-64下開啟後效能同樣會變差,即使多了不少register?