GNU Octave พบกับ JupyterLite: คำนวณได้ทุกที่ทุกเวลา

 (blog.jupyter.org)
3 คะแนน โดย GN⁺ 2025-10-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Xeus-Octave เข้าร่วมระบบนิเวศเคอร์เนลของ JupyterLite แล้ว ทำให้สามารถ รันโค้ด GNU Octave ได้โดยตรงในเบราว์เซอร์
  • GNU Octave เป็น ภาษาโอเพนซอร์สสำหรับการคำนวณเชิงวิทยาศาสตร์ที่เข้ากันได้กับ Matlab และโปรเจ็กต์นี้ได้นำมันไปพอร์ตให้ทำงานบนสภาพแวดล้อม WebAssembly(WASM)
  • เพื่อแก้ปัญหาโค้ดที่อิง Fortran และ การพึ่งพา BLAS/LAPACK จึงใช้ทูลเชนแบบคัสตอมที่ผสาน LLVM Flang, Emscripten, Netlib LAPACK
  • เนื่องจาก LLVM ยังไม่รองรับ Fortran common symbol (Common Block) จึงแก้ปัญหาเฉพาะหน้าด้วย แพตช์ชั่วคราว และมีแผนรองรับอย่างเป็นทางการใน LLVM 22
  • จากนี้ JupyterLite จึงขยายการรองรับจาก R มาสู่ Octave ด้วย ถือเป็นก้าวสำคัญของ การขยายระบบนิเวศการเขียนโปรแกรมเชิงวิทยาศาสตร์บนเบราว์เซอร์

ภาพรวมของ Xeus-Octave และการพอร์ตสู่ WebAssembly

  • Xeus-Octave คือ Jupyter kernel ที่สามารถรันโค้ด GNU Octave ในเบราว์เซอร์ได้ โดยแพ็กเกจผ่าน emscripten-forge
    • GNU Octave คือ ภาษาเสรีและโอเพนซอร์ส ที่สามารถรันสคริปต์ Matlab ได้โดยตรง
    • การรวมครั้งนี้ทำให้ใช้งานได้ทันทีในสภาพแวดล้อม JupyterLite โดยไม่ต้องติดตั้งเพิ่มเติม
  • แนวทางนี้คล้ายกับ Xeus-R-Lite ที่พัฒนาก่อนหน้า โดยใช้ ทูลเชนสำหรับคอมไพล์โค้ด Fortran (LLVM Flang + Emscripten)
  • สำหรับไลบรารีพึ่งพาด้านการคำนวณทางคณิตศาสตร์ของ Octave เลือกใช้ Netlib LAPACK แทน OpenBLAS เพื่อให้การบิลด์เข้ากันได้ดีขึ้น

ความท้าทายทางเทคนิคในกระบวนการบิลด์ WebAssembly

  • เกิดข้อผิดพลาดระหว่างบิลด์ใน LLVM เนื่องจากปัญหาการรองรับ Fortran common block (Common Symbol Block)
    • Wasm streamer ของ LLVM v20 ยังไม่ได้อิมพลีเมนต์ common symbol จึงต้องมีการแก้ไขโค้ด
    • ทีม QuantStack ร่วมกับ Serge Guelton ทำ แพตช์ชั่วคราว ให้ LLVM จัดการมันเป็น weak symbol
  • การรองรับอย่างเป็นทางการมีแผนจะรวมอยู่ใน LLVM v22 release และขณะนี้ LLVM เวอร์ชันที่แพตช์แล้วเปิดเผยสำหรับ Linux
  • ตัว Octave เองก็มีการปรับแก้ให้เหมาะกับเป้าหมาย WASM เช่น ปิดใช้งานฟังก์ชัน GUI และ รวม Fortran function signature

การรวม Xeus-Octave และการสาธิต

  • หลังบิลด์เสร็จ ก็สามารถ รัน Xeus-Octave ใน JupyterLite ได้เพียงเพิ่ม recipe ของ emscripten-forge
  • Xeus-Octave สร้างอยู่บน Xeus ซึ่งเป็นเฟรมเวิร์ก Jupyter kernel ที่พัฒนาด้วย C++ ทำให้สามารถรันคำสั่ง Octave และแสดงผลภาพบนเบราว์เซอร์ได้

แผนถัดไป

  • ขั้นต่อไปคือการรวม ระบบนิเวศแพ็กเกจของ Octave เข้ากับ conda-forge และ emscripten-forge
    • มีแผนปรับยูทิลิตี pkg ของ Octave ให้เหมาะกับสภาพแวดล้อมเบราว์เซอร์ เพื่อ กำหนดกระบวนการติดตั้งภายในสภาพแวดล้อม conda
  • สิ่งนี้คาดว่าจะช่วยเสริมความแข็งแกร่งให้กับ สภาพแวดล้อมการเขียนโปรแกรมเพื่อวิทยาศาสตร์และคณิตศาสตร์บนเบราว์เซอร์ มากยิ่งขึ้น

