אינטל רוצה משוב על ארכיטקטורת מעבד של 64 סיביות בלבד שנקראת x86S

אני מניח שזה דבר אמיתי? https://www.neowin.net/news/intel-w...sed-64-bit-only-cpu-architecture-called-x86s/

אני מניח... הנה הספר הלבן באתר של אינטל: https://www.intel.com/content/www/u...visioning-future-simplified-architecture.html

כך... נפטרים מכל החפצים הישנים ופשוט מריצים את x86-64. צריך לפשט הרבה היגיון, הייתי חושב. פחות כוח? לוגיקה אופטימלית (רץ מהר יותר)? אזור מות קטן יותר? ברור שהרבה אנשים יהיו נגד זה רק בגלל.

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

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

אני לא חושב שהאנשים שאנחנו צריכים לשמוע מהם הם אינטל, הם מיקרוסופט וצוות הפיתוח של Linux Kernel. באיזו מידה וטוב יתמכו מצבי אמולציה? יש כפתור מטרי של אפליקציות 32 סיביות. חשוב גם לדעת אם AMD נמצא על הסיפון. אם יש מעבר מסודר בין כל הספקים הגדולים זה דבר אחד. אם יש מצב שאני יכול לקנות מעבד AMD ולא לדאוג מה עובד ומה לא אבל מעבד של אינטל יכול לפעול רק עם Windows 11-64 או מערכת הפעלה מיוחדת אחרת, אז אינטל תצטרך להציג העלאת ביצועים משמעותית כדי להצדיק תאימות לאחור ערמומי?

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

אני מניח שהמטרה כאן היא קטנה יותר-קרירה-זולה יותר. מעניין אם הזיכיון יהיה ליבות X86S P, וליבות E מסורתיות.

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

מר E. בשר אמר:

עברו עשרות שנים מאז שעשיתי אסמבלר כלשהו, ​​אבל לא ניקיתי את ה-x86-64 הרבה מהחלקים?

לחץ להרחבה...

לא לגבי קידוד הוראות.

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

אבל ההוראות נראות כמעט זהות במצב 64 סיביות. האוגרים החדשים (r8 עד r15) ורוחב הנתונים החדשים (64 סיביות) מצוינים עם קידומות חדשות מול אותם קודים ישנים, ישנים. ככל הנראה המטרה הייתה להוסיף פונקציונליות של 64 סיביות עם שינויים מינימליים במפענחי ההוראות. אף אחד לא העז להתפשר על מצב 32 סיביות כאשר Win32 עדיין היה ה-API הדומיננטי לעתיד הנראה לעין.

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

mpat אמר:

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

זה אמור לומר שיישומי 32 סיביות לא יהוו בעיה.

לחץ להרחבה...

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

כן, הספר הלבן מתייחס ספציפית למצב User32, שבו קוד יישום 32-bit Ring 3 ממשיך לפעול ללא שינוי, כמו באופן דומה ב-ARMv8 AArch64 EL1 יכול להריץ קוד AArch32 EL0 בצורה רחבה תואמת ARMv7, ללא צורך להשתמש בטבלאות הדפים של ARMv7 או אחרים מאפיינים.

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

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

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

אם הכוונה היא לתחזק רק את שבבי ה-x86-S החדשים ובסופו של דבר ל-Sunset Full Legacy תואם X86, אני מצפה למעבר גדול ל-AMD או ARM עבור אלה שדואגים לתאימות לאחור או אל תעשה. נראה כאילו ה-x86-S ISA לא יוכל להריץ מערכת הפעלה מדור קודם של 32 סיביות בווירטאליזציה, שכן תמיכת חומרה כבר אינה קיימת, והדמיית טבעת 0 של 32 סיביות בווירטואליזציה היא יקרה ושגיאה נוֹטֶה.

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

אני לא מהנדס CPU, אבל השם גורם לי לתהות. X86"S", עבור מצב "S" בסגנון Windows-on-ARM של Windows (אך שמירה על תאימות חומרה מספקת כדי לאפשר מעבר מלא של Windows, למי שרוצה זאת)

הם יכולים לפתח עוד את הדגם ההיברידי של AlderLake, ליבות P ו-E של 64 סיביות בלבד ו-4 ליבות מדור קודם עם תאימות 32/x86 מופעלת.

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

הובולד אמר:

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

לחץ להרחבה...

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

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

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

הובולד אמר:

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

לחץ להרחבה...

בְּדִיוּק. אפילו עכשיו, המעבדים העדכניים ביותר של אינטל או AMD עדיין תומכים בכל המצבים המטורפים עוד מתקופת ה-8 סיביות, 16 סיביות ותחילת ה-32 סיביות.

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

להיפטר מהאשפה המוחלטת שהיא לפני x86-64 תהיה ברכה עצומה עבור מעצבי השבבים וצוותי האימות שלהם.

מטורף דוגי אמר:

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

לחץ להרחבה...

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

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

GeneralFailureDriveA אמר:

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

לחץ להרחבה...

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

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

GeneralFailureDriveA אמר:

