บิลด์ Windows ของ SciPy สำหรับ Python 3.12 ถูกยกให้เป็นปาฏิหาริย์เล็ก ๆ

• บิลด์ SciPy บน Windows ของ conda-forge ถูกปล่อยออกมาภายในสองวันหลังการออก Python 3.12.0 ทำให้การย้าย SciPy ไปยัง Python 3.12 ล่าช้าเพียงไม่กี่วัน แทนที่จะหยุดชะงักนานหลายเดือน
• เมื่อ distutils ถูกถอดออกจากไลบรารีมาตรฐานใน Python 3.12 ทาง SciPy จึงตัดสินใจย้ายจาก numpy.distutils ไปใช้เครื่องมือบิลด์ Meson
• Meson กำลังจะปฏิเสธชุดคอมไพเลอร์ MSVC+gfortran ที่ conda-forge ใช้อยู่ และบน Windows ก็ไม่มี Fortran compiler แบบฟรีที่เข้ากันได้กับ ABI ให้ conda-forge ใช้งาน
• conda-forge คาดว่า หากไม่สามารถบิลด์ SciPy บน Windows ใหม่ได้ การย้ายแพ็กเกจอย่างน้อยราว 1,000 ตัวที่พึ่งพา SciPy จะล่าช้าบนทุกแพลตฟอร์ม หรือไม่ก็ต้องตัด Windows ออกจากการย้าย Python
• LLVM 17.0 เป็นรีลีสแรกที่ลบแฟลก -flang-experimental-exec ออกจาก Flang และคาดว่า Flang มีระดับความพร้อมประมาณ “0.8 level maturity”
• หลังเพิ่มการรองรับ llvm-flang ให้ Meson ก็สามารถบิลด์และติดตั้ง SciPy ได้สำเร็จ โดยผลทดสอบคือ 54,987 passed, 2,866 skipped, 245 xfailed, 11 xpassed, 1 warning และผ่านครบ 100% {p:100}

[GN⁺]

ความคิดเห็นจาก Hacker News

