我之前的文章提到了為什么我們需要關(guān)注CPU利用率的問(wèn)題，總結(jié)一句話就是，利用率越低，你的系統(tǒng)效率越高、響應(yīng)越快，實(shí)時(shí)性越高。但是并沒(méi)有具體說(shuō)該如何計(jì)算CPU利用率。 今天，借助國(guó)產(chǎn)操作系統(tǒng)RT-Thread，我們開(kāi)始實(shí)操一番。在實(shí)操之前，需要簡(jiǎn)單了解幾個(gè)概念。鉤子函數(shù)，即以hook命名的那些函數(shù)。那么什么是鉤子函數(shù)呢？說(shuō)白了，就是一個(gè)函數(shù)指針，只是這個(gè)函數(shù)比較特殊一點(diǎn)。 特殊在哪？操作系統(tǒng)某些指定位置才會(huì)設(shè)置鉤子函數(shù)，比如程序運(yùn)行到空閑任務(wù)了，為了不修改系統(tǒng)源碼（沒(méi)事別修改源碼，很危險(xiǎn)的事情，除非你是真大佬），系統(tǒng)會(huì)提供一個(gè)設(shè)置鉤子函數(shù)的函數(shù)接口給你，當(dāng)你需要在空閑任務(wù)中執(zhí)行某些功能時(shí)，用這個(gè)函數(shù)設(shè)置你的需要功能函數(shù)就可以了，等系統(tǒng)運(yùn)行到空閑任務(wù)，他就會(huì)幫你調(diào)用這個(gè)函數(shù)了。 這個(gè)功能看著是不是有點(diǎn)眼熟，對(duì)的，和所謂的回調(diào)函數(shù)是一個(gè)道理（我也不明白為啥叫鉤子函數(shù)，可能是因?yàn)楹拖到y(tǒng)有關(guān)，和通用的回調(diào)函數(shù)又有點(diǎn)區(qū)別，所以就稱之為鉤子函數(shù)吧，不過(guò)你不要管名稱，只要知道意思就行了）。 除了在空閑任務(wù)可以設(shè)置鉤子函數(shù)，還有可能在任務(wù)切換、系統(tǒng)啟動(dòng)、任務(wù)創(chuàng)建等等關(guān)鍵的地方設(shè)置，當(dāng)然了，這里的每一個(gè)鉤子函數(shù)都是一個(gè)單獨(dú)的函數(shù)指針。 前面也說(shuō)了，設(shè)置鉤子函數(shù)的目的只有一個(gè)，那就是可以讓你在不修改系統(tǒng)源碼的情況下達(dá)到私人目的，讓系統(tǒng)的擴(kuò)展性更強(qiáng)，比如今天說(shuō)的內(nèi)容（還有下次介紹的線程CPU使用率問(wèn)題），如果系統(tǒng)沒(méi)有空閑鉤子函數(shù)的存在，你只能去修改系統(tǒng)源碼才能達(dá)到目的啦。 還有文章所說(shuō)的線程（task）、任務(wù)（thread），其實(shí)在RTOS中都是一樣的。在 uCOS、FreeRTOS 中，叫任務(wù)，RT-Thread 叫線程，只是叫的名稱不一樣，內(nèi)容都是差不多的。 然后再大概說(shuō)說(shuō)怎么計(jì)算的問(wèn)題。也就是在空閑鉤子函數(shù)里面，我們需要干什么事情才能到達(dá)CPU計(jì)算的目的。 首先，第一步肯定是設(shè)置鉤子函數(shù)，其次就是鉤子函數(shù)該怎么寫的問(wèn)題。這個(gè)網(wǎng)上一搜就出現(xiàn)了（魚(yú)鷹也是網(wǎng)上搜的代碼），然后就要分析為什么這么寫。 前面說(shuō)過(guò)，CPU利用率其實(shí)是首先計(jì)算一段時(shí)間內(nèi)空閑任務(wù)執(zhí)行時(shí)間，然后反推其他任務(wù)的執(zhí)行時(shí)間。 這里有兩個(gè)問(wèn)題，一段時(shí)間是多少？空閑任務(wù)的執(zhí)行時(shí)間怎么計(jì)算？先說(shuō)第二個(gè)問(wèn)題。用定時(shí)器時(shí)間掐？好像不好，因?yàn)槟悴恢朗裁磿r(shí)候程序就離開(kāi)了空閑任務(wù)跑去執(zhí)行其他任務(wù)了，而即使你可以知道它什么時(shí)候離開(kāi)空閑任務(wù)的，那也會(huì)增加計(jì)算難度，不是好的方式。 那怎么辦？還記得剛學(xué)單片機(jī)時(shí)你是怎么進(jìn)行軟件延時(shí)的嗎？對(duì)，就是用這個(gè)方法，軟件延時(shí)！ 只要程序執(zhí)行到空閑任務(wù)了，就用一個(gè)變量不停自加。這樣就可以根據(jù)變量值來(lái)大概計(jì)算空閑任務(wù)的執(zhí)行時(shí)間。 但是這里又存在一個(gè)問(wèn)題：如果這個(gè)變量一直自加，肯定會(huì)溢出，該怎么解決。 加大變量的大小，比如原先使用一個(gè)字節(jié)、兩個(gè)字節(jié)的，那么如果溢出，就用四個(gè)字節(jié)、八個(gè)字節(jié)。 但32位系統(tǒng)最大能支持的也就8個(gè)字節(jié)了，如果還是溢出了咋辦？再套一個(gè)循環(huán)，一個(gè)循環(huán)的數(shù)加完了，再加另一數(shù)就行了。 但是還有一個(gè)問(wèn)題，如果說(shuō)自加的時(shí)間不做限制，那么再多的變量也不行，而且還會(huì)影響CPU計(jì)算的實(shí)時(shí)性，也就不能實(shí)時(shí)反映CPU利用率了；而如果時(shí)間太短，如果剛好有任務(wù)的執(zhí)行時(shí)間在這個(gè)范圍，那么很可能你計(jì)算CPU利用率就直接是100%了。 比如說(shuō)你一個(gè)任務(wù)需要執(zhí)行10毫秒，然后你計(jì)算CPU的周期也是10毫秒，那么可能剛好開(kāi)始計(jì)算時(shí)跳到了那個(gè)任務(wù)執(zhí)行，那么你的變量就沒(méi)有自加了，也就會(huì)顯示100%利用率了。 這里其實(shí)說(shuō)的是前面的第一個(gè)問(wèn)題，一段時(shí)間是多少？ 對(duì)于這個(gè)時(shí)間，因?yàn)轸~(yú)鷹看的書籍比較少，所以也沒(méi)有理論支撐（如果有道友知道的，不如留言）。 但是肯定既要考慮變量溢出（這個(gè)可以通過(guò)加循環(huán)方式解決），又要考慮實(shí)時(shí)性，還要考慮其他任務(wù)的最大執(zhí)行時(shí)間，否則本來(lái)系統(tǒng)沒(méi)有問(wèn)題的，但是因?yàn)槟阕非髮?shí)時(shí)性，導(dǎo)致CPU利用率80%、90%的，那就很尷尬了。 以上討論如果沒(méi)有經(jīng)驗(yàn)可能比較難理解，所以建議大家在看完后面內(nèi)容，實(shí)操過(guò)后，再回頭重新看一遍，這樣才有更深的理解。 現(xiàn)在再看CPU計(jì)算公式：

