ความผิดพลาดมูลค่า 475 ล้านดอลลาร์ของ Intel: ปัญหาซิลิคอนของบั๊กการหารใน Pentium

 (righto.com)
3 คะแนน โดย GN⁺ 2024-12-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Pentium ที่ออกในปี 1993 ใช้วิธี SRT เพื่อให้การหารเลขทศนิยมลอยตัวเร็วกว่า Intel 486 แต่เมื่อข้อผิดพลาดของคำสั่ง FDIV ถูกเปิดเผยในปี 1994 Intel จึงยอมเปลี่ยนชิปที่มีข้อบกพร่องทั้งหมด โดยมีค่าใช้จ่าย 475 ล้านดอลลาร์
  • ข้อบกพร่องอยู่ใน PLA ที่ใช้สร้าง ตารางค้นหา สำหรับการหาร Intel ระบุว่าเกิดจากข้อผิดพลาดของสคริปต์ทำให้ขาดไป 5 รายการ แต่การวิเคราะห์ไดชี้ว่ามีรายการหายไป 16 รายการ และในนั้น 5 รายการก่อให้เกิดข้อผิดพลาดจริง
  • การหาร SRT แบบ radix-4 สร้างผลหารได้ 2 บิตต่อขั้นตอนจึงรวดเร็ว แต่มีโครงสร้างซับซ้อนที่แมปเศษเหลือบางส่วนและตัวหารไปยังตาราง P-D 2048 รายการ แล้วบีบอัดเป็น PLA 112 แถว
  • สาเหตุหลักคือ carry-save adder อาจทำให้ดัชนีสำหรับค้นหาต่ำกว่าเศษเหลือบางส่วนจริงหนึ่งช่อง แต่ Intel ใช้การปรับแก้ทางคณิตศาสตร์ที่ผิดกับขอบบนของโซน +2 ทำให้บางเซลล์ถูกปล่อยไว้เป็น 0
  • Pentium รุ่นที่แก้ไขแล้วไม่ได้เติมเฉพาะ 5 รายการที่หายไป แต่เติมพื้นที่ตารางที่ไม่ได้ใช้ทั้งหมดเป็น 2 ทำให้ขอบเขตเรียบง่ายขึ้น และแถว PLA ที่ใช้ก็ลดลงเหลือ 74 จาก 120 แถว เล็กกว่า PLA ที่มีข้อบกพร่องประมาณ 1/3

เส้นทางการเปิดเผยบั๊ก FDIV และค่าใช้จ่าย

  • Intel เปิดตัวโปรเซสเซอร์ Pentium ประสิทธิภาพสูงในปี 1993 และใส่อัลกอริทึมการหารเลขทศนิยมลอยตัวที่เร็วกว่า Intel 486 รุ่นก่อนหน้า
  • ในเดือนพฤษภาคม 1994 การทดสอบภายในของ Intel พบว่าการหารเลขทศนิยมลอยตัวของ Pentium ให้ผลไม่ถูกต้องในกรณีที่พบได้น้อยมาก
    • Intel เห็นว่ามีเพียงประมาณ 1 ค่าใน 9 พันล้านค่าที่ก่อปัญหา จึงมองว่าเป็นเรื่องเล็กน้อย
    • ถึงอย่างนั้น วงจร Pentium ก็ถูกแก้ไขอย่างเงียบ ๆ
  • ในเดือนตุลาคม 1994 ศาสตราจารย์ Thomas Nicely พบผลคำนวณผิดระหว่างทำวิจัยเรื่องส่วนกลับของจำนวนเฉพาะแฝด
    • การคำนวณ 1/824633702441 ผิดบนคอมพิวเตอร์ Pentium 3 เครื่องที่ต่างกัน ขณะที่คอมพิวเตอร์รุ่นก่อนหน้าให้คำตอบถูกต้อง
    • เมื่อไม่ได้รับการตอบสนองเพียงพอจากฝ่ายสนับสนุนเทคนิคของ Intel Nicely จึงส่งอีเมลไปยังนิตยสารคอมพิวเตอร์และบุคคลต่าง ๆ
    • อีเมลนี้ถูกโพสต์ในฟอรัม Compuserve และ Electronic Engineering Times เผยแพร่บทความ Intel fixes a Pentium FPU glitch เมื่อวันที่ 7 พฤศจิกายน
  • ในช่วงแรก Intel พยายามเสนอการเปลี่ยนชิปให้เฉพาะลูกค้าที่โน้มน้าววิศวกรได้ว่าจำเป็นต้องมีความแม่นยำ และผู้ใช้ก็ร้องเรียนในกลุ่มออนไลน์อย่าง comp.sys.intel
  • หลังข่าว CNN วันที่ 22 พฤศจิกายน ความสนใจจากสาธารณะเพิ่มขึ้น และสถานการณ์แย่ลงเมื่อ IBM ประกาศหยุดจัดส่งคอมพิวเตอร์ Pentium ในวันที่ 12 ธันวาคม
  • Intel ประกาศเมื่อวันที่ 19 ธันวาคมว่าจะเปลี่ยนชิปที่มีข้อบกพร่องให้ลูกค้าทุกคน
    • ค่าใช้จ่ายในการเรียกคืนคือ 475 ล้านดอลลาร์
    • คิดเป็นมูลค่าปัจจุบันเกิน 1 พันล้านดอลลาร์

