發信人: booth.bbs@bbs.stat.tku.edu.tw (藍色蝴蝶魚), 信區: fortran 標 題: How to be more fast ...... 我都在4DOS下跑程式， 而與其他同學比起來明顯的慢了一些， 不知有何方法可使程式RUN的快一些呢？ 寫批次檔或改autoexec會有用嗎....... ------------------------------------- 哈哈，我自己發現問題了， 因為寫的程式花俏了些， 我的副程式是寫成另一個FOR檔， 然後在主程式的結尾最後再加上$include， 結果在改了一些東東後乾脆將副程式直接寫在主程式裡， 後來就跑的飛快了........^_^ ---------------------------------------------------------------------------- 發信人: Devil@bar (璉璉), 信區: fortran 標 題: Re: How to be more fast ...... 這樣是完全不會對程式執行效率產生影響的! ---------------------------------------------------------------------------- 發信人: aurora@bar (怪怪胡), 信區: fortran 標 題: Re: How to be more fast ...... 如果說他是連副程式的結構都拆掉了 只有單一的主程式 那對速度確實有一些影響 尤其是在 win95 這作業系統下 ---------------------------------------------------------------------------- 發信人: Devil@bar (璉璉), 信區: fortran 標 題: Re: How to be more fast ...... 你是指主程式進入程序中所需要的記憶體切換嗎? 可是不管任何 OS 都需要啊! (ex. 將主程式中的變數依序推入堆積空間? 產生程序時所須要的時間? ) 可是放在主程式中也會拖慢主程式的啟動時間, 意義不也相同? 若是採用副程式會將主程式的速度從飛快拖慢下來, 那沒有一個程式能大起 來! 維護困難嘛! 所以我實在不瞭解您所指的在 Windows 95 下的影響! 是否能麻煩您稍加說 明, 您 post 中所指的情況? ---------------------------------------------------------------------------- 發信人: aurora@bar (怪怪胡), 信區: fortran 標 題: Re: How to be more fast ...... 其實我的推斷是基於直覺 因為win95的多工並非很好 尤其又是在4dos的shell底下作記憶體切換 若當你的程式要一直不停的call副程式時 也許大部分的時間都在做 i/o cpu所用的時間根本很少 至於別的os 我想雖然有沒有分別出副程式是有些些微差異 但應該影響不大 另外,我也看過有一些很大的程式,基於速度的考量,有時候也是不寫出副程式的 反正寫的人自己看得懂就好了 個人淺見,不吝指教. ---------------------------------------------------------------------------- 發信人: yhliu@bar (......), 信區: fortran 標 題: Re: How to be more fast ...... 不論是否用副程式, 和多工應扯不上關係, 因編譯過已成單一程式。 使用副程式對速度的影響, 充其量是在程式中加進副程式呼叫及引數 傳遞的一些指令 (就機器語言而言)。因此, 除非該副程式非常簡短, 短至所增加的副程式呼叫指令的相對時間具重要性, 並且該副程式被 呼叫頻率非常高。除此特例外, 一般使用副程式對執行效率的影響幾 乎可以忽略。當然, 若寫成副程式與併入主程式兩種寫法程式流程差 異太大 (例如副程式較具一般性, 因而增加許多條件判斷), 甚至完 全不同, 那根本不該相提並論。 除非真正有多工或需利用 windows 環境做對話, 否則不要在 dos 視 窗執行, 而應在純 dos 狀態 (單工) 執行, 其執行效率差很多! ---------------------------------------------------------------------------- 發信人: aurora@bar (怪怪胡), 信區: fortran 標 題: Re: How to be more fast ...... right, 那如何解釋你的第一二行話和最後兩行話的差別, 我實在不曉得哪一句才是對的 另外,原問問題的人他的說法也是表明 有沒有副程式對執行速度有很大的影響 我不曉得這又該如何解釋 謝謝不吝指教 ---------------------------------------------------------------------------- 發信人: yhliu@bar (......), 信區: fortran 標 題: Re: How to be more fast ...... 那是兩回事啊! 最後兩行話是說: 若你的程式不需要 Windows 界面, 不要用開 dos 視窗的方式執行。而最前面兩列說的是: 一個程式不會 因為撰寫時採用副程式的做法而嚴重影響執行效率。 沒看他的程式, 也無從猜測。如果真的完全是某部分程式碼獨立出來 成一副程式就會嚴重影響效率 (與我上述說法不符), 那應該是 compiler 的問題! (這也不是不可能! 有人能想像使用標準 Fortran 的格式化數值 輸入, 其效率遠低於自己寫個 Fortran 副程式來解碼, 把數字的 ASCII 碼轉換成數值嗎﹖我就親身經歷過這種做夢都想不到的事!) ---------------------------------------------------------------------------- 發信人: Devil@bar (璉璉), 信區: fortran 標 題: Re: How to be more fast ...... 看到這... 忽然想到前陣子本來打算做個測試報告給大家參考, 但因為老闆叫我 做的事太雜, 一直沒時間完成... 先把暫時的結果 post 出來好了! 結果 --------------------------------------------------------------------- 無責任測試 無螢幕輸出 編譯器 編譯法 執行時間 WorkSpace Visual Fortran 5.0 release 5.06 s QuickWin Visual Fortran 5.0 debug 5.16 s QuickWin Visual Fortran 5.0 MS-DOS 5.77 s 螢幕輸出 (Windows 環境下遠小於 MS-DOS 環境, MS-DOS 視窗稍慢於純 DOS) --------------------------------------------------------------------- 說明: 1.測試環境: cpu=pentium 233 mmx, SVGA: 11.3 TFT, 晶片: Chips and Tech. 65555 , 4MB , DRAM: 64 MB 2.測試目的: 對 2000 x 2000 的陣列跳躍式抽值計算, 藉此了解保護模式與真 實模式的差異 : 對繪圖環境與純文字環境測試, 藉此了解 Windows 環境的影響. 3.暫時結論: 在程式執行效率上，Release 比 Debug 模式少掉除錯符號及標記， 因此執行效率較高，在對於大陣列的運算上， Windows 模式較 DOS 模式省掉真實模式與保護模式的切換，執行效率較高。在對銀幕輸 出上 Windows 模式是以繪圖畫面對螢幕輸出，較 DOS 模式以文字 畫面輸出為慢，執行效率較差。總整上述相關執行效能之因素後， 採用 Windows 模式及 Release 模式編譯，並減少不必要的螢幕輸 出，以提高程式執行效能。 4.補充說明: 螢幕輸出部份上主要取決於顯示卡的能力, 所以有必要說明顯示卡 的種類. 測試程試碼 --------------------------------------------------------------------- c use dflib include 'flib.fi' include 'flib.fd' integer*2 ishr,ismin,issec,is100th,iehr,iemin,iesec,ie100th integer i real TmpArray(1:2000,1:2000) call GETTIM (ishr, ismin, issec, is100th) do i=1,2000 TmpArray(i,i)=sin(real(i)) do j=1,2000 TmpArray(i,j)=cos(real(j)) end do c write(*,*) i,TmpArray(i,i) end do call GETTIM (iehr, iemin, iesec, ie100th) write(*,*) real(((iehr-ishr)*60+iemin-ismin)*60+iesec-issec)+ 1 real(ie100th-is100th)/100 end --------------------------------------------------------------------- 又: 2000*2000*4/1024/1024 ~= 15.2587890625 (MB) DOS 模式只能支援 640 KB, 超過 1MB 以上須靠公用程式定址. 微軟用 DOSX.exe , Games 常用 DOS4gw.exe ---------------------------------------------------------------------------- 發信人: booth.bbs@bbs.stat.tku.edu.tw (藍色蝴蝶魚), 信區: fortran 標 題: Re: How to be more fast ...... ※ 引述《aurora.bbs@vlsi1.iie.ncku.edu.tw (怪怪胡)》： 抱歉，原本以為單純的問題卻引起大家的討論， 第一次的程式是分為兩個： AR1.FOR ............. CALL IMSL504( ) ........... END $INCLUDE IMSL504 IMSL504.FOR SUBROUTINE IMSL504( ) ............ END 第一次是寫了兩個程式，副程式是獨立出來另為一個檔案的！ 而第二次寫的時候將副程式擺在主程式裡CALL，一樣有寫副程式， 但只有一個程式。 是我一時沒搞清楚，理論上用一個檔案去連結另一個，應該較慢吧........ 另，提供一個試出來的辦法，在程式編輯完COMPILE之前會加上的DEBUG， 在COMPILE完之後可去掉再來一次，之後沒有了DEBUG的程式會跑的較快說...... 謝謝不吝指教！！ ---------------------------------------------------------------------------- 發信人: Devil@bar (璉璉), 信區: fortran 標 題: Re: How to be more fast ...... 您太客氣了吧? 大家討論正足以增進彼此的學識, 這也是 fortran版存在的目 的, 我是覺得你也可以一起加入討論, 很多技術的問題要靠一些前輩的提點, 也請各位前輩多多在連線 fortran版指導一下我們這些晚輩說! 加上 DEBUG會在程式機械碼各處加上除錯符號與標記, 以便配合除錯工具執行 Microsoft Fortran 3.x ~ 5.x用 CodeView , PowerStation已將除錯工具整 合至 IDE環境 (可至本站精華區參考除錯講座) , 這也是 Debug模式較慢的原 因. 看到 include就覺得你大概不管在主程式 call 或副程式 call 效果都是一 樣的. 程式語言編譯時一般分成編譯階段 (compiler) 與連結階段 (link), 在編譯階段時, 會將所有的 source(包含 include) 的編譯成機械碼 在連結階段會將所有用得到與相關的機械碼連結成一個執行檔 若找不到所須的機械碼, 一般設定是到各程式庫 (LIB)中去找, 假定你已有 IMSL 的 Lib檔, 則可順利連結, 若連結的是動態程式庫, 則不會將該程式碼連結至執行 檔, 而是執行時才載入. 在過去 OBJ, LIB, DLL之間是可以互相轉換的, 也許是智 慧財產的觀念, 現在只有單向 OBJ->LIB or OBJ->DLL . ---------------------------------------------------------------------------- 發信人: yhliu@bar (......), 信區: fortran 標 題: Re: How to be more fast ...... 我忘了定址超過 640k 的問題.... 在我的應用裡, 幾乎沒碰過 640k 不能做的事 (沒做 那麼大的 case)。若需要用到保護模式, 當然以能支 援保護模式的環境執行才適當。 ---------------------------------------------------------------------------- 發信人: d851001@ce.ntu.edu.tw (=?ISO-8859-1?Q?=B2=C4=A4=AD=A9=B6?=), 信區: fortran 標 題: Re: How to be more fast ...... 好久沒上FORTRAN版了，看到這個問題挺有意思，我也來談談我的看法！ 我覺得這個問題其實是另一類的『最佳化』問題！ 一般而言，最佳化可以分為algorithm及compiler最佳化兩類。前者程式本身的流程安排，後者 程式編譯器！通常編譯器(compiler)我們能動的不多，多半都在談流程安排！雖然說， 需不需要最佳化，需要視目的而定，但對喜歡自己動手寫程式的人而言，寫程式不只是要能跑出 所要東西，更要跑的快、跑的酷！ 早期，在台灣MS-Fortran系列compiler大概是一般用得最多的，晚近則以FPS為多（這裡不談 Unix、FreeBSD及Linux...的使用者），不論是MS-Fortran or FPS系列，微軟因為 FORTRAN compiler不是賺錢的金鵝，投入的少，其表現對 許多需要較高的人便轉向LAHEY Fortran，但無論如何，FPS IDE 設計的確不錯，on-line debuger也表現頗佳，雖然compiler蠻爛，還是很多人用 （另外一個原因是他便宜，取得容易） 所以一般想要較高效能，必須自己多方注意，如in-line coding.... 甚至走火入魔連subroutine, function能省得都沒了， 小程式無妨，要maintain大程式時，簡直想把當時寫程式的人捉來 打一頓！ 以先前網友所提的程式碼為例： 另外，debug模式必須將除錯指標送入堆疊中，已被debug用 ..... .... $include這個指令是F77過渡F90的產物，有點像模仿F90裡的『USE』，但只有 將所指向的檔案含入的意思。不會影響效能。（談到USE，本來想寫一篇fortran90 module的用法及應用，但事情太多，什麼時候面世就不曉得了） 在WIN95 or NT下每一程式都不可能得到CPU完全的使用權，會較純DOS慢，是正常的。 用NT（以下不談WIN9X，因為他實在很爛）主要目的在記憶體控制可達1.75GB， 或者目的為多緒程式，DCE運算（這個恐怕UNIX會比較好），介面較熟悉。 當程式大到某一個程度時（譬如我曾經跑一個ARRAY需要開到將近1GB，要RUN 52個小時，有極大量IO尖峰可能有超過200MB），DOS或WIN9X就沒輒了，或有大量 IO，這時候compiler本身是否有較佳的最佳化有時影響很大， 同樣一個程式，FPS4 compiles完後要52HR，DVF5約20HR，差別大吧！ 原因很簡單FPS的IO有問題，在大量IO下，有memory leakage現象，就是佔了系統資源後會HOLD住，然後 不斷向系統要IO資源，一直到系統受不了hold住為止。 即使後來PATCH過，效率還是很差！ DVF5.0雖然是承繼FPS但骨子裡是digital Fortran(Unix版） 除了IDE保留其餘全部放棄，可以說digital只是向MS買了visual studio的使用權。 在國外評比裡PCX86 MS plateform,上除了 ABSOFT FOTRAN在某些項目略勝兩分外，DVF把像NAG、STANFORD、FUJITSU .....通通幹掉，附帶一題，digital fortran在unix部分也是橫掃千軍。 可惜手頭上沒ABSOFT FORTRAN可以試試看。 題外話說了不少，希望不會太囉唆！