• เป็นบทความที่ยอดเยี่ยมจริง ๆ และตอนนี้ก็เข้าใจแล้วว่าทำไม pip install ถึงล้มเหลวใน Python 3.12 แต่จากนี้ไปดูเหมือนอนาคตจะสดใสขึ้น
  ผมชอบ Python แต่บทความนี้ยังช่วยให้เข้าใจด้วยว่าทำไมการแพ็กเกจของ Python ถึงเป็นความวุ่นวายที่ยังพอจัดการได้
  สาเหตุไม่ได้อยู่ที่ตัว Python เอง แต่อยู่ที่ความไม่เป็นมาตรฐานของเครื่องมือ build สำหรับ C/C++/Fortran และขนาดมหึมาของ ecosystem ซึ่งเป็นความซับซ้อนที่ลดทอนไม่ได้ในระดับหนึ่ง
  แค่สิ่งนี้ทำงานได้ก็แทบจะเป็นปาฏิหาริย์แล้ว

  • ใช่เลย เหตุผลพื้นฐานที่การแพ็กเกจของ Python ซับซ้อนอยู่ตรงนั้น
    ความสำเร็จของ Python ส่วนใหญ่เกิดจากการที่สามารถใช้ แพ็กเกจแบบผสมหลายภาษา ที่สำคัญได้ และตัวจัดการแพ็กเกจของภาษา mainstream อื่น ๆ แทบไม่ต้องรับมือกับปัญหาแบบนี้
    ตัวอย่างเช่น cargo ของ Rust นั้นยอดเยี่ยม แต่ส่วนใหญ่สามารถสมมติได้ว่าแพ็กเกจเป็นโค้ด Rust ล้วน และแม้จะเป็นภาษาที่ต้องคอมไพล์ แต่ภาษาก็ “เป็นเจ้าของ” คอมไพเลอร์เอง ทำให้กลยุทธ์การแจกจ่ายแบบ build จากซอร์สใช้ได้ผล
    ผมไม่รู้ว่า cargo จัดการ Fortran เป็นค่าเริ่มต้นอย่างไร แต่ถ้าแพ็กเกจ cargo ชั้นนำบน Windows ต้องใช้โค้ด Fortran ก็คงยากที่จะทำงานได้ราบรื่น
    การปรับปรุงครั้งใหญ่ที่สุดของ ecosystem Python คือการทำให้ wheel ซึ่งเป็นรูปแบบแพ็กเกจแบบไบนารีกลายเป็นมาตรฐาน และนับแต่นั้น ecosystem Python สายวิทยาศาสตร์จึงเริ่มเติบโตบน Windows อย่างจริงจัง
    อย่างไรก็ตาม ความเข้ากันได้ของไบนารีเป็นเรื่องปวดหัวมหาศาล โดยเฉพาะเมื่อต้องข้ามทั้งภาษาและ CPU
  • จะบอกว่าไม่เกี่ยวกับ Python ก็ไม่ได้ เพราะเหตุผลที่มี FFI binding แบบนี้อยู่ ก็เพราะ Python ช้าเกินไป
  • เห็นด้วยกับประโยคที่ว่า “แค่สิ่งนี้ทำงานได้ก็แทบจะเป็นปาฏิหาริย์แล้ว”
    ความซับซ้อนของ ecosystem ซอฟต์แวร์ดูเหมือนจะเพิ่มขึ้นแบบเอ็กซ์โปเนนเชียล และก็สงสัยว่าอะไรคือสิ่งที่ป้องกันไม่ให้ท้ายที่สุดมันกลายเป็น การล่มสลายแบบหอบาเบล
    แน่นอนว่านี่ไม่ใช่ปัญหาเฉพาะซอฟต์แวร์เท่านั้น แต่เป็นตัวอย่างที่ดี
  • เป็นบทความที่เปิดหูเปิดตามากจริง ๆ
    ผมเห็นบ่อย ๆ ว่าคนเอาตัวจัดการแพ็กเกจที่ตัวเองชอบไปเทียบกับของ Python แล้วสรุปว่า Python แย่มาก แต่ในความเป็นจริงไม่ใช่อย่างนั้น
    อย่างเดียวที่ยังไม่ค่อยเข้าใจคือ ทำไมฝั่ง Python ถึงไม่ใช้ ไลบรารีคณิตศาสตร์ C/C++ แทน Fortran
  • ปัญหาจริง ๆ ดูเหมือนจะอยู่ที่ Python มีแนวโน้มดึงดูด คนที่ไม่ได้ผ่านการฝึกฝนด้านการพัฒนาซอฟต์แวร์ เข้ามา
    กลายเป็นความยุ่งเหยิงซ้อนทับบนความยุ่งเหยิงอีกชั้น

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

  • จริง ๆ แล้วพวกเขาไม่ได้จำเป็นต้องทำเองเสมอไป
    อย่างที่มีการพูดถึงหลายครั้ง นักพัฒนา SciPy เป็นอาสาสมัคร
    เนื้อหาส่วนใหญ่ของเรื่องอธิบายว่าทำไม SciPy จึงทำได้เพียงหวังว่าจะมีใครสักคนสร้างคอมไพเลอร์ Fortran แบบโอเพนซอร์สสำหรับ Windows ให้ และดูเหมือนว่าผู้กอบกู้ส่วนใหญ่คือ นักพัฒนา NVIDIA
  • แม้แต่นั่นก็ไม่ใช่ประเด็นหลัก
    SciPy กำลังจ่ายราคาจากการตัดสินใจที่โง่เขลาและลำเอียงอย่างมากของนักพัฒนาหลัก Python ที่เลือก MSVC แทน MinGW เป็น toolchain สำหรับ Python บน Windows
    ผมมองว่าแรงจูงใจนั้นมาจากการสนับสนุนของ Microsoft
    ในรายชื่อนักพัฒนาหลักมีพนักงาน Microsoft อยู่ไม่น้อย พวกเขาได้รับค่าตอบแทนจาก Microsoft เพื่อเข้าร่วมในรายชื่อนั้น และนอกจากนี้ Microsoft ยังออกค่าใช้จ่ายเซิร์ฟเวอร์ CI ของโปรเจกต์ CPython ด้วย
    ถ้า Python ไม่ใช้เครื่องมือกรรมสิทธิ์ใน toolchain ปัญหาทั้งหมดนี้ก็คงหลีกเลี่ยงได้