אם הכוונה היא לתחזק רק את שבבי ה-x86-S החדשים ובסופו של דבר ל-Sunset Full Legacy תואם X86, אני מצפה למעבר גדול ל-AMD או ARM עבור אלה שדואגים לתאימות לאחור או אל תעשה. נראה כאילו ה-x86-S ISA לא יוכל להריץ מערכת הפעלה מדור קודם של 32 סיביות בווירטאליזציה, שכן תמיכת חומרה כבר אינה קיימת, והדמיית טבעת 0 של 32 סיביות בווירטואליזציה היא יקרה ושגיאה נוֹטֶה.

לחץ להרחבה...

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

הובולד אמר:

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

לחץ להרחבה...

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

רק אמר:

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

לחץ להרחבה...

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

רק אמר:

אני לא מהנדס CPU, אבל השם גורם לי לתהות. X86"S", עבור מצב "S" בסגנון Windows-on-ARM של Windows (אך שמירה על תאימות חומרה מספקת כדי לאפשר מעבר מלא של Windows, למי שרוצה זאת)

לחץ להרחבה...

אני בספק גדול כי ממה שראיתי אתה יכול להתקין את Windows 64 סיביות הקיים על שבב x86S מבלי ששינויים או אפילו מערכת ההפעלה יהיו מודעת. במחשב x86 מודרני עם UEFI, הקושחה תעביר אותו מיד למצב ארוך לפני שהיא עושה משהו אחר, והיא תועבר למערכת ההפעלה כבר במצב ארוך. זה אומר שכל החלקים נמצאים במקום לעשות זאת היום, מבלי ש-Windows/Linux/Whatever בכלל מודעים להבדל.

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

מגלודון אמר:

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

לחץ להרחבה...

הייתי מניח שאינטל בוחנת את המעבדים מבוססי ה-ARM של אפל וקצת עצבנית לגבי ההתפתחות המהירה בביצועים, תוך כדי מאמץ לפתח באמת את ארכיטקטורת x86 הבסיסית מבלי שצריכת החשמל תעבור מְטוּרָף. למיטב ידיעתי ARM לא קיים בביצועי חוט בודד, אבל התוכנה התחילה לעבור ריבוי חוטים כאשר קיבלנו מעבדים מרובי ליבות אפילו בגזרת התקציב.

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

מגלודון אמר:

איזה מבין אלה לדעתך יהווה בעיה? מתקין לינוקס עשוי להציג הודעת טקסט אך המעבד עדיין במצב ארוך.

לחץ להרחבה...

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

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

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

wireframed אמר:

הייתי מניח שאינטל בוחנת את המעבדים מבוססי ה-ARM של אפל וקצת עצבנית לגבי ההתפתחות המהירה בביצועים, תוך כדי מאמץ לפתח באמת את ארכיטקטורת x86 הבסיסית מבלי שצריכת החשמל תעבור מְטוּרָף. למיטב ידיעתי ARM לא קיים בביצועי חוט בודד, אבל התוכנה התחילה לעבור ריבוי חוטים כאשר קיבלנו מעבדים מרובי ליבות אפילו בגזרת התקציב.

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

לחץ להרחבה...

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

עומסי העבודה שיש לרוב האנשים אינם כאלה שגודלם ליניארי. בשלב מסוים אתה פשוט לא צריך יותר ליבות. אינטל חושבת כרגע ש-8 ליבות P מספיקות למוצר השולחני הגבוה ביותר שלהם. הליבות האלקטרוניות הנוספות בהחלט פוגעות בתשואות הולכות ופוחתות היום, בדיוק כפי שמעבר ממעבד ARM 32 ליבות למעבד ARM 64 ליבות. זה הרבה שרשורים שרק מחכים למשהו לעשות כאשר מה שאתה באמת רוצה הם שרשורים מהירים יותר. עבור עומסי עבודה שמתרחבים, יש כבר שרתים מבוססי ARM.

אולי לא תרצה את השרשורים המהירים יותר ב-CPU שמגיע לשיא של ~300w, אני אוותר שהיעילות של ARM היא נקודת מכירה, אבל הורדת מצב 16 סיביות לא תזיז את המחט על התרמיקה או הכוח של אינטל יְעִילוּת.

נווארה אמר:

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

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

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

לחץ להרחבה...

זו לא הייתה אשמתה של מיקרוסופט. זו הייתה אשמתה של AMD שהפילה את רוב התמיכה ב-16 סיביות במצב 64 סיביות. מה שעבד בסדר ב-32 סיביות נשבר לפתע במעבר של 64 סיביות.

זה גרם לי לכל כך הרבה כאב לאורך השנים. אני באמת רוצה למצוא את ראש הממשלה של AMD האחראי להחלטה העצומה ההיא ולעניש אותם בִּיסוֹדִיוּת.

מאלור אמר:

זו לא הייתה אשמתה של מיקרוסופט. זו הייתה אשמתה של AMD שהפילה את רוב התמיכה ב-16 סיביות במצב 64 סיביות. מה שעבד בסדר ב-32 סיביות נשבר לפתע במעבר של 64 סיביות.

זה גרם לי לכל כך הרבה כאב לאורך השנים. אני באמת רוצה למצוא את ראש הממשלה של AMD האחראי להחלטה העצומה ההיא ולעניש אותם בִּיסוֹדִיוּת.

לחץ להרחבה...

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

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

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

אמולציה היא מְאוֹד מְאוֹד איטי יותר מאשר ריצה ישירות על החומרה.

מאלור אמר:

לא הרווחנו כלום מהמחדל הזה.

לחץ להרחבה...

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

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