การหาร SRT ที่ Pentium ใช้

  • การหารยาวแบบไบนารีทั่วไปต้องใช้หนึ่งคล็อกต่อหนึ่งบิตของผลหาร จึงช้า
    • Intel 486 และโปรเซสเซอร์รุ่นก่อนหน้าใช้แนวทางนี้
  • Pentium ใช้อัลกอริทึม SRT แบบ radix-4 หรือทีละ 2 บิต
    • สร้างผลหารได้ 2 บิตในหนึ่งขั้นตอน จึงเร็วกว่าการหารไบนารีทั่วไปสองเท่า
    • ค่าหลักแต่ละตำแหน่งของผลหารเป็นหนึ่งใน -2, -1, 0, 1, 2
  • SRT อนุญาตให้ค่าหลักของผลหารเป็นลบได้ ดังนั้นแม้เลือกค่าที่มากไปเล็กน้อยในขั้นตอนหนึ่ง ก็สามารถแก้ด้วยค่าหลักลบในขั้นตอนถัดไปได้
  • ค่าหลักของผลหารไม่จำเป็นต้องถูกกำหนดเป็นค่าเดียวอย่างแม่นยำ จึงเลือกได้อย่างรวดเร็วด้วย ตารางค้นหา
    • ตัดเศษเหลือบางส่วนและตัวหารเหลือเพียงบางบิต เพื่อลดขนาดตารางให้อยู่ในระดับใช้งานได้จริง
  • วิธีนี้รวดเร็ว แต่ต้องมีตารางค้นหา วงจรสำหรับบวกหรือลบค่าคูณ 1 หรือ 2 และวงจรแปลงกลับเป็นรูปผลหารมาตรฐานเพิ่มเติม

โครงสร้างที่บีบอัดตาราง 2048 รายการเป็น PLA 112 แถว

  • ตารางค้นหา SRT ของ Pentium รับเศษเหลือบางส่วน p และตัวหาร d เป็นอินพุต แล้วส่งค่าหลักของผลหารที่เหมาะสมออกมา
  • ตารางประกอบด้วย 2048 รายการ
    • ตัวหารถูกสเกลให้อยู่ระหว่าง 1 และ 2 แล้วเป็นพิกัดแกน X
    • เศษเหลือบางส่วนเป็นค่าระหว่าง -8 ถึง 8 แล้วเป็นพิกัดแกน Y
    • ตัวหารใช้ 4 บิตจาก 1.dddd โดยไม่รวมบิตนำหน้าที่เป็น 1 เสมอ
    • เศษเหลือบางส่วนถูกตัดเป็นค่า signed 7 บิต pppp.ppp
    • รวมเป็นดัชนี 11 บิต ชี้ไปยัง 2^11 = 2048 รายการ
  • ตารางมี 5 พื้นที่ที่สอดคล้องกับค่าหลักของผลหาร +2, +1, 0, -1, -2
    • พื้นที่บางส่วนด้านบนและด้านล่างไม่ถูกใช้ตามคณิตศาสตร์ของ SRT
    • ในตารางเดิมที่มีข้อบกพร่อง รายการที่ไม่ได้ใช้ถูกเติมด้วย 0
    • รายการสีแดง 5 รายการที่เป็นปัญหาควรเป็น +2 แต่ถูกปล่อยไว้เป็น 0
  • Pentium ไม่ได้สร้างตารางนี้เป็น ROM แต่สร้างเป็น PLA (Programmable Logic Array)
    • หากเก็บทั้งตารางเป็น ROM จะต้องใช้ 2048 แถว
    • เนื่องจากโครงสร้างตารางมีความสม่ำเสมอและมีพื้นที่ว่างจำนวนมาก จึงใช้ PLA เพียง 112 แถว
  • PLA ประกอบด้วย AND plane และ OR plane
    • AND plane สร้างเทอมตรรกะจากการผสมบิตอินพุตกับบิตส่วนกลับ
    • OR plane รวมเทอมเหล่านั้นเพื่อสร้างบิตเอาต์พุตที่บอกว่าผลหารเป็น 1 หรือ 2
  • เมื่อนำรูปแบบทรานซิสเตอร์ของ PLA ออกจากภาพกล้องจุลทรรศน์ จะสามารถกู้สมการตรรกะของแต่ละแถว PLA ได้
    • แถว PLA ไม่ได้แทนหนึ่งช่องในตาราง แต่ทำงานเหมือนพื้นที่สี่เหลี่ยมที่ครอบหลายช่องพร้อมกัน
    • ยิ่งขอบเขตของตารางบางจุดหยักมากเท่าไร ก็ยิ่งต้องใช้แถว PLA มากขึ้นเท่านั้น

ขอบเขตทางคณิตศาสตร์และพื้นที่ +2 ที่ผิดพลาด

  • ขั้นตอนสำคัญของการหาร SRT คือการเลือกค่าหลักของผลหาร q จากอัตราส่วน p/d ซึ่งคือเศษเหลือบางส่วน p หารด้วยตัวหาร d
  • ช่วงที่อนุญาตของ p/d ต้องอยู่ใน [-8/3, 8/3] ด้วยเหตุผลทางคณิตศาสตร์
    • หลังเลือกค่าหลักของผลหารแล้ว จะลบ q*d และคูณด้วย 4 เพื่อสร้างเศษเหลือบางส่วนของขั้นตอนถัดไป
    • เพื่อให้กระบวนการนี้ทำซ้ำได้ ช่วงใหม่ต้องมีขนาดเท่ากับช่วงเดิม
  • SRT มีความซ้ำซ้อน ทำให้บางช่วงสามารถเลือกค่าหลักของผลหารได้หนึ่งในสองค่า
    • แต่ถ้าเลือก 0 ในตำแหน่งที่ควรเป็น q=2 เศษเหลือบางส่วนถัดไปจะหลุดออกนอกช่วงที่อนุญาต และอัลกอริทึมจะกู้คืนไม่ได้
    • บั๊ก FDIV อยู่ในกรณีนี้
  • ตาราง P-D ของ Pentium คือการควอนไทซ์ขอบเขตทางคณิตศาสตร์นี้เป็นระดับเซลล์
    • ขอบเขตแนวทแยงเป็นตัวกำหนดว่าเซลล์ใดต้องเป็น +2, เซลล์ใดเป็น +1 หรือ +2 ก็ได้, และเซลล์ใดต้องเป็น +1 เป็นต้น
  • ผลการวิเคราะห์ไดพบว่า เส้นขอบสี magenta ด้านบนของตารางที่มีข้อบกพร่องควรต้องอยู่เหนือเส้นขอบคณิตศาสตร์สีดำ แต่กลับตัดผ่านเส้นนั้นซ้ำ ๆ
    • ส่งผลให้บางเซลล์ที่ต้องเป็น +2 ถูกปล่อยไว้เป็น 0
    • เซลล์เหล่านี้คือรายการที่หายไปซึ่งก่อให้เกิดบั๊ก FDIV