cpu_usage = (total_count – count）/ total_count × 100 %（滑動(dòng)查看） cpu_usage: CPU利用率； total_count：?jiǎn)挝粫r(shí)間內(nèi)全速運(yùn)行下的變量值； count：?jiǎn)挝粫r(shí)間內(nèi)空閑任務(wù)自加的變量值。 total_count這個(gè)值表現(xiàn)了單片機(jī)全速運(yùn)行下，所能達(dá)到的最大值。所謂全速運(yùn)行，即不響應(yīng)中斷，也不去執(zhí)行其他任務(wù)，就單純讓它在一個(gè)地方持續(xù)運(yùn)行一段時(shí)間，這個(gè)值可以體現(xiàn)CPU的算力有多大。 比如，51單片機(jī)，可能這個(gè)值自加10毫秒之后只有100，STM32F1單片機(jī)自加能到1000，而STM32F4單片機(jī)能到2000，這樣就能體現(xiàn)他們之間的算力差別了。 這個(gè)值可以是動(dòng)態(tài)的，也可以是靜態(tài)的。靜態(tài)有靜態(tài)的好處，動(dòng)態(tài)有動(dòng)態(tài)的好處。 所謂的靜態(tài)是指，在系統(tǒng)沒(méi)有運(yùn)行任務(wù)時(shí)，關(guān)閉所有的中斷，自加這個(gè)值。這樣，這個(gè)值比較準(zhǔn)確，但是如果一開(kāi)始這個(gè)值計(jì)算錯(cuò)了，那么后面的計(jì)算肯定也是有問(wèn)題的，而且如果系統(tǒng)啟動(dòng)后長(zhǎng)時(shí)間既不啟動(dòng)任務(wù)，也不響應(yīng)中斷，肯定對(duì)系統(tǒng)有一定的影響。但是好處是，系統(tǒng)消耗更少，因?yàn)樗挥?jì)算一次。 而動(dòng)態(tài)計(jì)算，則是在空閑任務(wù)中，當(dāng)這個(gè)值為零時(shí)，計(jì)算一次，之后只會(huì)在空閑任務(wù)自加的變量值超過(guò)這個(gè)數(shù)時(shí)，才會(huì)更新這個(gè)值，這樣一來(lái)，最終還是能準(zhǔn)確反映CPU利用率的。好處是，不需要在開(kāi)機(jī)時(shí)關(guān)閉所有中斷，當(dāng)然壞處是，前期可能不是很準(zhǔn)，因?yàn)榭赡苡捎谥袛嘣驅(qū)е掠?jì)算的值較?。ㄖ袛嗵幚頃r(shí)消耗了算力）。 廢話太多了一些，直接開(kāi)始干吧。新建一個(gè)文件，拷貝如下代碼：

