其實我總覺得intel所說的thread 應該不是 樓上各位所提出的thread !!

因為就各位所知道的thread , 它的觀測角度是以OS為主 , 既然是以OS為中心

怎麼會變成以CPU為觀察點呢?? 難不成CPU會知道 process ? thread ?? 甚至Application ??
這不可能嘛!! 所以我才會認為intel 所說的2C4T之類的說法應該不是這類的thread !!

我大概知道 intel 所指的thread大概指的是什麼了....

我的答案是源自於intel 的 Superscalar (超純量架構)
這方面的資料請參考以下URL:
https://en.wikipedia.org/wiki/Superscalar_processor

簡單講, 一顆單核心的CPU 具備兩路相同的 pipeline , 藉以加速instruction code的處理
詳細的部份就不多說了 !!

簡而言之 1C2T的T 指的就是SuperScalar 架構裡的pipeline , 再試想 intel 為何不說
1C4T or 1C3T ?? 就是因為pipeline 數量沒有達到3路 or 4路的pipeline , 在SuperScalar架構之下
最多就是兩路 pipeline , 故單核心之下就是1C2T 來稱之!!

至於效能方面,1C2T 當然不可能等於實體的雙核心效能 , 實際使用方面,頂多也就是比
1C1T 好上10-20% !!

所以我認為intel 所指的thread應該就是指pipeline !!

https://zh.wikipedia.org/wiki/%E7%BA%BF%E7%A8%8B

https://zh.wikipedia.org/wiki/%E8%B...%A1%8C%E7%B7%92

感覺很多人分不清這兩個啊 :jolin: :jolin: :jolin:

應該這樣解:
1. 請勿修改原命題.
2. 請勿隨便誤解.


:laugh: :laugh:

這個我也沒辦法,想要瞭解intel所謂的thread ,一定至少要學過計算機結構 !!
我所指的pipeline也並不是就代表等於intel 的thread , 我只能夠說很接近了!!

各位之前所說的thread , 那是以OS為出發點,以OS做為觀察中心 , 去分別定義出process
application , thread !! 就連您提供的維基的網址,也是同時提到OS , Kernel 等等 ,就代表
要瞭解這幾個名詞必須從OS切入!! 既然如此,當然要學過貝殼書那一本講解OS的原理 ...

所以分不清是很正常的,相信就算是原本學資訊工程的人,也不一定可以解釋OS裡的thread
到底是什麼東西 , 就更別提intel所指的thread ....

反正,把結論記住就好 , 1C2T的CPU , 執行效率一定比1C1T的好10-20% (同時脈的狀況下) :ase :ase :ase

我發現大家好像有點搞錯了，不然我簡單解釋一下，至少我在國家的資訊、電子高考都有拿過全國榜首或前三名，觀念上應該不會錯太離譜，撇開考試分數不談，觀念有錯的話，我實作的程式或電路應該不會動，賣出去應該會被K得滿頭包吧？不過CPU本身我就沒設計過，只能說就是讀得熟而已。

Thread在台灣譯名就是執行緒，大陸譯名就叫線程。

我從程式的觀念切入，逐步講到在CPU怎麼運作，大家比較有感覺。

比方說我今天寫了一支有GUI的程式碼，假設我在程式碼裡寫了一個無窮迴圈，會發生什麼事呢？

大家可以猜得出來，整個GUI執行到該無窮迴圈會像當機一樣，因為CPU瘋狂的執行迴圈，所以沒辦法再執行迴圈以後的程式碼，因此使用者去點擊GUI，GUI就像死當，不會回應。

因此工程師在寫這類型的Code時，就會呼叫Thread函式庫，把這個無窮迴圈包成一個函數，並且指定一個Thread去執行這個函數。此時這支程式有兩個Thread在執行，一個是GUI Thread，一個是迴圈的Thread。

當程式執行時，作業系統就會排程Thread的執行方式，使用者如果不操作GUI，就讓無窮迴圈Thread去佔滿CPU的資源；如果使用者去操作了GUI，作業系統就會觸發執行Context-Switch，要求CPU把暫存器(Registers)都騰出來，換成處理GUI Thread，所以使用者在操作GUI時，就不會覺得程式有當掉，但事實上是兩個Thread在CPU裡快速切換。

以上就是Thread在執行時，程式、OS、CPU三者的狀態。

