[問題] compile 時間超過半小時

看板C_and_CPP作者 (藍影)時間14年前 (2011/12/29 23:40), 編輯推噓7(7推 0噓 18→)
留言25則, 11人參與, 最新討論串1/1
事情整體經過大致如連結所述 http://ppt.cc/k7T- 目前手邊專案已接近尾聲， 想請教若日後遇到類似問題是否可避開。 開發平台(Platform): (Ex: VC++, GCC, Linux, ...) Visual C++ 2008 / 2010 問題(Question)： 事情經過是這樣的，有份 project 用了 excel 寫了近 5000 個公式 (5000個儲存格)， 這 5000 個公式都參照其中之 6*24 儲存格，由於時間有限及一些因素， 故用了偷吃步的方式，先讀入 x[6][24] ，再將每個 x[i][j] 定義成一 macro， 最後直接把 excel 上之公式顯示出來，以額外的 project 去生成所需程式碼。 這裡有做初步改善之方式為，將額外生成之程式碼分開成 lazy.c 進行獨立編譯， 生成一 lazy.obj，這樣要產生完整程式碼就不用重頭編譯，(指令也只能自己下了..) 只是在 lazy.c 和需求者協議後，還是改了四次，且每次編譯時間都愈來愈長， 最後自動產生的 lazy.c 行數長達 11000 行左右，於是在第四次編譯時， 花了近半小時時間才編譯完成，當然編出來的執行檔效能不會有太大差別。 目前自己推可能是定義了6*24 = 144 個 macro， 且 5000 個公式最後都掛上 macro 表示，還必須判斷分母不能為 0 (不然會死當)， 故才拖到半小時。 不知是否有類似經驗之先進，能提示是否有其他解決方案？ 或，編譯半小時只是小事而已？ 謝謝各位不吝回覆，感激不盡。 --- 附一下我所說的部份 #define A1 x[0][0] // x[0][0] 對應到儲存格 A1 #define A2 x[1][0] // x[1][0] 對應到儲存格 A2 /* 一直定義到 x[5][23], 共 6*24 = 144 個 macro */ if( B1+C1 == 0.0) fprintf(fp,"-,"); else fprintf(fp, "%.2lf,", (B1)/(B1+C1)); /* 上面這二行是沒規則的公式, 直接寫另一個程式從 excel 抓下來處理 */ /* 共計有近 5000 個這種東西, 且使用之 macro 量不定 */ -- 世界上有種， 將 不可能 轉換為 無限可能 的強大力量， 我稱它為 - 信念。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 180.177.76.201
→
12/30 00:25, , 1F
小事,買四核心就解決,以前我make手機要花 2hrs
12/30 00:25, 1F
→
12/30 00:25, , 2F
結案才是重點,我猜太多 array
12/30 00:25, 2F
→
12/30 00:26, , 3F
看不太懂 lazy.c不能再依式子拆開 編譯的時後平行化嗎?
12/30 00:26, 3F
便是因公式繁多，要了解原理、歸納出公式，倒不如硬暴較符合急件需求。 較想請教的是，編譯平行化之需求
推
12/30 00:27, , 4F
假如經常遇到要花時間compile的話,單主機用i7 或是多台
12/30 00:27, 4F
→
12/30 00:27, , 5F
主機聯手compile, 會比較省點事.
12/30 00:27, 5F
推
12/30 01:44, , 6F
半小時是小事，整個過程的自動化比較重要
12/30 01:44, 6F
自動化，執行效能、結果、顯示，對方都算滿意。 看完推文後的心得: 我以為 Athlon II X2 245 2.92G Hz 算不錯了, 看來是我有所誤解。 在此先謝謝樓上各位給予意見，可能第一次遇到費這麼久的，所以有點傻眼。
推
12/30 07:49, , 7F
http://ppt.cc/9,EX 參考一下
12/30 07:49, 7F
→
12/30 10:21, , 8F
難怪,我用i5跑了兩年.build一直都很快,換台i5吧.
12/30 10:21, 8F
→
12/30 10:21, , 9F
RAM加大,硬碟加大,工具自己會最佳化.
12/30 10:21, 9F
推
12/30 10:57, , 10F
推樓上，換i5 + SSD才是王道..
12/30 10:57, 10F
推
12/30 16:37, , 11F
查一下.h是否有循環include的情況，機器只是隱藏了不良的習慣
12/30 16:37, 11F
→
12/30 22:25, , 12F
編譯工作對於IO的需求應該比較高，CPU幫助有限，衝SSD吧
12/30 22:25, 12F
推
12/30 22:54, , 13F
no,編譯工作是 computation intensive
12/30 22:54, 13F
@irh : 確定沒循環 include. 後來借用了另一台備配 程式是在RAMDISK 上生成， 記憶體 16GB， 2400MHz 記憶體 CL 9 CPU 3770K@4.6g Memory 16G CL9 HDD RAMDISK ， 18 分鐘 Orz.. 我在想瓶頸是卡在 5000 個 if-else ，還是 144 個 macro ? 還是 5000 個 if-else + 144 個 macro XD 問題可能有到牛角地步，是很好奇到底為什麼會變這樣而已.. ( 雖只是小事, 但難免會好奇..) ※ 編輯: tropical72 來自: 180.177.76.201 (12/31 01:41)
→
12/31 15:42, , 14F
編譯工作既吃 CPU 也吃 I/O，因為我都用 Gentoo 和
12/31 15:42, 14F
→
12/31 15:42, , 15F
FreeBSD，所有套件都是編譯安裝的，所以非常清楚。
12/31 15:42, 15F
→
12/31 15:43, , 16F
只是 CPU 的比重還是遠高於 I/O。
12/31 15:43, 16F
推
12/31 15:45, , 17F
I/O吃多重,也要看要編的程式的特性. 就這個而言,換成SSD
12/31 15:45, 17F
→
12/31 15:47, , 18F
應該沒有差 (應該只有 CPU-快取-ram 這樣的存取動作)
12/31 15:47, 18F
→
12/31 22:25, , 19F
原來是CPU比較重，我笨了...
12/31 22:25, 19F
→
01/01 14:00, , 20F
樓上謙虛了
01/01 14:00, 20F
→
01/01 17:40, , 21F
不，上過成功嶺真的會變笨...XD
01/01 17:40, 21F
→
01/01 17:58, , 22F
不知道你的.obj編出來多大? 我用程式碼產生器產生一個
01/01 17:58, 22F
→
01/01 17:58, , 23F
類似的程式, .obj: 1997kb
01/01 17:58, 23F
→
01/01 19:34, , 24F
obj : 2,459 KB
01/01 19:34, 24F
→
01/01 21:39, , 25F
static 太多..
01/01 21:39, 25F
‣ 更多 tropical72 的文章
文章代碼(AID): #1E_8doDv (C_and_CPP)