เหตุผลที่ fastDOOM ทำงานได้เร็ว

 (fabiensanglard.net)
1 คะแนน โดย GN⁺ 2025-03-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บน IBM PS/1 486-DX2 66MHz ซึ่งเป็นพีซีสมรรถนะสูงในปี 1993 DOOM ต้นฉบับทำได้ 21.5fps ใน demo1 ขณะที่ fastDOOM ภายใต้เงื่อนไขเดียวกันทำได้ถึง 30.1fps แสดงให้เห็นความต่างของการปรับแต่งพอร์ต DOS
  • fastDOOM เริ่มต้นจาก PCDOOM v2 ซึ่งผสานคอร์ของ Linux DOOM, I/O ของ Heretic, APODMX และ Mode Y graphics I/O ที่อิงจากการ disassemble DOOM.EXE
  • จากการ build และ benchmark 52 releases กับ 3,042 commits พบว่าการเพิ่มประสิทธิภาพไม่ได้มาจาก compiler สมัยใหม่เพียงอย่างเดียว แต่เกิดจาก การสะสมของ optimization เล็ก ๆ
  • การปรับปรุงที่ส่งผลมาก ได้แก่ การข้ามการ render status bar, inline FixedDiv, การปรับแต่ง BSP traversal, การข้าม visplane rendering, การตัด pointer indirection และ การแยก executable ตาม renderer
  • โหมดกราฟิกมีข้อดีข้อเสียต่างกันตาม CPU และ bus: CPU ช้าจะได้เปรียบกับ Mode Y ส่วน CPU เร็วและสภาพแวดล้อม VLB/PCI อาจเหมาะกับ Mode 13h หรือ VESA direct มากกว่า แต่ยังมีข้อจำกัดอย่าง VESA 2.0 อยู่

ความต่างด้านประสิทธิภาพที่เห็นบน 486-DX2

  • เมื่อรัน DOOM ต้นฉบับด้วย doom.exe -timedemo demo1 บน IBM PS/1 486-DX2 66MHz รุ่น “Mini-Tower” 2168 จะได้ผลลัพธ์ 1710 gametics in 2783 realtics
    • DOOM ไม่แสดง fps โดยตรง จึงต้องคำนวณด้วย 1710/2783*35 ซึ่งได้ผลลัพธ์เป็น 21.5fps
  • บนเครื่องเดียวกัน เมื่อรัน fdoom.exe -timedemo demo1 จะได้ 1710 gametics in 1988 realtics หรือ 30.1fps
  • ในแผนที่ที่หนักกว่า เช่น demo1 ของ doom2 เพิ่มจาก DOOM ต้นฉบับ 16.8fps เป็น fastDOOM 24.9fps หรือเร็วขึ้น 48%
  • อย่างไรก็ตาม การรองรับ joystick และ network gameplay ถูกถอดออก จึงไม่ใช่พอร์ตที่คงฟีเจอร์ทั้งหมดไว้ครบถ้วน

สายวิวัฒนาการของโค้ดที่นำไปสู่ fastDOOM

  • DOOM เดิมพัฒนาบน NeXT Workstation และมีโครงสร้างที่ port ได้ง่าย โดยแบ่งเป็นโค้ดคอร์ส่วนใหญ่กับ subsystem I/O ขนาดเล็ก
  • เวอร์ชัน DOS เชิงพาณิชย์ใช้ DOS I/O ที่ id Software เขียนเอง แต่ไม่สามารถ open source ได้ตรง ๆ ในปี 1997 เพราะพึ่งพา DMX ซึ่งเป็น proprietary sound library
  • โค้ดที่เผยแพร่เป็นเวอร์ชัน Linux ที่ Bernd Kreimeier จัดระเบียบระหว่างทำโปรเจกต์หนังสือเพื่ออธิบาย engine
  • เวอร์ชัน DOS อย่าง PCDOOM v2 ถูกประกอบขึ้นใหม่จากส่วนผสมต่อไปนี้
    • คอร์ ของ Linux DOOM
    • I/O ของ Heretic
    • APODMX เพื่อเลียนแบบ DMX
    • graphics I/O ใน i_ibm.c ที่ reverse engineering จากการ disassemble DOOM.EXE
  • fastDOOM ใช้ PCDOOM v2 นี้เป็นจุดเริ่มต้น