#include #include #define CPU_USAGE_CALC_TICK 10#define CPU_USAGE_LOOP 100 static rt_uint8_t cpu_usage_major = 0, cpu_usage_minor= 0;static rt_uint32_t total_count = 0; static void cpu_usage_idle_hook(void){ rt_tick_t tick; rt_uint32_t count; volatile rt_uint32_t loop; if (total_count == 0) { /* get total count */ rt_enter_critical(); tick = rt_tick_get(); while(rt_tick_get() - tick < CPU_USAGE_CALC_TICK) { total_count ++; loop = 0; while (loop < CPU_USAGE_LOOP) loop ++; } rt_exit_critical(); } count = 0; /* get CPU usage */ tick = rt_tick_get(); while (rt_tick_get() - tick < CPU_USAGE_CALC_TICK) { count ++; loop = 0; while (loop < CPU_USAGE_LOOP) loop ++; } /* calculate major and minor */ if (count < total_count) { count = total_count - count; cpu_usage_major = (count * 100) / total_count; cpu_usage_minor = ((count * 100) % total_count) * 100 / total_count; } else { total_count = count; /* no CPU usage */ cpu_usage_major = 0; cpu_usage_minor = 0; }} void cpu_usage_get(rt_uint8_t *major, rt_uint8_t *minor){ RT_ASSERT(major != RT_NULL); RT_ASSERT(minor != RT_NULL); *major = cpu_usage_major; *minor = cpu_usage_minor;} void cpu_usage_init(void){ /* set idle thread hook */ rt_thread_idle_sethook(cpu_usage_idle_hook);}以上的代碼網(wǎng)上找的，首先分析這兩個(gè)宏，第二個(gè)宏就是前面所說(shuō)的防止變量溢出用的，而第一個(gè)值就是CPU計(jì)算周期，這個(gè)值比較關(guān)鍵，后面再說(shuō)。 ? 首先在系統(tǒng)啟動(dòng)前設(shè)置鉤子函數(shù)：

然后，就沒(méi)有然后了。 對(duì)的，設(shè)置完之后就可以了，但為了讓我們能觀察到，可以打印出來(lái)。

我們可以觀察效果如何，開(kāi)始設(shè)置計(jì)算周期和任務(wù)延時(shí)函數(shù)一樣，10毫秒。 測(cè)試結(jié)果：

可以看到，因?yàn)槭莿?dòng)態(tài)計(jì)算的，所以開(kāi)始為0，因?yàn)橄到y(tǒng)首先運(yùn)行其他任務(wù)，只有其它任務(wù)不運(yùn)行時(shí)，才會(huì)開(kāi)始運(yùn)行空閑任務(wù)，所以CPU利用率為0。 但是即使后面有值了，你也會(huì)發(fā)現(xiàn)CPU利用率變化很大，0.82%~1.5%。而且你會(huì)發(fā)現(xiàn)除了開(kāi)始的0.0%，后面又再次出現(xiàn)了，這又是怎么回事？ 通過(guò)設(shè)置斷點(diǎn)分析，發(fā)現(xiàn)，這是因?yàn)橛?jì)算值超出了開(kāi)始的值，重新設(shè)置了：