• ที่บอกว่า “Meson พยายามปฏิเสธชุดผสม MSVC+gfortran ที่ใช้กันใน conda-forge” ฟังดูเหมือนบั๊ก
  ผมมองว่าเป้าหมายของ เครื่องมือบิลด์ คือการรันคำสั่งที่ถูกสั่ง ไม่ใช่มาขวางแบบ “ขอโทษนะ Dave”

  • จริง ๆ แล้วฝ่ายที่บ่นคือ MSVC linker
    ปัญหาคือ C runtime ที่ MSVC กับ gfortran ใช้นั้น โดยเฉพาะไลบรารี runtime ของ gfortran เองที่เขียนด้วย C ไม่ได้เข้ากันได้ในระดับ ABI
    วิธีเลี่ยงที่ NumPy เคยใช้คือการลิงก์อ็อบเจ็กต์ Fortran เป็น DLL เพื่อเพิ่มชั้นอ้อมที่เรียกว่า import library แล้วปลอบ MSVC ให้ยอม
    ดังนั้นจึงต้องมีงานเพิ่มเติมเพื่อสร้าง DLL แบบนี้
    จะทำในไฟล์คำอธิบายการบิลด์หรือใน Meson ก็ต้องทำอยู่ดี แต่ฝั่ง SciPy ไม่อยาก implement ชั้นอ้อมนี้ในทางใดทางหนึ่ง และนักพัฒนา Meson ก็ไม่ได้อยากช่วยอย่างแข็งขัน
    แน่นอนว่านักพัฒนา Meson ช่วยเรื่องทั่วไปอย่างการรองรับ Fortran และ Cython แต่ไม่อยากจัดหาแท่นเหยียบที่อันตราย
    ในทางปฏิบัติมันแทบจะเป็นการแฮ็ก และตัวอย่างเช่น มันทำงานได้ก็เพราะฝั่ง Fortran ไม่ได้ใช้ไฟล์ที่เปิดจากฝั่ง Python/C
    https://web.archive.org/web/20180711144501/https://pav.iki.f...
  • บทความเขียนได้ดีและละเอียด แต่ผมแปลกใจนิดหน่อยกับคำกล่าวที่ว่า Meson “ถูกใช้กันอย่างแพร่หลายในโปรเจกต์ C และ C++”
    โดยส่วนตัวผมเห็น Bazel บ่อยกว่า Meson
    Meson เขียนด้วย Python เลยน่าจะดูเป็นตัวเลือกที่ดีสำหรับ SciPy และสุดท้ายก็จบได้ด้วยดี ก็ต้องยินดีด้วย
    ถึงอย่างนั้น แม้จะมีความประหลาด ความซับซ้อน และปัญหาหลายอย่าง ผมยังมองว่า CMake ยังค่อนข้างใกล้เคียงมาตรฐานอยู่ดี
  • Meson ทำมากกว่าแค่รันคำสั่งที่ผู้ใช้สั่ง
    มันยังสามารถประกอบคำสั่งขึ้นมาเองเพื่อรองรับ MSVC/gcc/clang ได้ด้วย
    ถ้าขอให้มันประกอบคำสั่งสำหรับชุดผสมที่ไม่รู้จัก ก็แน่นอนว่ามันทำได้แค่พูดว่า “ขอโทษนะ Dave”
  • เห็นด้วย
    ขอเปิดเผยไว้ก่อนว่าผมเป็นผู้เขียน ระบบบิลด์คู่แข่งของ Meson ที่จะเปิดตัวเร็ว ๆ นี้
    แต่ rant เล็ก ๆ ที่ไม่ค่อยมีคนรู้จักชิ้นหนึ่ง [1] นี่แหละที่ทำให้ผมตระหนักถึงสิ่งที่เพิ่งพูดไป
    สรุปคือ build system ควรรันคำสั่งที่ผู้ใช้บอกให้รัน แค่นั้น
    เพราะบางครั้งโปรแกรมเมอร์ก็รู้จริง ๆ ว่าตัวเองกำลังทำอะไรอยู่
    น่าอายที่ก่อนอ่านคอมเมนต์นั้น ผมเคยคิดจะทำ build system ของตัวเองให้เหมือนมีเวทมนตร์
    แต่หลังจากอ่านคอมเมนต์นั้น ผมก็เข้าใจว่าสิ่งที่ทำให้ผู้คนเกลียด build system ก็คือ “เวทมนตร์” นั่นเอง
    [1]: https://ofekshilon.com/2016/08/30/cmake-rants/#comment-29273