การติดตามการเปลี่ยนแปลงประสิทธิภาพผ่าน releases และ commits

  • Victor “Viti95” Nieto release fastDOOM บ่อยครั้งและติด tag ให้แต่ละ release พร้อมดูแลให้หนึ่ง commit ทำหนึ่งเรื่อง
  • ประวัติ Git ของ fastDOOM ประกอบด้วย 3,042 commits จึงสามารถติดตามการเปลี่ยนแปลงประสิทธิภาพราย commit ได้
  • มีการดาวน์โหลด 52 fastDOOM releases, PCDOOM v2 และ DOOM.EXE ต้นฉบับ จากนั้นใช้โปรแกรม Go สร้าง RUN.BAT สำหรับรัน -timedemo demo1 แล้ว mount ด้วย mTCP NETDRIVE เพื่อทดสอบ
    • เงื่อนไขคือ DOOM.WAD, เปิด sound, screen size 10
    • รัน test suite ทั้งหมด 5 ครั้ง แล้วนำค่า fps เฉลี่ยไปวาดกราฟ
  • แม้ PCDOOM v2 จะ build ด้วย OpenWatcom 2 แต่ก็ไม่ได้ดีขึ้นจาก DOOM.EXE ต้นฉบับมากนัก จึงอธิบายการเพิ่มประสิทธิภาพของ fastDOOM ด้วย การใช้ compiler สมัยใหม่เพียงอย่างเดียวได้ยาก
  • กราฟขนาดไฟล์แสดงให้เห็นว่างานช่วงแรกมุ่งไปที่การจัดระเบียบและลบโค้ดเพื่อให้เบาลง
    • bf0e983: ถอด sound recording ออก
    • 5f38323: ลบสตริง error code
    • 8b9cac5: เปลี่ยนจาก TASM เป็น NASM

การเปลี่ยนแปลงราย release ที่ดันประสิทธิภาพให้สูงขึ้น

  • หาก timedemo ทั้ง 3,042 builds อาจใช้เวลาราว 9 วัน จึงทำ benchmark ระดับ commit โดยเน้น v0.1, v0.6, v0.8, v0.9.2, v0.9.7 ซึ่งมีการเพิ่มความเร็วชัดเจน

  • fastDOOM v0.1

    • v0.1 ประกอบด้วย 220 commits
    • patch ใหญ่ที่สุดคือ e16bab8 ใน build 36
      • “Crispy optimization” ทำให้การ render เป็น no-op เมื่อเปอร์เซ็นต์ใน status bar ไม่เปลี่ยน ลดการ render scrap buffer และ screen blit
      • การเปลี่ยนแปลงนี้อย่างเดียวทำให้เพิ่มขึ้น 2fps
    • a9359d5 ใน build 167 ทำให้ FixedDiv เป็น macro แบบ inline
    • 9bd3f20 ใน build 207 นำ optimization จาก PSX Doom มาปรับปรุงวิธี BSP traversal
    • dc0f48e ใน build 212 inline ฟังก์ชัน render พื้นผิวแนวนอน R_MakeSpans
    • ใน commits ทั้งหมด มี 100 commits ที่เป็นการลบ คิดเป็นราวครึ่งหนึ่งที่เป็น การลบโค้ด

  • fastDOOM v0.6

    • v0.6 ประกอบด้วย 33 commits
    • 22819fd ใน build 342 ข้าม visplane rendering ที่ไม่จำเป็น
    • 40e0d4b ใน build 359 และ ccd296f ใน build 360 ลดการอ้างอิงทางอ้อมผ่าน player pointer
    • f29e665 ใน build 369 inline screenspace line splitter

  • fastDOOM v0.8

    • v0.8 ประกอบด้วย 282 commits
    • เนื่องจาก sound system ไม่เสถียร จึง timedemo โดยไม่ใช้ sound แล้วปรับเทียบ fps
    • release นี้โฟกัสที่ text-mode renderer และเกิด regression ใน build 670 กับ build 730 เมื่อ Crispy optimization หลุดออกไป
    • การปรับปรุงหลักมีดังนี้
      • f279b7d: แยก executable ตาม renderer เช่น FDOOM.EXE, FDOOM13H.EXE
      • 1874ee8: ปิด compiler debugging
      • 6aae724: กู้คืน Crispy optimization
      • 1366ebf: compile เฉพาะโค้ดให้น้อยลงเมื่อทำได้

  • fastDOOM v0.9.2 และ v0.9.7

    • v0.9.2 มี 110 commits โดยการเปลี่ยนแปลงหลักคือการปรับแต่งการเปรียบเทียบ skyflatnum, optimization ของ R_DrawColumn สำหรับ Mode Y และการจัดระเบียบโค้ด R_DrawSpan
    • v0.9.7 ถูกแนะนำว่ามี 293 commits แต่ output ของคำสั่งแสดง 294 commits
    • release นี้ไม่สามารถลด noise ได้แม้ benchmark หลายครั้ง
    • การเปลี่ยนแปลงหลัก ได้แก่ การทดสอบการเปลี่ยน x86 ASM, การเลือก CPU สำหรับ 386SX และ optimization ของ CR2, optimization ของ ESP สำหรับ R_DrawSpan386SX, โค้ดที่อิงกับ ASM fuzz column rendering และการตัดการเปรียบเทียบ CMP ต่อ loop ออก

