Linode 推出免費試用方案...

Linode 一直是 Hacker News 的寵兒,其中有幾項與其他的 VPS 比起來相當突出:

  • 相當直覺而且簡單易懂的管理界面,另外還有 DNS 代管服務。
  • 超值的 CPU 用量,比起 AWS EC2 或是其他 VPS 的限制都寬不少。

另外價錢合理以及全球各地區都有機房也是很重要的特色。

不過國外有人寫了一篇關於 DigitalOcean 與 Linode 的比較文章後,Linode 就被打入冷宮了 XDDD

雖然 DigitalOcean 只有兩個點 (一個在美東,另外一個在歐洲),而且管理界面還有點陽春,但提供的品質與價錢遠遠超越 Linode... (請參考「DigitalOcean 與 Linode 的比較...」以及「測試 DigitalOcean 荷蘭阿姆斯特丹的機器...」這兩篇文章)

過了兩個禮拜後 Linode 總算反擊了:「Create a free account and Trial Linodes」,不過力道看起來很差啊,依照原文的說明是讓你試用 Linode 512 這個規格的機器幾個小時... XD

Once confirmed you will be taken to a welcome page (the Account tab), where you will be given the option to spin up a Linode 512 cloud server to play around with for a couple of hours.

對於台灣的使用者來說,Linode 有東京機房的服務還是相當有用的,有興趣的人可以跳進去測試看看 :p

CPU Branch Prediction 的成本...

在公司搞定一個速度最佳化的問題,想到之前在 Stack Overflow 上有看到 CPU branch prediction 的問題 (跟我解的問題應該沒關係,只是剛好想到),把文章找出來...

出自 Stack Overflow 上有人詢問某段 C++ 程式為什麼加上 sort 後快多了:「Why is processing a sorted array faster than an unsorted array?」。

發文者的範例程式已經簡化到很容易理解:先產生一個 32Kytes 的 array,然後裡面塞亂數。

接下來把每個 byte 當作 unsigned char,要找出這個 array 裡面所有值大於等於 128 的元素,把這些元素的值加起來。

原發文者發現,如果先把這個 array 排過再計算,十萬次只要 1.93 秒,但如果不排就直接計算需要 11.54 秒,時間差不多是原來的六倍。

回答的人答的相當詳細,還給了一個 branchless 的 hack 來解這個問題 (於是就不需要先 sort),很值得一看。

用 JavaScript 遠端攻陷 Intel Core2Duo...

Hacker News 上看到了「Intel Core2Duo cpu cache controller bug PoC」,透過 JavaScript 遠端攻擊 Intel Core2Duo,直接突破所有 application & OS 保護機制... exploit 說明裡提到測過 Intel Core 2 Duo T5750Intel Atom N270 這兩顆 CPU。

另外,從 exploit 給的資料中,可以找到 Kris KasperskyHITB 2008 給出來的 PDF:「Remote Code Execution through Intel CPU Bugs」。

居然用 JavaScript 戳...

Update:很像是假的:「http://news.ycombinator.com/item?id=4246338」。

AMD CPU bug 問題...

去年年底時 Matthew DillonDragonFly BSD mailing list 上的說明:「Buildworld loop seg-fault update -- I believe it is hardware」,以及今年三月從 AMD 確認問題「AMD cpu bug update -- AMD confirms! (additional info)」。

可以從 mailing list 上看到他想辦法重製問題的方法 (從兩天才能重製,到小於 60 秒就能重製),讓他覺得最棘手的原因是無法引入工具:

Debugging the issue in userland (and kernelland) is extremely difficult because most debugging mechanisms caused the problem to stop occuring.

當故事看還蠻... 有趣?(當事人大概不這麼覺得)

用 Lbzip2 解壓縮

手上抓了幾個 .bz2 的檔案要 bzcat 出來 pipe 丟給 Perl script 跑,用系統預設的 bzip2 發現速度卡在解壓縮,而不是 Perl script...

用 parallel 與 bzip2 當關鍵字到 apt-cache 裡面找,有找到兩個套件:Lbzip2Pbzip2,都裝起來後測解壓縮的功能,發現 Pbzip2 解壓縮時沒有辦法利用到多核心的優勢,而 Lbzip2 則是很順利的超過 100%,輸出結果讓 Perl script 也吃滿 CPU resource...

如果是壓縮時需要壓縮率,還是用 xz 就好...