• นึกว่าเรื่องแบบนี้ทุกคนก็ใช้ WSL2 แล้วจบไปแล้วเสียอีก
  ทำไมถึงต้องพยายามบิลด์เวอร์ชัน native Windows ด้วย?

  • นั่นก็เหมือนถามนักพัฒนา macOS ว่าทำไมไม่เลิกอยากได้ native build แล้วไปทำงานบน Linux virtual machine ล่ะ
    การทำงานใน virtual machine ไม่สะดวกและ การผสานรวม ก็แย่กว่า
  • มีนักวิจัยจำนวนมากกว่าที่คิดมากที่ใช้ Windows
    นักศึกษาก็เช่นกัน
  • องค์กรขนาดใหญ่ ที่แทบเป็นไปไม่ได้จะได้เครื่องที่ไม่ใช่ Windows ก็น่าจะเป็นกลุ่มผู้ใช้สำคัญ
  • การที่ Microsoft กับ NVIDIA แก้ปัญหา CUDA driver บน WSL2 ให้ได้ นี่เหมือนช่วยชีวิตจริง ๆ
    โดยเฉพาะเมื่อสามารถใช้ Docker Desktop บนนั้นได้ด้วย
    ถือเป็นการรีดสิ่งที่ดีที่สุดออกมาจากสถานการณ์ที่ไม่สมบูรณ์แบบ

• καταστροφή ตรง κατα ไม่ได้หมายถึง “ความฉับพลัน” แต่ใกล้กับ “ลงข้างล่าง” หรือ “ตาม” มากกว่า และมีนัยแรงว่าหักเหไปในทิศทางที่ไม่ดี
  คำตรงข้ามของ κατα โดยทั่วไปคือ ανα แต่ αναστροφή แปลตามตัวอักษรว่า “การหมุนขึ้น” หรือการกลับด้าน
  ดังนั้นคำประดิษฐ์อย่าง ευστροφη หรือ eustrophe ที่หมายถึง “การเปลี่ยนผ่านที่ดี” อาจจะดีกว่า
  ถึงอย่างนั้น ถ้าจะเถียงชนะ JRR Tolkien เรื่องการสร้างคำภาษาได้ นั่นก็คงเป็น ευκαταστροφη หรือโชคดีนั่นเอง
  โดยรวมแล้วชอบที่จับความรู้สึกของพระคุณอันท่วมท้นได้ และสิ่งแบบนั้นก็มอบความยินดีและความสุขให้โลก

  • kata ใน katastrofi จริง ๆ แล้วใกล้กับ “against” มากกว่า ดังนั้น katastrofi จึงเทียบได้กับการที่สิ่งหนึ่ง “หันหลังให้”

• ผมรู้สึกว่า BLAS ที่ดีที่สุดส่วนใหญ่เขียนด้วย C
  อย่าง MKL, BLIS, OpenBLAS เป็นต้น
  สงสัยเหมือนกันว่าจะไปได้ไกลแค่ไหนถ้าใช้แค่ C กับ Python
  และก็สงสัยว่าถ้าเริ่มตอนนี้ อาจเลือก libflame ไปเลยหรือเปล่า
  แน่นอนว่า SciPy ยังมีฟีเจอร์อื่น ๆ อีกมาก เช่น iterative methods, sparse matrices ดังนั้นการเลี่ยง Fortran อาจทำได้ยาก
  แต่ Fortran ก็เป็นภาษาที่ยอดเยี่ยม และดีใจที่สถานการณ์เครื่องมือบน Windows อย่างน้อยก็เริ่มดีขึ้นแล้ว

  • เคยมีการคุยกันอยู่หลายครั้งเรื่อง การเอา Fortran ออกจาก SciPy แต่เพราะเหตุผลที่พูดไปข้างต้นจึงไม่คืบหน้า
    ใน SciPy เองก็มีโค้ด Fortran อยู่มาก และถ้าจะเขียนใหม่ต้องใช้กำลังคนระดับหลายปี
    หลังจากเป็นไปได้แล้ว ส่วนแกนหลักบางส่วนที่เคยใช้ Fortran ก็ถูกเอาออกไปเหมือนกัน
    เช่นส่วนที่เกี่ยวกับ FFT
  • พูดตรง ๆ ผมไม่คิดเลยว่าจะได้เห็นประโยคว่า “Fortran เป็นภาษาที่ยอดเยี่ยม และดีใจที่สถานการณ์เครื่องมือบน Windows เริ่มดีขึ้น” ในปี 2023

• เป็นบทความที่ยอดเยี่ยม
  ปีนี้ผมใช้เวลามากไปกับการทำให้โปรเจกต์ CMake C++ ที่มี Python bindings ทันสมัยขึ้น และหลังจากเพิ่มเข้า conda-forge เป็น feedstock ใหม่ได้สำเร็จ ก็พูดได้อย่างมั่นใจว่า
  ถ้าผมได้เป็นจักรพรรดิเทพ มาตรการแรกด้าน IT ของผมคือการถอนรากถอนโคน Windows ออกไปจากทุกจักรวาลตลอดกาล