เกณฑ์การเลือก Mode 13h, Mode Y และ VESA direct

  • fastDOOM สำรวจ optimization หลายแบบสำหรับชุดผสม CPU และ video bus ที่หลากหลาย เช่น 386, 486, Pentium, Cyrix และ ISA, VLB, PCI
  • บน IBM PS/1 486-DX2 66MHz optimization ที่ใช้ Mode 13h แทน Mode Y กลับช้ากว่า

  • Mode 13h

    • hardware รับหน้าที่กระจายข้อมูลไปยัง VRAM bank ทั้งสี่ของ VGA ทำให้ CPU มองเห็นเหมือน framebuffer 320x200 แบบ linear เดี่ยว
    • ไม่สามารถทำ double buffering ใน VRAM ได้ จึงต้อง buffer ใน RAM แล้ว copy กลับไปยัง VRAM ทำให้ต้องเขียน byte สองครั้ง
    • engine ต้อง block ที่ VSYNC

  • Mode Y

    • สามารถเข้าถึง VGA bank แยกกันได้ จึงทำ VRAM triple buffering ได้ และเขียน byte ลง VRAM ได้โดยตรงเพียงครั้งเดียว
    • การเลือก bank ต้องใช้คำสั่ง OUT ที่ช้า
    • หากเขียนผ่าน latch ไปยัง VGA bank สองชุดพร้อมกัน จะทำการทำซ้ำ pixel แนวนอนได้ จึงได้ low-detail mode
    • การ render Specter ที่มองไม่เห็นต้อง readback จาก VRAM จึงช้ากว่ามาก
    • จากคำอธิบายของ John Carmack, DOOM ใช้ interleaved planar mode ที่คล้าย Mode X ในโหมด VGA 320×200×256 และหมุนเวียน display page สามหน้า
    • การทำ texture mapping ลง video memory โดยตรงทำให้การ์ดวิดีโอจำนวนมากได้ความเร็วเพิ่ม 10%~15%
    • ยังสามารถทำ page flip แบบไม่มี tearing ได้ เมื่อเทียบกับ main memory buffering
    • Heretic ออกในปี 1994 และด้วยการเปลี่ยนแปลงของ hardware ในเวลานั้น Mode 13h กลายเป็นตัวเลือกที่น่าสนใจกว่า Raven จึงแก้ DOOM engine ไปในทิศทางนี้
    • fastDOOM ให้ executable หลายแบบแก่ผู้ใช้
    • FDOOM.EXE
    • FDOOM13H.EXE
    • FDOOMVBD.EXE

  • Mode 13h และ VESA direct ของ fastDOOM

    • Mode 13h ของ fastDOOM render ลง framebuffer เดี่ยวใน RAM แล้วเมื่อทั้งฉากเสร็จจึง copy ไปยัง VRAM
    • ไม่บังคับ VSYNC จึงอาจเกิด flickering
    • บน 8-bit ISA bus ที่ช้า จะใช้ differential copy ที่ส่งเฉพาะ pixel ที่เปลี่ยน
    • บน bus ที่เร็วกว่า เช่น 16-bit ISA, VLB, PCI จะ copy backbuffer ทั้งหมดด้วย REP MOVS
    • จากการทดสอบของ Viti95 โหมดที่ดีที่สุดสำหรับ CPU 486 คือ FDOOMVBD.EXE ซึ่งเป็น VESA direct mode สำหรับ 320×200
      • ผสานข้อดีของ Mode Y กับโค้ด render ที่ optimize แล้วของ Heretic
      • หลีกเลี่ยงคำสั่ง OUT ยกเว้นหนึ่งครั้งต่อ frame ตอนสลับ buffer
      • ต้องใช้การ์ดจอ VLB หรือ PCI ที่เปิดใช้ LFB ได้และรองรับ VESA 2.0 และจะช้าใน low-detail กับ potato-detail mode
    • IBM 2168 ไม่รองรับ VESA 2.0 จึงเกิด error เมื่อรัน FDOOMVBP.EXE และ FDOOMVBD

