Buck - HWzone פורומים
עבור לתוכן
  • צור חשבון

Buck

משתמש רשום
  • מספר הודעות

    253
  • הצטרפות

  • ביקר לאחרונה

  • Days Won

    1

Buck last won the day on ספטמבר 26 2020

Buck had the most liked content!

דירוג

15 ניטרלי

אודות Buck

  • דרגה
    Zone Newbie

מידע נוסף

  • מין
    זכר

מבקרים אחרונים

16,570 צפיות בפרופיל
  1. מה עם סייברפאנק? אני מחכה לקנות כרטיס מסך חדש על מנת לשחק בו .
  2. זהו שבחומרה של הHDMI של ניוידיה היה באג והוא תומך רק בעד 60, מעניין אם גם ביציאה בכרטיסים של AMD. אני די בודאות קונה את הכרטיס הזה אז אני אצטרך למצוא זמן לעשות מחקר רשת.
  3. תגידו הכרטיס של AMD תומך בתעבורה של 120 הרץ על 4K או שהיציאות שלו הן חלק מהבאג? עכשיו אני מתלבט אם לקנות...
  4. אין על מה. זה די תלוי במתרגל\מורה שלך, הייתי שואל. זה מהדברים שאף אחד לא אומר לסטודנטים מראש לפני התרגיל שצריך לעשות אבל כל מיני נודים נפוחים באקדמיה אוהבים להוריד עליהם על מנת שהממוצע לא יהיה גבוה מידי... אם החלטת שכן אז שימי לב שאפשר להשתמש באותו האינדקס שהשתמשת בו להקצות על מנת לשחרר, שימי לב שאם נניח הקצת עד איבר 15 ואז ההקצאה נכשלה אז את יכולה להריץ את המשתנה i ששווה ל15 מ14 אחורה ל0 ולשחרר את כל האיברים שi רץ עליהם. אפשר לעשות זאת בפונקציה נפרדת (cleanup()) שמקבלת את i-1 כפרמטר כמו גם את המערך הדו מימדי.
  5. את צריכה להקצות בלולאה מערך בגודל n של פוינטרים לchar ואז לרוץ על המערך איבר איבר בלולאה ולהקצות בכל מקום n איברים בגודל char. אם את רוצה ממש את הקוד תכתבי אבל אולי תנסי לכתוב לבד, זה לא קשה במיוחד. קחי בחשבון שהקצאה דינמית יכולה להיכשל ואם היא נכשלה תצטרכי לשחרר את כל מה שהוקצה עד לאותו הרגע.
  6. אני חושב שהאיסור הוא על שימוש בכלים מורכבים של השפה שהוא לא למד עליהם ולא במבנה פשוט כמו מערך. goto בסי היא אחלה לניקיון משאבים, אלא אם המתרגלים/המרצים חושבים שהם מבינים בכתיבת קוד יותר מליינוס טריבלדס והכותבים של לינוקס...
  7. לא יודע מה הציעו לך, לא קראתי, אבל הכי פשוט ומהיר זה להשתמש בטבלה/מערך מאופס בגודל עשר, לעשות למספר מודולו עשר ולעשות פלוס אחד כל פעם במקום של הספרה שקיבלת. תחלק את המספר בעשר ותמשיך. ואז פשוט להוציא ספרה ספרה מהסטאק ולהוריד באחד במקום המתאים בטבלה. אם סיימת את המספר בלי לנסות לעשות מינוס אחד לאפס אז תחזיר true . אולי צריך להעתיק את הטבלה כמה פעמים ולחזור על התהליך עד שהסטאק מתרוקן ולהחזיר false תלוי בתנאים של הבעיה ובגודל הסטאק. זה קוד של איזה חמש שש שורות. יאללה נו, לא כתבתי כבר כמה שנים בג'אווה אז ברשותך אכתוב את הקוד בC, לא טרחתי לקמפל אבל זה לא באמת משנ
  8. מזלי שאני אנונימי אז אני יכול לכתוב את זה בלי לדאוג, הם ידועים בתעשייה כחברה שיכולה להיות מאוד לא סימפטית לשותפות וללקוחות, זה לא רק מהצד של המבקרים. אפשר לקחת את הסאגא שהיתה בינהם לאפל כדוגמא.
  9. nec_000 , אי אפשר לתייג פה? צריך לתת לך קרדיט על התחזית. לא מפתיע, זה היה ערוץ שהתקיף את ניוידיה ממש באגרסיביות.
  10. יש פתרון יותר טוב, הסיבוכיות בזמן של הפתרון הזה היא ריבועית. אם תוסיף עוד מערך שבו אתה מסמן אם עברת כבר בתא אז לא תצטרך לעבור בתאים פעמיים ואז תוכל להוריד את זה לO(2n).
  11. כנראה שאלך על מערכת מלאה של AMD בסיבוב הזה, על מנת להנות מהזכרון המשולב ומהתדר של הזיכרון, אבל אם הם יהיו הוגנים גם עם הכרטיסים שלהם אז אקנה מהם ולא מאמזון.
  12. זו קצת בעיה כי זה מאוד תלוי במימוש של החומרה והתוכנה, יש בשוק הרבה מאוד פתרונות לאיך לכתוב בSSD, בעקרון כל עוד הקובץ קטן מהמטמון של כל שבב אז אתה כותב למטמון שזו פעולה מהירה ואז הבקר יכול לכתוב ברקע את המידע מהמטמון לאיחסון עצמו. אם זה מעל הגודל של המטמון אז מאוד תלוי מה המצב בכונן, אם לא כתבו אליו הרבה זמן אז הבקר היה צריך לסדר את הזכרון בפנים בצורה שתאפשר לך להכניס מהר הרבה מידע בבת אחת. מה שנקרא בזמנו דפרגמנטציה כך שהכתיבה עדיין תיהיה מהירה. אם כל הזמן כותבים ומוחקים מידע מהכונן אתה צריך לחכות שהבקר או הדרייבר יסדרו בשבבים את המידע כך שיתפנה מספיק מקום רצוף לכתוב את
  13. הרעיון שSSD מורכב מהרבה שבבים קטנים כשלכל אחד יש מהירות כתיבה יחסית קטנה, כשיש לך קובץ גדול אז אפשר לחלק אותו לכמה בלוקים קטנים ואז במקום למשל לכתוב ב1000 לשבב אחד אתה כותב בו זמנית ב1000 לחמישה שבבים ואז אתה מקבל מהירות אפקטיבית של 5000. אם אתה רוצה לדעת מה המהירות האמיתית של כתיבה לשבב אחד אז תסתכל כמה ציפים גדולים יש לך על הגב של המעגל ותחלק את המהירות המקסימלית שהיצרן נותן במספר הזה. אגב, זו הסיבה שכוננים גדולים בדרך כלל יכולים להגיע למהירויות גדולות יותר.
  14. פאק ממש הזדקנתי, לקח לי יותר מידי זמן להבין... נשמע שהבעיה באלגוריתם שאתה מתאר היא שאתה לא יודע א-פריורית את הגיאומטריה של הצופה והעצמים. אני הייתי מנסה לחשב את הגיאומטריה לפני דברים אחרים או מנסה לפחות להסיק אותה מפריים קודם (למשל אם המשחק אומר לכרטיס הגראפי שהתמונה היא רק תזוזה או רק סיבוב אז חלק מהמידע יוכל להיות ממוחזר), מה שידרוש באמת שמירה חלקית של באפר קודם ושימוש בהפרשים, גם נשמע שיותר פשוט להשתמש ברינדור קודם של שכבה מוסתרת על מנת לרנדר אותה שוב כשהיא נחשפת וכך לפחות לחסוך קצת עבודה גם אם עשית עבודה מיותרת. שוב, אין סיכוי שלא חשבו על כך לפני וזו מתימטיקה לא פשוטה שאני לא י
  15. לגבי הארכיטקטורה, די ברור מהתמונה מהיכן הגיע הinfinity לשמות, זה באמת נראה כמו שמונה שוכב. יש כאן כמה בעיות שעולות לי מהיכרות עם המבנה הפנימי של מעבדים ובקרים, נראה לי מהמבנה שלליבות עצמן אסור לכתוב ישירות על אותן הכתובות בcache ואולי אפילו על כל הcache אחרת תיהיה כאן בעיית סנכרון היסטרית שתאט את הכרטיס בדומה למה שקורה עם מנעולים תוכנתיים קלאסיים כשכמה ליבות במעבד מעלות מידע לרגיסטרים שלהן במקביל מאותו איזור כתובות בcache ולפחות אחת מהן כותבת עליו וגורמת לכל הפעולות של כל האחרות להיזרק לפח כי המידע שהן עבדו עליו התיישן. בדיוק המקרה הקלאסי של MESI\MOESI. בנוסף, אם כתיבה
×
  • צור חדש...

בראש החדשות:

חדש באתר