איך תרגמנו 10 מיליון שורות של קוד C++ לתקן C++14 (ואז ל-C++17)

לפני זמן מה (בסתיו 2016), במהלך פיתוח הגרסה הבאה של פלטפורמת הטכנולוגיה 1C:Enterprise, עלתה בתוך צוות הפיתוח השאלה לגבי תמיכה בתקן החדש C ++ 14 בקוד שלנו. המעבר לתקן חדש, כפי שהנחנו, יאפשר לנו לכתוב דברים רבים בצורה אלגנטית, פשוטה ואמינה יותר, ויפשט את התמיכה והתחזוקה של הקוד. ונראה שאין שום דבר יוצא דופן בתרגום, אלמלא קנה המידה של בסיס הקוד והתכונות הספציפיות של הקוד שלנו.

למי שלא יודע, 1C:Enterprise היא סביבה לפיתוח מהיר של יישומים עסקיים חוצי פלטפורמות וזמן ריצה לביצועם על מערכת הפעלה ו-DBMS שונים. באופן כללי, המוצר מכיל:

• אשכול שרת יישומים, פועל על Windows ולינוקס
• לקוח, עובד עם השרת באמצעות http(ים) או פרוטוקול בינארי משלו, עובד על Windows, Linux, macOS
• לקוח אינטרנט, פועל בדפדפני Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari (כתוב ב-JavaScript)
• סביבת פיתוח (Configurator), עובד על Windows, Linux, macOS
• כלי ניהול שרתי יישומים, פועלים על Windows, Linux, macOS
• לקוח נייד, מתחבר לשרת באמצעות http(ים), עובד במכשירים ניידים המריצים אנדרואיד, iOS, Windows
• פלטפורמה ניידת - מסגרת ליצירת יישומים ניידים לא מקוונים עם יכולת סנכרון, פועלת על אנדרואיד, iOS, Windows
• סביבת פיתוח 1C:כלים לפיתוח ארגוני, כתוב ב-Java
• שרת מערכות אינטראקציה

אנו מנסים לכתוב את אותו קוד עבור מערכות הפעלה שונות ככל שניתן - בסיס קוד השרת נפוץ ב-99%, בסיס קוד הלקוח הוא כ-95%. פלטפורמת הטכנולוגיה 1C:Enterprise כתובה בעיקר ב-C++ ומאפייני קוד משוערים ניתנים להלן:

• 10 מיליון שורות של קוד C++,
• 14 אלף קבצים,
• 60 אלף כיתות,
• חצי מיליון שיטות.

ואת כל הדברים האלה היה צריך לתרגם ל-C++14. היום נספר לכם איך עשינו זאת ובמה נתקלנו בתהליך.

כתב ויתור

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

מה שהיה לנו

בתחילה, כתבנו את הקוד עבור פלטפורמת 1C:Enterprise 8 באמצעות Microsoft Visual Studio. הפרויקט התחיל בתחילת שנות ה-2000 והייתה לנו גרסה ל-Windows בלבד. באופן טבעי, מאז הקוד פותח באופן פעיל, מנגנונים רבים שוכתבו לחלוטין. אבל הקוד נכתב על פי תקן 1998, ולדוגמה, סוגריים ישרים שלנו הופרדו ברווחים כדי שהקומפילציה תצליח, כך:

vector<vector<int> > IntV;