ความพยายามที่ไม่ได้ผลและภาพรวม

  • มีการลองใช้ flag เฉพาะ processor ของ OpenWatcom อย่าง 4r/4s และ 3r/3s ด้วย แต่ถูกยุติไป
    • มีการลองทั้ง flag 386 และ 486 ของ wcc386 และท้ายที่สุดเวอร์ชัน 386 ดูเหมือนจะเร็วกว่าเสมอ
  • Viti95 ยังมีเป้าหมายที่จะเปลี่ยน compiler ของ fastDOOM จาก OpenWatcom v2 ไปเป็น DJGPP หรือก็คือ GCC
    • เพราะพบว่า GCC สร้างโค้ดที่เร็วกว่าได้จาก source เดียวกัน
    • หรือการปรับปรุง OpenWatcom v2 ให้ลดช่องว่างด้านประสิทธิภาพลงก็ยังเป็นทางเลือกที่พึงประสงค์
  • ประสิทธิภาพของ fastDOOM เป็นผลจากการใช้ประโยชน์จากการปรับปรุงเดิมของ Crispy, PSX, GBA และ Lee Killough พร้อมเพิ่ม optimization ใหม่จำนวนมาก
  • แนวคิดและโค้ดบางส่วนของ Ken Silverman ก็ถูกนำไปใส่ในฟังก์ชัน rendering สำหรับ UMC Green CPU ทำให้ hardware นั้นเร็วขึ้นอย่างมาก
  • fastDOOM ไม่ได้เกิดจากการเปลี่ยนแปลงวิเศษเพียงอย่างเดียว แต่เป็นตัวอย่างของ พอร์ต DOS ที่เร็วกว่าต้นฉบับ DOOM จากการสะสม optimization เล็ก ๆ นับพันรายการ

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

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

 
GN⁺ 2025-03-05
ความคิดเห็นจาก Hacker News

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

    • ตัวอย่างเช่น เคยมีกรณีที่แอปใช้ CPU 60% และ GPU 25% โดยไม่ทราบสาเหตุ สุดท้ายพบว่าเป็นเพราะแอนิเมชัน CSS เล็ก ๆ
      https://www.granola.ai/blog/dont-animate-height
    • นึกถึงกรณีการปรับแต่งใน Super Mario World สำหรับ SNES ที่การแสดงคะแนนผู้เล่นไม่มีประสิทธิภาพมาก จนกินเวลาของเฟรมไปประมาณ 1/6
      ในกรณีเลวร้ายที่สุด การแสดงคะแนนบนแถบสถานะใช้เวลาเกือบ 1/6 ของทั้งเฟรม ทำให้จุดที่เริ่มช้าลงต่ำลง และแพตช์ก็เปลี่ยนวิธีเก็บและแสดงคะแนนให้เกือบเป็นเวลาคงที่ จนเร็วกว่าเคสเดิมที่ดีที่สุดเล็กน้อยด้วยซ้ำ
      https://www.smwcentral.net/?p=section&a=details&id=35746
    • จากมุมมองนักพัฒนาเกม อาการช้าลงแบบนี้พบได้บ่อย
      การเรนเดอร์ UI อาจร้ายแรงได้จากความโปร่งใส การซ้อนเลเยอร์ การวาดซ้ำ โดยเฉพาะ การทำให้เกิดการจัดสรรหน่วยความจำ และวิธีเปรียบเทียบค่าเก่ากับค่าใหม่ก่อนวาดซ้ำช่วยได้มาก
      แม้ใน CSS ก็เคยมีโปรเจกต์ที่คอขวดอยู่ที่เลเยอร์และความโปร่งใส ตอนนั้นหัวใจสำคัญคือการลดจำนวนเลเยอร์
    • ตัวอย่างที่ชอบที่สุดคือปัญหา เวลาโหลดของ GTA Online ซึ่งสุดท้ายเกิดจากการจัดการไฟล์ JSON ขนาด 10MB อย่างผิดวิธี และคนภายนอกองค์กรเป็นผู้ตามรอยจนเจอ
      ลดการโหลดจาก 6 นาทีให้เหลือน้อยกว่า 2 นาที
      https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
    • นึกถึงเหตุการณ์ที่ npm ช้าลง 2 เท่า จากเดิมเพราะแถบความคืบหน้าในเทอร์มินัลที่ดูหวือหวา
      https://news.ycombinator.com/item?id=10974929

  • อาจไม่ใช่ผู้อ่านกลุ่มเป้าหมายจริง ๆ แต่ NETDRIVE ของ mTCP น่าสนใจมาก
    ไม่เคยคิดว่าสมัยเก่าขนาดนั้นจะมีตัวเลือก สตอเรจผ่านเครือข่าย ที่ใช้งานได้ พอลองค้นดูก็เจอ https://www.brutman.com/mTCP/mTCP_NetDrive.html ซึ่งเจ๋งจริง ๆ
    ว่ากันว่า NetDrive เป็นไดรเวอร์อุปกรณ์ที่ทำให้ DOS เข้าถึงอิมเมจดิสก์ระยะไกลที่โฮสต์โดยเครื่องอื่นได้เหมือนอุปกรณ์โลคัลที่ผูกเป็นตัวอักษรไดรฟ์

    • ในห้องคอมพิวเตอร์ของโรงเรียนช่วงต้นทศวรรษ 90 มี Mac Plus ประมาณ 25 เครื่องต่อเดซี่เชนกับ Mac II ผ่าน AppleTalk และ Plus ทุกเครื่องเมานต์ระบบไฟล์จาก Mac II
      มันช้ามากจนตอนเริ่มคาบ นักเรียนเสียเวลา 5–10 นาทีเพื่อเปิดโปรแกรมประมวลผลคำ และ Xerox Alto ก็ใช้การเมานต์ผ่านเครือข่ายกับไดรฟ์เช่นกัน
      เมื่อมีเครือข่าย ไม่นานก็ต้องมีใครสักคนอยากคัดลอกไฟล์ และวิธีที่สะดวกที่สุดคือทำให้มันดูเหมือนระบบไฟล์โลคัล
      DOS ไม่มีระบบเครือข่ายในตัว จึงตามหลังในเรื่องนี้และมีหลายอย่างที่ต้องทำเอง
    • มีทริกที่เรียบร้อยในการบูต DOS ผ่านเครือข่ายจาก iSCSI target ด้วย iPXE
      ทำให้เข้าถึงอุปกรณ์บล็อกบนเครือข่ายแบบอ่าน-เขียนได้ โดยไม่ต้องมีไดรเวอร์หรือการตั้งค่าฝั่ง DOS แต่ถ้าใช้เหมือนแชร์ก็พังได้เร็ว และมันใกล้เคียงกับอุปกรณ์บล็อกมากกว่า
      รู้สึกเหมือนเวทมนตร์ แต่ดูเหมือน iPXE จะแพตช์ BIOS เพื่อส่งการเข้าถึงดิสก์ไปยัง iSCSI
    • สงสัยว่าสมัย DOS มี NAS หรือ การเมานต์ WebDAV ไหม
      ของอย่าง FTP กับ telnet น่าจะมีอยู่แล้วแน่นอน แต่สงสัยว่าการเมานต์ระยะไกลถูกใช้งานจริงหรือไม่ หรือเป็นไปไม่ได้เพราะแบนด์วิดท์ต่ำ

  • เธรด GitHub ที่ Ken Silverman เข้าร่วมเป็นเหมือนขุมทรัพย์
    น่าทึ่งที่ได้เห็นผู้เขียน FastDOOM กับ Ken เจาะลึก รีจิสเตอร์ 486 และประสิทธิภาพระดับรอบสัญญาณนาฬิกา ที่เข้าใจยาก
    ดีใจที่ยังมีคนคอยดูแลให้ Doom ได้รับการปรับปรุงประสิทธิภาพอยู่

    • นึกถึง KenS ขึ้นมาเป็นครั้งแรกในรอบนานมาก ในยุค 90 เขาเคลื่อนไหวอย่างมากในแวดวง ม็อด Duke3D
      สคริปติงนั้นเป็น “การเขียนโค้ด” ครั้งแรกของผมแบบแท้จริง และในแง่หนึ่งก็เหมือนผมติดหนี้ทั้งอาชีพและทรัพย์สินทั้งหมดกับ KenS เลย น่าทึ่งมาก
    • ปีที่แล้วตอนทำ เอนจินเรนเดอร์ 2.5D คล้าย ๆ กัน ผมส่งอีเมลไปถาม Ken Silverman เกี่ยวกับส่วนที่ไม่ค่อยเป็นที่รู้จักของ Build Engine แล้วเขาตอบกลับมาเหมือนเป็นคนที่เพิ่งทำงานกับมันเมื่อวานนี้
    • ข้างในนั้นมีเนื้อหาที่เป็นอัญมณีจริง ๆ
      โดยเฉพาะไอเดียการใช้ CR2 และ CR3 เป็นรีจิสเตอร์ scratchpad บน 386SX และ 386DX ที่ไม่มีแคช ซึ่งการเข้าถึงหน่วยความจำช้ามาก
      เทคนิคการใช้ ESP เป็นตัวนับลูปโดยไม่ปิดอินเทอร์รัปต์ก็อัจฉริยะมาก โดยเป็นวิธีที่รับประกันให้มันชี้ไปยังตำแหน่งสแตกที่ถูกต้องเสมอ

  • ฟีเจอร์ที่ไม่ได้พูดถึงมากนักใน FastDOOM คือ โหมดวิดีโอ แปลก ๆ สารพัดแบบ
    โหมดข้อความ IBM MDA: https://www.youtube.com/watch?v=Op2tr2lGK6Y
    EGA & Plantronics ColorPlus: https://www.youtube.com/watch?v=gxx6lJvrITk
    CGA สีน้ำเงิน·ชมพูแบบคลาสสิก: https://youtu.be/rD0UteHi2qM
    CGA 320x200x16 ที่ใช้แฮ็ก ‘ANSI from Hell’: https://www.youtube.com/watch?v=ut0V1nGcTf8
    Hercules: https://www.youtube.com/watch?v=EEumutuyBBo
    ส่วนใหญ่ดูเหมือนจะรันช้ากว่า VGA เพราะต้องทำงานอย่างการ remapping สี

    • อยากให้รองรับ Tandy Graphics Adapter ด้วย
      ถ้าต้องรันด้วย CGA คงไม่ชอบแน่ และถ้ามันยังอยู่รอดมาถึงตอนนี้ ก็คงต้องมีบิลด์ 286 สำหรับ Tandy 1000 TL/2
    • เจ๋งมาก และแสดงให้เห็นอย่างดีว่าทำไมแง่มุมพวกนี้ของเกมจึงควรถูกแยกออกจากกัน
      ทำให้นึกถึง Clean Architecture แบบ “สมัยใหม่” ของแอปพลิเคชันแบ็กเอนด์
    • โหมดข้อความ IBM MDA นี่สยองมาก... ก็เลยดี

  • ประทับใจกับประโยค “IBM PS/1 486-DX2 66Mhz, ‘Mini-Tower’, model 2168. คอมพิวเตอร์ที่ตอนเป็นวัยรุ่นอยากได้มาตลอดแต่ซื้อไม่ได้”
    ราวปี 1992 ผมใช้พีซีเครื่องที่สี่ที่ประกอบเองอยู่ และงาน KCS computer show ที่ Marlborough MA เป็นแหล่งทรัพยากรมหาศาลสำหรับคนชอบงัดแงะ
    ซื้อชิ้นส่วนมาประกอบพีซี ใช้ไปสักพักแล้วขาย จากนั้นก็ซื้อชิ้นส่วนใหม่ วนแบบนั้น
    ช่วงปลายปี 1992 ผมรัน 486-DX3 100 ที่มีโคโปรเซสเซอร์คณิตศาสตร์ ULSI 487 อยู่ และอยู่พักหนึ่งก็น่าจะเป็นพีซีที่เร็วที่สุดในแคมปัส หรืออาจเป็นคอมพิวเตอร์ที่เร็วที่สุดเลยก็ว่าได้
    มันเร็วกว่า Pentium หลายรุ่น และไม่เกิดบั๊กคำนวณคณิตศาสตร์ด้วย
    บิลด์สุดท้ายสมเหตุสมผลขึ้นมาเพราะต้องจำลองโรงไฟฟ้าพลังความร้อนร่วมก๊าซ/ดีเซลเป็นสเปรดชีต Excel 21 หน้าเพื่อทำวิทยานิพนธ์เกียรตินิยม แล้วเวลา recalculation นานเกินไป
    สาขาที่เรียนคือวิทยาศาสตร์สิ่งแวดล้อม แต่เส้นทางอาชีพทั้งหมดกลายเป็นคอมพิวเตอร์

    • ไม่แน่ใจว่านี่ควรต้อง “ว้าว” หรือเปล่า
      จำเป็นต้องไปทำให้คนที่ซื้อคอมพิวเตอร์แบบนั้นในปี 1992 ไม่ได้รู้สึกแย่ด้วยหรือ
      อีกอย่าง ไม่มีสิ่งที่เรียกว่า “DX3” และ DX4 ซึ่งเป็น 486 100MHz ตัวแรกก็ออกมาในเดือนมีนาคม 1994 ดังนั้นที่บอกว่ารันช่วงปลายปี 1992 ดูไม่น่าถูกต้อง
      คอมพิวเตอร์เครื่องแรกของบ้านเรา ถ้าไม่นับ XT ที่ได้มาราวปี 1992 ซึ่งตอนนั้นก็เก่าเกินไปแล้ว คือ 66MHz 486-DX2 ที่ซื้อเมื่อต้นปี 1995
      ผ่านมาหลายสิบปีแล้ว แถมมีแต้มต่ออยู่ 3 ปี แต่พอเห็นคนอวดคอมพิวเตอร์ที่เป็นไปไม่ได้ว่ามันเร็วกว่าเครื่องของผม ก็ทำให้เสียศักดิ์ศรีแปลก ๆ
    • ทำให้นึกถึงความหลังจริง ๆ
      ราวปี 1992 ผมเป็นนักศึกษายากจน และกู้เงินจาก credit union มาประมาณ 2,000 ดอลลาร์เพื่อซื้อ 486 DX2-50
      ถ้าเทียบเป็นเงินสมัยนี้ก็คือใช้เงินเกิน 4,000 ดอลลาร์กับคอมพิวเตอร์ที่ค่อนข้างพื้นฐาน และผม dual boot DOS กับ Linux บนเจ้านั่น
    • 487 บน 486DX เหรอ ผมนึกว่า 487 มีประโยชน์เฉพาะกับชิป SX เท่านั้น
      ลองค้นดูแล้วพบว่า 487 มาตรฐานเดิมทีเป็น 486DX เต็มตัวที่ปิดการทำงานและแทนที่ 486SX
      หรือว่านั่นเป็นโคโปรเซสเซอร์สุดยอดแบบอื่นที่ผมไม่เคยรู้จักมาก่อนกันนะ
    • ถ้า “เร็วกว่า Pentium หลายรุ่นและไม่เกิดบั๊กคำนวณคณิตศาสตร์” ก็ถือเป็นเรื่องให้อวดเต็มที่
      เป็นการเอาชนะขาดลอยจริง ๆ

  • ไม่ใช่แค่การออก release บ่อย ๆ แต่ Viti95 ยังแสดง วินัยการใช้ Git ที่ยอดเยี่ยม โดยหนึ่ง commit ทำหนึ่งอย่าง และติด tag ให้แต่ละ release
    https://fabiensanglard.net/fastdoom/#:~:text=one%20commit%20...

  • ไม่เข้าใจว่า Ibuprofen หมายถึงอะไรในประโยค “ก่อนจะรู้จัก fastDOOM ผมทำใจแล้วว่าต้องกิน Ibuprofen ไปเล่นไป”

    • น่าจะหมายถึงอาการปวดหัวจากเฟรมเรตต่ำหรือเปล่า

  • ถ้าผู้เขียนเห็น ในเอกสารทั้งฉบับสะกดนามสกุลของ John Carmack ผิดเป็น “Carnmack”

  • ถ้ามองแบบไม่ประชดประชัน เหตุผลที่ซอฟต์แวร์สมัยใหม่ช้าและไม่มีการ optimize แบบนี้ อธิบายได้ด้วย สมมติฐานมาตรฐาน/การเพิ่มประสิทธิภาพ
    เมื่ออะไรบางอย่างกลายเป็นมาตรฐาน การ optimize ก็จะตามมา
    เพราะทุกคนอยากให้มันเร็วที่สุดขณะยังผ่านการทดสอบทั้งหมดของมาตรฐาน
    ตอนนี้ Doom ก็กลายเป็นเกมมาตรฐานที่ถูกพอร์ตไปทุกที่ ไม่ว่าจะเป็น CPU ใหม่หรือเครื่องปิ้งขนมปัง และโปรโตคอลอีเมลหรือมาตรฐานเบราว์เซอร์อย่าง WebRTC, QUIC ฯลฯ ก็คล้ายกัน
    เหตุผลที่เว็บแอปยุคใหม่หรือแอป Electron ไม่เร็ว เป็นเพราะยังอยู่ในช่วงสำรวจ
    มันถูกอัปเดตทุกวันให้เข้ากับความต้องการใหม่ ๆ ของผู้ใช้ และในแง่ประสิทธิภาพ แค่เร็วพอไม่ให้เกะกะก็เพียงพอ
    ดังนั้นแอป IRC จึงเร็วมาก แต่ Slack กับ Teams ก็จำเป็นต้องช้าอยู่เสมอ

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