之前看到這組城堡就很想買，今天下午剛好在在網路上找到了東東玩具，那裡大概是8折價還要再加80元運費，總共大概2479元，不過賣完了，缺貨。
於是我就花了一些時間搜尋新竹的玩具店，有人介紹奇新東西很多，價格也不錯。
下午便花了一點時間騎車去看看，不遠。東西的確不算少，新的好像都有個幾盒，不過沒有什麼夢幻逸品就是。所有的白標皆打85折，紅標據說是特價，沒有驗證便是。
那組城堡有貨，賣2549元，貴東東70元，嗯，要再考慮看看，叫老弟幫忙出錢好了，畢竟他也愛玩。可惜沒有滅星者戰艦。
2006年12月13日
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通常是極難為預測的，不論是發生的時間點或延遲時間。
此最佳化簡單來說，就是透過分析(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正式版推出了!!
根據ijliao、Sundararajan以及Danny Coward，SE 6已經正式支援JSR-223，包含Scripting API供scripting engine存取Java程式的資料，並內建由Mozilla's Rhino來的JavaScript engine。
由scripting.dev.java.net的列表來看，有一些似乎很熱門的語言都有對應的engine了，像是Python、Ruby等等...
Nicholas提出一個有趣的構想，使用JSR-223內建的JavaScript來實做一個類似RoR的框架。
開發Java應用的語言看來會越來越多樣化，尤其是講求快速開發的類script語言，如何彌補彈性造成的效能問題，如何更容易的在JVM上實作各種語言特定的功能等，這些都將會是可以好好研究的議題，事實上，JSR-292就是為了這些問題而提出的，可惜目前還在制定的階段。
根據ijliao、Sundararajan以及Danny Coward，SE 6已經正式支援JSR-223，包含Scripting API供scripting engine存取Java程式的資料，並內建由Mozilla's Rhino來的JavaScript engine。
由scripting.dev.java.net的列表來看，有一些似乎很熱門的語言都有對應的engine了，像是Python、Ruby等等...
Nicholas提出一個有趣的構想，使用JSR-223內建的JavaScript來實做一個類似RoR的框架。
開發Java應用的語言看來會越來越多樣化，尤其是講求快速開發的類script語言，如何彌補彈性造成的效能問題，如何更容易的在JVM上實作各種語言特定的功能等，這些都將會是可以好好研究的議題，事實上，JSR-292就是為了這些問題而提出的，可惜目前還在制定的階段。
2006年12月7日
Keroro的秘密基地!!
今天在酷玩摩人→玩具人爆走看到這個好東西的介紹，其實上個月我在台北地下街就看到有人在展示，當時就很想用力敗下去，但是似乎沒有販賣。隔了兩星期後我和魚仔在新竹城隍廟附近逛玩具店時，在靠近門口的一堆特賣品上，赫然擺了這個秘密基地，當下我立刻殺去領錢，哈哈。
要推薦一下那家玩具店，可惜我忘了名字，他是靠近城隍廟的兩間玩具店中較遠、在小吃店旁的那家:p為什麼要推薦呢？因為我只花了450 coco，不是酷玩摩人說的500~700，也比奇摩購物的599便宜喔。
總之，真的是物超所值，好玩又便宜，那天我和魚仔可是組裝的挺開心呢，哈哈。
要推薦一下那家玩具店，可惜我忘了名字，他是靠近城隍廟的兩間玩具店中較遠、在小吃店旁的那家: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、我的相簿、部落格相簿等...不知道是否有任何整合的計畫，否則可能會讓使用者相當困擾吧？
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_FLAGS、CC_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位元程式還有可能的優勢：
今天因為無聊，想在實驗室的電腦上跑一些程式，才發現有很大的問題。因為實驗室機器是安裝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_FLAGS、CC_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位元程式還有可能的優勢：
- 多了8個一般register及8個floating point register可用
- RIP addressing mode可以加速shared library的連結
- 較好的ABI(可用register傳遞參數)
- 較大的定址空間
訂閱：
文章 (Atom)