https://www.amazon.de/G-Skill-Ripjaws-X-Arbeitspeicher-240-polig-DDR3-RAM/dp/B00602MIPM/ref=sr_1_1?ie=UTF8&qid=1472834969&sr=8-1-spons&keywords=g.skill+ripjaws+8gb+1333mhz&psc=1

 

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

ציטוט של nec_000

 

איזו מן השוואה היא כאשר אינה מבוצעת clock מול clock ?

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

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

 

עוד דבר מבקש, נא להשוות I5 ל- I5, ו- i7 ל i7.  אינטל בכל זאת ב- I5 נעלה את היכולת להריץ תהליכונים מקבילים,

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

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

 

ולכן מעתה בואו בבקשה נתמקד: 2500K אל מול 6600K, ו- 2600K אל מול 6700K .תחת RAM under same speed.

 

 

 

 

היי,

 

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

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

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

 

אגב, בקישור לבחינה שנתתי מדובר במעבדי i7 בלבד (ו-AMD אחד) ואין שם עירוב בין i5 לבין i7.

הבדלי התדר עומדים על כ- 17%, הבדלי הביצועים עומדים על כ-30% לעיתים.

בכל אופן, אם נתבונן בנתוני ה- Frame Time, נראה שה- 2600K יותר מבלה זמן רב יותר נופל ל-30FPS כאשר VSYNC מופעל.

ייתכן ונתון מתאים יותר יהיה כמה פעמים קצב המשחק נופל מ-60 FPS ל- 30FPS ולא משך הזמן הכולל במילישניות.

זה כנראה הרבה יותר מטריד כאשר במשך 2 דקות משחק נניח הקצב צונח ל-30FPS מסונכרן 20 פעמים למשך 20 מילישניות כל פעם מאשר פעם אחת למשך 400 מילישניות.

 

אם נחזור לנושא ה- i5 לבין ה- i7, מצאתי את המבחן שביצע הבחור הזה:

http://www.overclock.net/a/intel-core-i3-vs-core-i5-vs-core-i7-gaming-performance-with-geforce-gtx970

 

כאשר ב-2 מתוך 3 המשחקים שבדק האחוזון ה-99 של הפריימים מרונדר הרבה יותר לאט על ה- i5 לעומת ה- i7.

לצערי הוא לא צירף נתונים שמראים כמה זמן הכרטיס מבלה בכל קצב VSYNC.

אבל ניתן לראות למשל במשחק Witcher 3  ש-1% מהפריימים האיטיים ביותר במערכת כאשר ה- i5 פועל מרונדרים בפחות מ- 30FPS בממוצע, כלומר הסנכרון נופל ל- 20hz, בעוד ה- i7 מחזיק את ה-1% האיטיים ביותר עדיין מעל 30FPS בממוצע, וקצב הסנכרון ישאר ב- 30Hz.

 

אני משער כי ייתכן וההסבר טמון בריבוי הנימים.

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

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

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

 

 

ציטוט של coch

@nec_000

אני מודאג ממישהו שלא רואה מה זה נפילות פריימים מאיזור ה 60 לאיזור ה 30-40.

בערך ב 4:40 להסתכל למשך 15 שניות ולהגיד לי האם אני טועה שאני רואה את זה בבירור.

מצפה לתגובה חכמה.

 

 

 

 

איך הנך מסוגל להבחין ידידי, אם הסרטון מוגבל ל- 30hz , לא שמת לב מה תלית כאן ?

 

ואם הנך רואה בסרטון שכזה "בעיות", זה ממש לא בגלל 30FPS, אלא בשל משהו אחר שמוריד אותם way way מתחת

לערך זה. תתרשם לבד:

קח סרטון שרץ ב- 30FPS רציף. לא ירידה אל 30, אלא 30FPS יציבים וקבוע. האם כל הסרטון מגמגם לך ?

 

סיכום:

הנך מבלבל בין stutters לבין 30FPS. זה לא אותו דבר, לא קרוב או דומה או ליד.

כשמודדים stutters התופעה נראית כמו שניה שלימה של חור בלי פריימים כלל,

או כמה שניות שבהם ה FPS מגמגם בין 1-5 בערך. כדי שתקבל פרופורציה לסדר גודל.

 

התחושה הגדולה ביותר היא בשל input lag שפתאום מרקיע שחקים ויכול להיות 250 מילישניות או יותר, ופחות קשור ל- FPS עצמו.

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

 

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