carry-save adder ทำให้ข้อผิดพลาดพบได้น้อยแต่ร้ายแรงได้อย่างไร

  • วงจรหารของ Pentium ใช้ carry-save adder เพื่อให้การบวกและลบเร็วขึ้น
    • carry-save adder ไม่ส่งต่อ carry ทันที แต่เก็บไว้ในคำแยกต่างหาก จึงเหมาะกับการหารที่ต้องบวกหลายครั้ง
    • ตอนท้ายยังต้องใช้การบวกที่ช้ากว่าเพื่อรวม carry ที่เก็บไว้
  • ดัชนีตารางค้นหาต้องใช้เศษเหลือบางส่วน แต่ carry-save adder เก็บเศษเหลือบางส่วนแยกเป็นบิต sum และบิต carry
  • Pentium ใช้ carry-lookahead adder เพื่อคำนวณเฉพาะ 7 บิตที่จำเป็นสำหรับดัชนีตารางอย่างรวดเร็ว
    • วงจรนี้คำนวณ carry ของแต่ละหลักแบบขนาน
    • ไม่เหมาะกับคำขนาดใหญ่เพราะซับซ้อนมาก แต่ใช้งานได้จริงสำหรับค่า 7 บิต
  • ปัญหาคือเศษเหลือบางส่วนมี 64 บิต แต่การคำนวณดัชนีตารางใช้เพียง 7 บิต
    • เมื่อบิตที่เหลือถูกตัดทิ้งก่อนการรวมค่า เศษเหลือบางส่วนสำหรับดัชนีอาจต่ำกว่าค่าจริงเล็กน้อย
    • กล่าวอย่างเฉพาะเจาะจงคืออาจเกิดออฟเซ็ตลงมาหนึ่งช่องจากเซลล์ที่ถูกต้อง หรือ 1/8
  • ด้วยผลนี้ ขอบเขตบางเส้นต้องเลื่อนลง 1/8 แต่ไม่ใช่ว่าทุกขอบเขตต้องเลื่อน
    • ขอบ +2 ด้านบนไม่ควรถูกเลื่อนลง แต่ Intel สร้างตารางที่เลื่อนผิดไป
    • ผลจาก carry-save นี้เป็นผลที่รู้จักกันอยู่แล้ว และถูกกล่าวถึงในบทความวิชาการเรื่องการหาร SRT ในยุคนั้น

จุดที่คำอธิบายของ Intel แยกจากการวิเคราะห์ได

  • เอกสารไวต์เปเปอร์ของ Intel อธิบายว่ามีปัญหากับสคริปต์ที่นำตารางใส่ลงใน PLA ทำให้บางรายการหายไปจาก PLA
    • Intel เรียกสิ่งนี้ว่า Programmable Lookup Array แต่โครงสร้างจริงคือ Programmable Logic Array
  • การวิเคราะห์ไดมองว่ารายการที่หายไปสอดคล้องกับ ข้อผิดพลาดของขอบเขตทางคณิตศาสตร์ มากกว่าความผิดพลาดจากการคัดลอกธรรมดา
    • เป็นไปได้ว่าโปรแกรมสร้างตารางกำหนดเงื่อนไขขอบเขตผิด
    • คำว่า “สคริปต์” อาจถูกต้องในเชิงเทคนิค หากหมายถึงการใช้โปรแกรมภาษา C สร้างตาราง แต่การตีความคือแก่นของปัญหาอยู่ที่ขอบเขตทางคณิตศาสตร์ที่ผิด
  • The Pentium Chronicles ของ Robert Colwell ให้คำอธิบายอีกแบบหนึ่ง
    • โดยอธิบายว่าการออกแบบ Pentium เดิมใช้ตารางค้นหาแบบเดียวกับ 486 และเกิดข้อผิดพลาดระหว่างปรับให้เหมาะสมเพื่อลดพื้นที่ไดก่อนออกจำหน่ายไม่นาน
  • คำอธิบายนี้มีจุดที่ไม่สอดคล้องกัน
    • Pentium ใช้อัลกอริทึมการหารที่ต่างจาก 486 ตั้งแต่แรก
    • Pentium ใช้ radix-4 SRT ส่วน 486 ใช้การหารไบนารีมาตรฐาน
    • 486 ไม่มีตารางค้นหานี้
    • PLA ที่มีข้อบกพร่องยังเหลือแถวที่ไม่ได้ใช้ 8 แถว ดังนั้นถ้าต้องการลดวงจรอย่างง่าย ๆ ก็น่าจะลบแถวเหล่านี้ก่อน

เหตุผลที่ PLA รุ่นแก้ไขมีขนาดเล็กลง

  • รายงานข่าวในเวลานั้นระบุว่า Intel เพิ่มทรานซิสเตอร์หลายสิบตัวหรือ gate sequence เพิ่มเติมใน PLA เพื่อแก้ข้อบกพร่อง
  • PLA รุ่นแก้ไขที่ตรวจบนไดแสดงภาพตรงกันข้าม
    • ขนาด PLA เท่าเดิม
    • เทอมประมาณ 1/3 ถูกลบออก
    • ใช้เพียง 74 แถวจาก 120 แถว และอีก 46 แถวว่าง
    • PLA เดิมที่มีข้อบกพร่องมีแถวว่าง 8 แถว
  • การแก้ไขของ Intel ไม่ใช่การเติมเฉพาะ 5 รายการที่หายไปให้เป็น 2
    • แต่เติมรายการตารางทั้งหมดที่ไม่ได้ใช้เป็น 2
    • ทำให้ไม่มีโอกาสเข้าถึงรายการว่างโดยไม่ตั้งใจ
  • เมื่อเติมพื้นที่ที่ไม่ได้ใช้เป็น 2 ขอบเขตของตารางก็เรียบง่ายขึ้น
    • ขอบเขตที่หยักต้องใช้เทอม PLA จำนวนมาก
    • พื้นที่สี่เหลี่ยมขนาดใหญ่สามารถครอบด้วยเทอม PLA เดียวได้
    • ดังนั้นแม้จะเติมเซลล์ในตารางมากขึ้น สมการ PLA กลับเรียบง่ายขึ้น
  • เนื่องจากเทอมตรรกะของ PLA รุ่นแก้ไขต่างจาก PLA เดิมโดยสิ้นเชิง จึงยากจะชี้ว่าทรานซิสเตอร์บางตัวเป็นตัวแก้บั๊ก

