MulderPatch 1.2 release
星期天花了一點時間改了一下 MulderPatch 的程式,釋出 1.2 更新版。同樣地,在 ppc 上正常運作的功能移植到 intel 機器上就爛了。每次要編成 universal binary 總是要費很多功夫,花了我整個晚上,因為我並沒有 intel 的機器可以測試。
寫 MulderPatch 的過程中,我更加體驗到 ppc 架構比起 intel x86 實在是合理許多。先不提 register 的數量優勢,在 ppc 上的 BOOL 是 4 bytes ,intel 上只有 1 byte。看起來 intel 比較節省記憶體,但是當 未知回傳型態的 objective-C method 回傳 BOOL 時,intel 版就必須做很累贅的指標轉型或者 & 0x000000FF (硬降轉 BOOL 會編不過)。應該說,big endian 逼得 ppc 不得不使 BOOL 是 4 bytes,但是這樣設計真的很方便啊~ 可惜 ppc 不爭氣。為什麼不是 ppc 超快超涼超便宜,
“這就有點怪了,通常是語言實作底層 native type。而且在相同語言底下,不同平台有那麼大的差異倒是蠻好奇的。以前用 virtual c++ 的經驗,bool 實際上弄出來的 byte size 就是 4。
---jclin. 3/19, 2007另外雖然是 x86 CISC 架構,以先前反組譯 windows 程式的經驗,絕大部份的程式都會直接使用 EAX, EBX, ECX… 等等這些 32 bit register 反而不太會像一般寫組語那樣還用 AX, AH, AL 等等;或是類似 RISC load/store 那樣,也很少看到如 ADD DWORD PTR [0x12345678], 0xff 這種包含 load, add, store 一次做很多的指令。個人是覺得 compiler 也是朝 RISC 和簡單化這種方向在走,而且 x86 CPU 內部的微指令集就像是 RISC 那樣;太複雜化的指令 compiler 最做最佳化會很難,CPU decode/execute 效率可能也不高。所以用 32bit 的指令雖然佔空間,但是效率上卻可能比 16bit 好,例如 MOV EAX,1; INC EAX 語 MOV AX,1; INC AX 這樣都是同樣目的。
另外 intel 畢竟是全球半導體跟微處理機的龍頭,靠他的製程技術和微處理器架構演變出來的 CPU,也不能說是 PPC 不爭氣。另外我是覺得 x86 並非不好的架構,只是 x86 指令寫得好也是有他的優點,例如寫成 32bit 模式的指令。我覺得 x86 指令雖然複雜,但是可以想成是一種壓縮後的資料,經過 fetch/decode 後可以變成微指令,然後透過 superscaler、out-of-order… 等等可以得到更好的執行效率。此外另外一個觀點是,因為是複雜指令,所以相同 instruction cache size 下,x86 的指令是否應該比 RISC 在 cache 內所儲存的實際運算量還多?相同的 size 下,x86 decode 出來的 micro code 做得比 RISC 還多事情,是否也能減少 cache miss 來得比 RISC 好?
此外 x86 的 MMX, SSE, SSE2 而寫出來的最佳化程式,像是在 multimedia 就很常用,至少 LAME 裡面就有;但卻沒有看過 LAME 有 AltiVec 的 FFT/iFFT 版本(很久之前看的,不確定有沒有加了)。大概也是因為 x86 CPU 市佔率高,很多 open source 軟體會有人幫忙寫 MMX/SSE/SSE2 指令集來最佳化。所以魚幫水、水幫魚,有些軟體在 x86 上就是效率比較高。像是 LAME 在 PPC 上可能壓縮 MP3 就會比 iTunes 來得慢,iTunes 也是因為有 Apple 自己的 AltiVec library 優化,但並非大多數軟體都會用 Apple AltiVec lib。另外因為 virtualization 的關係,總是要相同的指令集,x86 有 windows/linux/blah blah。所以我個人覺得 x86 transition 比留在 ppc 上來得好。:P”