這就是動(dòng)態(tài)計(jì)算的一些問(wèn)題了，它在一開(kāi)始的一段時(shí)間里，因?yàn)闊o(wú)法完全表現(xiàn)算力，只能通過(guò)后面不停的修正該值才能達(dá)到穩(wěn)定。 現(xiàn)在修改計(jì)算周期 20 毫秒：

發(fā)現(xiàn)它的表現(xiàn)更差勁，4.3%~11.61%，而且會(huì)周期性出現(xiàn)低利用率的情況。 再改，100毫秒：

可以看到這個(gè)比較穩(wěn)定了，13.71%~14.35%。 那么這個(gè)測(cè)試代碼實(shí)際情況的CPU利用率是多少呢？ 我們可以通過(guò)前面的筆記《KEIL 下如何準(zhǔn)確測(cè)量代碼執(zhí)行時(shí)間？》大概計(jì)算線程執(zhí)行時(shí)間：

1.59毫秒，10毫秒執(zhí)行周期，如果只有這個(gè)任務(wù)執(zhí)行，大概1.59/10=15.9%（準(zhǔn)確計(jì)算應(yīng)該是 1.59/(10 + 1.59) =13.7%）。 和前面的100毫秒類似。 我們先不管前面的結(jié)果，先理解一下里面的計(jì)算方法。 首先，如果total_count開(kāi)始為0，那么開(kāi)始第一次計(jì)算。這次計(jì)算會(huì)關(guān)閉調(diào)度器。

計(jì)算過(guò)后，就不再進(jìn)入。 之后就是動(dòng)態(tài)計(jì)算過(guò)程：

和第一次計(jì)算一樣，都是在一定時(shí)間內(nèi)自加計(jì)數(shù)器，不同的是，這次不會(huì)關(guān)閉調(diào)度器，也就是說(shuō)，如果有高優(yōu)先級(jí)任務(wù)就緒，那么是可以執(zhí)行其他任務(wù)的。 并且計(jì)時(shí)時(shí)間使用的是系統(tǒng)函數(shù)rt_tick_get()，單位為系統(tǒng)調(diào)度時(shí)間。測(cè)試環(huán)境中，系統(tǒng)調(diào)度時(shí)間為 1 毫秒。 有意思的是，在進(jìn)行最終的計(jì)算時(shí)，采用了分步計(jì)算，首先計(jì)算整數(shù)，再計(jì)算小數(shù)。 為什么要這樣做？效率！ 這樣的計(jì)算方法，可以將浮點(diǎn)運(yùn)算轉(zhuǎn)化成整型運(yùn)算，這在沒(méi)有浮點(diǎn)運(yùn)算單元的單片機(jī)中，能大大減少計(jì)算時(shí)間。 另外，為了防止溢出，還使用了一個(gè)循環(huán)結(jié)構(gòu)。 理解了以上內(nèi)容，現(xiàn)在開(kāi)始進(jìn)行魚(yú)鷹式深度思考：

上面的分步計(jì)算是否存在問(wèn)題？

關(guān)調(diào)度器只關(guān)閉了任務(wù)調(diào)度，但還是會(huì)響應(yīng)中斷，這能夠體現(xiàn)單片機(jī)最大算力嗎？

使用rt_tick_get() 函數(shù)進(jìn)行計(jì)時(shí)，精度是多少，會(huì)影響最終的計(jì)時(shí)嗎？

有必要使用循環(huán)體嗎？如果單位時(shí)間內(nèi)不溢出，是否不用循環(huán)體會(huì)更好？

前面的CPU使用率為什么會(huì)跳動(dòng)，按理說(shuō)任務(wù)的執(zhí)行時(shí)間應(yīng)該是確定的，也只有一個(gè)任務(wù)在運(yùn)行，不應(yīng)該跳動(dòng)才對(duì)？

10毫秒的計(jì)算和100毫秒的計(jì)算差別在哪？

