老地方冰果室交流區

在下最近在測試嵌入式系統用的程式。軟體弄好了，但是硬體平台廠商跳票延後，於是就弄了一個簡單的 Chip 模擬環境，打算先丟到電腦上測試。因為只是過渡期的測試用，懶得花太多心思去弄什麼完整架構，用了一堆 shared memory、fork、pthread 和 signal，然後用 usleep 和 SIGALRM 模擬時脈，想當然爾，寫出來的程式吃 CPU 資源吃到爆。程式是標準 POSIX 環境，在下分別在 PowerPC G4 1G、Dual G4 867 和 Intel P4 3G 的平台上編譯執行，結果卻出乎意料之外。

在下一開始寫的時候在 PB 1G 上編譯，為了時脈與 thread 衝突問題，花了不少精神調整 usleep 間隔來確保 shared memory & mutex 動作來得及完成。後來把程式搬到家裡的 PM G4 Dual 867 上，怪怪，執行效率驚人。縮短 usleep 信號間隔測試，程式的處理速度硬是快了將近一倍。

這兩天，為了要和其他人的程式碼整合測試，把程式碼原封不動搬到公司最新的一台 P4 3G 的 Fedora 2.0 平台上重新編譯。一執行，就被嚇了一跳，thread mutex 與 share memory 的處理速度慢到不行。必須重新調整 usleep 間隔，延長成原來的 1.5 倍才能正常運作。

這三台機器，光看時脈，P4 3G 是老 PM G4 867 的三倍以上；但是 Multi-thread 程式的執行效率，老 PM G4 867 卻是新 P4 3G 的三倍。雖然說這樣的評估與測試很籠統、有很多其他因素會影響，不過這樣的結果也實在有點誇張。不曉得這是 Apple 的 Dual CPU 架構設計得好，還是 BSD 天生就比 Linux 適合跑 Multi-thread 程式？

看來終於有理由要公司敗一台 PM Dual G5 來給在下操了

我是個外行人啦，
不過土想也知道，一顆CPU做Multi-threading 就如同叫他去做 Multi-processing, 不做比做快，因為CPU還得抽出一些額外的時間去做thread management.
多顆 CPU 在做 Multi-threading 則是平行處理，快是當然爾！

我很久沒有寫 C++ 程式了...

http://www.cprogramming.com/function.html

Mac 的 xCode 更是裝過沒用，換新 OS 就沒在裝了，我找不到 usleep function 定義，到Google 去找 C++ function library 也沒看到

倒是 PHP 有這個指令，莫非你用 PHP？應該不是....
我覺得這個 usleep function 可能大有問題，他的 delay time 是依據啥？ real time clocl？ 還是計算 CPU 指令的 clock time？

我也有 P4 3.0G, 925X, PCI-E ，不是 Server 級 Xeon 雙 CPU 版，如果跟你一樣 (我想是一樣)，不就一樣慢？？

打錯了，是 ualarm。
不過 usleep 也是 Standard C Library 的一個函式，
碰到不清楚的函式，記得要先去問男人喔。

ulysses 寫:碰到不清楚的函式，記得要先去問男人喔。

啊？不懂？？是指問女人會【問道於盲】嗎？

原來【The ualarm() function appeared in 4.3BSD.】這是 BSD 的函式啊，Windows 不支援這個吧？

所以你說的【Standard C Library 的一個函式】指的應該是 UNIX/Linux 系統，而不是 Windows 吧？我手上的書沒找到....

我找到這個：
http://www.osxfaq.com/man/3/ualarm.ws

include <unistd.h>

u_int
ualarm(u_int microseconds, u_int interval)

看了半天我只知道這個 ualarm() 需要兩個從 0 開始的正整數，第二個參數若不是 0 會每隔幾個微秒重複一次。

底下的東西對我來說是.... 有字天書，看不懂～～～
不幸的是，你早就懂了...... 淚～～ 我老了...... 泣～～～

http://www.linux.or.jp/JM/html/LDP_man- ... arm.3.html

/* BSD 版 */
#include <unistd.h>

unsigned int

ualarm(unsigned int usecs, unsigned int interval);

/* SUSv2 版 */
#define _XOPEN_SOURCE 500

#include <unistd.h>

useconds_t ualarm(useconds_t usecs, useconds_t interval);

The ualarm() function waits a count of microseconds before asserting the
terminating signal SIGALRM. System activity or time used in processing
the call may cause a slight delay.

If the interval argument is non-zero, the SIGALRM signal will be sent to
the process every interval microseconds after the timer expires (e.g. af-
ter value microseconds have passed).

實時間隔定時器有點特別。 Linux 在核心中使用了定時器機制來處理它。 每個程序有
自己的 timer_list 資料結構, 當實時間隔定時器運行時， 系統的 timer list (定時器列表)中把
它排入了隊列。 當定時器的時間間隔一到， 負責處理定時器事件的 bottom half handler 會
把它從隊列中刪除， 然後調用調用間隔定時器的處理器(並不是 CPU, 而是一段程式碼)。 這
個處理器這就產生了 SIGALRM 信號並且重啟間隔定時器， 又把它加入系統定時器隊列。

進藤光 寫:

ulysses 寫:碰到不清楚的函式，記得要先去問男人喔。

啊？不懂？？是指問女人會【問道於盲】嗎？

自修 unix 的不二法門，不懂的東西問男人(man)。

就小弟的角度來看
Solaris > BSD > Linux > Windows

不過,小弟想問ulysses,"時脈與 thread 衝突"是什麼狀況,又怎麼會用到usleep??

--
小弟是習慣使用VxWorks,舊版VxWorks沒有thread :X

在下現在弄的是一個 RF 的通訊協定，Physical Layer 是晶片，MAC Layer 是 Firmware。那個晶片設計的很爛，CSMA/CD 之類的低階動作還要由 Firmware 來控制。用程式模擬時自然就是 Physical 一個 thread，MAC 一個 thread，然後 CSMA/CD 的 slot 就用 shared memory 和 timer interrupt 來模擬。例如說傳送一個 Packet 應該在 3 個 slot 內完畢，可是 Physical Layer 在 3 個 slot 內無法完成 Shared Memory 的 Mutex & Copy 動作，就會出鎚了。所以 thread 的效率就直接影響 timer interrupt 的頻率。

ross_tt 寫:自修 unix 的不二法門，不懂的東西問男人(man)。

我果然是 UNIX 白癡～～～ 連大名鼎鼎的 UNIX MAN 都沒聽過.....

感謝指導～～

ulysses 寫:在下現在弄的是一個 RF 的通訊協定，Physical Layer 是晶片，MAC Layer 是 Firmware。那個晶片設計的很爛，CSMA/CD 之類的低階動作還要由 Firmware 來控制。用程式模擬時自然就是 Physical 一個 thread，MAC 一個 thread，然後 CSMA/CD 的 slot 就用 shared memory 和 timer interrupt 來模擬。例如說傳送一個 Packet 應該在 3 個 slot 內完畢，可是 Physical Layer 在 3 個 slot 內無法完成 Shared Memory 的 Mutex & Copy 動作，就會出鎚了。所以 thread 的效率就直接影響 timer interrupt 的頻率。

Soga~~
Dual 867跟PowerPC G4 1G比起來效率驚人應該是可以預期的,
不過3G的Fedora...................
Linux跟Mac OS X的schedular應該有相當的差異吧!!
kernel 2.4之前,都不能算是RTOS..........
搞不好要餓很久才被分到一點點resource........Orz

謝謝指教 //bow