ผลกระทบจริงและข้อถกเถียง

  • โอกาสเกิดข้อบกพร่องในการหารแบบสุ่มอยู่ที่ประมาณ 1 ใน 9 พันล้าน ซึ่งต่ำมาก
    • ผลหารที่ผิดมักต่างกันในหลักทศนิยมที่ 9 หรือ 10
    • ในกรณีแย่ที่สุดที่พบได้น้อย อาจเกิดข้อผิดพลาดที่เลขนัยสำคัญหลักที่ 4
  • ไวต์เปเปอร์ของ Intel ประเมินว่าผู้ใช้ทั่วไปมีโอกาสเจอปัญหาเพียงหนึ่งครั้งใน 27,000 ปี
    • โดยระบุว่าสำหรับผู้ใช้ส่วนใหญ่ไม่ใช่ปัญหา และผู้ใช้บางส่วนในงานวิทยาศาสตร์/วิศวกรรมและวิศวกรรมการเงินอาจต้องใช้โปรเซสเซอร์ที่แก้ไขแล้วหรือวิธีเลี่ยงในซอฟต์แวร์
  • IBM วิเคราะห์เองว่าลูกค้าอาจพบปัญหาได้ทุกไม่กี่วัน จึงหยุดขาย Pentium
    • ในเวลานั้น IBM ก็มีโปรเซสเซอร์คู่แข่งอย่าง PowerPC ด้วย
  • บางการประเมินมองว่าในงานใช้งานจริง คนที่ค้นพบบั๊กน่าจะมีเพียงศาสตราจารย์ Nicely คนเดียว
    • การวิเคราะห์ของ IBM ถูกมองว่ามีลักษณะเหมือนเลือกตัวเลขที่ทำให้เกิดข้อผิดพลาดได้ง่าย
    • ผู้ใช้ส่วนใหญ่จะไม่เจอบั๊ก และแม้เจอก็มีแนวโน้มว่าความแม่นยำเลขทศนิยมลอยตัวที่ลดลงเล็กน้อยจะไม่เป็นปัญหา
  • แต่บั๊ก FDIV สามารถทำซ้ำได้อย่าง กำหนดแน่นอน
    • หาก dividend และ divisor บางคู่ก่อปัญหา จะได้ผลลัพธ์ผิด 100%
    • เพราะลูกค้าสามารถทำซ้ำบนคอมพิวเตอร์ของตนได้ง่าย Intel จึงยากที่จะอ้างว่าเป็น “ปัญหาที่ไม่มีทางเจอ”

บั๊กโปรเซสเซอร์หลังจากนั้นและไมโครโค้ดที่แพตช์ได้

  • บั๊ก FDIV เป็นหนึ่งในบั๊กโปรเซสเซอร์ที่มีชื่อเสียงที่สุด แต่ Intel ก็มีบั๊กสำคัญอื่น ๆ เช่นกัน
  • โปรเซสเซอร์ 386 รุ่นแรกบางตัวมีปัญหาการคูณ 32 บิต
    • ให้ผลลัพธ์ผิดแบบคาดเดาไม่ได้ภายใต้เงื่อนไขอุณหภูมิ แรงดัน และความถี่บางอย่าง
    • สาเหตุคือปัญหาเลย์เอาต์ที่มี margin ทางไฟฟ้าไม่เพียงพอ
    • Intel จำกัดการขายชิปที่มีข้อบกพร่องให้ใช้ในตลาด 16 บิต และทำเครื่องหมายว่า “16 BIT S/W ONLY”
  • ปัญหาอีกอย่างของ Pentium คือ F00F bug ที่พบในปี 1997
    • ลำดับคำสั่งบางแบบที่เริ่มด้วย F0 0F ทำให้โปรเซสเซอร์หยุดจนกว่าจะรีบูต
    • แก้ได้ด้วยการอัปเดตระบบปฏิบัติการ
  • Pentium มีไมโครโค้ดฝังตายตัวใน ROM จึงไม่สามารถแก้บั๊ก FDIV ด้วยการอัปเดตไมโครโค้ดได้
  • Intel เพิ่มไมโครโค้ดที่แพตช์ได้ใน Pentium Pro ปี 1995
    • เดิมมีไว้เพื่อการดีบักและทดสอบชิป
    • หลังบั๊ก FDIV จึงเห็นชัดว่ามีคุณค่าต่อการแก้บั๊กด้วย
    • Pentium Pro มี SRAM สำหรับเก็บไมโครอินสตรักชันได้สูงสุด 60 รายการ พร้อมกับไมโครโค้ดใน ROM และ BIOS สามารถโหลดแพตช์ระหว่างบูตได้
  • แพตช์ไมโครโค้ดของโปรเซสเซอร์ Intel สมัยใหม่ถูกใช้กับปัญหาหลากหลาย ตั้งแต่ช่องโหว่ Spectre ไปจนถึง ปัญหาแรงดันไฟฟ้า