7. 終極問(wèn)題，如何精確計(jì)算CPU使用率？ 上面的問(wèn)題，如果只是粗略計(jì)算，其實(shí)都可以不用考慮，本著對(duì)技術(shù)的熱愛(ài)，還是聊一聊好了。 1、分步計(jì)算，不知道你想到了什么BUG？這個(gè)問(wèn)題其實(shí)在以往的筆記都提過(guò)，這次再說(shuō)一次。 當(dāng)你在獲取CPU使用率時(shí)，如果剛好在更新這兩個(gè)值，那么可能整數(shù)部分是上一次計(jì)算的值，而小數(shù)部分卻是這次計(jì)算的值，那么肯定有問(wèn)題。 這就涉及到數(shù)據(jù)完整性獲取的問(wèn)題。怎么解決。關(guān)調(diào)度器、關(guān)中斷都可以。 但是因?yàn)槭谴致杂?jì)算，那么小數(shù)部分即使是錯(cuò)誤的，也沒(méi)事。 2、因?yàn)橹魂P(guān)調(diào)度器，所以對(duì)于中斷還是會(huì)響應(yīng)，比如說(shuō)你設(shè)定計(jì)算周期為100毫秒，那么1毫秒一次的systick中斷肯定會(huì)執(zhí)行，那么在100毫秒中，有100次進(jìn)入中斷執(zhí)行，而這些算力在上述算法中是無(wú)法體現(xiàn)的。 3、rt_tick_get() 函數(shù)精度問(wèn)題，因?yàn)檫@個(gè)是系統(tǒng)的軟件計(jì)時(shí)器，所以在測(cè)試環(huán)境中為1毫秒遞增一次，也就是說(shuō)它的精度在1毫秒。因此，在100毫秒的計(jì)算周期里面，有1% 的誤差存在，在10毫秒的計(jì)算周期里面，誤差10%！ 4、有沒(méi)有必要用循環(huán)體？在1秒計(jì)算一次的情況下，即使不用循環(huán)體，也不會(huì)導(dǎo)致溢出問(wèn)題。而且使用了循環(huán)體，還會(huì)導(dǎo)致精度降低，畢竟樣本少了。比如使用循環(huán)體最大值為100，不使用時(shí)為10000，哪個(gè)精度高？ 5、CPU使用率跳動(dòng)問(wèn)題。因?yàn)槭菧y(cè)試，所以只有一個(gè)任務(wù)在運(yùn)行，而且任務(wù)很簡(jiǎn)單。

這個(gè)任務(wù)的執(zhí)行時(shí)間應(yīng)該是固定的才對(duì)，但即使是使用了后面的高精度計(jì)算方式，CPU使用率還是會(huì)跳動(dòng)，這是為什么？ 第一，rt_kprintf函數(shù)執(zhí)行時(shí)間是不固定的，不固定在哪，比如要顯示的變量開(kāi)始是1，后面是1000，因此它輸出的字符串不一樣，并且打印時(shí)間也不一樣，因?yàn)槭遣樵兎绞酱蛴?，所以差別很大！這就是我為什么推薦DMA打印的原因，未使用前是10%，使用后可能就是1%，甚至更低。 第二點(diǎn)，也是非常容易忽視的一點(diǎn)，插入的中斷執(zhí)行時(shí)間。 系統(tǒng)每隔1毫秒需要進(jìn)入systick執(zhí)行一次（或者其他中斷執(zhí)行時(shí)間），如果說(shuō)任務(wù)的執(zhí)行時(shí)間超過(guò)1毫秒，那么中間必然會(huì)先執(zhí)行中斷，再執(zhí)行任務(wù)，這樣一來(lái)，因?yàn)橹袛嗟牟迦?，?dǎo)致時(shí)間不再那么準(zhǔn)確了。而當(dāng)你把打印的時(shí)間控制在 1 毫秒以內(nèi)，那么CPU使用率會(huì)變的非常穩(wěn)定。 第三：延時(shí)rt_thread_delay()函數(shù)本身的誤差，受到系統(tǒng)精度的影響，這個(gè)延時(shí)時(shí)間其實(shí)也不是固定的，會(huì)有一定的浮動(dòng)。 6、10毫秒和100毫秒計(jì)算的差別？ 如果說(shuō)你的任務(wù)執(zhí)行時(shí)間小于1毫秒，那么在10毫秒和100毫秒的計(jì)算差別不是很大，但是如果說(shuō)計(jì)算周期變成了5毫秒，即使任務(wù)執(zhí)行時(shí)間小于1毫秒的情況下，計(jì)算值也是會(huì)在最大和最小之間來(lái)回跳動(dòng)的。而執(zhí)行時(shí)間一旦超過(guò)1毫秒，那么10毫秒和100毫秒的計(jì)算就有較大的差別。 并且測(cè)試的時(shí)候，因?yàn)橄到y(tǒng)延時(shí)時(shí)間是10毫秒，而計(jì)算的時(shí)候也是10毫秒的周期，所以出現(xiàn)了比較詭異的事情，因?yàn)榘蠢碚f(shuō)延時(shí)10毫秒，任務(wù)執(zhí)行時(shí)間2.56毫秒，任務(wù)運(yùn)行周期為12 毫秒（還記得前面所說(shuō)的延時(shí)誤差嗎），CPU 使用率按理應(yīng)該是 21.3 左右，實(shí)際上卻是 6.5% 左右，相差太大了，這就非常奇怪了。而且如果更改執(zhí)行時(shí)間為1.5毫秒時(shí)（通過(guò)修改代碼修改執(zhí)行時(shí)間），發(fā)現(xiàn)計(jì)算值又正常了；而即使不修改執(zhí)行時(shí)間，修改計(jì)算時(shí)間為100毫秒，又正常了，這是怎么回事？ 通過(guò)深入分析發(fā)現(xiàn)，剛好在主任務(wù)延時(shí)10毫秒的時(shí)候，切換到了空閑任務(wù)進(jìn)行空閑時(shí)間計(jì)算，執(zhí)行了9.4毫秒的時(shí)候，又切回到了主任務(wù)，所以計(jì)算時(shí)，得到了6.5%的計(jì)算值。 粗略表示如下所示：

