האם DRIVE COMPRESSION מוסיף או גורע מהביצועים ?

[Art Tatum]

בעשור האחרון השאלה עלתה שוב ושוב.

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

עולה השאלה, האם כתיבה וקריאה ל/מכונן מכווץ תחסוך זמן המתנה ?

[multicore]

שיפור בביצועים זה בטוח לא מביא.

[Art Tatum]

מקריאה שעשיתי על כונני SSD נראה שבקרי SF משתמשים בכיווץ כדי להפחית את כמות הנתונים שהמידע תופס על הSSD ובכך משפרים ביצועים.

Oh, I completely agree. 260MB/s as its slowest sequential operation is a phenomenal leap forward. And yes, I've seen a high number Interweb threads dedicated to SandForce bashing by Intel fanboys.

Granted, if the vast majority of your files are already compressed, then current SF drives don't offer a significant advantage over other controllers... but the reality is that most folks don't have excessive amounts of highly compressed files. At least not that they would store on an SSD. Folks that have TBs of uncompressable music, pictures, and videos are probably keeping them on a large platter anyway, so the argument is moot for most users. Still, it is an issue - however mild it might be.

אני יודע שזה לא מקור מוסמך אלה סתם תגובה של מישהו.

בכל מקרה זה גרם לי לחשוב.

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

יכול להיות שהאשם הוא בשיטת הכיווץ/פריסה ולא ברעיון הכללי שאולי נכון ליישם במציאות הקיימת ?

האם אין מצב בו DRIVE COMPRESSION כן מוסיף לביצועים ?

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

הנה ציטוט יותר ברור:

You can store compressed data on an SSD, it's just the SandForce controller gets a lot of its relative speed from compressing and abridging data when it does writes. That is, the controller has to write less for a compressible chunk of data, so it appears faster. For data that's already compressed, the controller can't compress it further, so writes are now at their real speed.

No other SSD controllers do this, so what speed they have is the same over compressed and non compressed data, regardless.

[X7-007]

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

אבל בארדיסקים אסור שיהיה אם מקום זה לא בעיה.

[Art Tatum]

ועובדה שבקרי SF עושים בזה שימוש בהצלחה ומגיעים לשיפור משמעותי ביותר בביצועים בזכות זה.

תחשוב שאתה צריך עכשיו לכתוב לדיסק 10GB ויש לך מעבד SB עתידי עם 16 ליבות ב6GHZ.

אתה יכול להעביר את ה10GB האלה דרך המעבד ולכווץ אותם בזמן אמת יותר מהר ממהירות הכתיבה לכונן.

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

לא חבל על כל הכוח המבוזבז הזה אם אפשר לעשות בו שימוש חכם כדי להאיץ את הגורם מספר 1 לעיכובים ?

[ha]

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

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

[Art Tatum]

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

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

אני שואל את השאלה הזאת כבר המון המון שנים.

למה אין בוינדוס QUEUE לפעולות קבצים שנעשות דרך הWINDOWS EXPLORER ומערבות את אותם כוננים פיזים ?

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

זה משהו שכל כך קל ליצור, והיה צריך להיעשות כבר בXP אם לא בME אם לא ב98 אם לא ב95.

ואני שואל את עצמי עד מתי ?

התשובה כנראה היא עד שמקינטוש יעשו את זה.

או עד שזה לא יהיה רלוונטי יותר בגלל שלכולם יהיה SSD.

או שהם יעשו את זה יום אחד סתם פתאום, וכולנו נשאל: למה לקח 20 שנה לכתוב קוד של 5 דקות שיכל לחסוך מיליוני שעות ברחבי העולם במשך הזמן ?