הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
Unicode ב־C++ תיקון טעות.
עדכון קטן על תמיכה ב־Unicode ב־C++. למעשה, כשאמרתי בכתבה קודמת שאין כל תמיכה ב־Unicode, טעיתי. דווקא יש תמיכה אם כי היא לא מתקרבת למה ש־ICU נותן.
std::locale נותן מספר ממשקים בפרט: std::ctype<> שמאפשר המרה של case והמרת קידוד בין קידוד מקומי כמו utf-8 או cp1255 למחרוזות של wchar_t. הוא מצליח להמודד עם מקרים יחסית פשוטים כמו המרת "Артём" (השם הפרטי שלי ברוסית) לאותיות גדולות וקטנות בצורה נכונה: АРТЁМ. דבר שכל הכלים, אפילו פחות מוצלחים כמו Python ו־qt3 מצליחים לבצע ללא בעיה.
אבל תמיכה מובנית עדיין לא מצליחה להתמודד עם מקרים מסובכים יותר כמו ß הגרמנית ו־Σ היוונית.
כך שלצרכים הבסיסיים, ניתן להסתפק ב־API של C++ כפישהו, אבל כמובן זאת לא תמיכה מלאה (כמו גם בשפות אחרות, משל Python).
לדוגמה toupper:
// Set global locale
locale::global(locale("en_US.UTF-8"));
// Now we can use locale for various purposes
wchar_t str[]=L"Артём";
use_facet<ctype<wchar_t> >(locale()).toupper(str,str+5);
ייסורי Unicode ב־2009, או תמיכה ב־unicode בסביבות שונות.
אחד הדברים החסרים ביותר ב־C++, מבחינתי, זה העדר תמיכה טובה ב־Unicode. למרות ש־std::wstring ו־std::locale קיימים הם לא נותנים מענה על כל דרישות העבודה עם Unicode.
יש שפות תכנות כמו Python ו־Java בהן התמיכה הזו נחשבת ל"טבעית". אז החלטתי לעשות בדיקה ולבדוק מספר דברים חיוניים בעיבוד טקסט טבעי: החלפה בין אותיות גדולות וקטנות וכן מציאת גבולות המילים. דברים שנראים טריוויאליים עבור אנגלית למעשה הופכים לכלל לא טריויאליים כאשר מדובר בשפות אחרות:
- שינוי אות קטנה לגדולה: ß גרמנית צריכה להפוך ל־SS (שתי אותיות).
- שינוי אות גדולה לקטנה: Σ היוונית הופכת ל־σ במרכז המילה ול־ς בסופה.
- הפרדת מילים לצורך חיתוך הטקסט: 中文 אלה שתי מילים ולא מילה אחת.
בדקתי 6 כלים: ספריית ICU עם API במספר שפות, ספריית glib יחד עם pango עבור C, ספריות Qt3 ו־Qt4 עבור C++, וגם כלים טבעיים של Java, C++ ושל Python.
אקדים ואומר, המקרים הפשוטים כמו המרת: "Артём" (השם הפרטי שלי ברוסית) ל"АРТЁМ" עבדו בכל הכלים ושפות, אבל במקרים יותר מורכבים התוצאות היו כלל לא מעודדות:
| כלי | לאותיות גדולות | לאותיות קטנות | גבולות המילים |
|---|---|---|---|
| C++ | נכשל | נכשל | אין תמיכה |
| C++/ICU | הצליח | הצליח | הצליח |
| C++/Qt4 | הצליח | נכשל | הצליח |
| C++/Qt3 | נכשל | נכשל | אין תמיכה |
| C/glib+pango | הצליח | הצליח | נכשל |
| Java/JDK | הצליח | הצליח | נכשל |
| Java/ICU4j | הצליח | הצליח | הצליח |
| Python | נכשל | נכשל | אין תמיכה |
| Python/PyICU | הצליח | הצליח | הצליח |
עכשיו פרטים
המשך...האם בסיס הנתונים הוא צוואר הבקבוק של המערכת?
אחת הדעות המקובלות בקרב מפתח Web היא שבסיס הנתונים הוא צוואר בקבוק של המערכות. בסופו של דבר, אם יש המון נתונים והחיפוש לוקח 
אז אין מה לעשות. ברמה תיאורתית זה נכון.
אם יש לך בסיס נתונים של 1,000,000Gb (שזה 
) אז כנראה החזקה מספיק גדולה ואין משמעות לטכנולוגיות אחרות... השאלה היא האם זה נכון?
כידוע, מודל הסיבוכיות הוא עובד יפה כשמדובר במספרים גדולים מספיק ונוהג להתעלם מקבועים. מסתבר שהקבועים הם מספיק חשובים.
כדי להבין את זה, נקח כדוגמה את אחד הפרוייקטי ה־web הגדולים --- wikipedia או ליתר דיוק את חוות השרתים של wikimedia.
נתונים גולמיים:
- בחוות השרתים נמצאים כ־300 שרתים שונים.
- מתוכם במסלול הראשי:
- 95 שרתי Squid -- מה שנקרא Upstream cache שנותנים מענה לכ־78% מכל הבקשות (hit ratio שלהם).
- 144 שרתי Apache+PHP. שנותנים מענה ל־25% הנותרים.
- 20 שרתי MySQL שונים הרצים בתצורות Master Slave השונות.
- השרתים האחרים נותנים מענה לחיפוש, טיפול בקבצים סטטיים ועוד.
- מנגנון memcached משפרים ב־7% הנוספים את היעילות של יצירת התוכן ע"י שרתי Apache.
לכן כיצד שרתי SQL יכולים להוות צוואר בקבוק של המערכת אם הם מהווים פחות מ־10% מכל השרתים הקיימים בחווה? בהנחה שהמערכת שנבנתה ע"י media wiki היא מאוזנת, ברור לנו שרוב העומס החישובי נופל דווקא על שרתי apache המריצים את PHP.
אז האם באמת בסיס הנתונים הוא צוואר הבקבוק?
יותר מחשבים יותר ביצועים?
כשבניתי CppCMS תמיד לקחתי בחשבון ששרת יחיד לא תמיד יוכל להבטיח ביצועים מספיק טובים של שירות web עמוס. לכן, תמיד בתכנון המערכת, לקחתי בחשבון את האפשרויות של scale up.
בהחלט, הרבה יותר קל לתכנן מערכת שרצה על מחשב בודד עם זכרון משותף עם cache נגיש בצורה יעילה ועוד. אבל, במציאות זה לא יכול להיות. מערכות שמסוגלות לעמוד בעומסים גובהים הן בסופו של דבר חייבות להיות מוכנות לפעול בצורה מבוזרת.
לאחרונה הצלחתי להשיג גישה זמנית לרשת מחשבים חזקים במיוחד: Intel עם 4 ליבות שרצים ב־2.4GHz ו־4GB של זכרון. כך יכולתי לבדוק את מנגנון ה־cache המבוזר בעובד מעל TCP/IP ולהבין כמה אני מפסיק כתוצאה מביזור:
# Local Distributed
1 5,500 5,500
2 11,500 9,500
3 15,200 13,500
הטבלה מציגה את מספר הדפים בשניה שהמערכת wiki שבניתי מסוגלת לספק תחת הנחה של פגיעה 100% ב־cache (בגלל אילוצי הגישה לא יכולתי לשנות את הפרמטר). מספר השרתים הוא בין 1 ל־3 ומנגנוני ה־cache הם: cache המקומי הלא־מסונכון ו־cache המבוזר המסונכרן באופן מלא.
אפשר לראות, מחשב בודד מסוגל לייצר כ5 וחצי אלפי עמודים בשניה והמספר הזה הולך וגדל בצורה קרובה ללינארית עם שימוש ב־cache מקומי (כצפוי). שימוש ב־cache המבוזר מעל TCP/IP מקטין את מהירות הכוללת של המערכת אך עדיין שיפור ביצועים נשאר קרוב ללינארי.
יש לציין שהצלחתי למלא כמחצית מרוחב הפס של רשת 1GBit.
כמובן הניסוי הוא די מלאכותי, אבל הוא נועד בעיקר לבדוק עד כמה מנגון ה־cache המבוזר הוא יעיל. אני לא מביא לכאן פרטים מדויקים של ניסוי מפני שהוא היה יותר ניסוי פנימי, אבל בסה"כ הוא נותן הבנה של סדרי הגודל של מה שהמערכת מסוגלת לספק.
הכרות עם Java.
למרות שכבר יצא לי לדבג קוד שכתוב ב־Java לא הייתה לי התנסות מעמיקה עם שפת התכנות הזו. כלומר, אני מכיר את עקרונות הפעולה שלה... אבל לא עבדתי אתה הרבה.
לאחרונה, התחלתי לכתוב יישומים ויישומונים ב־Java ביניהם רכיבי GUI קטנים. הסיבות לכך היו שניים:
- דרישת הקורס -- הגשת תרגילים ב־Java.
- צורך לכתוב רכיבי GUI בלתי תלויים בפלטפורמה גם למערכות אקזוטיות ביותר כמו OpenVMS.
אז התחלתי להשתמש בה קצת יותר לעומק ו־... התחלתי להפנים כמה דברים מעניינים:
- יש דור מתכנתים שמקולקלים ע"י Java וחושבים במושגים שלה גם בשפות תכנות אחרות.
- Java היא בהחלט שפה יפה... יפה בפשוטתה המוחלטת הגובלת באמירה --- "כל המתכנתים מטומטמים"
עכשיו נסכם בקצרה
המשך...
