לכל מחאה יש את העת שלה

ב־יום ראשון, 14 באוגוסט 2011, מאת ארתיום; פורסם תחת: תכנה חופשית; ‏10 תגובות

אני נהניתי מאוד מאוגוסט פינגווין, העברתי הרצאה, הצגתי פוסטר, קיבלתי המון תגובות החיוביות.

בסה"כ הכנס היה מאוד מוצלח ומהנה, ההרצאה של שחר שמש על תקן המקלדת החדש הייתה מעולה, נהניתי לראות את ההרצאה על הנגשת תקציב המדינה. אבל...

לא הבניתי, מה הקשר בין הכנס התכנה החופשית ועמותת המקור לבין "סדנת פיתוח למחאה החברתית", שבצורה לא ברורה התגנבה יום אחד לפני תחילת הכנס?

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

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

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

הפוסטר והמצגת מאוגוסט פינגווין

ב־יום שבת, 13 באוגוסט 2011, מאת ארתיום; פורסם תחת: תכנה חופשית, פיתוח, תכנה ומחשבים, CppCMS, C++‎‏, Unicode, Boost‏; תגובה אחת

אני מפרסם כמו שהבטחתי את המצגת והפוסטר מהכנס:

  • המצגת של ההרצאה על Boost.Locale:
  • הפוסטר על CppCMS‏: pdf‏

Clang - הפתעה נעימה

ב־יום רביעי, 10 באוגוסט 2011, מאת ארתיום; פורסם תחת: תכנה חופשית, פיתוח, תכנה ומחשבים, C++‎‏; ‏4 תגובות

כבר הרבה זמן אני שומע על Clang. עד לא מזמן די נהגתי להתעלם ממנו, בעיקר בגלל ששמעתי מילים כמו: "מכונה וירטואלית" ו־"JIT" שהטעו אותי. אבל לא זמן התחלתי להתעמק קצת יותר וגיליתי... קומפיילר C++‎ בשל.

מפתחים שעובדים עם שפות כמו C++‎, יודעים שהמצב שלנו שונה ממצבם של המפתחים העובדים עם שפות שיש להם "אבא יחיד". לשפות פופולריות רבות כמו PHP, Python, Perl, Ruby יש "אבא אחד" שמחליט כיצד הכל מתקדם. גם לשפות שיש להן תקן כללי, כמו Java או C#‎, עדיין יש "אבא אחד" בפועל. הוא נותן את הטון: אם זה Sun (ז"ל) עבור Java ו־Microsoft עבור C#‎.

כך או אחרת, המצב שונה כאשר מדובר ב־C++‎. יש הרבה יצרנים שונים שמפתחים קומפיירים, טובים יותר או טובים פחות. בצורה כזו תמיד יש תחרות ביניהם, אבל כמובן יש גם אי תאימויות ביניהם וגם לא תמיד יש תאימות לתקן עצמו.

עד לא מזמן, ל־GCC היה מונופול כמעט מלאה בתחום C++‎ ותוכנה חופשית. למרות שקיימים מספר קופיילרים של C היה רק קומפיילר חופשי אחד של C++‎. יש לזה יתרון וגם חסכון. היתרון הגדול ביותר הוא שגם קומפיירים אחרים (לפחות בלינוקס) שאפו להיות תואמי GCC. כך למשל הקומפיילר של Intel תואם מבחינה בינארית ל־GCC ומאפשר להשתמש בספריות של אחד יחד עם השני (שזה בכלל לא מובן מאליו בתחום C++‎). גם GCC אפשר זו בקלות יחסית ע"י מעבר ל־ABI סטנדרטי החל מגרסה 3.4.

אז כשניסיתי לפני מספר ימים Clang לראשונה הופתעתי לגלות קומפיילר C++‎ איכותי שתואם GCC כמעט ב־100%, אבל מיצרן אחר ובנוי על בסיס קוד שונה לחלוטין.

ניסיתי לבנות את CppCMS אתו, והצלחתי לעשות זאת מאוד מהר כמעט ללא בעיות!

אני שמח שסוף־סוף יש אלטרנטיבה טובה וחופשית ל־GCC, לא בגלל ש־GCC לא טוב ולא בגלל ש־Clang מעולה. אני שמח כי טוב שיש לך אפשרות בחירה, ובמיוחד טוב שיש תאימות גבוהה ביניהם!

