啓動一個線程並終止它需要數百個機器週期。但這只是一個開始。線程之間的上下文切換(如果線程正在執行任何有用的事情時會發生)將重複消耗更多數百個機器週期。所有這些線程的執行上下文將消耗許多字節的內存,這反過來會弄亂許多行緩存,從而妨礙了CPU在數百個機器週期中的又一個很大的努力。事實上,多任務處理是數百個機器週期的一個重要消費者。多任務處理僅在CPU功耗方面變得有利可圖當您設法獲得足夠的處理器以處理概念上獨立的數據塊(因此並行處理不會威脅到它們的完整性)並且大到足以顯示淨收益時與單處理器版本。
在所有其他情況下,多任務處理是在所有域,但一個固有低效:反應。任務可以對外部事件作出快速而準確的反應,最終來自外部H/W組件(無論是定時器的內部時鐘還是用於網絡流量的WiFi /以太網控制器)。
這種在不浪費CPU的情況下等待外部事件的能力是提高整體CPU效率的原因。就是這樣。
在其他性能參數方面(內存消耗時間內核調用內部的浪費,等等),推出一個新的線程是總的淨虧損。
概括地說,多任務編程的技術歸結爲:
- 識別所述外部I/O流,你將不得不處理
- 考慮反應性的要求考慮(記住多個反應性=更少CPU /內存在99%的時間內高效運行)
- 以合理的效率/易於維護的折中方式爲所需事件設置處理程序。
多處理器架構正在增加一個新的複雜程度,因爲現在任何程序都可以看作是一個擁有許多外部CPU的進程,可以用作額外的電源。但是你的問題似乎沒有任何關係。
的多任務處理效率的量度,最終將取決於給定的計劃預計以應付同時和一組給定的反應性限制內外部事件數。
最後我來談談你的問題。
要應對外部事件,每一個新的樹枝或死昆蟲的位必須移動周圍的蟻丘是一個非常粗糙和低效的進場時間發動的任務。
您在您的處置許多強大的同步工具,這將讓你從(近)在(幾乎)沒有成本最優效率的單個任務範圍內的是一幫異步事件的反應。
通常情況下,在多個輸入阻塞等待,例如像Unix的口味select()
或微軟的WaitForMultipleEvents()
對口。
使用這些會給你一個性能提升無比超過幾十個CPU週期,你可以擠出你這個任務的結果收集優化項目的更大。
所以我的答案是:不要打擾優化線程設置。這不是問題。
你最好將時間花在重新考慮你的架構,這樣經過深思熟慮的線程少數可以取代無用CPU成羣的記憶豬當前的設計會催生。
你不小心一個字?從線程返回值,對嗎? –
?你什麼意思?是 – Luka
是的,但我想最有效的方式 – Luka