- มีระบบจำนวนมากกว่าที่หลายคนจินตนาการ ซึ่งสามารถทำงานได้ดีเพียงพอบน ฮาร์ดแวร์รุ่นเก่า
- หากมีการทำ การเพิ่มประสิทธิภาพซอฟต์แวร์ อย่างแท้จริง ก็มีความเป็นไปได้สูงที่จะบรรลุประสิทธิภาพเช่นนี้
- สัญญาณราคาตลาดของ ทรัพยากรคอมพิวติ้งที่ขาดแคลน ช่วยสร้างแรงจูงใจต่อประสิทธิภาพของซอฟต์แวร์
- มีความจำเป็นต้องเปลี่ยนผลิตภัณฑ์ ไมโครเซอร์วิสที่อิงอินเทอร์พรีเตอร์ เดิม ไปเป็น สถาปัตยกรรมแบบโมโนลิธิกที่สร้างด้วยเนทีฟโค้ด
- ในทางกลับกัน หากไม่มีทรัพยากรประมวลผลที่ราคาถูกมากและขยายขนาดได้ง่าย ก็มีความเป็นไปได้ว่า การพัฒนาผลิตภัณฑ์ใหม่ที่เป็นนวัตกรรม จะเกิดขึ้นได้ยากกว่ามาก
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
อาจโต้แย้งได้ว่าในตลาด ซอฟต์แวร์ที่มีบั๊กเยอะและไร้ประสิทธิภาพก็ขายได้ดีพอๆ กับซอฟต์แวร์ที่สมบูรณ์แบบ เพราะอย่างใดอย่างหนึ่งในสองแบบนี้คือซอฟต์แวร์ที่ต้นทุนถูกที่สุดในการสร้าง เรื่องนี้คล้ายกับแนวคิด “ตลาดมะนาว” กล่าวคือตลาดซื้อขายกันราวกับว่าสินค้าทุกชิ้นมีคุณภาพสูง ทั้งที่จริงแล้วลดคุณภาพลงเพื่อลดต้นทุน ผู้ซื้อแยกของคุณภาพสูงกับคุณภาพต่ำก่อนซื้อไม่ได้ จึงทำให้ความต้องการของทั้งสองแบบใกล้เคียงกันอย่างผิดธรรมชาติ นี่คือผลของความไม่สมมาตรของข้อมูล และปรากฏการณ์นี้ก็เป็นจริงอยู่แล้ว แถมยิ่งจริงขึ้นในโลก AI ผู้ใช้แยกไม่ออกระหว่างแอปพลิเคชันแมชชีนเลิร์นนิงที่ซับซ้อนกับเครื่องซักผ้าที่แค่ติดป้ายว่า “AI” คำว่า AI เองก็ทำให้ตั้งราคาพรีเมียมได้ ผู้ใช้จึงจ่ายแพงเกินจริงให้กับเครื่องซักผ้า และการที่ผู้ซื้อคิดว่ากำลังจ่ายเงินให้ “ซอฟต์แวร์ที่ออกแบบและเขียนโดยผู้เชี่ยวชาญ” ทั้งที่ของจริงแย่มาก ก็แทบเป็นเรื่องเดียวกัน ซอฟต์แวร์เกือบทั้งหมดถูกเขียนในระดับ IC1-3 และในบริษัทส่วนใหญ่ คน QA กลายเป็นตัวชี้วัดเดียวของการยกระดับคุณภาพ บางครั้งก็หวังพึ่งเด็กฝึกงานที่ท่องคาถา “LGTM” ว่าจะช่วยให้ดีขึ้น แต่ในความเป็นจริง แค่นั้นยังแทบไม่ค่อยเกิดขึ้นเลย
ฉันเคยพยายามสร้างสตาร์ตอัปซอฟต์แวร์ที่แตกต่างด้วยคุณภาพ โดยมั่นใจว่าถ้าสินค้าดีกว่า คนก็ต้องมองออกและประสบความสำเร็จ แต่ความจริงไม่เป็นแบบนั้น มันเติบโตนะ แต่ช้าเกินไปจนเงินหมดก่อนจะทำกำไรได้ สิ่งที่ได้เรียนรู้คือ ต้นทุนต่ำ และคุณภาพต่ำที่ตามมา กลับเป็นข้อได้เปรียบในการแข่งขันในตลาดแข่งขัน ฉันเคยได้ยินเรื่องนี้ตั้งแต่สมัยมหาวิทยาลัย แต่ประสบการณ์ครั้งนี้ทำให้ซึมลึกถึงกระดูกเลย นี่แหละคือเหตุผลที่ทุกอย่างในตลาดกลายเป็นของธรรมดา และยิ่งได้รับความนิยมมากขึ้น คุณภาพสูงก็ยิ่งเสื่อมลง เมื่อสินค้าขยายขนาด แรงกดดันให้ลดต้นทุนก็ยิ่งมากขึ้น คนอยากซื้อของถูก จึงมีคนลดต้นทุนลงไปอีกโดยแลกกับคุณภาพเพื่อขายให้ถูกกว่า บริษัทต่างๆ จ่ายให้น้อยที่สุดเท่าที่พออยู่รอดและมีกำไร แน่นอนว่าบางครั้งก็มีข้อยกเว้น แต่สุดท้ายก็ไหลไปสู่การลดต้นทุนแบบค่อยเป็นค่อยไป น่าจะมีชื่อเรียกปรากฏการณ์นี้อยู่ แต่ต่างจากตลาดมะนาวเล็กน้อย เพราะตลาดไม่ได้พังทลาย เพียงแต่เกิดความธรรมดาระดับคงที่อยู่ทุกหนแห่ง
มีข้อโต้แย้งต่อมุมมองที่ว่าตลาดขายสินค้าทุกอย่างราวกับเป็น “ของคุณภาพสูง” เพราะคำว่า “คุณภาพสูง” สำคัญมาก ถ้าหมายถึงประสิทธิภาพแย่ก็ถือว่าคุณภาพต่ำ แต่ในความเป็นจริง แอปอย่าง Teams, Slack, Jira ที่มักถูกมองว่าประสิทธิภาพไม่ดี ก็มีคู่แข่งที่ทำงานได้เร็วกว่ามาก ทว่าถ้าจะให้ผู้ใช้เลือก Weechat ที่เป็น terminal UI ไม่มีวิดีโอแชต ไม่มีอีโมจิ แทน Slack คนส่วนใหญ่ก็คงมองอย่างหลังว่าเป็นของคุณภาพต่ำกว่า ประสิทธิภาพก็เป็นเพียงฟีเจอร์หนึ่งเท่านั้น เช่น ความสำเร็จในช่วงแรกของ Chrome มาจากความเร็ว และนักพัฒนา Python ก็ย้ายไปใช้ uv/ruff เพราะประสิทธิภาพดีขึ้น แต่ถ้า Slack เปิดใน 10ms แทนที่จะ 5 วินาที ผู้ใช้ส่วนใหญ่ก็คงไม่สนใจอยู่ดี
ฉันไม่เห็นด้วยที่ว่าซอฟต์แวร์ไร้ประสิทธิภาพเป็นผลจากโครงสร้างตลาดมะนาว จะเป็นเช่นนั้นก็ต่อเมื่อมีความไม่สมมาตรของข้อมูลเท่านั้น ในกรณีส่วนใหญ่ คนไม่ได้ใส่ใจกับบั๊กเล็กน้อยนักและต้องการราคาที่ถูกกว่า ถ้าทำ QA อย่างเข้มข้นมากและมีขั้นตอนตรวจโค้ดโดยวิศวกรหลายคน พอเทียบราคาแล้วจะเห็นชัด ฉันเคยทำซอฟต์แวร์ให้ร้านหนังสือเล็กๆ แห่งหนึ่ง ทำเร็วและคิดราคาไม่แพงนัก ถึงจะไม่สมบูรณ์แบบ แต่ถ้ามีปัญหาก็แก้ให้ทันที ลูกค้าก็รู้ว่านี่เป็นดีลที่ดีและพอใจ
ฉันเคยใช้พอร์ทัล HR, การเบิกค่าใช้จ่าย, การติดตามเวลา, และประกันของบริษัทใหญ่ๆ ที่แย่มากๆ จนสงสัยว่าคนที่จ่ายเงินซื้อเคยลองใช้สินค้านี้จริงหรือเปล่า ถ้าทีมของฉันเอาผลิตภัณฑ์ที่เต็มไปด้วยบั๊กและฝันร้ายด้าน UI แบบนั้นไปให้ลูกค้า คงโดนด่าทันที ไม่ก็โดนลดบทบาท หรืออาจถึงขั้นโดนไล่ออก
แก่นแท้ที่ว่าตลาดซื้อ “ซอฟต์แวร์ที่เต็มไปด้วยบั๊กและไร้ประสิทธิภาพ” ได้ดีนั้น จริงๆ แล้วตลาดกำลังซื้อ <i>การสนับสนุน</i> สิ่งนี้ใช้ได้แม้กับ Google หรือบริษัทที่มีการสนับสนุนจากมนุษย์น้อยก็ตาม “การสนับสนุน” ปรากฏได้หลายรูปแบบ — เอกสาร, วิดีโอ, ข้อมูลตามบล็อก, คนที่ช่วยเหลือได้, การรองรับสภาพแวดล้อมที่ฉันใช้อยู่ (ระบบปฏิบัติการ, เบราว์เซอร์ ฯลฯ), การรองรับงานที่ฉันต้องการทำ ฯลฯ ปัจจัยอันดับหนึ่งที่ทำให้ ERP ที่แย่ที่สุดยังอยู่รอดได้ก็คือคนจริงๆ การมีหรือไม่มีการสนับสนุนเป็นเส้นตายของผลิตภัณฑ์ ถ้าทีมเล็กจะชนะศึก ก็ควรลด “ความจำเป็นต้องพึ่งการสนับสนุน” และใส่การสนับสนุนในมิติอื่นแทน วิธีที่ง่ายที่สุดคือเพิ่มคน และต้องสื่อสารจุดแข็งให้ถูกต้อง เพราะการสนับสนุนแต่ละชนิดถูกประเมินต่างกัน เช่น โค้ดโอเพนซอร์ส vs โค้ดปิด หลายคนเลือกแบบปิดถ้ามีการสนับสนุนมากกว่า มากกว่าตัวโค้ดเสียอีก
เหตุผลใหญ่ข้อหนึ่งที่ฉันชอบซื้อของที่ Costco คือพวกเขามักไม่ขายของขยะ ถึงตัวกรองของเขาจะไม่ตรงกับมาตรฐานของฉันเสมอไป แต่ก็เป็นตัวกรองคุณภาพที่มีความหมาย
ต่อให้ผู้ใช้ตัดสินใจจากคุณภาพและประสิทธิภาพของซอฟต์แวร์ได้จริง แต่ถ้าดูรายชื่อแอปที่ฉันเปิดอยู่ ก็ไม่มีแอปไหนแทนกันได้เพียงเพราะอีกตัวทำงานได้เร็วกว่า เช่น Docker, iterm2, WhatsApp ต่างก็มีเหตุผลเฉพาะที่ฉันใช้ ต่อให้มีทางออกที่เร็วที่สุด ก็ไม่ใช่ว่าจะเปลี่ยนไปใช้ได้ โจทย์ที่สำคัญกว่าประสิทธิภาพคือการมีซอฟต์แวร์ที่ตอบความต้องการของฉันได้ตั้งแต่แรก
ซอฟต์แวร์ 99% ถูกเขียนขึ้นโดยไม่คำนึงถึงประสิทธิภาพ ใน HN เองก็มักมีแนวโน้มมองการปรับปรุงประสิทธิภาพเป็นเรื่องต้องห้าม แม้แต่วิศวกรระดับ L4/5 ขึ้นไปก็มักขาดสัญชาตญาณด้านประสิทธิภาพ ในมุมธุรกิจเองก็ไม่สนใจประสิทธิภาพจนกว่าฮาร์ดแวร์จะรันซอฟต์แวร์นั้นไม่ไหว และถึงตอนนั้นทางเลือกแรกก็มักเป็นการเพิ่มฮาร์ดแวร์
โครงสร้างตลาดปัจจุบันทำให้ซอฟต์แวร์ที่มีบั๊กเยอะและไร้ประสิทธิภาพครองโลกได้ เพราะเราซื้อฮาร์ดแวร์มาเพิ่มเพื่อให้มันรันได้เสมอ ซอฟต์แวร์พองตัวขึ้นเพื่อกินสเปกประมวลผลของฮาร์ดแวร์ — นี่คือกฎ “What Andy gives, Bill takes away” เพราะอย่างนี้จึงไม่มีแรงจูงใจให้สร้างซอฟต์แวร์คุณภาพสูงแบบ lean แต่ถ้าวันหนึ่งมาถึงโลกที่ไม่อาจหาชิปทันสมัยได้อีกต่อไป (เช่น วิกฤตภูมิรัฐศาสตร์, โรงงานขนาดใหญ่ถูกทำลาย ฯลฯ) ซอฟต์แวร์ที่ใช้ทรัพยากรอย่างประหยัดจะมีมูลค่าทางเศรษฐกิจสูงมาก — ซอฟต์แวร์ที่พองเกินจำเป็นจะรันไม่ได้อีกต่อไป Carmack บอกว่าในสถานการณ์แบบนั้น ยังมีช่องให้ปรับแต่งประสิทธิภาพได้มากพอ จนสุดท้ายเราน่าจะยังหาทางทำให้ซอฟต์แวร์รันบนชิปยุคเก่าได้
ซอฟต์แวร์ที่ออกแบบมาดีคือซอฟต์แวร์ที่เปลี่ยนแทนได้ง่าย ตรงกันข้าม ชุดสปาเกตตีโค้ดที่เต็มไปด้วยบั๊กเป็นสิ่งที่ไม่มีใครอยากแตะ จึงคงอยู่ตลอดไป ถ้ามองด้วยวิวัฒนาการล้วนๆ ซอฟต์แวร์แย่ๆ ต่างหากที่ลงเอยด้วยการครองโลก
เหตุผลที่ตลาดรถมือสองเป็นตลาดมะนาวก็เพราะแยกยากระหว่างรถที่ดูแลมาดีกับรถที่ใกล้พัง แต่ตลาดรถใหม่ไม่เป็นแบบนั้นเพราะมีการควบคุมเข้มงวด ซอฟต์แวร์นั้นใหม่เสมอ เช่นเดียวกับที่คุณภาพรถยนต์ดีขึ้นตลอดหลายทศวรรษ ซอฟต์แวร์ก็สามารถยกระดับคุณภาพได้เช่นกัน ควรขายได้ก็ต่อเมื่อผ่านมาตรฐานบางอย่าง ถ้ามีบั๊กร้ายแรงก็ควรมีการเรียกคืน ถ้าจงใจขายของด้อยคุณภาพก็ควรโดนลงโทษ อุตสาหกรรมอื่นก็ทำกันแบบนี้ทั้งนั้น
ด้วยการมาของ Web 2.0 แบบ “เบต้าไม่สิ้นสุด” และโมเดล SaaS ความอดทนของผู้ใช้ก็เปลี่ยนไปเช่นกัน Microsoft ใช้เวลาหลายยุคสมัยปลูกฝังความคิดว่า “ซอฟต์แวร์มันพังก็เป็นเรื่องปกติ” เมื่อทุกคนชินกับซอฟต์แวร์แย่ๆ ไปแล้ว คนก็เริ่มมองไม่เห็นคุณค่าของซอฟต์แวร์ดีๆ
ฉันซื้อเครื่องซักผ้าที่ติดตรา AI แบบนั้นมาจริงๆ ฉันขำกับการตลาดนะ แต่ราคามันสมเหตุสมผลก็เลยซื้อ
บางทีเขาอาจกำลังพูดถึงแค่ช่องโหว่ด้านความปลอดภัย ถ้า Excel หรือ Photoshop เต็มไปด้วยปัญหาด้านประสิทธิภาพหรือบั๊กอื่นๆ ผู้ใช้คงเลิกใช้ไปอย่างรวดเร็ว แต่เรื่องความปลอดภัย ผู้ใช้มักไม่รู้จนกว่าจะเกิดปัญหา และถึงจะโดนแฮ็กก็ไม่รู้สาเหตุ นักพัฒนาจึงไม่มีแรงจูงใจ ส่วนประสิทธิภาพนั้น พอถึงระดับที่ “พอใช้ได้” แล้ว ก็เริ่มไม่อยากทุ่มทรัพยากรเพิ่มให้กับการปรับแต่ง เพราะกฎผลตอบแทนลดลง
ต่อให้ผู้ใช้แยกไม่ออกระหว่าง AI ที่ซับซ้อนกับ “เครื่องซักผ้า AI” ที่เป็นแค่เปลือก แต่ AI ที่ดีอาจช่วยให้ผู้ใช้เอาชนะปัญหาความไม่สมมาตรของข้อมูลได้เอง สุดท้ายถ้ามีวิธีเลือก AI ที่ดี ก็อาจแก้ปัญหานี้ได้
ฉันไม่คิดว่าการทำ “ซอฟต์แวร์ที่ถูกที่สุด” จะแปลว่าราคาถูกเสมอไป ในระดับสตาร์ตอัป ของที่ทำแบบลวกๆ อาจถูกกว่า แต่พอสเกลใหญ่ขึ้นกลับแพงกว่า สายการบินยังพยายามลดต้นทุนแม้แต่เอามะกอกออกหนึ่งลูก แล้วทำไมการให้วิศวกรไป optimize ถึงดูไม่คุ้มกันแน่ เราเพิ่มแต่ฟีเจอร์ใหม่ๆ แต่ผู้ใช้กลับรู้สึกว่าแต่ละอัปเดตช้าลงเสมอ และพอมันเร็วขึ้น คนก็โห่ร้องยินดี วิศวกรกลับทำตัวเหมือน MBA แล้วตอบซ้ำๆ ว่า “ไม่มีมูลค่า” ทั้งที่ “มูลค่า” ของการแก้บั๊กในซอฟต์แวร์นั้นเป็นเรื่องอัตวิสัยมาก หน้าที่ของวิศวกรคือแก้บั๊ก แบรนด์ก็สำคัญ แต่แบรนด์ใหญ่ในวันนี้กลับเมินมูลค่าของแบรนด์ตัวเอง อาจเพราะผู้บริโภคไม่ค่อยเปลี่ยนไปใช้เจ้าอื่น แต่ต่อให้เปลี่ยนก็มีแต่ UI ใหม่ให้เรียนรู้เพิ่มขึ้นไปอีก (แม้แต่ Apple เองก็ไม่ได้ใช้งานได้อย่างเป็นธรรมชาติแล้ว)
โลกตอนนี้อาจยังรันบนฮาร์ดแวร์รุ่นเก่าๆ ได้อยู่ แต่ในเมื่อ CPU และฮาร์ดแวร์ยังคงเร็วขึ้นเรื่อยๆ ก็ไม่มีเหตุผลจำเป็นให้ต้องทำโค้ดให้มีประสิทธิภาพมากขึ้น
ปัญหาความไม่สมมาตรของข้อมูลสามารถเอาชนะได้ในผลิตภัณฑ์ FOSS หรือแบบ proprietary “shared source” เพราะถ้าดูโค้ดเองก็พอจะเห็นภาพรวมได้ว่าคุณภาพดีหรือไม่ ถึงจะหา actual bug ไม่เจอ แต่ก็พอประเมินวัฒนธรรมการพัฒนาที่มีสำนึกได้จากความยาวของฟังก์ชัน, คอมเมนต์, การตั้งชื่อ ฯลฯ ถ้าเปิดดูแล้วเจอผลิตภัณฑ์ proprietary ราคาแพงที่มี db schema เละเทะ ก็ยากจะเชื่อถือ
ซอฟต์แวร์แย่ๆ ในระยะยาวมีต้นทุนการสร้าง (และบำรุงรักษา) สูงกว่า
เพราะอย่างนี้จึงมีการพูดว่าแบรนด์ทำหน้าที่เป็นผู้พิทักษ์คุณภาพ
เช่นเดียวกับที่กฎหมายห้ามขายอาหารมีพิษ หมดอายุ หรือใส่สารเสพติด ซอฟต์แวร์ก็ควรถูกกำกับดูแลเช่นกัน แต่ก่อนมี GDPR กฎระเบียบแทบไม่มีความหมาย และแม้ตอนนี้ การละเมิดก็ยังเป็นเรื่องปกติ
พลังการประมวลผลเพิ่มขึ้นราว 1000 เท่านับจากปี 1980 ถ้าสมมติว่าการตรวจขอบเขตของ dynamic array ทำให้ช้าลง 5% (ซึ่งจริงๆ น้อยกว่านั้นมาก) ต่อให้เปิดการตรวจนี้ไว้ เราก็ยังได้ใช้คอมพิวเตอร์ที่เร็วขึ้น 950 เท่า ถ้าย้อนกลับไปปี 1980 แล้วให้เลือกระหว่าง “คอมพิวเตอร์ที่เร็วขึ้น 950 เท่า มีบั๊กน้อยลง และดีบักง่ายขึ้น” กับ “คอมพิวเตอร์ที่เร็วขึ้น 1000 เท่า แต่ยังมีบั๊กเยอะและดีบักยากกว่าเดิม” คนส่วนใหญ่คงเลือก 950 เท่า แต่สุดท้ายเราเลือก 1000 เท่า ส่วนตัวฉันคิดว่าพวก 1000xers ทำให้สถานการณ์พัง
แต่ประสิทธิภาพ 1000 เท่านั้นไม่ได้สูญไปกับการตรวจขอบเขต มันถูกเผาทิ้งไปกับชั้นนามธรรมที่ไม่มีที่สิ้นสุดและความไร้ประสิทธิภาพต่างหาก
ฉันเคยบังคับให้ซัพพลายเออร์เอาซอฟต์แวร์ช้าๆ และเต็มไปด้วยบั๊กของเขาไปรันบน Sparc 20 ผลลัพธ์คือเขาต้อง optimize ซอฟต์แวร์ และนั่นกลายเป็นพื้นฐานที่ทำให้บริษัทประสบความสำเร็จในตลาด การ optimize คือความได้เปรียบในการแข่งขัน
จะพูดแบบนั้นได้ก็เฉพาะหลังปี 1980 เท่านั้น ถ้าสรุปจากวิดีโอล่าสุดคือ “คอมพิวเตอร์ทุกวันนี้ไม่ได้เร็วไปกว่าคอมพิวเตอร์เมื่อ 20 ปีก่อนมากนัก เว้นแต่จะมีการ optimize โดยเฉพาะ” แม้ผู้เขียนจะมองข้ามอย่าง compiler optimization แต่ในความเป็นจริง การเพิ่มขึ้นของประสิทธิภาพน้อยกว่าที่คิดมาก และตลอด 15 ปีเพิ่มขึ้นแค่สองเท่าเท่านั้น
บอกว่าการตรวจขอบเขตของ array มีต้นทุนแค่ 5% แต่ไม่ใช่ทุกอัลกอริทึมจะเรียบง่ายขนาดนั้น ขึ้นกับจำนวนรอบประมวลผล แค่ใส่การตรวจเข้าไปก็อาจทำให้ต้นทุนเพิ่ม 3-4 เท่าได้ ในบางงาน ถ้าบังคับให้มีการตรวจแบบนี้ ภาษานั้นอาจเสียความสามารถในการแข่งขันไปเลย ในกรณีส่วนใหญ่คงไม่เป็นไร แต่ฉันเห็นว่าควรแยกเป็นโหมดปลอดภัย/โหมดทั่วไปจะดีกว่า
ถ้าคิดแค่เรื่องการตรวจขอบเขตอย่างเดียว ต้นทุนอาจต่ำ แต่ overhead ของภาษาแบบปลอดภัยนั้นสูงกว่ามาก ภาษาแบบ GC อาจกินหน่วยความจำเพิ่มหลายเท่า
อย่าลืมกฎของจำนวนมาก ประสิทธิภาพลดลง 5% ในระบบเดียวอาจไม่ใช่เรื่องใหญ่ แต่ถ้าความสูญเสีย 5% นี้สะสมทั่วทั้งสภาพแวดล้อมการประมวลผลของโลก ผลกระทบจะมหาศาล
ฉันเห็นด้วยกับธรรมชาติของมนุษย์ที่ชอบผลประโยชน์ระยะสั้น แต่การตรวจขอบเขตแบบไดนามิกไม่ได้แก้ปัญหาด้านความปลอดภัยโดยตัวมันเอง เรายังไม่มีคำตอบสุดท้ายอยู่ดี
ต้นตอแท้จริงที่เรามาอยู่ในสภาพนี้ ก็เพราะเราถูกผูกติดกับเบราว์เซอร์
คำตอบแรกแทบจะเป็นคำตอบที่ถูกต้องอยู่แล้ว แค่ C ยังถูกใช้อย่างแพร่หลายก็บอกชัดว่าปัญหาหลักคือประสิทธิภาพที่หายไปในชั้นล่างของสแต็ก
ตัวเลข “5%” ฟังดูไม่มีหลักฐานชัด ไม่แน่ใจว่าอิงต้นทุนจากอะไร ถ้าต้องตรวจทุกครั้งที่ใส่ค่าเข้า array จริงๆ ก็สงสัยว่าต้นทุนอาจเกินสองเท่าด้วยซ้ำ
ปัจจุบันภาษาโปรแกรมส่วนใหญ่รองรับการตรวจขอบเขต array โดยปริยายอยู่แล้ว
มันทำให้นึกถึงตอน Node.js ออกมาใหม่ๆ ข้อดีใหญ่คือเชื่อมการเขียนโค้ดฝั่ง client และ server เข้าด้วยกัน แต่ตอนนี้มันกลายเป็นฝันร้ายด้านความปลอดภัยไปแล้ว ดังนั้น ภาษามินิมัลที่มี code base เล็กก็มีข้อดีเหมือนกัน
ถ้าพวกเรารู้เร็วกว่านี้ว่าสตริงเพียงตัวเดียวสามารถเก็บข้อมูลระดับกิกะไบต์ได้ ก็อาจเลิกใช้ null-terminated string ไปนานแล้ว และทุกคนคงเจ็บปวดน้อยกว่านี้
คนที่ได้สนุกกับผลิตภัณฑ์เร็วขึ้น 1000 เท่า หรือพวก 1000Xers จริงๆ แล้วมีน้อยมาก ซอฟต์แวร์เดสก์ท็อปที่ผู้ใช้ทั่วไปเจอยังคงช้าอยู่ดี
จริงๆ มันเร็วขึ้นราว 100,000 เท่า คลอกอย่างเดียวก็ 1000 เท่า คอร์ก็ 10 เท่า คำสั่งเองก็มี AVX ฯลฯ อีก 10 เท่า รวมเชิงสถาปัตยกรรมแล้วเร็วขึ้น 1-2 ล้านเท่า แต่แทบไม่ส่งผลต่อความเร็วที่ผู้ใช้รู้สึกได้เลย
มีการยกคำพูดของ Robert Barton ที่เรียกคนพวกนี้ว่า “มหาปุโรหิตแห่งลัทธิชั้นต่ำ”
ถ้ามองตั้งแต่ 1980 ก็เร็วขึ้นมาก แต่ถ้ามองตั้งแต่ 2005 ก็เพิ่มขึ้นแค่ราว 5 เท่า
คลอก 2000 เท่า บวก SIMD และ IPC อีก 80 เท่า พอคูณจำนวนคอร์เข้าไปก็จบที่เร็วขึ้น 1-2 ล้านเท่า แต่โปรแกรมส่วนใหญ่ผู้เขียนกลับคิดแค่ว่า “ถ้ามันทำงานได้ ก็นั่นคือความเร็วของมัน” มีคนน้อยมากที่คิดเรื่อง optimization จริงจัง แม้ในหมู่ผู้ใช้ HN ก็เหมือนกัน
ในปี 2001 เราควรกำหนดให้ CPU 1GHz เป็นเกณฑ์สำหรับการรันซอฟต์แวร์พื้นฐาน ประสบการณ์กับ AI ก็น่าผิดหวังมากเช่นกัน ฉันคาดหวังว่า LLM ควรทำเรื่องอย่างการแปลงภาษา การ optimize โค้ด ฯลฯ ได้สบาย แต่ความจริงไม่ใช่เลย ฉันเคยให้ AI พอร์ตโค้ด Unix
sedไปเป็นภาษาใน JVM ด้วย มันทำได้แค่พื้นฐานเกินๆ ส่วนระดับกลางขึ้นไปล้มเหลวทั้งหมด สุดท้ายกระแสทั้งหมดนี้มีเป้าหมายคือ “ลดงานคน” ไม่ใช่ยกระดับคุณภาพซอฟต์แวร์ AI จะสร้างซอฟต์แวร์แย่ๆ เพิ่มขึ้นอีกมากในอนาคตนี่แหละคือ JavaScript และอนาคตของผู้ใช้
การทำงานที่ Google (และ Facebook) ทำให้ฉันตระหนักว่าฮาร์ดแวร์ราคาถูกแค่ไหน และการ optimize โค้ดนั้นส่วนใหญ่ไม่มีมูลค่า เมื่อกว่า 10 ปีก่อน Google จำเป็นต้องบริหารทรัพยากรดาต้าเซ็นเตอร์ และแต่ละโปรเจกต์มีงบประมาณ มีการแลกเทียบต้นทุนสัมพัทธ์ระหว่าง CPU, HDD, flash ฯลฯ แม้ flash จะแพงกว่า hard ถึง 20 เท่า แต่เมื่อดูคอขวดจริงแล้ว บ่อยครั้ง flash กลับถูกกว่า ทรัพยากรเหล่านี้ถูกแปลงค่าเป็นเวลาของวิศวกรซอฟต์แวร์ด้วย (1 SWE = 1 คน 1 ปี) ถ้าการ optimize ไม่สามารถประหยัด CPU core ได้เกิน 5000 คอร์ ก็กลับไม่คุ้ม มีความหมายเฉพาะกับโปรเจกต์ใหญ่มากเท่านั้น นอกนั้นโค้ดก็ถูกแทนที่อย่างรวดเร็วอยู่ดีจึงไม่คุ้ม optimize อีกอย่าง ในแง่การใช้งาน Web อินเทอร์เฟซแบบเมาส์นั้นไร้ประสิทธิภาพมาก ขณะที่เทอร์มินัลแบบข้อความเมื่อ 30-40 ปีก่อนมีประสิทธิภาพกว่ามาก ฉันเคยหวังว่า “เมื่อเว็บเป็นมาตรฐานแล้ว เราจะก้าวไปสู่ขั้นต่อไป” แต่ก็ไม่เกิดขึ้น ทุกสัปดาห์ยังมี framework ใหม่ออกมา และยังถึงขั้น reimplement แถบเลื่อนเดิมให้ไม่เข้ากับฮาร์ดแวร์อีกด้วย ฉันไม่รู้ทางออกของปัญหานี้จริงๆ
ฉันมองว่านี่เป็นการตัดสินใจที่ใช้ได้เฉพาะบริษัทที่ต้นทุนวิศวกรรมสูง มาร์จินมาก และมีหลายโปรเจกต์เท่านั้น ถ้ามีกำไรเหลือจริงๆ แม้เพียงเล็กน้อย ก็ควรเอาวิศวกรไป optimize แทน ในโลกจริง แต่ละบริษัทเอาแต่เลียนแบบ Google จึงตัดสินใจแบบไม่เกี่ยวกับตรรกะทางเศรษฐศาสตร์ และสิ่งนี้อธิบายปัญหาได้หลายอย่าง
ฉันก็เคยอยู่ Google เช่นกัน Google มักพูดเรื่อง optimization ตามการใช้ CPU แต่ความจริงมีสองเรื่องที่ให้ความสำคัญมาก — latency และอัตราการใช้งาน server โดยรวม ทั้งสองอย่างเป็น KPI สำคัญขององค์กรระดับบน จึงทุ่มทรัพยากรวิศวกรรมลงไปมหาศาล ยิ่งมีเครื่องมากก็ยิ่งไม่อยากปล่อยให้ว่าง และธุรกิจที่อ่อนไหวต่อ latency ก็พยายามลดลงแม้เพียงไม่กี่ ms
มาตรฐานแบบ Google ใช้ได้เพราะเป็นบริษัทที่ต้นทุนต่อ core สูง สำหรับบริษัททั่วไปส่วนใหญ่ไม่เกี่ยวอะไรเลย วิธีคิดแบบนี้ใช้ได้เฉพาะระดับ Facebook/Google/Netflix เท่านั้น
ที่ Google คิดค้น compression ที่ดีกว่าและ binary serialization format ใหม่ๆ ก็เพื่อเพิ่มความสามารถทำกำไรของตัวเอง
ตอนเห็นพาดหัวบทความ ฉันคิดว่า Carmack กำลังวิจารณ์การ optimize ซอฟต์แวร์บนฮาร์ดแวร์สมรรถนะต่ำ แต่จริงๆ ไม่ใช่ เขากำลังพูดถึงการทดลองทางความคิดว่าถ้าความก้าวหน้าของฮาร์ดแวร์หยุดลงจะเป็นอย่างไร และสรุปว่า “ถ้าไม่มีคอมพิวติ้งราคาถูกและขยายขนาดได้ นวัตกรรมของผลิตภัณฑ์ก็จะลดลง”
เป็นเรื่องที่เชื่อมกับเธรดเมื่อวาน
สำหรับข้อสรุปที่ว่า “หากไม่มีคอมพิวติ้งราคาถูกและขยายขนาดได้ นวัตกรรมจะลดลง” ในความจริงแล้ว หลังยุคสมาร์ตโฟนเราแทบไม่มีนวัตกรรมอะไรอีก และเมื่อทุนพึ่งพาแต่ความก้าวหน้าของฮาร์ดแวร์ สินค้าใหม่ก็ไม่ได้ต่างจากของเดิมอย่างมีนัยสำคัญอีกต่อไป
ส่วนตัวฉันไม่เห็นด้วยกับข้ออ้างนั้น ต่อให้หยุดพัฒนาฟีเจอร์ไปพักหนึ่ง พอเตรียมตัวพร้อมแล้วนวัตกรรมก็จะกลับมาได้ อาจมีช่วงขาลง แต่ไม่ใช่เรื่องถาวร
แก่นสำคัญคือ “ความเทอะทะ” หรือ bloat ไม่ได้เป็นแค่ความสูญเปล่า แต่เกิดจากแรงจูงใจทางเศรษฐกิจในการเพิ่มผลิตภาพการพัฒนา การใช้ภาษาที่ซับซ้อนน้อยกว่าช่วยเพิ่มผลิตภาพได้ จึงช่วยให้จ้างคนน้อยลงและลดต้นทุนได้
ถ้ายืดอายุฮาร์ดแวร์ออกไปจากการหมดอายุแบบวางแผนไว้ได้อีก 5 หรือ 10 ปี ก็จะลดทั้งขยะอิเล็กทรอนิกส์ การใช้แร่หายาก และการปล่อยก๊าซเรือนกระจกได้มหาศาล แต่ตลาดซอฟต์แวร์ไม่ได้แบกรับต้นทุนจากผลกระทบภายนอกเหล่านี้ การปล่อยของแล้วค่อยทดสอบ แก้ไข และทำซ้ำ มีต้นทุนถูกกว่าการออกแบบระยะยาวมาก อุตสาหกรรมเกมบางส่วนเจอสูตรที่ทำให้ประสิทธิภาพสูงพร้อมรายได้สูงได้แล้ว แต่ยังไม่แพร่หลาย ซอฟต์แวร์องค์กรและซอฟต์แวร์ผู้บริโภคโดยทั่วไปสนใจแค่ข้อกำหนดขั้นต่ำที่ผู้ใช้ “ยังทนได้” มากกว่าจะสนใจประสิทธิภาพ การเพิ่มฟีเจอร์ใหม่และการเปลี่ยนแปลงต่อเนื่องทำให้ดูแลเรื่องประสิทธิภาพได้ยาก และงบประมาณก็มักเผื่ออัตราความผิดพลาดไว้ ต่างจากแนวทางที่ปล่อยของในสภาพ “พร้อมกว่า” เพราะมีความซับซ้อนและความเสี่ยงจากการเปลี่ยนแปลงสูงกว่า
ตลอดกว่า 10 ปีที่ผ่านมา เรารัน matching engine ของตลาดซื้อขายทั้งระบบบน single thread เพราะอย่างน้อยในส่วนการประมวลผลธุรกรรมแบบ serialized นั้น พลังการประมวลผลไม่ได้โตเร็วขนาดนั้น ถ้าไม่ได้ระดับหลายล้าน TPS ก็ไม่จำเป็นต้องขยายเป็นคลัสเตอร์ด้วยซ้ำ กลับกัน การออกแบบให้เรียบง่ายและทำงานบนเครื่องเดียวได้เป็นทางเลือกที่ดีกว่า
เรื่องนี้น่าหงุดหงิดมาก สถาปนิกระบบจำนวนมากทำระบบให้ซับซ้อนขึ้นเพื่อสลักตัวตนของตัวเองลงไป และก็สร้างปัญหาใหม่เพิ่มเท่านั้น ทั้งที่ดีไซน์เดิมก็รองรับความต้องการส่วนใหญ่ได้อยู่แล้ว และด้วยพลังประมวลผลในเครื่องปัจจุบัน การทำงานบนเครื่องเดียวก็สบายๆ
ฉันสงสัยว่าทำไมการจับคู่คำสั่งซื้อถึงทำแบบขนานไม่ได้ — ถ้าใช้การย่อ log คล้ายการ sort จะทำให้ประมวลผลแบบขนานได้หรือไม่ หรือเป็นเพราะกระบวนการ matching แทบไม่มีการคำนวณอื่นนอกจากการ sort อยู่แล้ว
ถ้าเป็นงานประมวลผลง่ายๆ ก็ทำ single thread ได้ แต่ถ้าต้องมีการคำนวณซับซ้อนในแต่ละธุรกรรมก็ทำไม่ได้ เพียงแต่ฉันไม่มีความรู้โดเมนพอจะนึกออกว่าการประมวลผลที่ซับซ้อนขนาดนั้นในงานจริงคืออะไร
ถ้าเครื่องมือพัฒนายังคงก้าวหน้าต่อไป ในอดีตเราสร้าง native GUI แบบสมบูรณ์ได้ง่ายด้วย RAD แต่วันนี้ Electron กลายเป็นกระแสหลัก แถมยังกลายเป็นสภาพที่มีเว็บเบราว์เซอร์หลายตัวติดตั้งอยู่แยกกันในรูปของ Chromium ดัดแปลง
สุดท้ายแล้วนี่คือปัญหาเศรษฐศาสตร์ของการจัดสรรทรัพยากร ว่าจะให้เวลานักพัฒนาไปกับการ optimize ซอฟต์แวร์ หรือให้ไปสร้างฟีเจอร์ใหม่ ถ้าอย่างหลังทำเงินได้มากกว่า บริษัทก็จะทำแบบนั้น ในทางกลับกัน ถ้า optimization สำคัญกว่า ก็จะปรับพฤติกรรมตามนั้น
ฉันเห็นด้วยว่าเป็นเรื่องเศรษฐศาสตร์ แต่แก่นแท้คือมันเป็นกรณีที่บริษัทซอฟต์แวร์ผลักภาระผลกระทบภายนอกเชิงลบไปให้สังคมโดยรวม พวกเขาไม่สนใจการใช้พลังงานเพิ่ม ความสูญเปล่า หรือขยะอิเล็กทรอนิกส์ที่มากขึ้น
มันคือโครงสร้างที่ผลักหนี้ทางเทคนิคและหนี้ทางการเงินไปให้คนอื่น พร้อมกับเพิ่มขยะมหาศาล แม้หลายกรณี optimization อาจไม่คุ้มจริง แต่ธรรมเนียมการเพิ่มแค่ server เข้าไปเรื่อยๆ ก็ชวนเสียดาย
เรื่อง “เพิ่มฟีเจอร์สำคัญกว่า” ก็แล้วแต่กรณี ฉันแทบไม่ใช้ฟีเจอร์ใหม่ส่วนใหญ่ใน macOS, Windows, Android รุ่นใหม่ๆ และให้ความสำคัญกับสภาพแวดล้อมที่มีประสิทธิภาพและปลอดภัยมากกว่า กับซอฟต์แวร์ออกแบบเองก็อยากได้การปรับปรุงประสิทธิภาพมากกว่าฟีเจอร์ใหม่ๆ บางครั้งยังอยากได้ Illustrator/Photoshop แบบเมื่อ 10 ปีก่อนด้วยซ้ำ ซอฟต์แวร์ทำเพลงนั้นฟีเจอร์ใหม่ช่วยเติมเต็มความต้องการได้จริง แต่ถ้าทำลายประสิทธิภาพฉันก็ไม่ชอบ ตัวแก้ไขโค้ดแค่ VSCode ก็พอแล้ว และก็อยากให้มันเร็วและเบากว่านี้
ในชีวิตฉัน การทำให้มีประสิทธิภาพเป็นเรื่องสำคัญมาก เช่น เวลาเดินไปหยิบของในครัว ฉันจะถือขยะหรือจานไปด้วยเสมอเพื่อไม่ต้องเดินสองรอบ ซอฟต์แวร์ก็คล้ายกัน แต่ระหว่าง “ทุ่มเวลาวิศวกรราคาแพงไป optimize” กับ “เพิ่ม RAM/ทรัพยากร” อย่างหลังถูกกว่าเสมอ จะคุ้ม optimize ก็ต่อเมื่อปัญหาใหญ่พอ ตลาดจะเป็นผู้ตัดสินสุดท้ายว่าทางเลือกไหนให้ประโยชน์มากกว่า ถ้าวันหนึ่งประโยชน์จากการเพิ่มฮาร์ดแวร์ลดลง ก็จะหันกลับมา optimize เอง กฎของมัวร์ยังไม่ชนเพดานจริงๆ จึงยังไม่เกิดจุดนั้น
ท้ายที่สุดก็เป็นเรื่องอุปสงค์ ถ้าผู้บริโภคให้ความสำคัญกับซอฟต์แวร์ที่เร็วกว่า พวกเขาก็จะยอมจ่ายเพิ่ม แต่ในความเป็นจริง ถ้าประสิทธิภาพแย่ลงแต่ราคาถูกกว่า คนก็มักเลือกทางนั้น
นี่แหละคือความหมายของ “enshitification”
แอป Electron แม้จะถูกบ่นเรื่องประสิทธิภาพมาก แต่ก็เป็นนวัตกรรมสำคัญที่ทำให้ทนสภาพแวดล้อมการทำงานบนแล็ปท็อปลินุกซ์ได้ เช่น เข้าประชุม Teams ได้ง่ายโดยไม่ต้องติดตั้งอะไร ต่อให้ทุกคนโหยหาการ optimize โค้ดแบบ Winamp ความสะดวกในการเข้าถึงของแอป Electron ก็ยังใช้งานได้จริง
ช่วงนี้ฉันเล่นเกม Balatro แล้วรู้สึกว่า แม้ทุกวันนี้จะเป็นเกมที่ต้องคำนวณง่ายๆ และกราฟิกเรียบๆ เท่านั้น แต่สเปกขั้นต่ำที่ต้องการกลับสูงขึ้นเรื่อยๆ ทั้งที่มันน่าจะรันได้บนฮาร์ดแวร์ยุค 90 อย่าง Pentium II + 3dfx ได้สบาย จึงน่าตกใจที่ต้องการสเปกระดับโน้ตบุ๊กสมัยใหม่