這時候大家就會問個問題，那如果Thread越來越多，一天到晚都在Context-Switch，CPU做沒兩個指令就要把暫存器騰出來給別個Thread使用，這樣是不是很浪費時間沒效率？另外一點是，如果Thread A和B剛好是不衝突的，兩者用的是CPU裡不同功能方塊，這樣切換來切換去是不是很白痴，為什麼不要讓他們同時執行就好？

所以Intel也想到了，這就是為什麼Hyper-Threading會誕生。

Intel實作Hyper-Threading的方式，簡單來說就是讓一個CPU核心有兩套暫存器，但共用其他運算、控制功能方塊(ALU / CU)，因為x86作業系統判定有幾顆CPU主要就是透過辨視有幾套x86暫存器，所以開了Hyper-Threading，就是把CPU裡每個核心的兩套暫存器都打開，作業系統就會以為多了一倍的CPU。

這樣一來就不難思考為什麼Hyper-Threading總是在某些情況特別管用，但有些情況就弱得要命。以上述的情況來思考，GUI Thread 和 無窮迴圈Thread 用的功能方塊不同，所以透過Hyper-Threading就能讓兩個Thread的指令都塞到同一顆CPU核心去同時執行，不用再Context Switch。但是如果遇到要平行計算的硬派應用，Hyper-Threading就不管用了，因為一堆Thread都搶著用CPU裡同一組ALU功能方塊，兩個Thread只好一前一後乖乖排隊，效能當然不會增加。

至於Pipeline，它是很早就出現的技術，它和Hyper-Threading沒有衝突或關聯，兩者可以分別使用，也能同時使用，共同點都是為了提升CPU裡功能方塊的利用率，不要讓這些功能方塊閒置的手段而已，利用率提高的話，指令消化速度當然就會變好。

很可惜.... 不是這樣的, 這些東西不能混為一談喔. :laugh:
軟體是軟體,硬體是硬體, 作業系統是作業系統, 計算機架構是計算機架構,處理器架構是處理器架構..各自有專門的教科書喔 :laugh:

我沒有考啥高考啦, 不過我當時考台大電機研究所的作業系統,是拿八十幾分的...

正確的故事來由應該是從 "作業系統"的發展開始.
古老的機器,處理器資源是非常昂貴的, 而IO 速度卻是非常緩慢, 處理器常常發呆等I/O,
於是有人想到分時多工, 把CPU等待的時間分給別人用, 於是寫了作業系統去管理, 開始把單工變成多工, 把處理器的資源榨光. 於是有了process（互不干擾的工作） 與 context-switching 及改善效能的概念...
為了這三個概念, 各自發展了軟體(比如threads)與硬體(管線,超純量,循環使用的register, HT,DMA等等)的各種技術 ..現在都很複雜了,詳見各維基百科.

這些觀念要理解應該是不複雜，看看Code都還OK。

我在前文是解釋Hardware Thread和Software Thread之間的運作方式，應該是沒有混為一談啦。

而且軟體就是跑在硬體上面，把Software/OS/Hardware都分開來當作是不一樣的東西，沒有去追根究底了解運作方式，程式怎麼讓硬體動起來的過程就理解不到了，比較可惜。

Thread的本質確實要從軟體出發，往下至硬體層理解，才會有深刻感受，因為在CPU的層級就會剩下一行一行Instructions的執行，其實已沒有所謂的Thread了，Thread是靠OS去實現的，有興趣可以寫段C++，使用STL Thread，然後用Compiler Explorer或gcc -S把它翻成組語，就會發現直接餵給CPU的指令已經沒有Thread的存在，都是剩下Pogram Counter的操作，讓OS去處理了。剛好奇聽魔王兄的建議去看Wiki，Wiki的說明也是從這角度出發，一路從軟體往下講至OS，再到硬體層。

https://en.wikipedia.org/wiki/Thread_(computing)

我只知道你這樣寫, 鐵定會被教授打槍！
:laugh:

推薦你看兩本書, 一本是恐龍的OS,
一本是計算機結構computer architecture a quantitative approach（喔,剛掃了一下新版, 竟然有介紹i7 , 也許可以爬看看.）

------------
update: 書好像沒仔細講HT...

哈，應該是不會啦，考試院舉辦的高考閱卷委員大多是台政清交成的教授，我之前這樣寫，計算機結構也是都85~94左右。

你說的研究所考試我就不肯定了，因為我台清交電機電子資工研究所是申請就直升保送了，沒有再考試，說不定我考不上也有可能。

恐龍本OS和David版計組是大學時的聖經本，不過這兩本比較入門，還是要唸一下計算機結構，Computer Organization會比較有Feel，能的話實作一下會比較有感覺。