ความผิดพลาดที่เกิดจากวงจรที่ซับซ้อนขึ้น

  • ตามกฎของมัวร์ จำนวนทรานซิสเตอร์ในโปรเซสเซอร์เพิ่มขึ้น ทำให้วงจรและอัลกอริทึมซับซ้อนขึ้นด้วย
  • การเปลี่ยนแปลงของการรองรับการหารแสดงเรื่องนี้ได้ชัดเจน
    • Intel 8080 ในปี 1974 ใช้ทรานซิสเตอร์ 6000 ตัว และไม่รองรับการหารด้วยฮาร์ดแวร์หรือคณิตศาสตร์เลขทศนิยมลอยตัว
    • Intel 8086 ในปี 1978 ใช้ทรานซิสเตอร์ 29,000 ตัว และทำการหารจำนวนเต็มด้วยไมโครโค้ด แต่เลขทศนิยมลอยตัวต้องใช้โคโปรเซสเซอร์ 8087
    • Intel 486 ในปี 1989 ใช้ทรานซิสเตอร์ 1.2 ล้านตัว และรวมการรองรับเลขทศนิยมลอยตัวไว้ในชิป
    • Pentium ในปี 1993 ใช้ทรานซิสเตอร์ 3.1 ล้านตัว และใช้อัลกอริทึมการหาร SRT ที่เร็วกว่าแต่ซับซ้อนกว่า
  • แค่ PLA สำหรับการหารของ Pentium ก็มี ไซต์ทรานซิสเตอร์ประมาณ 4900 จุด
    • มากกว่าโปรเซสเซอร์ MOS Technology 6502 ทั้งตัว
    • กล่าวได้ว่าองค์ประกอบหนึ่งของวงจรหารใน Pentium ใช้ทรานซิสเตอร์มากกว่าโปรเซสเซอร์ทั้งตัวในปี 1975
  • ผลกระทบระยะยาวของบั๊ก FDIV ยังเป็นที่ถกเถียง
    • คู่แข่งอย่าง AMD ได้ประโยชน์จากโฆษณาที่ล้อเลียนปัญหาของ Pentium
    • Robert Colwell มองว่าบั๊ก FDIV อาจมีผลสุทธิเป็นบวก เพราะทำให้ชื่อ Pentium เป็นที่รู้จักอย่างมาก และแสดงให้เห็นว่า Intel พร้อมหนุนหลังแบรนด์ของตน
  • Intel ผ่านพ้นบั๊ก FDIV มาได้ แต่ข้อบกพร่องในเวลานั้นแสดงให้เห็นว่าเมื่อคณิตศาสตร์ที่ซับซ้อน การบีบอัดวงจร และข้อจำกัดของการตรวจสอบมารวมกัน ข้อผิดพลาดที่พบได้น้อยมากก็อาจขยายเป็นปัญหาความเชื่อมั่นครั้งใหญ่ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-12-30
