סיכום הפוסט: מחפש פתרון יצירתי לקמפל פרוייקט מאוד גדול. המטרה היא ליצור סביבה שכל הפרוייקט נמצא ב- RAM ומתקמפל ל- RAM + גיבויים לדיסק.

--

אני עובד על פרוייקט מאוד גדול שלוקח זמן רב לקמפל. הקומפיילרים ישנים (gcc 2.96) וכך גם סביבת הקומפילציה (make). שניהם, לדעתי, עובדים עם ת'רד אחד. תהליך הקומפילציה דורש הרבה מאוד עבודה עם גישות רבות לדיסק (חיפוש קשרים בין קבצים, טעינת קבצי מקור, יצירת קבצי תוצר) ועבודת CPU (הקומפילציה וכו'). היום אני רוצה לבנות מערכת שתאיץ בצורה משמעותית את התהליך.

הבעיה היא כזו: כל סביבת העבודה היא XP. יתרה מזו, כדי להאיץ את אחד משלבי התהליך, אנו משתמשים ב- RAMDrive בנפח של בערך ג'יגה וחצי). זה אומר שאנו עובדים בסביבה עם בערך 2.5GB.

אני מנסה על פתרון יצירתי עם RAM. מה שהכי הייתי רוצה לעשות זה מערכת עם 8GB RAM, כאשר 4 מתוכו מוקצים לRAM דרייב (זה מה שהפרוייקט מצריך. עדיף יותר אפילו). עם הפעלת המחשב אני אעלה את הפרוייקט מהדיסק (ב RAID 0) לRAM ואקמפל את הכל ב- RAM ל- RAM (כלומר שכל תוצרי התהליך יווצרו וישמרו ל- RAM). כשאני מכבה את המחשב, אני מעתיק הכל חזרה לדיסק (כמובן שהכל מוגן עם UPS + איזשהי מערכת העתקה לדיסק כדי לא לאבד מידע במקרה של התרסקות).

הבעיה היא שXP לא תומכת ביותר מ- 4 ג'יגה. כמובן שאני יכול לנסות את XP64 אבל סביבת העבודה לא בנויה לכך ואני צופה בעיות (אלא אם כן XP64 היא קומפטיבילית ב- 100% לXP32 מה שאני מעריך שלא).

יש למישהו רעיונות לפתרון?

למה אתה משתמש ב2.96? לא רק שזו גרסאת פיתוח (SNAPSHOT) שלא תואמת לשום דבר אחר היא גם ממש ממש ישנה (כרגע קיימת גרסא 4.4.0)

ממה שראיתי יש אנשים שמדווחים על התקנה עובדת של 4.4.X על מערכות 64 ביט

למה אתה משתמש ב2.96

מדובר בסביבת עבודה של windriver שכוללת גם קומפיילר יעודי. אין לי שליטה על זה ולא מעשי לעבור לקומפיילר שלא אושר ע"י windriver. הפרוייקט עצמו הוא מוצר תקשורת (סוג של מרכזיה) שעוברות בו מיליוני שיחות סלולאריים... כשל קטן והמוצר נזרק לפח. [br]פורסם בתאריך: 6.06.2009 בשעה 13:23:56

---

חשבתי על רעיון.

לקנות מערכת עם 8GB או יותר ולהריץ עליה מערכת הפעלה שתומכת בכמות כזו של זכרון. מתוך מערכת ההפעלה הזו, להריץ RAMdrive בגודל גדול (נאמר, 5 GB). לאחר מכן להריץ VMWare עם XP. הXP תחת VMWare יראה את הRAMdrive כדיסק לכל דבר ויוכל לגשת גם ל- 4GB זכרון ראשי.

כל השאלה זה האם העבודה עם VMware תאיט יותר ממה שהפתרון יתרום?

תראה... לא עוברים לקומפיילר חדש אז אין מה לעשות

אם אין תמיכה ב64 אז אין תמיכה

מה שכן אפשר לעשות זה לקנות התקן שמתחבר בSATA/PCIE שמחברים אליו זכרונות והוא משמש ככונן קשיח לכל דבר(כך שאתה עוקף את הבעיה של 64 ביט)

משהו דומה לזה: http://hwzone.co.il/news/1242513565/31867/

פתרון נורמלי יותר הוא פשוט לעבוד עם כונני SSD קטנים (בשביל להוריד את המחיר הכללי) במערך RAID

