פתרון מדידה ושיפור ביצועים

פתרון התרגיל הראשון

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

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

פתרון התרגיל השני

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

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

פתרון התרגיל השלישי

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

בניסוי שבו latency נשלט על ידי שרת חיצוני איטי, אותו שינוי עשוי כמעט לא להשפיע על p95. זאת בדיקה מועילה שמפרידה בין חיסכון CPU לבין הcritical path של התרחיש. נגיש גם שגיאות וtimeouts; גרסה ש"מהירה" כי היא דוחה יותר בקשות אינה השוואה שקולה בלי לציין זאת.