בצורה המונית/מסחרית נגישה וזולה.

 

ציטוט של nec_000

איך הנך מסוגל להבחין ידידי, אם הסרטון מוגבל ל- 30FPS , לא שמת לב מה תלית כאן ?

 

ואם הנך רואה בסרטון שכזה "בעיות", זה ממש לא בגלל 30FPS, אלא בשל משהו אחר שמוריד אותם way way מתחת לערך זה.

 

תתרשם לבד:

קח סרטון שרץ ב- 30FPS רציף. לא ירידה אל 30, אלא 30FPS יציבים וקבוע. האם כל הסרטון מגמגם לך ?

 

סיכום:

הנך מבלבל בין stutters לבין 30FPS. זה לא אותו דבר, לא קרוב או דומה או ליד.

כשמודדים stutters התופעה נראית כמו שניה שלימה של חור בלי פריימים כלל,

או כמה שניות שבהם ה FPS מגמגם בין 1-5 בערך. כדי שתקבל פרופורציה לסדר גודל.

 

אפשר לראות בצד שמאל למעלה את הfps counter שצונח

 

צפיתי עכשיו, כמדוני שניה 4:46 או 4:47, זה לא 30 FPS אלא stutter רציני,  זו היתה חצי שניה של תקיעה ממשית,

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

וזה חברים לא בגלל מעבד.

 

זה  בוודאות אחד מאלו: IO, קריאה מדיסק,  heavy transfer , אולי data lag ברשת (אם זה משחק רשת),

יתכן טעינת משהו לכרטיס הגראפי דרך החריץ pci-e, טקסטורות, וכדומה....

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

מוריד את קצב העבודה בצורה לינארית, קרי יפלוט פחות FPS, ירד מ 60 ל 54. זה אינו בא לידי ביטוי או מרגיש כ- stutter.

stutter זו נפילה ברמה הרבה הרבה יותר דרסטית, כאילו המעבד ב 1000% ניצול, קרי נותן רק עשירית ממה שיכול ולכן זורק

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

 

הסיבה שכלי הניטור לא מראה 2 או 4 FPS באותו רגע נובעת משתי סיבות אפשריות:

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

2. או שבפועל היו כן כל התמונות על המסך, אלא שהיו הרבה תמונות זהות מצוירות, מה שמחזק את ההערכה במקרה שכזה

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

והמתין לדבר אחר חיצוני, data מהשרת (למשל).

 

ציטוט של nec_000

צונח לכמה ? ל 10 ? 5 ? תחסוך לי לצפות - סומך עליך שראית ותעביר נתון מדויק.

 

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

כנראה לא נמדד כראוי. זה אומר שיש שם input lag רציני שאינו מוצא את ביטויו במוניטור מהסוג שנבחר להצגה.

 

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

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

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

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

שמתי לב, והיות והסרטון ב- 30hz, וה- stutter נראה כמו בקושי 2-4 פריימים בשניה לרגע קט וחוזר ליציבות, זו אינה

ירידה של המערכת ל 30FPS. זו תקיעה שמקורה בצוואר בקבוק רציני במערכת.

 

עכשיו, אם זה משחק שרת, סבירות גבוהה ל- data lag מהשרת. בדר"כ כשבשרת אזור מועמס (הרבה שחקנים הרבה אקשן)

בדר"כ מתחילים לקרטע ב- traffic שהם שולחים אל ה- clients. זה עומס נקודתי בשרת עצמו ולא קשור לקליינט.

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

 

ואם מדובר ב- stutter מקומי בקליינט, שלא נובע מ- data מהשרת, אז יש הרבה סיבות שעשויות לגרום לכאלו קפיצות גסות:

IO מדיסק, אנטיוירוס שמתחיל לבדוק דברים מסוימים ברקע, או לבדוק את ה- traffic של הכותר עצמו ממש, עבודת FW שפתאום

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

אפילו context switch במעבד אינו גורם ל- 250 מילישניות, אלא לננו שניות.

 

האם מעבד CPU שמתחיל להיות נדרש לעומס שעולה על 100%, נגיד 110, 120, אפילו 130 אחוז גורם ל- stutters כאלו ?

חד וחלק לא.

 

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

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