קראתי על ה- i-RAM ובגלל מגבלת ה- SATA שלו (130MB/s בבנצ'מרקים) אני מוותר. ה- X1 נשמע מצויין אבל אני מבין שזה ממש ממש חדש ועוד לא מוצע בשוק. אין ספק שRAMdrive פיזי היה הפתרון המושלם פה.

לגבי SSD - היתרון קיים, אבל לא מהותי מספיק לפי הבנתי.

מה דעתך לגבי הרעיון עם VM (בפוסט הערוך שלי למעלה?)

עד כמה שאני יודע אין אפשרות להריץ מערכת 64 ביט מהוסט שהוא 32 ביט

עריכה-

אוקי עכשיו הבנתי...

זה יכול לעבוד, אבל זה יהיה דיי איטי.... מה שכדאי לעשות זה לקנות חומרה יעודית לאמולציה (מעבד שתומך בסט פקודות מסויים) ואז זה ישפר את המהירות הכללית

משהו אבל מציק לי ברעיון. ממה שאני זוכר שהתקנתי מערכות ווירטואליות אני לא זוכר שפניתי לדיסקים החיצוניים

אולי ישנה אפשרות כזאת ויכול להיות מאוד שהזיכרון שלי מטעה אותי

עריכה2-

אבל שכחתי לגמרי מהבעיה המרכזית. כמה זמן בעצם לוקח אותו קימפול? ומדוע זה מפריע? הרי אם תעשה מערכת קימפול נפרדת אתה בעצם מבטל את הבעיה

מדובר במערכת שאני קונה בעצמי אז אני לא רוצה להוציא אלפי דולרים על דברים אקזוטיים. אני חשבתי על ה- i7 920 עם שני 7200.11 ברייד 0. בגדול אני מבין שיהיה איטי יותר להריץ VM מאשר לעבוד נייטיב, אבל השאלה היא בכמה. משום מה, אני מחפש בגוגל VMWare benchmarks ופשוט אין תוצאות. לא לגבי הירידה בביצועי המעבד ולא (יותר חשוב) לגבי transfer rates של הרד דיסקים.

לא ביררתי ב- 100% אבל נשמע לי הגיוני ש- VMWare תתמוך באפשרות שתגיד לה להוסיף HD וירטואלי על HD פיזי לבחירתך. כך למשל אני יכול ליצור סביבת XP על הרייד0 (כדי שכל השינויים ישמרו) וליצור עוד HD וירטואלי של VM על ה RAMDrive שאצור בתוך הויסטה. ה- XP ירוץ באמולציה על דיסק קשיח רגיל ויראה דיסק וירטואלי שלמעשה ממופה לדיסק ה- RAMDrive שרץ בתוך הויסטה. כל השאלה זה תכלס כמה שיפור בביצועים אני אראה פה... קשה לדעת בלי להוציא את הכסף לצערי.

לגבי הקומפילציה, מדובר בתהליך שאורך בצורה הרגילה משהו כמו 3-4 דקות. תחשוב שכל פעם שאתה משנה קצת קוד אתה צריך לחכות את הזמן הזה - בזבוז משווע. אני רוצה שזה יקח לא יותר מחצי דקה. אם מקמפלים את כל הפרוייקט זה עניין של בערך חצי שעה (לא קורה הרבה אבל קורה).

לגבי מכונה נפרדת - מה הכוונה? הקומפיילר חייב לרוץ על XP.

בשעות הקרובות אעשה ניסוי לקמפל את כל הפרוייקט על גבי RAMdrive (מה שמשאיר מעט יחסית זכרון למערכת ההפעלה) ואכתוב מה השיפור בביצועים.

בעיקרון חשבתי שהבעיה שלך עם אורך הזמן זה שאתה לא יכול להמשיך לעבוד בזמן שאתה מקמפל...

אבל 3-4 דקות זה בהחלט לא מטורף... אם אתה לגמרי בטוח שהדיסק הקשיח הוא הבעייתי הפתרון הפשוט ביותר זה הSSD.... אפשר להגיע איתם לביצועים מאוד מרשימים בעלות לא מטורפת ונוחות מקסימלית

עריכה- האמת הפתרון הרבה יותר פשוט...

בעזרת שימוש במצב PAE בסביבת 32BIT אפשר לנצל את הזיכרון הלא מנוצל כדי לעשות RAMDISK

מדריך-http://hwzone.co.il/community/index.php?topic=413047.0

3-4 דקות זה באמת לא מטורף לכשעצמו אבל כשאתה מקמפל כמה עשרות פעמים ביום זה מצטבר להרבה זמן.

בכל מקרה, הרגע עשיתי בדיקה - העברתי את הפרוייקט ל- RAMDrive וקימפלתי עליו - התוצאות לא מספיק טובות. יתרון של 15% בערך. אומנם יש עדיין גישות לדיסק (כי כל קבצי סביבת העבודה נמצאים על הדיסק) אבל עדיין ציפיתי להרבה יותר.

וידאתי שאכן רק ליבה אחת בפעולה. חשבתי על משהו שאוכל לכתוב שישתמש בשאר הליבות.

קימפול על מספר ליבות? אני דיי בטוח שזה יותר העניין של הקומפיילר עצמו ולא מה שאתה כותב...

אם אתה רוצה שיפור עד כמה שאפשר תעביר הכל לRAMDISK אבל אז יש בעיה של של נתיבים וכו' והמעבר לדיסק ומהדיסק

כמו שכתבתי כבר קודם, הפתרון הכי הגיוני זה מערך כלשהו של SSD

Pavius תריץ קימפול ותבדוק את ה-cpu usage בליבה שמריצה את המשימה,

אם בממוצע היא עובדת קרוב ל-100% אז המעבד הוא צוואר הבקבוק,

אם בממוצע הליבה עובדת בניצול נמוך(נגיד 50% ומטה) אז הוא מחכה לטעינת קבצים רוב הזמן.

זה לא הקומפיילר עצמו, אלא מי שמריץ את הקומפיילר. אם תריץ שתי קומפילציות במקביל (שני פרוססים של הקומפיילר) הם ירוצו כל אחד על ליבה נפרדת. make עובד בצורה כזו שהוא סה"כ יוצר פרוסס של הקומפיילר שעושה ממש את העבודה. אני רציתי לכתוב משהו ש- make יקרא לו והוא יריץ X פרוססים של הקומפיילר - כלומר אפליקציה שתשב בין מייק לקומפיילר. במקרה שיש שתי ליבות, אוכל להריץ שני פרוססים בו זמנית. אם מייק יקרא לי שוב הוא ימתין עד שאחד הפרוססים מסתיים.

מה שגיליתי זה שאיחרתי בכמה שנים ויש דבר כזה, אפילו במייק עצמו. שיניתי את ה- makefiles שלנו ועכשיו (במקרה של קומפליציה של מספר קבצים) יש שיפור של בדיוק 100% על מחשב עם שתי ליבות. מן הסתם ככל שיש יותר ליבות (ובהנחה שצריך לקמפל הרבה קבצים) השיפור לינארי. השינוי אגב, נכון לכל make שתעשו. פשוט תריצו make -jX כאשר X הוא מספר הליבות.

nirt - בכל מקרה ה- CPU עובד בקרוב ל- 100%, לרוב ממש ב- 100% (לפני השינוי של המייק זה היה קצת יותר מ- 50%). למרות זאת אני מאמין ששיפור בביצועי הדיסק יכולים לשפר את התהליך.

אז אני מבין שפתרת את הבעיה... אבל אפשר לשפר עוד - אם בקימפול הקודם (על ליבה אחת) הליבה המסויימת שהריצה את המשימה עבדה 100% או קרוב לזה(את זה אתה צריך לבדוק ב-task manager בלשונית performance ולראות את הגרף של הליבה שמריצה ולא את אחוז הניצול שמופיע בכללי כי הוא מראה את אחוז הניצול של כל המעבד ז"א של 2 הליבות ביחד) אז ללא ספק המעבד הוא צוואר הבקבוק ואז כל שיפור בו אם אוברקלוק או שדרוג ישפרו את זמן הקימפול

הבעיה לעולם לא תפתר - זה תמיד עניין של כמה אפשר לשפר. הקומפילציה עדיין איטית ואני רוצה לשפר אותה עוד. בכל מקרה בנוגע לשאלה שלך - ליבה אחת עבדה קרוב ל- 100% (ומן הסתם זה נראה כמו 50% בטאב הראשי).

עם התגלית הזו נראה לי שאקנה i7 - מעניין אם HT יאפשר לי לראות שיפור גם אם אגיד למייק להריץ 8 קומפילציות במקביל (2 לכל ליבה). לגבי SSD\Raid0 אני עדיין עושה מחקר. כנראה שעד שאוכל להריץ את הסביבה במערכת הפעלה native שתתמוך ביותר מארבעה ג'יגה זכרון לא אעשה משחקי RAM. בינתיים ממחקר שטחי השיפור ניכר אבל לא משמעותי. אולי אעשה זאת מקומית פה ושם.

מה המפרט של המחשב שזה רץ עליו ?