לדוג' נניח שיש לי מחשב עם המון RAM, נגיד 32GB, אני מפעיל את windows בלי הרבה סרויסים ותוכנות ברקע, בערך 1GB תפוס.

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

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

אפילו עם 8GB לא ראיתי (ככל הזכור לי) ניצול מלא של הזיכרון (חוץ מכרום שחושב שהוא באכול כפי יכולתך).

מה הבעיה בזה?

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

נניח וכתבתי תוכנה עם מערך בגודל 1GB (לא משנה כרגע סוג המשתנה בתוך המערך ועוד זיכרון שהולך "מהצד")

גם אם יהיה לי 128GB של ראם במחשב התוכנה לא תדע לנצל אותו כי מוגדר לה רק משתנה אחד בגודל 1GB

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

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

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

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

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

אם יש לך הרבה מאד זיכרון פנוי וממש בא לך לנצל אותו לשיפור המהירות של המשחקים, נסה להגדיר חלק מהזיכרון כ RAM Drive. תוכנת RAM Drive או RAM Disk פשוט לוקחת חלק מהזיכרון ומוסיפה אותו ככונן במחשב. אתה יכול להשתמש בכונן הזה כמו התקן איחסון רגיל, כאשר היתרון הוא כמובן שמדובר בכונן מאד מהיר (כל המידע נמצא בזיכרון הפיזי/ה RAM ולא על התקן איחסון פיזי), אבל מצד שני המידע שבכונן כזה יימחק עם כיבוי או אתחול המחשב (בחלק מתוכנות ה RAM Drive יש אפשרות לשמור להתקן איחסון פיזי את המידע שנמצא בכונן הוירטואלי הזה כך שיהיה אפשר לעבוד עם הכונן גם לאחר הפעלה מחדש של המחשב). חיסרון נוסף הוא הנפח - גם אם יש לך 32GB ואתה מקצה 16GB מתוכם לכונן כזה,, זהו עדיין נפח איחסון דיי קטן, וכיום יש משחקים שדורשים נפח איחסון הרבה יותר גדול.

איזה בעיות ?

א. מפתחים מכוונים למחנה המשותף הנמוך ביותר, אחרת מה ? יכתבו קוד אחד אם יש 4 גיגה, אחר אם יש 2 וחצי, אחר אם יש 8 וכו' ?

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

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

לגבי סמלול:

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

3. היום יותר ויותר ישומים (וגם משחקים) הם 64 ביט, אין להם את המגבלות הללו.

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

3. הבנת הנקרא: הוא לא אמר שהיכולת של המערכת כולה לנצל זכרון מוגבלת ל4GB, אלא שההקצאה לכל תהליך בנפרד היא מוגבלת.

תמיד התלבטתי אם חוזרים על שגיאות מספיק פעמים אז הם לא יהיו שגיאות?

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

אם הייתי רואה 80% זיכרון תפוס קבוע הייתי מבסוט.

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

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

אתה צודק באינטואיציה שזכרון פנוי הוא 'מבוזבז' אבל המצב שאתה מתאר הוא לא אפשרי..

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

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

מה שרשמת כ "

לא חסר דברים שאפשר לדחוף לזיכרון ובסופו של דבר יאיצו את הפעולה של המערכת" הוא נורא פשטני כי זה בלתי אפשרי

למערכת לנחש מראש במדויק מהם ה"דברים" האלה שאתה מדבר עליהם...

למרות זאת... אם אתה רוצה ברמתך לתעדף משהו מסויים יש דרך לעשות זאת באמצעות ראםדיסק כמו שרשמו פה.

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

שני האפשרויות יכולות להאיץ מאוד(!) את המערכת ,

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

נראה לי דווקא מאוד קל לניחוש איזה מידע יעזור ולהכניס אותו לזכרון מוקדם.

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

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

לדו"ג: אני בטוח ש: המחשב שלי\סייר, CHROME, אחד מיישומי OFFICE טכט' יופיעו אצל הרבה מאוד אנשים.

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

תקרא על superfetch/prefetch. זה קיים שנים במערכות הפעלה של מייקרוסופט.

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