אינה מובילה ל- stutters. עומס על מעבד מוצג תמיד כירידה לינארית בתפוקה, שאינה מורגשת בסביבת real time כקפיצה.

אלא מורגשת כעליה הדרגתית ומתונה ב input lag, שנגיד אם הרפרנס הוא 60FPS, קרי 16מילשניות, ירידה בתפוקה כדי 20% מעלה את

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

 

גמגומים כמו פתאום קפיצה ל- 250 מילשניות ויותר. ואולי ברצף כמה פעמים, זה נטו תקיעה במקום הרבה יותר איטי בשרשרת ההפקה של

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

 

מציעה לחברים ללמוד קצת בחומר חופשי על real time computing ועל ההשפעה של הרכיבים השונים על מכונה שכזו. יעשה לכם

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

 

 

עריכה/הרחבה למי שמתעניין:

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

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

 

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

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

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

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

 

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

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

בהיררכיה גבוהה דיה של משאבים. כל מה שצריך נמצא מראש ב- Vram של המאיץ הגראפי למשל.

גם מה שצריך מעבירים ל- cach של המעבד בדחיפה, ומוודאים שהוא לא ייגש לזכרון הראשי, באיזו שהיא צורה שחלילה 

תתבטא כקפיצה בפלט.

 

מערכת Real Time למשל כמו מערכת נ"מ, אוהב לתת זאת כדוגמא קצת הצידה, מערכת בקרת האש והשליטה של המכ"מ,

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

בזמן אמת, לא מסתמכים עליהם, הם מוגדרים כ non reliable real time device.

גם אין ירידה ל- trafic כבד מול זכרון RAM. אבויה אם המערכת לרגע קט תכנס לגמגומון, שבעטיו השליטה על המיירט שאמור

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

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

עם lag אפס בכל רובד. אפס משמעו פחות ממילי שניה. 

*למעט העליה הראשונה של המערכת שמצריכה טעינת כל החומר הראשוני לכל רכיביה, כמו הפעלה ראשונה של מחשב.

אך אחרי זה, חלקות הרמטית תמיד ואמינות 100%, יש redundency ומקור חשמל בלתי תלוי סביבה. המערכת אפילו מוגנת EMP

אם זה מעניין עוד, ומוכנה לעידן גרעיני.

 

 

ברגע התקיעה הברורה ב4:45 שים לב לשעון משמאל למטה, שמראה על שימוש בCPU איך הוא מקפץ ל100 אחוז וחונק את המשחק לשניה.

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

^אכן,

אך מה הסיבה המדויקת אין לנו מושג.

וכאן גם מעבד 7700K לא היה מועיל - נכנסו לצוואר בקבוק רציני. לא כזה שעוד 10% כח עיבוד, וגם לא 20 היו פותרים אותו.

*גם לא 50% יותר, שכן משהו כבד נכנס לתהליך והפריע לו ממש.

 

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

 

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

זה צניחה של פריימים מאיזור ה 62 לאיזור ה 31 במכה אחת. 4:45, הסיבה לצניחה לא מעניינת.

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

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

שמח שראית את זה.

 

הבעיה coch שהנך בכח ממש, מוכן להאמין כפנת, שה- stutter זה ירידה ל- 30 FPS, (וזו כבר טעות ראשונה באבחנת המצב שכן זה

אינו מה שמרגיש כ- stutter). ושנית שהנך נדבק רק להסבר אפשרי אחד, והוא שהבעיה מקורה רק בגלל המעבד, ואילו הוא רק

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

הנך מסוגל לענות עליה כלפי עצמך. זה עניין אישי שלך כבר.

 

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

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

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

 

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

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

מדופלמים בתחום. הראית ניסוי שמסביר ומגדיר מהו stutter ? (וזה לא ירידה ל- 30FPS שכח מזה)

 

יכול לשתפך כתכנת (בעברי), כאלגוריתמאי, כמנתח ומפתח מערכות real time, כמשתתף בפרויקטים (גם) של סימולטורים בתחום האזרחי

והבטחוני, כמנהל פרויקטים (בכיר) כיום, מנהל חטיבה בתעשייה אווירית זה מספיק ראוי ? ככה רק 800 מהנדסים ומדענים מוכלים בה, סביר

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

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

 

הנני מוכן לחתום לך עם חותמת של שעווה על מעטפה מתקופתו של לואי ה- 14, שלעולם stutter במערכת real time מהסוג שלפנינו, אינה

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

