之前因為要用到nvperfhud，所以裝的是78.01的driver
然後結果即像提到的那樣，不管如何優化，vbo相比var，fps總會掉近1/5
怎麼試都是一樣，情況不像想象中那麼簡單： 應該會和d3d中vb的lock/unlock一樣吧（<--- 天真）
最後看到有人說nvidia和ati的實現不一樣，nvidia有做mru之類的優化，ati則在處理static_draw會簡單得video memory > agp memory > system memory，最重要的是opengl是依賴於driver的
所以去下了個最新的81.98裝上
結果發現差距沒有了，暈~
結論：1. 因為目前ogl的驅動已經很成熟的情況下，一些過去的efficient方法，現在並不一定實用了：像是說帶range的比普通drawelements要快一說
2. var是system memory級，在draw時會copy到agp或video的memory中；而vbo會由client指定由driver決定將data放在哪，通常會放在「比較合適」的地方
3. vbo在create和lock時要注意，類似d3d的vb在使用中要注意的：write_only、discard、nooverwrite，這些flag的使用，會很大程度上影響到效率，以下是說明
非write_only的資料，即會read，而我們知道video memory在read起來是很慢的
在lock住vb寫資料時，discard會告訴driver，不需要等待gpu的同步，因為不需要之前舊的資料
在lock住vb寫資料時，nooverwrite會告訴driver，不需要等待gpu的同步，因為不會影響到已有的資料
4. vbo適合static buffer，這時通常會比var快近一倍；而dynamic buffer，就目前來看，至少opengl在nvidia的drvier實現中差別不大
5. vbo是存在有「最佳傳輸量」的，在不同的顯示卡上，其「最佳資料量/fps影響」也不同，有人做了專門的benchmark
ps，以上亂說一氣，保持了一直以來的記流水帳的風格，見諒見諒~
關於code blocks的編譯速度問題
在乙個程式寫好之後，按下f9，便可以進行編譯並且執行，在2018年的寒假之中，編譯速度一直困擾著我，因為每次編譯都需要十秒左右的時間，體驗極差。而此前，編譯時間一直保持在0 second。經過我的多番努力，終於解決了問題。原來，此前，我一般將檔案儲存在e盤之中 機械硬碟 而寒假，為了省事直接放在了桌...
關於cin和scanf速度的問題
在leetcode最優解法中常常看到 int型別引數 static int x string型別引數 int some 查了一下發現是解決 cin，cout效率低的問題 cin cout之所以效率低，是因為先把要輸出的東西存入緩衝區，再輸出，導致效率降低，而這段語句可以來打消iostream的輸入 ...
關於GBA模擬器悲慘的速度問題
滑鐵盧，絕對的滑鐵盧。辛辛苦苦花了乙個星期的時間移植arm彙編到，模擬器核心，沒想到速度竟然僅僅提公升了5 10 有時候還沒有！太悲慘了。唯一的好處是讓我重溫了一遍x86的彙編以及學習了arm彙編。而且我測試的rom中似乎還沒有對所有的彙編 進行呼叫。為了以防萬一，我決定還是暫時不起用自己寫的arm...