• เป็นคำถามที่ซื่อมาก ๆ แต่ semantics ของ Fortran ต่างกันขนาดที่ไม่สามารถแปลงเป็น C ก่อน แล้วค่อยคอมไพล์ด้วยคอมไพเลอร์ C ได้หรือ?
  หลังจากนั้นก็น่าจะดูแลรักษาต่อเป็น C ได้ไม่ใช่หรือ?
  ไม่น่าจะมีคนสาย Fortran ที่ดูแลไลบรารีเก่า ๆ แบบนี้มากนัก แต่ก็ยังต้องดูแลรักษาอยู่ดีไม่ใช่หรือ?

  • ถ้ายอมให้ช้าลงได้ ก็ทำได้
    Fortran ไม่มี pointer มีแค่ array และอาร์กิวเมนต์ของฟังก์ชันไม่สามารถเป็น alias กันได้ ดังนั้นถ้าพักเรื่องความน่ากลัวของบล็อก COMMON ไว้ก่อน การ optimize แบบ aggressive และการ vectorize ก็ทำได้ง่ายกว่า
    ไลบรารีคณิตศาสตร์มาตรฐานของ Fortran นั้นใช้งานได้ดีและเร็วอยู่แล้ว
    ใน C/C++ โดยเฉพาะถ้าใช้คีย์เวิร์ด restrict ของ C ก็สามารถเขียนโค้ดที่เร็วเทียบเท่าได้
    แต่ถ้าแปลงโค้ดเดิมผ่านขั้นตอน f2c ในหลายกรณี performance จะตกลงมาก
  • Fortran เป็น ภาษาระดับสูงกว่า C
    นักพัฒนา Fortran ก็มีอยู่มากพอ
    มันแย่มากสำหรับการพัฒนาแอปพลิเคชัน แต่นั่นก็ไม่ใช่พื้นที่หลักของ Fortran
  • มีของแบบนั้นอยู่แล้ว
    f2c มีมาหลายสิบปีแล้ว
  • ใช่แล้ว Fortran มี array แบบ native

• มีเรื่องเล็ก ๆ ที่สงสัยอยู่ อย่างที่ผมเข้าใจ aarch64 กับ arm64 คือสิ่งเดียวกัน
  ผมเข้าใจผิดหรือเปล่า?

  • เป็นสิ่งเดียวกัน แต่ในอดีตฝั่ง backend เคยมี implementation ของ LLVM ที่แข่งขันกันอยู่สองตัว
    [1] https://www.phoronix.com/news/MTY5ODk
  • ลิงก์จำเป็น: https://lkml.org/lkml/2012/7/15/133
  • เท่าที่ผมเห็นใน Python, aarch64 มักหมายถึง Linux ส่วน arm64 มักหมายถึง macOS ARM
    ผมไม่ได้รู้ด้านนี้ดีพอที่จะเข้าใจว่าทำไมชื่อถึงต่างกัน

• การเปลี่ยนแปลงระบบ build ของ Python ตามให้ทันได้ยากจริง ๆ
  ก็อยากรู้ตัวเลข performance บน Windows เหมือนกัน
  แต่โดยหลักแล้วอาจไม่สำคัญนัก
  เพราะงานจริงจังน่าจะรันบนเครื่อง Linux

  • โชคดีที่ตอนนี้น่าจะช้าลงแล้ว
    การเปลี่ยนผ่านครั้งใหญ่คือการทำให้ทุกคนยอมรับ PEP 517 โดยเฉพาะการย้ายโปรเจกต์ Setuptools เดิม
  • สำหรับงานคำนวณด้วย CPU ล้วน ๆ Windows ก็เร็วพอ ๆ กับ Linux
    เพราะ 99.9% ของเวลาคือการรัน โค้ดของผู้ใช้ ไม่ใช่ระบบปฏิบัติการ

[ahwjdekf]

นี่เป็นกรณีที่เผยให้เห็นอย่างชัดเจนเลยว่าเราต้องไปพึ่งพาภาษาแบบคอมไพล์เป็นไบนารีอย่างน่าเวทนาแค่ไหน

[kayws426]

แก้ได้ในฝั่ง Python แต่ในอีโคซิสเต็มอื่นยังแก้ไม่ได้ไม่ใช่หรือ? เพราะอย่างนั้นถึงต้องมีการแจกไบนารีที่คอมไพล์ไว้ล่วงหน้าไงล่ะ