Re: [分享] 面向對象編程從骨子裡就有問題

看板Soft_Job作者mgtsai時間11年前 (2013/02/23 02:39)推噓6(6推 0噓 82→)

留言88則, 9人參與討論串5/12 (看更多)

※ 引述《mahoihei (Alvar)》之銘言： : 早上看到一篇對個人來說很衝擊性的文章 : http://goo.gl/z4Fa3 : 為什麼說是很衝擊性,因為我自己的編程基礎由oop開始的 : 而在oop design更是我在這個領域最喜愛的地方 : 想問大家對這篇文章有什麼見解?? 點進去看這個 URL，幾乎只是引述別人所講的隻字片語這樣子作文風格，不太對我的胃口，看起來很像是直銷傳單中所慣用的技倆不過文章末尾有 3 個 link，最後一個是 Sony PS3 RD 所寫的投影片我覺得這份投影片倒是滿值得參考的指出在 game design 時某些地方使用純 OOP 實作，會帶來不良後果 (Tony Albrecht，現在是一家公司的 founder) ---------- 投影片中的範例，其中之一提到，以目前眾家 compiler 的實作中會將同一個物件的所有 member variable 所需的記憶體配置在同一塊區域內 (以物件本身作為 memory locality) 但這個模式，在重複性大量資料處理中，卻會發生一個嚴重的副作用：會使得 CPU 對 memory access 時的 cache miss rate 拉升以致於效能嚴重低落以 CPU 與 RAM 於半導體技術進步速度，CPU 的進步比 RAM 的進步快非常多，以致於現今 CPU 存取 RAM，以 Intel 所提供的資料 http://www.gdcvault.com/play/1014645/-SPONSORED-Hotspots-FLOPS-and 存取 L1 cache 需 4 個 clock cycles 存取 L2 cache 需 10 個 clock cycles 存取 L3 cache 需 75 個 clock cycles 存取外部 RAM 需數百個 clock cycles (在 1980 年代 IBM PC 剛問世的那時，CPU 存取 RAM 只需數個 clock cycle) 換句話說，記憶體存取 cache hit 與 miss 與否，會大幅影響系統效能在 game design 中，經常用到 4x4 的轉換矩陣若以單精度浮點數來看 (4 bytes)，一個 4x4 轉換矩陣佔 64 bytes 以現在 Intel CPU 的 L2 cache 的 line width 通常是 128 bytes 換句話說，一個 L2 cache line 只裝了兩個 4x4 矩陣當一大堆物件需進行矩陣相乘的運算 (在 game design 很常見) 若以 OOP 的寫法 (C++)，可能會寫成以下的方式 (簡化自投影片中的例子) void functionA() { for (i = 0; i < N; i++) { objArray[i].Transform(parentTransform); } } inline void Object::Transform(Matrix &parentTransform) { this->m_worldTransform = parentTransform * this->m_Transform; } 其中 m_worldTransform 與 m_Transform 這兩個 member variable 均為 64-byte 的 4x4 矩陣因為 objArray[i] 這個物件中，除了 m_worldTransform 與 m_Transform 兩個矩陣還包含其它變數，virtual table pointer 等等其它東西所以一個物件在 L2 cache 中，可能佔據 2 個或以上的 cache line 在執行上述的迴圈時，以投影片中的演示發現每執行一次的矩陣相乘，會發生至少二至三次以上 L2 cache miss 若改變寫法，將 m_worldTransform 與 m_Transform 從物件中拆出來使用單純的陣列存放，如下： for (i = 0; i < N; i++) { worldTransformArray[i] = parentTransform * transformArray[i]; } 這種做法是將同質性的資料放在一起而原本同一個物件的 m_worldTransform 與 m_Transform 被拆放至兩個陣列中以陣列本身作 memory locality (這種技巧，若有接觸 GPU programming 的人，應該滿熟悉) 以 OOP 的概念來看，這已經破壞 Data Encapsulation 但這樣的做法，卻可以降低 L2 cache miss rate 至每矩陣相乘 1 次 cache miss 在 N 很大時，改用矩陣的寫法，比起使用純 OOP 的寫法，效能將會大幅提升 ---------- 加上投影片中所演示的其它部分，均指出在 game design 時有些地方必須避開 OOP 的實作方式，會比較洽當 ---------- 是否使用 OOP，我自己的信條時，直接回歸至實務面的考量適合的地方用之，不適合的地方避之一味的使用或是一味的不使用，都不是件好事當然平常 OOP 帶來的好處不少，且配合 IDE tool 亦會使開發更為便利但在特殊場合中，比如投影片中所提的 game design 這時反而要故意破壞一般 OOP 的寫法尤其是 performance insentive 的部分，更須檢討這些地方是否適合使用 OOP -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.32.58.129

推

Ntst0

02/23 03:57, , 1^F

02/23 03:57, 1^F

會知道這個綽號的，大概是天寶年間的活躍人物不過您的 ID，我一時猜不出來倒底是哪位老同學老朋友上 FB 搜尋我的中文名字加我吧

→

atst2

02/23 10:03, , 2^F

02/23 10:03, 2^F

→

atst2

02/23 10:03, , 3^F

02/23 10:03, 3^F

→

atst2

02/23 10:03, , 4^F

02/23 10:03, 4^F

它的重點不在於 array 是不是要以 array pool 或 singleton 包裝改良後的 implementation 是不是可以再包裝成另外的物件不是投影片的重點這篇的重點在於，以 OOP 其中一個核心概念：Data Encapsulation 像 m_worldTransform 與 m_Transform，既然是 Object 的屬性，要包在 Object 裡將它們從 class Object 拆出去的做法，馬上就違反 OOP 的天條但這樣包進去 class Object 裡，會造成 performance impact 而且會使硬體上的加速功能失效，諸如 cache prefetch 的機制在投影片中，如果資料好好規劃，performance 可以相差四、五倍以上以 game design 這個領域，這可是生與死的巨大差別！！！ ※ 編輯: mgtsai 來自: 122.116.84.29 (02/23 10:41)

推

LaPass

02/23 11:06, , 5^F

02/23 11:06, 5^F

→

LaPass

02/23 11:06, , 6^F

02/23 11:06, 6^F

→

atst2

02/23 11:20, , 7^F

02/23 11:20, 7^F