通過(guò)這個(gè)分析，你應(yīng)該知道，計(jì)算CPU的時(shí)候，盡量不要使用和任務(wù)延時(shí)時(shí)間一樣的計(jì)算周期，否則會(huì)出現(xiàn)莫名其妙的事情；還有一點(diǎn)就是，任務(wù)的執(zhí)行周期 = 任務(wù)執(zhí)行時(shí)間 + 系統(tǒng)延時(shí)，而前面所介紹的計(jì)算方法只是粗略的表示，嚴(yán)格來(lái)說(shuō)是有問(wèn)題的。 7、終極問(wèn)題，如何提高計(jì)算精度？通過(guò)以上分析，我們其實(shí)已經(jīng)知道了計(jì)算時(shí)的一些問(wèn)題點(diǎn)。首先，計(jì)算周期問(wèn)題，這個(gè)可以根據(jù)系統(tǒng)來(lái)確定，但是千萬(wàn)要注意前面的提到的問(wèn)題。如果說(shuō)500毫秒計(jì)算周期可以滿足要求的話，就沒(méi)必要使用50毫秒，不然你會(huì)發(fā)現(xiàn)計(jì)算值跳動(dòng)很大。 其次，時(shí)間精度問(wèn)題，這個(gè)問(wèn)題老生常談了，魚(yú)鷹建議是DWT，如果沒(méi)有，找一個(gè)定時(shí)器代替也是可以的。 最后是單位時(shí)間算力問(wèn)題，為了保證精確，可以關(guān)閉中斷進(jìn)行第一次計(jì)算，或者用短一點(diǎn)的時(shí)間，比如1毫秒得到一個(gè)算力，如果計(jì)算周期為100毫秒，那這個(gè)算力乘以100就行了。當(dāng)然如果系統(tǒng)時(shí)鐘不經(jīng)常變的話，也可以通過(guò)靜態(tài)方式先得到單位時(shí)間的算力，之后就以它為標(biāo)準(zhǔn)就可以了。這樣就不會(huì)有長(zhǎng)時(shí)間關(guān)中斷的情況出現(xiàn)了。 但是計(jì)算算力的時(shí)候，千萬(wàn)千萬(wàn)要注意一點(diǎn)的是，C語(yǔ)言轉(zhuǎn)化為匯編代碼時(shí)，可能一樣的代碼，在不同的地方執(zhí)行時(shí)間是不一樣的（比如前面代碼的第一次計(jì)算和后面的計(jì)算，看似一樣，但實(shí)際上有較大差別，原因就在于執(zhí)行效率不一樣），這個(gè)涉及到寄存器比內(nèi)存效率更高的問(wèn)題，所以計(jì)算算力時(shí)，可以把它封裝成一個(gè)函數(shù)，這樣，只要優(yōu)化等級(jí)不變，那么函數(shù)的執(zhí)行時(shí)間就可以認(rèn)為是確定的。