ผู้มีส่วนร่วมหลักและเบื้องหลัง

  • นักพัฒนาหลัก Isabel Paredes จาก QuantStack เคยรับผิดชอบ การพอร์ตภาษา R และเฟรมเวิร์ก ROS ไปสู่ WebAssembly มาก่อน
  • Emscripten-forge ขับเคลื่อนโดย Thorsten Beier และมีผู้ร่วมพัฒนาหลายคน เช่น Anutosh Bhat, Martin Renou เป็นต้น
  • JupyterLite ดูแลโดย Jeremy Tuloup และ Xeus ดูแลหลักโดย Johan Mabille
  • Xeus-Octave พัฒนาโดย Giulio Girardi และ Antoine Prouvost

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

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

 
GN⁺ 2025-10-21
ความคิดเห็นจาก Hacker News
  • ถ้าใครเพิ่งเคยได้ยินชื่อ Octave เป็นครั้งแรก Octave คือซอฟต์แวร์โอเพนซอร์สที่แทบจะเป็นร่างโคลนของ MATLAB ซึ่งเป็นซอฟต์แวร์เชิงพาณิชย์ ดูรายละเอียดในวิกิพีเดีย
    • คำว่า "โคลนเกือบทั้งหมด" อาจจะพูดเกินไปนิดหน่อย แม้จะชอบซอฟต์แวร์โอเพนซอร์ส แต่ถ้าจะทำงานที่ซับซ้อนขึ้นก็ยังรู้สึกว่า Octave ตาม MATLAB ได้ไม่ครบถ้วนสมบูรณ์นัก ดูความแตกต่างระหว่าง Octave กับ MATLAB
    • ใน MOOC ด้านแมชชีนเลิร์นนิงยุคแรกของศาสตราจารย์ Andrew Ng ใช้ Octave ดังนั้นถ้ากำลังหาสื่อฝึกปฏิบัติและตัวอย่างก็มีประโยชน์มาก เพลย์ลิสต์ YouTube
    • เมื่อ 15 ปีก่อนตอนเรียนปริญญาตรี ผมใช้ Octave แทน MATLAB ในวิชาวิเคราะห์เชิงตัวเลข และในเนื้อหาที่เรียนตอนนั้น ความเข้ากันได้ของภาษาถือว่าสมบูรณ์ดีมาก
    • แม้จะไม่ใช่ผู้ใช้ MATLAB โดยตรง แต่ก็รู้สึกได้ว่าการโคลนแค่ภาษาไม่ได้ทำให้ได้ทุกอย่างของ MATLAB เพราะ MATLAB เป็นชุดซอฟต์แวร์แบบ GUI และมีแอปจำนวนมากที่ใช้ได้โดยไม่ต้องเขียนโค้ด รวมถึงมีการซัพพอร์ตอย่างเป็นทางการจากผู้ขายด้วย เดิมทีโอเพนซอร์สมักถูกมองว่าแปลกหรือไม่น่าเชื่อถือ แต่ช่วงหลังภาพลักษณ์ในด้านนี้ก็เปลี่ยนไปเร็วมาก
    • Scilab ก็เป็นอีกซอฟต์แวร์หนึ่งที่เลียนแบบ MATLAB แต่เมื่อเทียบกับ Octave แล้วจะเน้นด้านฟังก์ชันการใช้งานมากกว่าความเข้ากันได้
  • สำหรับคนที่เพิ่งเคยได้ยิน JupyterLite มันก็คือ Jupyter Notebook/Lab แบบเดิม แต่ทำงานทั้งหมดในเบราว์เซอร์ โดยไม่ต้องมีเซิร์ฟเวอร์หรือแบ็กเอนด์ ทุกอย่างรันฝั่งไคลเอนต์ล้วน ๆ
    • ถ้า Python รันอยู่บน Web Assembly ก็น่าจะช้ามากพอสมควร
  • ด้วยเทคโนโลยีเดียวกันนี้เอง (คือ "xeus-stack" ลิงก์ xeus-stack) จึงมีภาษา/เคอร์เนลที่รันบน jupyterlite ได้หลากหลายกว่ามาก เช่น c++, python, R, lua, javascript เป็นต้น ถ้าอยากลองใช้งานดูให้ดูที่ Try Jupyter Lab หรือ เอกสาร JupyterLite และถ้าอยากทำดีพลอยเมนต์ของตัวเองก็ใช้ เทมเพลต repo xeus-lite-demo ได้
  • Octave เป็นทางเลือกสำคัญสำหรับนักศึกษาปริญญาตรีมาอย่างยาวนาน และเป็นที่รักของนักเรียนจำนวนมาก เป็นตัวอย่างที่ดีว่า GNU มีส่วนช่วยต่อความก้าวหน้าของมนุษยชาติอย่างไร แนะนำมากสำหรับงานวิเคราะห์เชิงตัวเลข และยังขยายต่อด้วย GNU-Fortran หรือ GNU-C ได้ง่าย พร้อมส่วนขยายหลายอย่างที่ให้มาด้วย มันเป็น DSL ที่เชี่ยวชาญด้านการคำนวณเชิงตัวเลข ในทำนองเดียวกัน Scilab ก็เป็นแพ็กเกจที่น่าแนะนำเช่นกัน แต่ขยายต่อได้น้อยกว่า
  • ผมรู้สึกอยู่เสมอว่า เสน่ห์ที่แท้จริงกลับถูกกลบไปท่ามกลางประเด็นต่าง ๆ ที่ผู้เขียนกล่าวถึง ถ้าเอาไดอะแกรมขึ้นมาไว้ด้านหน้าให้เด่นกว่าเดิม และเน้นฟีเจอร์ของรีลีสถัดไปรวมถึงประเด็นในกระบวนการสร้างให้ชัดขึ้น ก็น่าจะดีกว่านี้
  • ผมอยากให้มีการ transpile GNU Octave ไปเป็นภาษาอื่นมาโดยตลอด Octave เองก็สามารถ embed ผ่านไลบรารี C ได้อยู่แล้ว โดยดูได้ที่ วิธี embed Octave ใน C/C++ และ เอกสารทางการของโปรแกรมแบบ standalone นอกจากนี้ยังมีแพ็กเกจ OpenCL ที่รองรับ GPU acceleration ด้วย ดูได้ที่ แพ็กเกจ OpenCL แต่น่าเสียดายที่มันไม่ได้ใช้ GPU แบบอัตโนมัติแฝงอยู่เบื้องหลัง แต่ใช้แนวทางที่มีชนิดข้อมูลและฟังก์ชัน GPU แบบชัดเจนแทน ดู oclArray ซึ่งหมายความว่าไม่ใช่โครงสร้างที่เอาโค้ด Octave เดิมไปรันบน GPU ได้ตรง ๆ ถ้ามี GPU acceleration บนเบราว์เซอร์ผ่าน OpenCL ได้ด้วยก็คงยอดเยี่ยม แต่ตอนนี้ WebCL ยังไปไม่ถึงขั้นใช้งานจริง ดูเอกสาร WebCL, Khronos WebCL และตอนนี้แนวโน้มคือ WebCL กำลังถูกแทนที่ด้วย WebGPU วิธีใช้ WebCL บน Chrome, ข้อมูลมาตรฐาน gpuweb, เอกสาร Chrome Web API
    • ถ้าจะพูดถึงความรู้สึกส่วนตัว ผมมองว่าเหตุที่อุตสาหกรรมยังยึดติดกับแนวทางเชิงพาณิชย์แทนที่จะเลือกโซลูชันเปิดที่ชัดเจนนั้น ก็เพราะเรื่องกำไรอย่างเห็นได้ชัด ดูได้จากประวัตินวัตกรรมมากมาย เช่น blue LED พอ AI ช่วยลดภาระของนักพัฒนาได้บ้าง ก็อาจเป็นโอกาสให้เรากลับไปสำรวจเส้นทางที่ชัดเจนแบบนี้อีกครั้งก็ได้ จริง ๆ แล้วทุกครั้งที่มีนวัตกรรมทางเทคโนโลยี นักพัฒนากลับต้องแบกรับภาระมากขึ้นและต้องไต่เส้นโค้งการเรียนรู้ที่ชันขึ้น แต่ค่าตอบแทนจริง ๆ โดยเฉพาะเงินเดือนเริ่มต้นกลับแทบไม่ขยับเลย หากการ pair programming กับ AI แพร่หลายขึ้น สุดท้ายก็อาจทำให้คุณภาพโค้ดลดลงและเกิด codebase ที่ซับซ้อนเกินจำเป็นจำนวนมากได้เช่นกัน
    • เพราะอย่างนี้ผมจึงสนใจวิธีทางเลือก เช่น abstraction ที่ต้องเขียนยืดยาวใน Python บางที Octave เขียนได้จบในบรรทัดเดียว ถ้าจะให้กระชับกว่านั้นอีกก็คงต้องไปทางภาษาแนว functional assembly อย่าง LISP แต่ก็เท่ากับต้องยอมสละความสะดวกเชิงไวยากรณ์ของภาษาแบบอาร์เรย์ไป
    • แก่นสำคัญคือ ผมคิดว่าเส้นทางที่พาไปสู่ AI แบบ J.A.R.V.I.S./Star Trek ได้โดยตรงนั้น คือ DSL อย่าง Octave/MATLAB และเครื่องมือเขียนตรรกะทางธุรกิจแบบยุค 1980 อย่าง Spreadsheets, HyperCard, Microsoft Access, FileMaker เป็นต้น ถ้ามีเครื่องมือแบบ Octave แบบเปิดที่เร่งด้วย GPU ได้ ก็อาจเพิ่มประสิทธิภาพการสร้างซอฟต์แวร์และช่วยผลักดันความก้าวหน้าของ AI ได้โดยตรงด้วย