מעבד אינו קורס בבום ונופל לביצועי 0-10% מהרפרנס שלו בלי שום סיבה.

 

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

להקפיץ את זמן הביצוע מאזור של 16 מילישניות, נגיד לאזור של 250 . זה stutter.

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

קוד שהוא או זר לאפליקציה המורצת, או שהוא חלק מהאפליקציה אך מהווה כשל תכנוני בה, בהנחה שזו מערכת real time זאת אומרת.

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

המעבד שחזק ממנו ב 20 אחוז, ותכשיל גם את המעבד שחזק ממנו כפליים. לעולם עומס שכזה הוא way above their capabilities.

 

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

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

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

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

אולי אף יותר ממני, ולכן שווה לך לבקש גם את התייחסותו לנושא במקביל.

 

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

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

הולך חבר ?

 

-----------------------------------------------------------------------------------------------------------------------------

**stav, בו תעזור ותן את משנתך לפני החברים במקביל. רוצים לשמוע גם את מה שיש לך לשתף עימנו בנושא.

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

שלום לכולם,

 

נסחפתי לדיון, קראתי את כולו,  והוא מרתק מאוד.

גלוי נאות: איני מבין גדול בתחום אולם לדעתי אני "מספיק מבין" כדי לשאול את nec ו- coch את השאלות שאולי יובילו להסכמה- אגב, אני מהנדס אלקטרוניקה בתחום ה-RF בחברת HOT.

 

מספר שאלות:

 

coch- למה זה לא הגיוני בעינך שהשיפור בביצועים לא נבעו  מהחלפת המעבד עצמו אלא "ממערכת טריה" עם לוח אם, מערכת הפעלה, רכיבי i/O משופרים.

 

nec- בהנחה ש- coch החליף רק את המעבד, ובהנחה שהוא משחק ברשת ומפעיל רכיבי I/O, לא יתכן שהשיפור במעבד בלבד הוא זה ששדרג לו את החוויה ?

 

תודה מראש לעונים- רוברט

ציטוט של srobert

coch- למה זה לא הגיוני בעינך שהשיפור בביצועים לא נבעו  מהחלפת המעבד עצמו אלא "ממערכת טריה" עם לוח אם, מערכת הפעלה, רכיבי i/O משופרים.

 

 

 

בוקר טוב.. כמה דברים שאני יציין בנושא. חשוב שתבין שכאשר דיברתי בכל הדיון על נפילות פריימים קבועות עם i5 3570K מומהר מעל 4.0 לא היה שינוי

במאיץ הגרפי או במערכת הפעלה, עבדתי עם השילוש המבוסס Z77 גם על חלונות 10. מה שהשתנה בעצם למעבר 6700K זה DDR4 בלבד.

 

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

הסיבה היא שכאשר ה GPU usage עם ה 970GTX הישן עובד על אותם אחוזים בשרת מלא ב BF4  ב CPU ( המומהר ) יש חניקה יותר גדולה

אל מול ה i7 ( בסטוק ) כלומר הבדל של עשרות אחוזים ( 25-40 אחוז הבדל בשרת מלא ) אפשרי שהמעבד במצבים כאלה גורם לנפילות מורגשות.

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

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

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

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

ההשלכה על DDR4 לא נכונה מבחינתי, זה הכול.. הסברים טכניים וכו' לא יכולים לתת מענה לכך ש ה CPU usage במפה מפוצצת שחקנים שונה

בין המעבדים במשחק הזה. סה"כ יש לי 256 שעות על BF4 במצטבר, ויותר מ 250 שעות היו עם ה i5 מאחר ואני כבר לא משחק חודשים.

 

The main problem is the bad CPU-Thread-Affinity.

A pure Quad-Core CPU via D3D (DirectX) --> 4 cores and job threads in use via Bugfield4

A pure Quad-Core CPU via Mantle --> 4 cores and 3 Job threads in use via Bugfield4

An i7 2600k or an i7 3770k (both INTEL socket 1155) would be very helpful to decrease the CPU-Usage ;-)

 

@nec_000 אפרופו הוכחות. גם לך אין שום הוכחה אפילו לא אחת שמעבר מ DDR3 1866 ל DDR4 2800 עם אותו נפח של 16GB

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

שהוא עובדה, אלא רק הסברים והטפות.