推 ader888:大推啊 我也是因為這樣寫超久 這應該是種本性上的固執 12/12 06:38
推 ddio:我自己到交作業的前兩個小時也都還在琢磨multi-thread呀 XD 12/12 08:34
→ ddio:最後只好辛酸地開始在報告上分析為什麼要用single thread.. 12/12 08:35
各位都很火大.
multithreaded progamming 主要是用在 SMP 架構下的
大部分的同學大概...一輩子都不會也沒有機會去碰它.
平行計算最可怕的地方在於 :
有問題的地方大多在 資料的分配和讀取
最沒有問題的地方就是在 演算法.
唔, 甚至, 為了大幅度的減少 平行計算 程式的困難 ( 比如說 sync )
有 OpenMPI 或是 MPI 這類優秀(!?)的 API 輔助.
對我個人來說, 我是不太懂什麼 "加速".
有些人比我還要早接觸一些非關 演算法 的加速方法, 而我大概是一知半解吧.
對於 variable dereference 的問題
在下學疏且淺, 今早才從大神聽來 @@"
我最多能, 而且會的方式是 改進 演算法 ( 成功率極低 )
不然, 就是像 這次作業要求 使用 multi-threading 來看是否能加速.
我一寫完就知道 single thread 比起 multi thread 來的快.
我查找許多資料, 卻是給我 諸如 p4 提供的 hyper-thread 功能
可以 logically 表現兩個 core 分別處理 不同的 thread. 理論上 能提供 1.28
的 enhancement. 嘗試過一些從簡單平行計算學來的方式也因為 thread creation
overhead 和 frequent context-switch 而沒有任何幫助.
我其實頗意外大部分的人丟 single thread 的 程式上去.
我的版本, 任何一個 single thread 程式大概都能贏的過我
但是我也花了相當多的時間在研究, 在推敲到底 single core 上
如何利用 multiple threads 才有優勢.
我想, 讓那些覺得 "受到" 委屈的同學 照前一個 spec 來交作業也不失為一個好方法
他們有很多 功課 考試 要顧, 所以憤慨.
雖然手上也有很多書要看, 作業要寫, 但我也是花了 一個禮拜 每天 花三四個小時
在想這個問題.
我大概真的是很傻一直鑽牛角尖.
也太笨, 不會寫有效率的或好的code.
可是我相信這個作業是要我們寫一個能幫助工作的 multi-threaded program.
所以我不會, 也不願意上傳 single process 的版本.
即使到最後證明我在這樣的測資下錯了, 也比只為了分數好.
或許有些自私, 我也希望那些 交出 single thread program 的人能夠
寫下 為什麼 multi-thread 在原本的測資下比較不好.
並希望 助教 能 po 出 寫的好的 report 讓大家看看.
唔, 請不吝指教. 但是不要流於謾罵.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.132.136.133