49 คะแนน โดย GN⁺ 2024-03-11 | 4 ความคิดเห็น | แชร์ทาง WhatsApp

การแสดงตัวเลขด้าน latency ที่โปรแกรมเมอร์ควรรู้ในรูปแบบภาพ

  • การอ้างอิง L1 cache: 1 นาโนวินาที
  • การทำนายสาขาผิดพลาด: 3 นาโนวินาที
  • การอ้างอิง L2 cache: 4 นาโนวินาที
  • การล็อก/ปลดล็อก mutex: 17 นาโนวินาที
  • การส่งข้อมูล 1KB ผ่านเครือข่าย 1 Gbps: 44 นาโนวินาที
  • การอ้างอิงหน่วยความจำหลัก: 100 นาโนวินาที
  • การบีบอัดข้อมูล 1KB ด้วย Zippy: 2 ไมโครวินาที
  • การอ่านแบบลำดับ 1MB จากหน่วยความจำ: 3 ไมโครวินาที
  • การอ่านแบบสุ่ม 4K จาก SSD: 16 ไมโครวินาที
  • การอ่านแบบลำดับ 1MB จาก SSD: 49 ไมโครวินาที
  • เวลาไป-กลับภายในดาต้าเซ็นเตอร์เดียวกัน: 500 ไมโครวินาที
  • การอ่านแบบลำดับ 1MB จากดิสก์: 825 ไมโครวินาที
  • การ seek ของดิสก์: 2 มิลลิวินาที
  • การส่งแพ็กเก็ตจากแคลิฟอร์เนียไปเนเธอร์แลนด์แล้วกลับมา: 150 มิลลิวินาที

ความเห็นของ GN⁺

  • ข้อมูลชุดนี้สามารถเป็นข้อมูลอ้างอิงสำคัญสำหรับโปรแกรมเมอร์เมื่อต้องออกแบบระบบหรือทำ performance optimization ได้ หากรู้ว่าการประมวลผลหรือการทำงานแต่ละอย่างใช้เวลานานแค่ไหน ก็จะช่วยระบุได้ว่าส่วนใดเป็นคอขวดและสามารถปรับปรุงได้
  • ตัวอย่างเช่น เมื่อเปรียบเทียบเวลาเข้าถึงหน่วยความจำกับ network latency จะเห็นได้ว่าการลดจำนวน network call และประมวลผลข้อมูลภายในหน่วยความจำนั้นเร็วกว่าอย่างมาก ซึ่งอาจเป็นข้อพิจารณาสำคัญในการออกแบบ distributed system
  • latency เหล่านี้สามารถเปลี่ยนแปลงได้ตามพัฒนาการของฮาร์ดแวร์และเทคโนโลยี ดังนั้นการอัปเดตข้อมูลล่าสุดอยู่เสมอจึงเป็นสิ่งสำคัญ ตัวอย่างเช่น การพัฒนาของ SSD ทำให้เวลาอ่านข้อมูลจากดิสก์สั้นลงอย่างมาก
  • เมื่อนำเทคโนโลยีใหม่หรือโอเพ่นซอร์สมาใช้งาน ควรพิจารณา latency เหล่านี้เพื่อคาดการณ์ประสิทธิภาพของระบบ และตัดสินใจว่าเทคโนโลยีใดจะมีประสิทธิผลมากที่สุดในสภาพแวดล้อมจริง ตัวอย่างเช่น การใช้โซลูชันแคชในหน่วยความจำสามารถลด network latency ได้ แต่ก็ต้องพิจารณาเพิ่มเติมเรื่องความสอดคล้องของแคชและการซิงก์ข้อมูล

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

 
kleinstein 2024-03-11

https://colin-scott.github.io/personal_website/research/…
อันนี้ดูดีกว่านะครับ

 
cosine20 2024-03-11

โอ๊ย UI/UX ไม่ถูกใจจริง ๆ...

 
yangeok 2024-03-18

จริงเลย สุดๆ,,

 
GN⁺ 2024-03-11
ความคิดเห็นจาก Hacker News
  • สรุปความคิดเห็นที่หนึ่ง:

    • ผู้ใช้แชร์โค้ด JavaScript ซึ่งวนลูปผ่านองค์ประกอบลูกขององค์ประกอบ HTML ที่มีคลาส latency-container และแสดงค่า latency ของแต่ละรายการ
    • ค่า latency ที่แสดงครอบคลุมงานคอมพิวเตอร์หลากหลายประเภท ตั้งแต่การอ้างอิงแคช L1 ไปจนถึงเวลาไป-กลับภายในดาต้าเซ็นเตอร์
  • สรุปความคิดเห็นที่สอง:

    • มองว่าการใช้งานของส่วนติดต่อผู้ใช้ (UI) ไม่ดีนัก และยกให้เป็นกรณีศึกษาที่น่าสนใจเกี่ยวกับประสบการณ์ผู้ใช้ (UX)
    • วิจารณ์ว่า UI ไม่ตอบสนองความคาดหวังของผู้ใช้ในการทำหน้าที่หลัก และเข้าใจได้ยาก
    • ผู้ใช้บอกว่าจำเป็นต้องอ่านวิธีใช้ แต่ผู้ใช้ส่วนใหญ่มักไม่ชอบทำเช่นนั้น
    • เน้นว่าสามารถเรียนรู้บทเรียนด้าน UX ได้จากการถกเถียงเกี่ยวกับปัญหาเหล่านี้
  • สรุปความคิดเห็นที่สาม:

    • ชี้ว่าชื่อเรื่องไม่มีคำว่า "Latency" ทำให้ค้นหาเจอผลลัพธ์อื่นได้ยาก
    • อ้างอิงแหล่งข้อมูลอื่นและบอกว่าชอบข้อมูลแบบข้อความที่ให้รายละเอียดเรื่อง latency มากกว่า
  • สรุปความคิดเห็นที่สี่:

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

    • รวบรวมแหล่งข้อมูลที่เกี่ยวข้องกับที่มาของข้อมูล latency และให้ภูมิหลังทางประวัติศาสตร์ของข้อมูลนี้
  • สรุปความคิดเห็นที่หก:

    • กล่าวว่าค่า latency ที่เกี่ยวกับเครือข่ายนั้นไม่ค่อยสอดคล้องกับสัญชาตญาณ
    • แชร์ประสบการณ์ส่วนตัวว่าเหตุใดบริการอย่าง Google Stadia จึงอาจทำงานได้เร็วกว่าที่คาดไว้
  • สรุปความคิดเห็นที่เจ็ด:

    • ในฐานะผู้ใช้ Firefox บนมือถือ ระบุว่าไม่เข้าใจว่า UI พยายามจะแสดงอะไร
  • สรุปความคิดเห็นที่แปด:

    • ระบุว่าไม่เข้าใจความหมายของตัวเลขที่แสดงใน UI และสับสนเพราะมันดูเหมือนปีในอนาคต
  • สรุปความคิดเห็นที่เก้า:

    • บอกว่าชื่อเรื่องค่อนข้างลึกลับ และคาดว่าจะเป็นเนื้อหาเกี่ยวกับตัวเลขอย่าง 16, 256, 65536 เป็นต้น
    • แสดงความสงสัยต่อข้ออ้างที่ว่าในปี 2030 การส่งข้อมูล 1K ไบต์ผ่านเครือข่ายกิกะบิตจะเร็วกว่าการทำนายกิ่งก้านผิดพลาดภายใน CPU