מה שלא התרשמתי ממנו זה הביצועים. למרות הבטחות רבות Clang עבד רק בכ־20% יותר מהר ללא אופטימיזציה והיה אפילו אטי יותר בקומפילציה עם אופטימיזציה מלאה.

כך או אחרת... Clang בהחלט רשם אצלי כמה נקודות זכות!

כשהקצאות הזיכרון משנות

ב־יום רביעי, 10 באוגוסט 2011, מאת ארתיום; פורסם תחת: תכנה חופשית, לינוקס, תכנה ומחשבים, CppCMS, C++‎‏; ‏16 תגובות

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

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

ב־C++‎ יש מחרוזת הטובה הישנה: std::string. אבל יש לה מגבלה אחת: היא דורשת הקצאה של חתיכת זיכרון. זה נכון לכל מחרוזות בכל השפות ובכל הכלים גם אם הם immutable ומשתמשות ב-reference counting - עדין יש צורך להקצות זיכרון לאותה החתיכה.

בואו ניקח לדוגמה יישום פשוט שמאתר מקום כלשהו בעץ המשתמש במפתחות std::string המבוסס על std::map. הוא מקבל כפרמטר מחרוזת כמו ‎/foo/bar/124‎ ומחלץ ממנה את המפתחות foo ו־bar כחלקים במסלול, יישום בסגנון xpath.‏

אז עבור פונקציה:

void find_path(std::string const &str);

הקריאה

find_path("/foo/bar/123");

תצטרך ליצור שלוש מחרוזות:

  • ‎/foo/bar/123‎
  • foo
  • bar

כך או אחרת עבור שולש מחרוזות האלה נצטרך להקצות שלוש חתיכות זיכרון, גם אם המחרוזות שלנו משתמשות ב-reference counting או הן immutable.

אז כיצד CppCMS מתמודד עם הבעיה הזו:

  1. קיימת מחלקה מיוחדת cppcms::string_key שמחזיקה מתוכה את ה־std::string הישן והטוב. אבל בנוסף, ניתן ליצור את אותה המחלקה באופן מפורש מזוג מצביעים מטיפוס char const *‎, כך שהיא שומרת רק הצבעה לטקסט ולא מעתיקה אותו.

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

  2. עכשיו נשנה את הפונקציה find_path קלות ונוסיף לה עוד גרסה:

    void find_path(char const *str);
void find_path(std::string const &str);

    עכשיו, נשתמש רק במחרוזות שלא "מחזיקות בעלות על התוכן" ובכך נוכל ליצור מחרוזת מקורית ותת־מחרוזות foo ו־bar בלי להקצות זיכרון בכלל.

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

CppCMS החל מגרסה 0.99.9 ששוחררה היום, אימץ את הטכניקה הזו בצורה רחבה ואפשר, במקרים מסוימים, להכפיל את ביצועים המערכת כולה.

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

שוחררה גרסת Boost.Locale חדשה

ב־יום שני, 11 ביולי 2011, מאת ארתיום; פורסם תחת: תכנה חופשית, לינוקס, פיתוח, תכנה ומחשבים, CppCMS, C++‎‏, Unicode, Boost‏; ‏3 תגובות

אחרי עבודה ארוכה על שיפורי ממשק ותיקוני בעיות שהועלו בתהליך בחינה רשמית של Boost.Locale הגרסה החדשה 4.0.0 שוחררה.

בקרוב אתחיל לשלב אותה בעץ svn של Boost, כך שאם הכל ילך בסדר, אני צופה שהיא תיכנס לגרסה 1.48 או לכל המאוחר 1.49 של Boost.

כרגיל:

במקביל שוחררה גרסת CppCMS 0.99.8 שמכילה את כל השינויים של Boost.Locale וגם תיקוני באגים שהצטברו במהלך 3 חודשים אחרונים.

אם עדיין לא שמתם לב, אני נותן הרצאה על Boost.Locale באוגוסט פינגווין - תבואו יהיה מעניין (גם אם אתם לא מדברים ב־C++‎)

העמוד הקודם

העמוד הבא

דפים

נושאים