Re: [分享] 面向對象編程從骨子裡就有問題
※ 引述《mgtsai ()》之銘言：
: 標題: Re: [分享] 面向對象編程從骨子裡就有問題
: 時間: Sat Feb 23 02:38:59 2013
:
: 是否使用 OOP，我自己的信條時，直接回歸至實務面的考量
: 適合的地方用之，不適合的地方避之
: 一味的使用或是一味的不使用，都不是件好事
:
: 當然平常 OOP 帶來的好處不少，且配合 IDE tool 亦會使開發更為便利
: 但在特殊場合中，比如投影片中所提的 game design
: 這時反而要故意破壞一般 OOP 的寫法
: 尤其是 performance insentive 的部分，更須檢討這些地方是否適合使用 OOP
:
: --
: ※ 發信站: 批踢踢實業坊(ptt.cc)
: ◆ From: 114.32.58.129
: 推 LaPass:請問一下.... 用JAVA的應該不用管這個吧? JVM會搞定這些的 02/23 11:06
: → LaPass:樣子.... 02/23 11:06
Java....... 呃，這我就得要潑冷水，因為真實世界總是不美好的
像 Java 這類缺乏 value class/type 的語言只會比 C++ 更慘
除了那八個 primitive type 之外，其它的，Java 一律視為物件
問題會發生在那些 4x4 矩陣 (Matrix) 的物件上
在 C++ 中，像 m_worldTransform 與 m_Transform 這兩個 64-byte 矩陣物件
可以直接嵌在 Object 物件裡頭，配置在同一塊記憶體區間內
所以當進行 m_worldTransform m_Transform 運算時
就會一同在 Object 物件所配置的同一塊記憶體內處理
但在 Java 中，除了 Object 物件之外，還必須 new 兩個 Matrix 物件
JVM 再怎麼厲害，它並無法判斷這一個 Object 物件與相關的兩個 Matrix 物件
必須配置在相近的記憶體區塊中
資料分開放的結果，一定會造成 cache miss rate 提高，比 C++ 高兩三倍以上
若只是單純直接以投影片中的寫法，定義兩個 Matrix[]
也是沒辦法解決上述的問題，因為除了 new Matrix[N] 之外
對於陣列中的每個元素，還必須各別 new Matrix(...)
所以結果下來，與拆不拆開來基本上沒什麼差別
不過還是有解的，如果放棄使用 Matrix 物件，改使用兩個大 float[]
而程式碼改為：
for (i = 0; i < N; i++) {
matrixMul(worldTxElemArray, txElemArray, i * 16, parentMatrix);
}
(其中 worldTxElemArray 與 txElemArray 均為 float 陣列)
則可如投影片中，降低 cache miss rate 與使用到 cache prefetch 的硬體加速
不過程式碼這樣子寫，已經完全偏離 OOP 的精神了
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 122.116.84.29
※ 編輯: mgtsai 來自: 122.116.84.29 (02/23 15:09)
討論串 (同標題文章)