看板 b93902HW 關於我們 聯絡資訊
我很肯定住教出作業的原則,如同助教所提,是為了讓我們觀察thread overhead 和效能之間的影響,並且在其中取得平衡。 我很尊重助教出的作業,加上這個禮拜有兩科期中考以及兩個project等待生出來, 所以OS作業我很早就開始寫,並且早在原本deadline前的兩個禮拜就完成了。 中間當然跟同學有互相討論,做些小小的修改。大家雖然覺得原本測資不適合發揮 multi-thread的最佳功能,但是也想辦法在這樣的情況下找出最佳解,很多人都很認真 的再作。 我就是下面DE所提 coding不算快的同學,我想部分同學也會跟我ㄧ樣也沒有把握說自己 coding很快很威。雖然我是個coding小嫩咖,但是我認為每個程式作業都值得我們 從中去學習。我也看到很多同學認真的在完成這次作業。 但是,我發現我們尊重助教作業的程度似乎比助教尊重自己所出的作業的程度來的高。 我沒有當過助教,我知道助教辛苦,我相信設計作業有難度我也覺得OS兩位(應該是兩位吧?) 助教DEMO的時候人都很好。但是spec在deadline以後修改應該已經不只是設計作業難度的問題了。 既然助教堅持修改spec,那麼我希望這次的spec不要又是處於浮動狀態。 如果有不當的冒犯還請見諒。 ※ 引述《denehs (DE)》之銘言: : 不好意思如果有冒犯還請見諒 : 但我想請問助教在出作業之前 : 有自己先把這個作業寫過一次嗎? : 如果有的話, 應該不會現在才發現需要改input size吧? : 我沒有當過助教或許沒什麼資格說話 : 但是我認為身為一個助教, 在出作業前應該先把作業寫過一次 : 至少我知道P老師的C & ACP的助教都有這樣做 : 助教或許很忙沒有時間這樣做, 但我們也不是整天閒閒沒事幹阿... : 甚至還有很多人這禮拜還有期中考要考 : 又不是每個人Coding速度都很快, 我的速度算是快的, 也花了非常長的時間寫這個作業 : 現在離deadline又只剩一周就要每個人重新對1000*1000的size再tune一次 : 如果每科的助教都這樣搞還得了.. : 現在說這些好像也沒什麼用 : 我只是很難過從大一到現在很多本來可以是很棒的課 : 都被助教搞爛了 : 最後還是要推一下C的好人助教 (雖然我沒抽到加簽Orz) : 還有ACP的助教, 上學期計結, 還有之前組語, 演算法的小金都很棒 : 如果有冒犯我在這邊先道歉. : ※ 引述《shiing (!?)》之銘言: : : 有同學反應project2的題目有點問題。助教在出作業之時確實有些因素沒有考慮進去。 : : 出矩陣相乘的意義在於有大量的I/O和計算要同時處理。 : : 100*100的size太小和會導致multithread效率不彰和Strassen Algorithm會拖慢速度。 : : 因此大家在寫作業可能會觀察到single thread的效率可能是最好的。 : : 這次作業的核心意義在於讓大家了解到thread數量和系統效率的關係, : : 目的在於找出最好的辦法。 : : 開thread的overhead太大,因此若矩陣size太小,將I/O與計算的部分overlap仍然可能效 : : 能會輸給single thread。 : : 為了這個原因,我們將矩陣的size調大,最大到1000*1000。 : : 我們的原則還是一樣的,希望大家能觀察thread的數量與系統效能的關係。 : : 對於大部分已經做完的同學,我們願意說聲對不起, : : 臨時更改題目的規定的確是不好的行為 : : 最後,若有任何問題,歡迎與助教們討論 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.112.30.32 ※ 編輯: dannitelu 來自: 140.112.30.32 (12/11 15:24)
ader888:你太和善囉 12/11 17:11
dannitelu:我知道.. 因為我po的時候看到zemil那篇了 12/11 17:18