ความคิดเห็นจาก Hacker News

  • ผมเป็นผู้เขียนเอง ถ้ามีคำถามเกี่ยวกับ Pentium ก็ตอบได้ครับ :-)
    เธรด Mastodon เกี่ยวกับบั๊กนี้เคยขึ้น HN เมื่อไม่กี่สัปดาห์ก่อน คุณอาจคุ้นอยู่แล้ว แต่ตอนนี้ผมเขียนบทความบล็อกฉบับละเอียดเสร็จแล้ว โพสต์ HN ก่อนหน้านี้ก็มีคอมเมนต์ค่อนข้างเยอะ: https://news.ycombinator.com/item?id=42391079

    • 475 ล้านดอลลาร์นี้อาจเป็นค่าใช้จ่ายด้านการตลาดที่ดีที่สุดของ Intel ก็ได้ เพราะบั๊กและการเรียกคืนทำให้แม้แต่คนนอกวงการเทคโนโลยีก็รู้จัก Intel และในช่วงที่ผู้คนคาดว่าจะมี 586 หรือ 686 ต่อจาก 486 อยู่ๆ ก็มีชื่อ Pentium โผล่มา ผมมองว่าเหตุการณ์นี้ช่วยสร้างการรับรู้และความรู้สึกเชิงบวกต่อแบรนด์ จนต่อเนื่องไปถึง Pentium MMX ในภายหลัง
    • เช่นเคย บทความและการวิเคราะห์ยอดเยี่ยมมาก พอมาคิดตอนนี้ก็ค่อนข้างแปลกที่ปัญหาที่มองได้ว่าเป็นข้อผิดพลาดเล็กๆ ของ CPU กลายเป็นพาดหัวข่าวทั่วโลก
      ภายใน Intel เองก็เคยมีข้อผิดพลาดร้ายแรงกว่านี้ และบริษัทอื่นก็มีเหมือนกัน แต่เรื่องเหล่านั้นถูกลืมไปหมดแล้ว ผมสงสัยเรื่องสแต็กค่าของหน่วยทศนิยมลอยตัวของ Pentium—ไม่แน่ใจชื่อเรียกที่ถูกต้อง—กับการปรับแก้ส่วนนั้นมาก นานมาแล้วก็จริง แต่ใช่ไหมว่าเหมือนทำ register renaming รูปแบบแรกๆ จนต้องคอยจัดการ fxchg ด้วยมืออย่างระมัดระวัง?
    • ผมสงสัยส่วนที่ว่า “บั๊กน่าจะอยู่ในไมโครโค้ดขนาดมหึมาของ Pentium ไมโครโค้ดซับซ้อนเกินกว่าจะวิเคราะห์ได้ยาก และอย่าคาดหวังบทความบล็อกละเอียดๆ ในหัวข้อนี้”
      การ “ดัมป์” ไมโครโค้ด ออกมาเป็นบิตสตรีมนั้นยากแค่ไหน? ทำด้วยโปรแกรมจากภาพไดความละเอียดสูงได้ไหม? แน่นอนว่าเมื่อเทียบกับการทำ reverse engineering ว่าบิตสตรีมนั้นหมายถึงอะไร นั่นอาจถือว่าง่ายกว่า
      ผมก็สงสัยส่วนที่ว่า “ตรวจสอบ PLA อย่างละเอียดด้วยกล้องจุลทรรศน์” ด้วย งานแบบนี้ทำที่บ้านหรือเปล่า ในแล็บมีอุปกรณ์อะไรบ้าง และเรียนรู้เทคนิคพวกนี้มาได้อย่างไร
    • ผมกำลังจะถามว่าเลือกใช้ เลขอาโวกาโดร ในคำอธิบายเลขทศนิยมลอยตัวโดยตั้งใจหรือเปล่า แล้วก็เพิ่งนึกได้ว่าอีกตัวเลขหนึ่งคือค่าคงที่ของพลังค์
    • เพิ่งรู้ว่าการหารทศนิยมลอยตัวสามารถทำแบบนี้ได้ด้วย ตลกดีที่ผมไม่เคยรู้ว่าถ้าจะ implement การหารทศนิยมลอยตัวจริงๆ ต้องใช้ การหารจำนวนเต็ม หลายขั้นตอน
      พอมองย้อนกลับไป ก็สงสัยว่าทำไมถึงไม่เติมส่วนที่ไม่ได้ใช้ของตาราง lookup ด้วย 2 และ -2 ตั้งแต่แรก

  • ตัวบั๊กเองก็น่าสนใจ แต่ การตอบสนองของ Intel ก็น่าสนใจในตัวมันเอง ดูเหมือนว่าไม่ได้เปลี่ยนเป็นโปรเซสเซอร์ที่ไม่มีข้อบกพร่องให้ทุกคนที่ต้องการ และผลก็คือโดนวิจารณ์หนักมาก
    ถ้าเทียบกันแล้ว ผมนึกถึงการเปิดตัว Amazon Colorsoft มากๆ อุปกรณ์บางเครื่อง รวมถึงของผม มีปัญหากราฟิกเป็นแถบสีเหลือง Amazon ใช้เวลาตรวจสอบข้อเท็จจริงราวหนึ่งหรือสองวันแล้วก็ยอมรับ จากนั้นก็เงียบๆ เปลี่ยนให้ทั้งหมด ไม่ใช่การเรียกคืน แค่ขอก็ส่งเครื่องใหม่ให้ ของที่เปลี่ยนให้ผมจะมาถึงวันศุกร์นี้ หวังว่าจะแก้ได้ ดูชัดเจนว่าการมี ระบบคืนสินค้า/ซัพพอร์ต ที่แข็งแกร่งมากเมื่อการเปิดตัวสะดุดนั้นเป็นข้อได้เปรียบที่ใหญ่กว่าที่การวิเคราะห์มักคาดไว้มาก
    คล้ายกันคือปัญหาเสียงรบกวนของ Apple AirPods Pro เมื่อไม่กี่ปีก่อน ช่วงหลังไม่ได้เป็นข่าวใหญ่เท่าไร AirPods ของผมต้องเปลี่ยนสองครั้ง แต่ Apple ก็เปลี่ยนให้เงียบๆ และผมรู้สึกว่าขีดความสามารถด้านซัพพอร์ตที่ไม่ค่อยปรากฏให้เห็นภายนอกนั้นทำงานได้ค่อนข้างทรงพลัง
    Colorsoft: https://www.tomsguide.com/tablets/e-readers/amazon-kindle-co...
    AirPods Pro: https://support.apple.com/airpods-pro-service-program-sound-...

    • กรณี Kindle กับ AirPod เป็นผลิตภัณฑ์ที่ค่อนข้างเล็กสำหรับแต่ละบริษัท จึงไม่ค่อยเทียบกับ Pentium ได้ตรงนัก
      ฝั่ง Apple ถ้าจะเทียบให้ดีกว่าคือ iPhone 4 Antennagate ทางแก้ที่เทียบเท่ากันคงเป็นการเปลี่ยนฟรีให้ผลิตภัณฑ์เรือธงที่เป็นหัวใจของยอดขาย แต่ Apple ไม่ได้ทำแบบนั้น
      ในทางกลับกัน สุดท้าย Intel ก็เสนอการเปลี่ยนฟรีให้ทุกคนที่ร้องขอ และยอมรับผลกระทบทางการเงินครั้งใหญ่
    • ผมเคยใช้ MacBook สีขาวรุ่นแรก เคสฝาบนแตกและเปลี่ยนสีเพราะโครงสร้างปิดแบบแม่เหล็ก ตลอดอายุการใช้งานของคอมพิวเตอร์เครื่องนั้น ผมได้เปลี่ยนฟรีสามสี่ครั้ง และยังทำให้แม้หลัง AppleCare 3 ปี หมดแล้ว
      ท่าทีของ Apple ที่รับผิดชอบผลิตภัณฑ์แบบนั้นน่านับถือจริงๆ
    • ผมมองว่าการตอบสนองของ Intel คือการลงทุนกับความถูกต้องแม่นยำอย่างมากอยู่ช่วงหนึ่ง ต่อมาพวกเขาเห็นว่า AMD ไม่ถูกลงโทษแม้มีอัตราข้อบกพร่องสูงกว่า และช่วงหลังดูเหมือน Intel จะไปลงทุนในเรื่องอื่นๆ เพื่อแข่งกับ AMD ในตัวชี้วัดอื่น แทนที่จะเป็นว่า CPU มีบั๊กน้อยแค่ไหน
    • โดยมากแล้วมันไม่ใช่ปัญหาของผู้บริโภครายบุคคล บริษัทต่างๆ ซื้อคอมพิวเตอร์ Pentium ที่ราคาค่อนข้างแพงผ่านผู้จัดจำหน่าย และผู้ขายก็เปลี่ยนให้ตามสัญญาซัพพอร์ต
      ผมเข้าใจว่าหมายถึงอะไร เพราะเคยเจอสถานการณ์ “การรับประกันเงา” ของ Apple สำหรับผู้บริโภค แต่ผมมองว่ามันต่างจาก วิกฤต IT ที่ Intel เผชิญมาก ในเวลานั้น คำว่า “IBM พูดไว้อย่างนั้น” มีน้ำหนักมหาศาลในวงการ IT
    • นั่นเป็นวิธีพื้นฐานของ Amazon อยู่แล้ว แทบจะคืนสินค้าได้โดยไม่ยุ่งยาก ไม่ว่าจะด้วยเหตุผลอะไร

  • เอกสารไวต์เปเปอร์ของ Intel ระบุว่าผู้ใช้ทั่วไปจะเจอปัญหานี้หนึ่งครั้งในทุก 27,000 ปี และถือว่าไม่สำคัญเมื่อเทียบกับสาเหตุความผิดพลาดอื่น ๆ เช่น DRAM bit flip ในทางกลับกัน IBM ประเมินจากการวิเคราะห์ของตนเองว่าลูกค้าอาจเจอมันได้ทุกไม่กี่วัน
    ตัวเลขสองชุดนี้อาจไม่ได้ห่างกันอย่างที่ดูเหมือน Intel น่าจะมองจากฐานผู้ใช้รายเดียว ส่วน IBM อาจคิดจากมุมมองของ คำขอซัพพอร์ต
    ที่ทำงานผมก็เคยเจอปัญหาคล้ายกัน ถ้าประมวลผลคำขอวันละ 100 ล้านครั้ง ปัญหาระดับหนึ่งในพันล้านก็จะเกิดขึ้นเดือนละหลายครั้ง ถ้าเป็นชนิดที่ลูกค้าหรือแย่กว่านั้นคือผู้จัดการสังเกตเห็นได้ ผู้คนจะมองข้ามตัวส่วนและเริ่มสงสัยว่าทุกคนไร้ความสามารถ เดือนละสี่ครั้งสามารถถูกแปลว่า “ตลอดเวลา” ได้ภายใต้อคติจากประสบการณ์ของมนุษย์ ถ้ามีกลุ่มเหตุการณ์ทางสถิติแบบสัปดาห์ละสามครั้งเกิดขึ้นสองรอบ ก็จะต้องมีใครสักคนเดือดแน่

    • ไม่ใช่ การประเมินของ IBM ก็อิงจาก ผู้ใช้รายเดียว เช่นกัน IBM คำนวณว่าผู้ใช้สเปรดชีตทั่วไปทำการหาร 5,000 ครั้งต่อวินาทีระหว่างการคำนวณใหม่ และคำนวณใหม่วันละ 15 นาที
      อีกทั้งยังมองว่าตัวเลขที่ผู้คนใช้มีโอกาสก่อให้เกิดข้อผิดพลาดสูงกว่าตัวเลขแบบกระจายสม่ำเสมอของ Intel ถึง 90 เท่า ดังนั้นจึงได้ผลว่าผู้ใช้หนึ่งคนจะเจอข้อผิดพลาดทุก 24 วัน

  • มีช่วงหนึ่งที่บอกว่า “ดูเหมือนคนที่สังเกตเห็นบั๊กนี้ในการใช้งานจริงมีเพียงคนเดียว คือศาสตราจารย์ Nicely”
    ทำให้นึกถึงงานวิจัยเก่า ๆ ที่แจกเครื่องคิดเลขสำหรับเรียนคณิตศาสตร์ให้นักเรียน เครื่องคิดเลขถูกดัดแปลงให้ให้ผลลัพธ์ผิด และนักวิจัยอยากรู้ว่าเครื่องคิดเลขต้องผิดมากแค่ไหน นักเรียนถึงจะสังเกตเห็นความผิดปกติ
    คำตอบคือ 2 เท่า
    การสังเกตเห็นข้อผิดพลาดกับการได้รับผลกระทบจากข้อผิดพลาดเป็นคนละเรื่องกันโดยสิ้นเชิง จะมีสักกี่คนที่ตรวจว่าผลลัพธ์จากคอมพิวเตอร์ถูกต้องไหม? ผมคิดว่าน้อยมาก ๆ ๆ แม้แต่ผมตอนทำการคำนวณทางวิศวกรรมที่ Boeing ก็ไม่ได้ทำ ยกเว้นครั้งหนึ่งที่รันสมการย้อนกลับเพื่อตรวจว่าผลลัพธ์สอดคล้องกับอินพุตหรือไม่

    • ตอนอยู่มหาวิทยาลัยผมเคยติวฟิสิกส์ เมื่อนักศึกษาเอาโจทย์ที่ทำมาให้ดูและขอ feedback ผมมักบอกพวกเขาว่า ถ้าคำนวณความสูงของรถไฟเหาะได้ 23,000 ไมล์ ก็ต้องมีอะไรผิดแน่นอน
      สุดท้ายแล้วขึ้นอยู่กับบริบท และคนที่คำนวณเข้าใจเนื้อหามากแค่ไหนเป็นอย่างมาก
    • ประโยคที่ว่า “การสังเกตเห็นข้อผิดพลาดกับการได้รับผลกระทบจากข้อผิดพลาดเป็นคนละเรื่องกันโดยสิ้นเชิง” ถูกต้องแค่ในระดับหนึ่ง ถ้ายกตัวอย่างการใช้งานของผู้บริโภค เช่น ระหว่างเล่นเกมเกิดเอาต์พุตผิด แต่สุดท้ายไม่มีใครสังเกตอะไรได้เลย แบบนั้นถือว่าได้รับผลกระทบจริงหรือ?
      ใน Pentium ตอนใช้ FDIV มีสัดส่วนมากแค่ไหนที่ไม่ได้ใช้กับมัลติมีเดีย แต่ใช้เพื่อ เอาต์พุตที่สำคัญเชิงตัวเลข?

  • ผมจำบั๊กนั้นได้ เพราะควบคุมไม่ได้ว่าลูกค้าจะรันบน CPU ตัวไหน จึงต้องใส่โค้ด ตรวจจับ FPU ที่มีข้อบกพร่อง ไว้ในไลบรารี แล้วรันโค้ดหลบเลี่ยงแทน โค้ดนี้ Intel เป็นคนให้มา
    พูดอีกอย่างคือปัญหาของ Intel กลายเป็นปัญหาของผม เฮ้อ

  • นึกถึงมุกที่แพร่กันตอนนั้น มันจับบรรยากาศหลายอย่างของยุค 90 ได้ดี:
    I AM PENTIUM OF BORG.
    DIVISION IS FUTILE.
    YOU WILL BE APPROXIMATED.

    • อันนั้นน่าจะเคยอยู่ใน ตัวสร้างลายเซ็น ของผม

  • เป็นบทความยอดเยี่ยมอีกชิ้นของ Ken ที่จำได้เป็นพิเศษเพราะ PC เครื่องแรกที่ผมซื้อด้วยเงินตัวเองมี CPU รุ่นที่ได้รับผลกระทบ ก่อนหน้านั้นผมไม่ค่อยสนใจ PC เพราะมันรันซอฟต์แวร์ “จริงจัง” ไม่ได้
    แต่ Windows NT เปลี่ยนเรื่องนั้นได้ และต้องขอบคุณ Cutler เมนบอร์ดราคาถูกจากไต้หวันยังทำให้การประกอบเครื่องเองเป็นเรื่องทำได้จริง และจนถึงตอนนี้หลายคนก็ยังทำแบบนั้น Ken ชี้ว่าผู้ใช้ตรวจได้ง่ายว่า CPU ของตัวเองได้รับผลกระทบหรือไม่ ผมจำได้ว่ามันง่ายประมาณพิมพ์สูตรหารที่มีเลขวิเศษลงใน Excel ถ้า Microsoft ออก Excel เวอร์ชันที่หลบเลี่ยงบั๊กนี้ จำนวนผู้ใช้ที่ขอเปลี่ยนคงน้อยลง

    • PC เหล่านี้รัน 386BSD ไม่ได้หรือ?

  • เป็นการวิเคราะห์ที่น่าสนใจและดื้อดึงจริง ๆ ความพยายามในการวิเคราะห์ซิลิคอนและแบ่งปันผลลัพธ์นั้นยอดเยี่ยมมาก โดยเฉพาะที่ PR ของ Intel ทำให้สาเหตุจริงฟังดูเหมือนเป็นการตกหล่นเล็กน้อย แต่บทความนี้ชี้ให้เห็น สาเหตุราก ที่แท้จริง
    อันที่จริงมันเป็นปัญหาที่ให้อภัยได้น้อยกว่ามากและควรถูกตำหนิมากกว่า เพราะเป็นการทำอัลกอริทึมสร้างตารางพัง

  • ประโยคที่ว่า “Smith โพสต์อีเมลนั้นลงในฟอรัม Compuserve ซึ่งเป็นโซเชียลมีเดียเวอร์ชันปี 1990” ทำให้ผมรู้สึกแปลก ๆ

    • ผมชอบเรียกมันว่า ยุค 1900 แทนยุค 1990
    • ความรู้สึกแรกที่แวบขึ้นมาคือข้อมูลพวกนั้นน่าจะหายไปโดยแทบไม่เคยถูกขุดเลย พวกโชคดีเอ๊ย!
    • เขาส่งมันด้วย คอมพิวเตอร์ส่วนบุคคล ซึ่งเป็นบรรพบุรุษของสมาร์ตโฟน

  • ตารางที่แก้แล้วเรียบง่ายกว่ามาก เพราะแทนที่จะเพิ่มวงจรให้คืนค่า 0 สำหรับค่าที่อยู่นอกช่วง ก็ให้คืนค่า 2 ไปเลย ถ้าอย่างนั้นก็สงสัยว่าทำไมไม่ทำแบบนั้นตั้งแต่แรก

    • รู้สึกเหมือนเป็น optimization ที่หลุดรอดไปเพราะหลายคนแบ่งงานกันทำ จนไม่มีใครรู้ภาพรวมของปัญหาอย่างสมบูรณ์
      คนที่สร้างตารางอาจไม่รู้ว่าถ้าเติมค่านอกช่วงด้วย 2 จะได้ PLA ที่เรียบง่ายกว่า ส่วนคนที่ยัดตารางเข้าไปใน PLA อาจไม่รู้ว่า 0 เป็น ค่าไม่เกี่ยวข้อง (don't care) และสันนิษฐานว่าต้องรักษาไว้
      หรืออาจหยุด optimization ทันทีที่รู้สึกว่า PLA เล็กพอตามต้องการแล้วก็ได้ ถ้าวางแผนเลย์เอาต์เสร็จไปแล้ว ต่อให้ทำ PLA ให้เล็กลงอีก ชิปทั้งตัวก็คงไม่ได้เล็กลง และเอาเวลาวิศวกรรมไปใช้กับส่วนอื่นคงดีกว่า
    • ทำให้นึกถึงคำพูดว่า “ทำให้มันทำงานได้ก่อน แล้วค่อยทำให้เร็ว” โดยพื้นฐานแล้วนี่คือ ปัญหาซอฟต์แวร์ ที่แก้ด้วยวิธีแบบซอฟต์แวร์
      เหมือนซอฟต์แวร์ส่วนใหญ่ มันมี optimization ที่เหลือค้างอยู่เพราะไม่มีใครนึกออกทันเวลา และ CPU ในยุคนั้นก็แพตช์ไม่ได้
    • การคืนค่า 0 สำหรับรายการตารางที่ไม่ได้กำหนดเป็นตัวเลือกที่ชัดเจนที่สุด การตั้งรายการเหล่านี้เป็น 2 ต้องอาศัยการก้าวกระโดดทางแนวคิดเล็กน้อย แม้ว่าถ้าทำแบบนั้นจะป้องกันข้อผิดพลาด FDIV และทำให้ PLA เรียบง่ายขึ้นได้ แต่คงโทษ Intel ด้วยเรื่องนี้ได้ยาก
    • ถึงอย่างนั้นมันคงเป็นการแก้ที่ทำให้วิศวกรรู้สึกสะใจมากจริง ๆ
    • การลงเวลา engineering เพิ่ม ทำให้ได้วิธีแก้ที่มีประสิทธิภาพกว่า