CPU不管什么樣的編程語(yǔ)言,什么樣的代碼框架,最終都是由CPU去執(zhí)行完成的(當(dāng)然這么說(shuō)不太準(zhǔn)確,也有GPU、TPU、協(xié)處理器等其他情況,當(dāng)然這不是本文探討的重點(diǎn))。
所以要想提高性能,提高并發(fā)量,首要問(wèn)題就是如何讓CPU跑的更快?
這個(gè)問(wèn)題,也是一直以來(lái)CPU廠商一直在努力追求的方向。
如何讓CPU更快?CPU廠商做了兩個(gè)方面的努力:
加快指令執(zhí)行的速度
加快CPU讀取數(shù)據(jù)的速度
對(duì)于第一個(gè)方向,CPU執(zhí)行指令的快慢,是跟CPU的主頻緊密相關(guān)的,如何更快的取指令、指令譯碼、執(zhí)行,縮短CPU的指令周期,提升主頻在相當(dāng)長(zhǎng)一段時(shí)間里都是非常有效的辦法。
從幾百M(fèi)Hz,到如今到幾GHz,CPU主頻有了長(zhǎng)足的進(jìn)步,相同時(shí)間里能夠執(zhí)行的指令數(shù)變的更多了。
對(duì)于第二個(gè)方向,如何提升CPU讀取數(shù)據(jù)的速度,答案就是加緩存,利用局部性原理將內(nèi)存中經(jīng)常會(huì)訪問(wèn)的數(shù)據(jù)搬運(yùn)到CPU中,這樣大大提升了存取速度。
從一級(jí)緩存,到二級(jí)緩存,乃至三級(jí)緩存,CPU緩存的層級(jí)和容量也在不斷提升,讀寫數(shù)據(jù)的時(shí)間省了不少。
但隨著時(shí)間到推移,尤其進(jìn)入21世紀(jì)之后,處理器廠商發(fā)現(xiàn),進(jìn)一步提升主頻變得越來(lái)越困難了,CPU的緩存也很難進(jìn)一步擴(kuò)容。
怎么辦呢?既然一個(gè)人干活的速度已經(jīng)很難再提升,那何不多找?guī)讉€(gè)人一起干?于是,多核技術(shù)來(lái)了,一個(gè)CPU里面有多個(gè)核心,眾人劃槳開(kāi)大船,CPU的速度再一次騰飛~
甚至,讓一個(gè)核在“閑暇時(shí)間”,利用“閑置資源”去執(zhí)行另外的線程,誕生了讓一個(gè)核“同時(shí)”執(zhí)行兩個(gè)線程的超線程技術(shù)。
上面簡(jiǎn)單交代了為了提升性能,CPU所做的努力。但是光是CPU快是沒(méi)用的,還需要我們更好的去利用開(kāi)發(fā),否則就是對(duì)CPU算力的浪費(fèi)。
上面提到了線程,是的,如何提高性能,提高并發(fā)量?使用多線程技術(shù)當(dāng)然是一個(gè)非常好的思路。
但多線程的引入,就不得不提到兩個(gè)跟線程有關(guān)的話題:
線程同步
線程阻塞
多個(gè)線程協(xié)同工作,必然會(huì)引入同步的問(wèn)題,常規(guī)解決方案是加鎖,加鎖的線程一般會(huì)進(jìn)入阻塞。
線程遇到阻塞了,就需要切換,而切換是有一定的成本開(kāi)銷的,不僅是系統(tǒng)調(diào)度的時(shí)間開(kāi)銷,還可能有CPU緩存失效的損失。
如果線程頻頻加鎖,頻頻阻塞,那這個(gè)損失就相當(dāng)可觀了。為了提升性能,無(wú)鎖編程技術(shù)就出現(xiàn)了,利用CPU提供的機(jī)制,提供更輕量的加鎖方案。
同時(shí),為了讓切換后的線程仍然能夠在之前的CPU核心上運(yùn)行,降低緩存損失,線程的CPU親和性綁定技術(shù)也出現(xiàn)了。
現(xiàn)代操作系統(tǒng)都是以時(shí)間片的形式來(lái)調(diào)度分配給多個(gè)線程使用。如果時(shí)間片還沒(méi)用完就因?yàn)檫@樣或那樣的原因?qū)?zhí)行機(jī)會(huì)拱手相讓,那線程也太虧了。
于是,有人提出要充分利用CPU,別讓線程阻塞,交出執(zhí)行權(quán),自己在應(yīng)用層實(shí)現(xiàn)多個(gè)執(zhí)行流的調(diào)度,這里阻塞了,就去執(zhí)行那里,總之要把時(shí)間片充分用完,這就誕生了協(xié)程技術(shù),阻塞了不要緊,我還能干別的,不要輕易發(fā)生線程切換。
內(nèi)存與CPU工作相關(guān)的第一親密伙伴就是內(nèi)存了,二者協(xié)作才能唱好一出戲。
提升內(nèi)存訪問(wèn)的速度,同樣是高性能開(kāi)發(fā)話題重要組成部分!
那如何提升呢?硬件層面程序員是很難改變的,咱們只好從軟件層面下功夫。
內(nèi)存的管理經(jīng)歷了從實(shí)地址模式到分頁(yè)式內(nèi)存管理,如今的計(jì)算機(jī)中,CPU拿的的地址都是虛擬地址,這中間就會(huì)涉及到地址的轉(zhuǎn)換,在這里就有文章可做,有兩個(gè)方向可以努力:
減少缺頁(yè)異常
使用大頁(yè)技術(shù)
現(xiàn)代操作系統(tǒng),基本上都會(huì)使用一個(gè)叫換頁(yè)/交換文件的技術(shù):內(nèi)存空間有限,但進(jìn)程越來(lái)越多,對(duì)內(nèi)存空間的需求越來(lái)越大,用完了怎么辦?于是在硬盤上劃分一塊區(qū)域出來(lái),把內(nèi)存中很久不用的數(shù)據(jù)轉(zhuǎn)移到這塊區(qū)域上來(lái),等程序用到的時(shí)候,觸發(fā)訪問(wèn)異常,再在異常處理函數(shù)中將其從硬盤讀取進(jìn)來(lái)。
可以想象,如果程序訪問(wèn)的內(nèi)存老是不在內(nèi)存中,而是被交換到了硬盤上,就會(huì)頻繁觸發(fā)缺頁(yè)異常,那程序的性能肯定大打折扣,所以減少缺頁(yè)異常也是提升性能的好辦法。
從虛擬地址尋址真實(shí)的物理內(nèi)存,這個(gè)過(guò)程是CPU完成的,具體來(lái)說(shuō),就是通過(guò)查表,從頁(yè)表-》一級(jí)頁(yè)目錄-》二級(jí)頁(yè)目錄-》物理內(nèi)存。
頁(yè)目錄和頁(yè)表是存在內(nèi)存中的,毫無(wú)疑問(wèn),內(nèi)存尋址是一個(gè)非常非常高頻的事情,時(shí)時(shí)刻刻都在發(fā)生,而多次查表勢(shì)必是很慢的,有鑒于此,CPU引入了一個(gè)叫TLB(Translation Look- aside buffer)的東西,使用緩存頁(yè)表項(xiàng)的方式來(lái)減少內(nèi)存查表的操作,加快尋址速度。
默認(rèn)情況下,操作系統(tǒng)是以4KB為單位管理內(nèi)存頁(yè)的,對(duì)于一些需要大量?jī)?nèi)存的服務(wù)器程序(Redis、JVM、ElascticSearch等等),動(dòng)輒就是幾十個(gè)G,按照4KB的單位劃分,那得產(chǎn)生多少的頁(yè)表項(xiàng)??!
而CPU中的TLB的大小是有限的,內(nèi)存越多,頁(yè)表項(xiàng)也就越多,TLB緩存失效的概率也就越大。所以,大頁(yè)內(nèi)存技術(shù)就出現(xiàn)了,4KB太小,就弄大點(diǎn)。大頁(yè)內(nèi)存技術(shù)的出現(xiàn),減少了缺頁(yè)異常的出現(xiàn)次數(shù),也提高了TLB命中的概率,對(duì)于提升性能有很大的幫助。
在一些高配置的服務(wù)器上,內(nèi)存數(shù)量龐大,而CPU多個(gè)核都要通過(guò)內(nèi)存總線訪問(wèn)內(nèi)存,可想而知,CPU核數(shù)上去以后,內(nèi)存總線的競(jìng)爭(zhēng)勢(shì)必也會(huì)加劇。于是NUMA架構(gòu)出現(xiàn)了,把CPU核心劃分不同的分組,各自使用自己的內(nèi)存訪問(wèn)總線,提高內(nèi)存的訪問(wèn)速度。
I/OCPU和內(nèi)存都?jí)蚩炝?,但這還是不夠。我們的程序日常工作中,除了一些CPU密集型的程序(執(zhí)行數(shù)學(xué)運(yùn)算,加密解密,機(jī)器學(xué)習(xí)等等)以外,相當(dāng)一部分時(shí)間都是在執(zhí)行I/O,如讀寫硬盤文件、收發(fā)網(wǎng)絡(luò)數(shù)據(jù)包等等。
所以,如何提升I/O的速度,是高性能開(kāi)發(fā)技術(shù)領(lǐng)域一個(gè)重要的話題。
因?yàn)镮/O會(huì)涉及到與外設(shè)(硬盤、網(wǎng)卡等)的交互,而這些外設(shè)又通常是非常慢(相對(duì)CPU執(zhí)行速度)的,所以正常情況下,線程執(zhí)行到I/O操作時(shí)難免會(huì)阻塞,這也是前面在CPU部分提到過(guò)的。
阻塞以后那就沒(méi)辦法干活了,為了能干活,那就開(kāi)多個(gè)線程。但線程資源是很昂貴的,沒(méi)辦法大量使用,況且線程多了,多個(gè)線程切換調(diào)度同樣是很花時(shí)間的。
那可不可以讓線程執(zhí)行I/O時(shí)不阻塞呢?于是,新的技術(shù)又出現(xiàn)了:
非阻塞I/O
I/O多路復(fù)用
異步I/O
原來(lái)的阻塞I/O是一直等,等到I/O的完成,非阻塞I/O一般是輪詢,可以去干別的事,過(guò)一會(huì)兒就來(lái)問(wèn)一下:好了沒(méi)有?
但每個(gè)線程都去輪詢也不是個(gè)事兒啊,干脆交給一個(gè)線程去專門負(fù)責(zé)吧,這就是I/O多路復(fù)用,通過(guò)select/poll的方式只用一個(gè)線程就可以處理多個(gè)I/O目標(biāo)。再然后,再改進(jìn)一下,用epoll,連輪詢也不用了,改用內(nèi)核喚醒通知的機(jī)制,同時(shí)處理的I/O目標(biāo)還更多了。
異步I/O就更爽了,設(shè)置一個(gè)回調(diào)函數(shù),自己干別的事去了,回頭操作系統(tǒng)叫你來(lái)收數(shù)據(jù)就好了。
再說(shuō)回到I/O本身,會(huì)將數(shù)據(jù)在內(nèi)存和外設(shè)之間傳輸,如果數(shù)據(jù)量很大,讓CPU去搬運(yùn)數(shù)據(jù)的話,既耗時(shí)又沒(méi)有技術(shù)含量,這是對(duì)CPU算力的很大浪費(fèi)。
所以,為了將CPU從中解放出來(lái),又誕生了一門技術(shù):直接內(nèi)存訪問(wèn)DMA,把數(shù)據(jù)的傳輸工作外包出去,交由DMA控制器來(lái)完成,CPU只在背后發(fā)號(hào)施令即可。
有了DMA,再也不用麻煩CPU去執(zhí)行數(shù)據(jù)的搬運(yùn)工作。但對(duì)于應(yīng)用程序而言,想要把文件通過(guò)網(wǎng)絡(luò)發(fā)送出去,還是要把數(shù)據(jù)在內(nèi)核態(tài)空間和用戶態(tài)空間來(lái)回折騰兩次,這兩步還得CPU出馬去復(fù)制拷貝,屬于一種浪費(fèi),為了解決這個(gè)問(wèn)題,提升性能,又進(jìn)一步產(chǎn)生了零拷貝技術(shù),徹底為CPU減負(fù)。
算法架構(gòu)CPU、內(nèi)存、I/O都?jí)蚩炝耍瑔闻_(tái)計(jì)算機(jī)的性能已經(jīng)很難提升了。不過(guò),現(xiàn)在的服務(wù)器很少是單打獨(dú)斗了,接下來(lái)就要把目光轉(zhuǎn)移到算法、架構(gòu)上來(lái)了。
一臺(tái)服務(wù)器搞不定,那就用硬件堆出性能來(lái),分布式集群技術(shù)和負(fù)載均衡技術(shù)就派上用場(chǎng)了。
這年頭,哪個(gè)后端服務(wù)沒(méi)有數(shù)據(jù)庫(kù)?如何讓數(shù)據(jù)庫(kù)更快?該輪到索引技術(shù)上了,通過(guò)給數(shù)據(jù)庫(kù)建立索引,提升檢索速度。
但數(shù)據(jù)庫(kù)這家伙的數(shù)據(jù)畢竟是存在硬盤上的,讀取的時(shí)候勢(shì)必會(huì)慢,要是大量的數(shù)據(jù)請(qǐng)求都懟上來(lái),這誰(shuí)頂?shù)米??于是基于?nèi)存的數(shù)據(jù)庫(kù)緩存Redis、Memcached應(yīng)運(yùn)而生,畢竟,訪問(wèn)內(nèi)存比從數(shù)據(jù)庫(kù)查詢快得多。
算法架構(gòu)這一塊的技術(shù)實(shí)在太多了,也是從一個(gè)普通碼農(nóng)通往架構(gòu)師的必經(jīng)之路,咱們下回再聊。
總結(jié)高性能、高并發(fā)是后端開(kāi)發(fā)永恒追求的話題。
每一項(xiàng)技術(shù)都不是憑空出現(xiàn)的,一定是為了解決某個(gè)問(wèn)題而提出。我們?cè)趯W(xué)這些技術(shù)的時(shí)候,掌握它出現(xiàn)的原因,和其他技術(shù)之間的關(guān)聯(lián),在自己的大腦中建立一座技術(shù)知識(shí)層級(jí)圖,一定能事半功倍。
-
cpu
+關(guān)注
關(guān)注
68文章
10873瀏覽量
212083 -
編程語(yǔ)言
+關(guān)注
關(guān)注
10文章
1946瀏覽量
34792 -
代碼
+關(guān)注
關(guān)注
30文章
4797瀏覽量
68707
原文標(biāo)題:為了追求更快,CPU、內(nèi)存、I/O都做了哪些努力?
文章出處:【微信號(hào):zhuyandz,微信公眾號(hào):FPGA之家】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論