בשנת 2006, עם שחרורו של פלטפורמה גרסה 8.1, התחלנו לתמוך בלינוקס ועברנו לספרייה סטנדרטית של צד שלישי STLPort. אחת הסיבות למעבר הייתה עבודה עם קווים רחבים. בקוד שלנו, אנו משתמשים ב-std::wstring, המבוסס על סוג wchar_t, לאורך כל הדרך. גודלו ב-Windows הוא 2 בתים, ובלינוקס ברירת המחדל היא 4 בתים. זה הוביל לאי תאימות של הפרוטוקולים הבינאריים שלנו בין הלקוח לשרת, כמו גם לנתונים קבועים שונים. באמצעות אפשרויות gcc, אתה יכול לציין שהגודל של wchar_t במהלך ההידור הוא גם 2 בתים, אבל אז אתה יכול לשכוח מהשימוש בספרייה הסטנדרטית מהמהדר, מכיוון הוא משתמש ב-glibc, אשר בתורו מורכב עבור wchar_t של 4 בתים. סיבות נוספות היו הטמעה טובה יותר של מחלקות סטנדרטיות, תמיכה בטבלאות גיבוב ואפילו אמולציה של הסמנטיקה של מעבר בתוך מכולות, שבה השתמשנו באופן פעיל. ועוד סיבה אחת, כמו שאומרים אחרונה חביבה, הייתה ביצועי מיתר. היה לנו שיעור משלנו למיתרים, כי... בשל המאפיינים הספציפיים של התוכנה שלנו, נעשה שימוש נרחב מאוד בפעולות מחרוזות ועבורנו זה קריטי.

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

הקו שלנו השתמש בשתי טכנולוגיות אופטימיזציה עיקריות:

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

כדי להאיץ את הקומפילציה של הפלטפורמה, הסרנו את מימוש הזרם מגרסה STLPort שלנו (שלא השתמשנו), זה נתן לנו הידור מהיר יותר בכ-20%. לאחר מכן נאלצנו לעשות שימוש מוגבל לְהַגבִּיר. Boost עושה שימוש רב בזרם, במיוחד בממשקי ה-API של השירותים שלו (לדוגמה, לרישום), אז נאלצנו לשנות אותו כדי להסיר את השימוש בזרם. זה, בתורו, הקשה עלינו לעבור לגרסאות חדשות של Boost.

דרך שלישית

בעת המעבר לתקן C++14, שקלנו את האפשרויות הבאות:

1. שדרג את STLPort ששינינו לתקן C++14. האפשרות קשה מאוד, כי... התמיכה ב- STLPort הופסקה ב-2010, ונצטרך לבנות את כל הקוד שלו בעצמנו.
2. מעבר למימוש STL אחר התואם ל-C++14. רצוי מאוד שהיישום הזה יהיה עבור Windows ו-Linux.
3. בעת הידור עבור כל מערכת הפעלה, השתמש בספרייה המובנית במהדר המתאים.

האפשרות הראשונה נדחתה על הסף עקב עבודה רבה מדי.

חשבנו על האפשרות השנייה זמן מה; נחשב כמועמד libc ++, אבל באותו זמן זה לא עבד תחת Windows. כדי להעביר את libc++ ל-Windows, תצטרכו לעשות עבודה רבה - למשל, לכתוב בעצמכם כל מה שקשור לשרשורים, סנכרון שרשור ואטומיות, מכיוון ש-libc++ בשימוש באזורים אלה POSIX API.

ובחרנו בדרך השלישית.

מעבר

אז, היינו צריכים להחליף את השימוש ב-STLPort בספריות של המהדרים המתאימים (Visual Studio 2015 עבור Windows, gcc 7 עבור Linux, clang 8 עבור macOS).

למרבה המזל, הקוד שלנו נכתב בעיקר לפי הנחיות ולא השתמש בכל מיני טריקים חכמים, כך שההגירה לספריות חדשות התנהלה בצורה חלקה יחסית, בעזרת סקריפטים שהחליפו את שמות הטיפוסים, המחלקות, מרחבי השמות וכוללים במקור קבצים. ההעברה השפיעה על 10 קובצי מקור (מתוך 000). wchar_t הוחלף ב-char14_t; החלטנו לנטוש את השימוש ב-wchar_t, כי char000_t לוקח 16 בתים בכל מערכת ההפעלה ואינו מקלקל את תאימות הקוד בין Windows ו-Linux.

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

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

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

