Post by å°ç½不是設計和硬体相關的程式也要瞭解硬体?
不用吧?
要，因為現在不只是在寫 PC 的程式，
在非 PC 的環境下某些 C 的寫法還是要考慮到硬體。
Post by å°ç½compiler都幫你最佳化了
你只要focus在演算法上就好了
還沒有這麼理想。
Post by å°ç½亂槍打鳥反而什麼都沒打到
判斷奇偶，我看過有人寫num & 01h
會比 num%2 快到哪裡去嗎?
還是差了好幾條 assembly code，
用 gcc -O2 -S 試出來的，
版本是 3.4.2。
Post by å°ç½高階程式用高階的表示法才不失一致性
如果是 C 的話其實低階一點的寫法還是能讓程式快一點，
理想的情況下最好是使用者還能把意圖寫清楚幫助編譯器進行最佳化，
編譯器要做最佳化，還是需要使用者多加給予一些提示，
這些例子屢見不鮮，
像是 gcc 的 attribute，
很多編譯器都會有的 fastcall（自動幫參數標 register 修飾字），
1999 年剛進 ISO C 的 const、inline、restrict，
還有怕編譯器做過頭，叫編譯器不要做 caching，
早在 1989 年就進 ANSI C 的 volatile，
很多地方都顯示現代的 compiler 並沒有我們想的那麼聰明，
所以我是建議還是別太果斷，
多做一點實驗來驗證自己的想法比較好...
附帶一提，
目前編譯器比較難的問題還是在 pointer analysis，
因為只要出現 pointer access 的地方編譯器就得很保守的做評估，
比較爛一點的編譯器通常看到用 pointer 做間接存取就假設它會破壞所有變數了，
後面的變數再次使用都通通要從 stack 重新 load 出來，
不能直接把之前 cache 在 register 的值拿出來續用，
先進一點的編譯器會有一些理論 model 可以減少這些狀況，
不過還是有限，
ISO C99 加進去的 restrict 修飾字主要也是解決 alias analysis 的問題，
但這都是要靠使用者跟 library 設計者主動去寫出來。
--
Name: Tseng, Ling-hua E-mail Address: ***@it.muds.net
School: National Chung Cheng University
Department: Computer Science and Information Engineering
Researching: Porting GCC and Implementing VLIW instruction scheduler in GCC
Homepage: https://it.muds.net/~uranus
--
[1;37m╔═══╗ [m┼────────────────────────╮[m
[1;37m║[33m狂狷 [37m║ [m│[1;37m＊ [35mOrigin：[1;32m[ 狂 狷 年 少 ] whshs.cs.nccu.edu.tw[m ╰─╮
[1;37m║ [33m年少[37m║[m ┼╮ [1;33m< IP：140.119.164.16 >[0;37m ╰─╮
[1;37m╚╦═╦╝ [m ╰ [1;37m ＊[36m From[1;30m：218-171-140-189.dynamic.hinet.net [m
[1;37;44m ─╨─╨─ [33mＫＧＢＢＳ[37m ─ [32m◎[36m 遨翔"BBS"的[4;37m狂狷[m[1;36;44m不馴；屬於[4;37m年少[;1;36;44m的輕狂色彩 [32m◎ [m