![]() |
PCDVD數位科技討論區
(https://www.pcdvd.com.tw/index.php)
- 系統組件
(https://www.pcdvd.com.tw/forumdisplay.php?f=19)
- - [Process Tamer] 虛擬HT工具-讓你的CPU也擁有HT -AMD User也可以用
(https://www.pcdvd.com.tw/showthread.php?t=510047)
|
---|
計算機結構學的不好,有些地方不太懂,希望又大大能夠解答
1.所謂的muilty-thread 的程式寫法是否是將一個程式交由CPU執行的時候能同時提供多給Thread給多個CPU亦或是虛擬出來的多CPU(HT技術)執行? 2.多工的廣泛定義,應該是同時執行多個工作?一般CPU要執行多個程式都是看OS的寫法,理論上單一CPU沒有多核心設計(包括虛擬)的多工能力應該都是看CPU的執行能力,因為同一個時間被執行的thread都是一個? 3.如果1與2是正確的話,沒有支援multy-thread的單一程式,就算OS有支援multy-thread用多CPU、多核心單一CPU(包括虛擬),效能都是一樣?(在只執行此一程式的情形下) 4.換一個角度,根本不可能用軟體模擬出擁有同時執行多個thread的CPU在一個不支援同時處理多個thread的單一CPU上,因為被CPU執行的thread永遠只有一個。 5.說HT是模擬擁有2個CPU下這應該是100%成立的?就INTEL官方的HT試意圖,HT技術是在CPU 等待其他資料進來的空檔插入另一個thread來做處理,所以並不是兩個thread同時執行(跟雙核心有很大的不同),視空檔大小決定後到的thread所佔的CPU資源? 6.如果5成立,今天就算是管線不長,HT也能順利執行而且能力更好,因為thread處理的更快? |
感謝樓主, 讓我們能更方便地"調效"CPU對於進程的使用率~ :like:
..電腦就是要經過使用者調效, 才能發揮它最"合適"的作用嘛~ 又沒花$$就可以長知識, 就應該心存感謝了不是~?? :p ..不過, 那中間左邊的數字與右邊的拉bar要調怎樣才會比較順~? cpu:2.6G-celeron ram:1G |
引用:
1. 你說對一半, Multi-Thread 程式應該這麼看, 當有多 CPU 的時候, 例如兩顆, 那就平均分配, 那個有空就那個去執行, CPU 越多, thread 排隊的時間越短. 而只有單一 CPU 時, 那就照排, 所以排列時間比較長. 2. 事實上, 多工應該說是分時、平行運算混合, 拿現在的 Windows XP 為例, 你一進入程式可能已經執行了幾十個 Process, 這些 Process 可能是單一 thread, 或是 multi-threads, 但, 平常會有幾十顆同樣數量的 CPU 同時平行運算嗎?所以其中分時多工也必定存在. 每一秒可能切割成許許多多單位, 優先權高的多分配一點, 可能是 5/1000 秒, 優先權低的可能是 1/1000 秒, 然後利用 CPU 中的 task 切換每一個 Process、thread, 來讓使用者感覺到你程式是同時在執行的. 有人講到 Super-Scalar, 這是 thread 等級的平行處理技術, 這部份我還要再了解一下, 只是如果 Super-Scalar 真像某位朋友說的是平行處理, 也就不需要 HT 了. 3. 結論沒錯. 4. 基本上, 在 286 開始就已經開始支援多工機制 (保護模式), 提供 Task 的切換, 這就是單核心多工的基礎, thread 跟 Process 的性質差不多, 能多 Process 切換執行, 多 thread 就可以, 只不過作業系統在實作的時候要清楚 thread 跟 Process 的不同跟溝通. Super-Scalar 具有某種程度的指令平行處理能力, 不過不能跟雙核或 HT 混為一談. 5. 應該說是切換, 當一邊 thread 差生空檔, 另一邊 thread 就可以取得比較多的CPU資源. 在作業系統的優先權觀念來說, 是優先權對調. 6. 管線不長, 效能浪費就少, HT 就比較沒有發揮的餘地. 管線長的設計, 在分支預測錯誤的時候, Lantecy 比較長, 這段時間內, CPU 的運算資源可能是 hold 沒在用的, 白白浪費掉. 而管線短的這個 Lantecy 時間短, HT 的幫助就很小了. 可以試著在有 HT 的 P4 玩看看兩個 CPUMark(單一Process單一thread的測試程式應該都可以), 到工作管理員中一個設給 CPU0 跑, 一個設給 CPU1, 看結果如何, 再來試著自己推測原因 :) 還有, 我對於媒體用 HT 來下標題, 也不認為是對的. |
引用:
superscalar 很簡單的指一個時脈裡面執行兩個以上指令的能力 CPU 不管你是Thread 還是 Process 那個應該是OS/APP 管的 P4 HT 是RR 沒有優先權的差別 |
真是太難太深奧了~
能夠發明這些東西的人真是厲害阿 :cool: 爭吵的原因大概是這個吧:讓你的CPU也擁有"HT" 我不是念這門科系的專業,也無從評論~不過站在我念的科系上舉個小例子給發文的樓主一點建議,舉個最簡單的例子: 2種降血壓藥,A藥藉由排除過多體液來降血壓,B藥是由抑制我們的交感神經來達到降血壓的目的 或許站在一般人的立場,這同樣都降血壓,沒什麼不一樣!不過在我們的立場,不一樣就是不一樣!不能以同樣的結果就把他們歸為是同一類的東西 或許我無權評論,但有時我覺得有些東西還是能"追根究底"一些比較好 對你的熱心貢獻我想大多數人都很感謝!或許你很委屈,不過這何嘗不是能多學習一點東西的機會?看要換個角度想或是直接把電腦關掉出去打打球~睡一覺等等都好(看到你回覆這麼多........勢必該安慰你與心理輔導一下!) 一個常被幹剿且愛專門離題又睡不著的人在此與你共勉之~ |
引用:
Super-Scalar 和現在說的 HT 、多CPU、多核所稱的平行處理有那些不同? P4 HT 的在分配效能時, 是怎樣的分配法?平均分配?也就是說我跑兩個單執行緒的程式, 如 CPU mark, 兩隻各分一半? 星期一上班來玩玩看能不能這樣玩. |
效能有加強一點,但絕對不能拿來和HT相提並論,不然設計這套軟體的公司就會向使用者收取ㄧ筆費用了。
|
引用:
這套軟體不是拿來加強效能的吧. HT 是拿來補 P4 原來就比較差的效能. |
1.我想該澄清一個觀點,不管是什麼核心,只要在於X86之下的架構,可說是"不可能"有同時分配的問題的。因為指令執行是序列式的,平時是在於這些指令沒有很相關的關係時才會發生。
2.HT不是虛擬兩個CPU,他是虛擬一個Thread來做"可以"平行處理狀況的執行,本身需要程式有特別為他編寫才能發揮效能。 3.我想HT根管線長短沒有什麼關係,管線只不過是指令分級的程度,跟導入虛擬Thread沒有直接關係。 4.因為管線分的更細了,所以其實有時候指令執行是卡再分時上面,就是序列式的執行,但是其實如果中間比如有一些如邏輯運算的東西可以先做,那是不是可以先做出來存起來備用,如此就有了平行化的處理方式,那麼如果把主序列的指令也這樣做呢?為了完成這樣的想法,所以必須再原有架構上面再虛擬一個Thread(一個通路),當然程式也要這樣寫才有用。程式就必須把它模組化,讓它可以個別來執行,再把他組合起來。 5.一般的無HT技術的處理器那麼如果要全速執行下因為必須指令是一個一個排隊來,雖然可以運用的部份很多,但是需要運用的部份一次都是一個,那其他人就不能用啦,這時就卡住了,雖然是在等待資料,可是因為AS只有一個,那前面就有人用了,所以就算想給其他人用,也是沒辦法,所以他會是滿載的。 但有HT的因為有多了一個AS,那所以還可以給其他人用,一個AS來作主要的事情。所以其實他會是比較輕鬆的,程式雖然還是卡在同一個地方,但是他還有另一個AS可以使用,可以在分配其他項目到位工作的單元,這樣可以盡量填滿整個CPU的大部分結構。在做的時候還是可以分配一些沒用到的給其他人使用,當然這時候我們看到的就不會是滿載了。 |
引用:
第一點和第四點中,指令當然是不相關才可以非循序執行,和是不是 X86 架構應該沒有關係才對不是嗎?Out-Of-Order-Execution 是現在大多數先進處理器的基礎。而多處理器系統執行程式時仍然會遇到這個問題,只是能夠藉由適當的在設計程式時事先避免部分相依性的指令編排,以再進一步提升效率。而搬到單處理器系統來說這也還是有好處的。 HT 我從來沒有去看過他的技術文件,不過我覺得和虛擬 thread 是不同的兩回事,thread 是用來被執行的,多虛擬一個我不覺得有幫助,形容成多出一個指令執行單元我覺得可能比較合適,即使我認為這恐怕還是簡化的形容方式....。一個 thread 不是一個通路,而是一個佔資源的東西。 [以下是無根據發言,印象來自多年前的 0&1 Byte]------ 在 superscalar 這種概念中,平行化的程度不如純粹的雙處理器,主要是為了軟體相容性,避免發生錯誤,畢竟由硬體做判斷所能判斷的程度有限,所以能平行化的規模不大,但也因此不須特別為其編寫程式 (說是這樣說,靠 Compiler 來做一定程度的最佳化還是有的,只是不用像寫 Multi-Thread 程式那樣) [不負責發言結束]---------------------------------- 有錯的話也請大家不吝指導。 |
所有的時間均為GMT +8。 現在的時間是08:02 PM. |
vBulletin Version 3.0.1
powered_by_vbulletin 2025。