עוד נחשפה תכונה מעניינת של הטמעת קונטיינרים בספריות משובצות: ריק (ללא אלמנטים) std::map ו-std::set מספריות מובנות מקצות זיכרון. ובשל תכונות היישום, במקומות מסוימים בקוד נוצרים די הרבה מכולות ריקות מסוג זה. מיכלי זיכרון סטנדרטיים מוקצים מעט, לאלמנט שורש אחד, אבל עבורנו זה התברר כחיוני - במספר תרחישים, הביצועים שלנו ירדו משמעותית וצריכת הזיכרון עלתה (בהשוואה ל-STLPort). לכן, בקוד שלנו החלפנו את שני סוגי הקונטיינרים הללו מהספריות המובנות ביישום שלהם מבית Boost, שם לקונטיינרים אלו לא הייתה תכונה זו, וזה פתר את הבעיה של האטה וצריכת זיכרון מוגברת.

כפי שקורה לעתים קרובות לאחר שינויים בקנה מידה גדול בפרויקטים גדולים, האיטרציה הראשונה של קוד המקור לא עבדה ללא בעיות, וכאן, במיוחד, התמיכה באיטרטורים של איתור באגים ביישום Windows הועילה. צעד אחר צעד התקדמנו, ועד אביב 2017 (גרסה 8.3.11 1C:Enterprise) הושלמה ההגירה.

תוצאות של

המעבר לתקן C++14 לקח לנו כ-6 חודשים. רוב הזמן עבד על הפרויקט מפתח אחד (אך בעל כישורים גבוהים מאוד), ובשלב הסופי הצטרפו נציגים של צוותים האחראים על תחומים ספציפיים - ממשק משתמש, אשכול שרתים, כלי פיתוח וניהול וכו'.

המעבר פשט מאוד את עבודתנו במעבר לגרסאות האחרונות של התקן. לפיכך, גרסה 1C:Enterprise 8.3.14 (בפיתוח, שחרור מתוכנן לתחילת השנה הבאה) כבר הועברה לתקן C++17.

לאחר ההגירה, למפתחים יש אפשרויות נוספות. אם קודם לכן הייתה לנו גרסה שונה משלנו של STL ומרחב שמות סטד אחד, כעת יש לנו מחלקות סטנדרטיות מספריות המהדרים המובנות במרחב השמות של std, במרחב השמות stdx - הקווים והמכולות שלנו מותאמים למשימות שלנו, בדחיפה - ה- הגרסה האחרונה של boost. והמפתח משתמש באותן מחלקות שמתאימות בצורה מיטבית כדי לפתור את הבעיות שלו.

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

כף זפת

אולי ההשלכה הכי לא נעימה (אך לא קריטית) של הגירה היא שאנו עומדים בפני עלייה בנפח קבצי obj, והתוצאה המלאה של הבנייה עם כל קבצי הביניים החלה לתפוס 60–70 GB. התנהגות זו נובעת מהמוזרויות של ספריות סטנדרטיות מודרניות, שהפכו פחות קריטיות לגודל קבצי השירות שנוצרו. זה לא משפיע על פעולת יישום ההידור, אבל זה גורם למספר אי נוחות בפיתוח, במיוחד זה מגדיל את זמן ההידור. גם הדרישות לשטח דיסק פנוי בשרתי בנייה ובמכונות מפתחים עולות. המפתחים שלנו עובדים על כמה גרסאות של הפלטפורמה במקביל, ומאות גיגה-בייט של קבצי ביניים לפעמים יוצרים קשיים בעבודתם. הבעיה לא נעימה, אבל לא קריטית; דחינו את הפתרון שלה לעת עתה. אנו שוקלים את הטכנולוגיה כאחת האפשרויות לפתור אותה לבנות אחדות (בפרט, גוגל משתמשת בו בעת פיתוח דפדפן כרום).

מקור: www.habr.com