โครงการ GNU Compiler Collection หรือ GCC เปิดตัว คอมไพเลอร์ภาษา Rust (gccrs) เป็นอีกทางเลือกหนึ่งนอกเหนือจากคอมไพเลอร์หลักของโครงการ Rust โดยตรง ( rustc )

แนวทางของ GCC ต้องการเป็นชุดคอมไพเลอร์สำหรับภาษาโปรแกรมแบบครบวงจร และสร้างคอมไพเลอร์สำหรับภาษาต่างๆ ในชุดอยู่แล้ว (เช่น gccgo) กรณีของ gccrs ถูกพัฒนาขึ้นมาตั้งแต่ปี 2014 ก่อน Rust ออกเวอร์ชัน 1.0 ด้วยซ้ำ แต่ถูกทอดทิ้งไประยะหนึ่ง ก่อนมีนักพัฒนารายอื่นมารับช่วงโครงการต่อในปี 2019 แล้วพัฒนาต่อเรื่อยมา

Ubuntu เตรียมทดลองคอมไพล์แพ็กเกจในดิสโทร ด้วยการรีดประสิทธิภาพแบบ O3 optimization ของคอมไพเลอร์ GCC ซึ่งจะทำให้แอพรันได้เร็วขึ้นกว่า O2 optimization ที่ใช้อยู่ในปัจจุบัน

O3 optimization เป็นตัวเลือกของ GCC ที่มีอยู่แล้ว ข้อดีคือไบนารีที่คอมไพล์จะมีประสิทธิภาพตอนรันมากขึ้น แต่ต้องแลกมาด้วยระยะเวลาการคอมไพล์ที่นานกว่าเดิม และขนาดของไบนารีที่อาจใหญ่ขึ้น

Ubuntu บอกว่าเป้าหมายของดิสโทรคือการรีดประสิทธิภาพอยู่แล้ว ดังนั้นจึงต้องการทดลองดูว่าถ้าคอมไพล์เป็น O3 จะส่งผลต่อประสิทธิภาพในการรันงานรูปแบบต่างๆ มากน้อยแค่ไหน ก่อนนำข้อมูลไปตัดสินใจต่อไปว่าควรอยู่กับ O2 เหมือนเดิม หรือขยับไป O3

GCC โครงการคอมไพลเลอร์ของ GNU ประกาศรับโค้ดรองรับภาษา Rust เข้าโครงการ หลังจาก Philip Herron นักพัฒนาจาก Embecosm พัฒนาโครงการนี้มาตั้งแต่ปลายปี 2020

โครงการคอมไพลเลอร์ขนาดใหญ่อย่าง GCC หรือ LLVM จะแบ่งฟีเจอร์ด้านการรองรับภาษา (front-end) ออกจากการรองรับสถาปัตยกรรมซีพียู (back-end) ทุกวันนี้คอมไพลเลอร์ rustc ที่เป็นคอมไพลเลอร์หลักของภาษา Rust นั้นใช้ LLVM ขณะที่ GCC รองรับสถาปัตยกรรมซีพียูกว้างขวางกว่า

โครงการ GCC Rust มีเป้าหมายแรกที่จะรองรับภาษา Rust ระดับเดียวกับ rustc 1.40 ซึ่งออกมาตั้งแต่ปี 2020 และตอนนี้ rustc อยู่ที่เวอร์ชั่น 1.62.0 และกว่าที่โครงการจะรวมเข้าไปใน GCC จริงก็น่าจะเป็น GCC 13 คาดว่าจะออกตัวจริงปี 2023 และเป็นการรองรับระดับเบต้าเท่านั้น

กูเกิลนำเสนอปัญญาประดิษฐ์ MLGO นำมาช่วยคอมไพลเลอร์ให้ออปติไมซ์โค้ดได้ดีขึ้นกว่าเดิม ทั้งในแง่ประสิทธิภาพการทำงาน และขนาดโค้ดที่ได้หลังจากคอมไพล์แล้ว

การปรับปรุงขนาดโค้ดนั้นอาศัยการย้ายโค้ดจากในฟังก์ชั่นออกมาภายนอก (inlining) ที่ก่อนหน้านี้คอมไพล์เลอร์ก็มีตัวออปติไมซ์แบบ heuristic ที่ค้นหาแนวทางการทำ inlining ให้ได้โค้ดขนาดเล็กที่สุดอยู่แล้ว แต่กระบวนการออปติไมซ์นั้นซับซ้อนและปรับปรุงเพิ่มเติมได้ยาก การใช้ MLGO เข้าไปช่วยออปติไมซ์เป็นการฝึกปัญญาประดิษฐ์แบบ reinforce learning (RL) ที่ปัญญาประดิษฐ์จะได้รางวัลจากตัดสินใจทำ inlining แล้วโค้ดเล็กลง ผที่ได้จากการคอมไพล์โค้ดภายในของกูเกิลเองสามารถลดขนาดโค้ดได้ 3-7%

อินเทลมีสินค้าชิ้นสำคัญในสายซอฟต์แวร์คือ Intel C++ Compiler ที่รีดประสิทธิภาพซีพียูได้ดีกว่าคอมไพล์เลอร์โอเพนซอร์สทั่วไป แต่ปีนี้อินเทลก็เตรียมย้ายเอนจินภายในของคอมไพล์เลอร์นี้ไปใช้ LLVM แทนแล้ว

LLVM เป็นโครงการที่มีโครงการย่อยๆ อยู่จำนวนมาก เช่น คอมไพล์เลอร์ภาษา C++ นั้นมีโครงการ Clang เป็นตัวคอมไพล์ภาษา (frontend) อยู่ โดยอินเทลจะพัฒนาให้ LLVM สามารถออปติไมซ์โค้ดได้ดีขึ้น โดยโค้ดส่วนหนึ่งจะส่งกลับเข้าโครงการ LLVM แต่บางส่วนจะเก็บไว้กับคอมไพล์เลอร์ Intel oneAPI เท่านั้น

หลังจากสหรัฐฯ แบนไม่ให้หัวเว่ยใช้เทคโนโลยีสหรัฐฯ ทางหัวเว่ยก็พยายามแสดงความพร้อมที่จะใช้เทคโนโลยีของตัวเองตลอดมา โดยระบบปฎิบัติการ HarmonyOS นั้นมีหัวใจสำคัญคือ Ark Compiler ที่จะมาทดแทนจาวาคอมไพล์เลอร์ในแอนดรอยด์ แต่นักพัฒนาจีนที่ทดลองใช้งานก็พบว่ามันยังไม่สามารถใช้งานได้จริง

Max Zhou อดีตหัวหน้าฝ่ายวิศวกรรมของ Mobike ที่ออกมาตั้งบริษัท MetaApp ระบุว่า Ark Compiler เป็นแค่การประชาสัมพันธ์

Chrome 64 เปลี่ยนคอมไพล์เลอร์จาก Microsoft Visual C++ (MSVC) มาเป็น Clang ให้เหมือนกับแพลตฟอร์มอื่นๆ ได้แก่ macOS, iOS, Linux, Chrome OS, Android, และ Windows

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

เราทราบกันดีว่า Firefox 57 เร็วขึ้นกว่าเดิมมาก แต่นั่นเป็นเพียงจุดเริ่มต้นเท่านั้น เพราะ Mozilla มีแผนปรับปรุงเอนจินอีกมาก และใน Firefox 58 ก็มีของใหม่ที่ช่วยให้การประมวลผล JavaScript เร็วขึ้นอีก

ที่ผ่านมา Firefox รองรับ WebAssembly หรือการคอมไฟล์ JavaScript เป็นไบนารีเพื่อให้ได้ประสิทธิภาพดีขึ้นกว่าเดิม ใน Firefox 58 จะปรับปรุงการคอมไพล์ WebAssembly โดยใช้เทคนิค 2 อย่างประกอบกัน

Avast เปิดซอร์สโค้ดของ RetDec (Retargetable Decompiler) ดีคอมไพเลอร์ที่ช่วยแปลงไบนารีกลับเป็นซอร์สโค้ด

RetDec ถูกใช้งานภายในบริษัท Avast เพื่อใช้วิเคราะห์ไวรัส-มัลแวร์ที่มาในรูปของไบนารี สำหรับดูพฤติกรรมการทำงานของมัน รวมถึงหาวิธีแก้ไข (ในกรณีเป็น ransomware)

RetDec พัฒนาขึ้นจากโครงการคอมไพเลอร์โอเพนซอร์ส LLVM และเมื่อมันถูกเปิดซอร์สกลับมาอีกครั้ง (ใช้สัญญาอนุญาต MIT) ก็ช่วยให้เรามีดีคอมไพเลอร์ที่มีคุณภาพระดับใช้งานจริงเพิ่มอีกหนึ่งตัว

โค้ดอยู่บน GitHub ใช้งานได้ทั้งบนวินโดวส์และลินุกซ์ คนที่สนใจการแปลงไบนารีกลับ สามารถลองเล่นได้จาก บริการออนไลน์ของ Avast

เป้าหมายสำคัญอย่างหนึ่งในการรักษาความปลอดภัยซอฟต์แวร์โอเพนซอร์ส คือการทำให้การคอมไพล์สามารถทำซ้ำได้ (reproducible builds) เพื่อให้คนภายนอกแน่ใจได้ว่าซอร์สโค้ดที่เปิดเผยออกมาตรงกับซอฟต์แวร์ที่กำลังใช้งานอยู่ แต่กระบวนการทำจริงนั้นมีเงื่อนไขหลายอย่างที่ทำให้โค้ดไม่สามารถคอมไพล์ออกมาให้ตรงกันทุกครั้ง แต่วันนี้ทาง NetBSD ก็ออกมาระบุว่าตอนนี้การคอมไพล์บนสถาปัตยกรรม amd64 และ sparc64 สามารถทำซ้ำได้แล้ว

ทาง NetBSD แจงรายการปัญหาที่พบจากการพยายามทำให้การคอมไพล์ทำซ้ำได้ ได้แก่

ฟีเจอร์ใหม่ของ Android 7.0 ที่ลึกลงไปในระดับของการคอมไพล์คือการนำเทคนิค Just in Time (JIT) compiler มาใช้กับ รันไทม์แบบ ART ที่เริ่มใช้มาตั้งแต่ Android 5.0

โครงการนำ Clang มาใช้คอมไพล์โค้ดภาษา C++ ของไมโครซอฟท์ มีความก้าวหน้าอย่างจับต้องได้อีกขั้นเมื่อไมโครซอฟท์ได้นำเสนอวิธีการคอมไพล์โค้ดวินโดวส์แอพด้วย Clang ในงาน CPPCon 2015 ที่ผ่านมา และคาดว่าจะเพิ่มวิธีการคอมไพล์นี้ในชุดอัพเดตสำหรับ Visual C++ ที่จะออกมาในเดือนหน้าด้วย

โครงการชุดคอมไพเลอร์โอเพนซอร์ส LLVM มีคอมไพเลอร์ภาษา C/C++/Objective-C ชื่อว่า Clang ที่ถูกใช้งานอย่างแพร่หลาย ปกติแล้ว Clang ทำงานบนระบบปฏิบัติการสายยูนิกซ์ แต่ก็สามารถใช้บนวินโดวส์ได้ด้วย

ล่าสุด Clang ได้ผู้สนับสนุนรายใหม่คือ "ไมโครซอฟท์" ที่ปกติแล้วใช้ Visual C++ ของตัวเองเสมอมา (Clang เริ่มพัฒนาโดยแอปเปิล แต่ปัจจุบันดูแลโดยชุมชน)

นโยบายใหม่ของไมโครซอฟท์มาจาก การเปิดให้ Visual Studio คอมไพล์โค้ดจาก Android/iOS ทำให้ไมโครซอฟท์จำเป็นต้องหาคอมไพเลอร์ที่ทำงานบนแพลตฟอร์มอื่นๆ ได้ด้วย ซึ่ง Clang ก็มารับบทนี้

ไมโครซอฟท์อธิบายการทำงานของการคอมไพล์เป็นแผนภาพด้านล่าง

ต่อเนื่องจากแผนการ โอเพนซอร์ส.NET Framework และ รองรับการทำงานบนลินุกซ์และโอเอสเท็น ล่าสุดไมโครซอฟท์เปิดตัวโครงการพัฒนาคอมไพเลอร์ชื่อว่า LLILC (อ่านว่า lilac) ซึ่งเป็นคอมไพเลอร์แบบ Just in Time (JIT) สำหรับ CoreCLR เพื่อใช้งานร่วมกับ LLVM ข้อดีของ LLVM อ่านได้ใน ข่าวเก่า

คอมไพล์เลอร์ภาษา Go ก่อนหน้านี้พัฒนาด้วยภาษาซีมาโดยตลอด แต่เมื่อคืนที่ผ่านมา Russ Cox ทีมงานภาษา Go ก็ ลบโค้ดเหล่านี้ออกจาก Git ใน master branch แล้ว

การที่ Go สามารถคอมไพล์ตัวเองได้ ทำให้ Go กลายเป็นภาษาในกลุ่ม self-hosting อีกหนึ่งตัว

ตอนนี้คอมไพล์เลอร์ที่เขียนด้วยภาษา Go ยังช้ากว่าที่เขียนด้วยซีอยู่เล็กน้อย แต่ Cox ระบุว่าน่าจะแก้ปัญหาได้ภายในสัปดาห์หน้า

ที่มา - @_rsc

หลังจากที่กูเกิลออก เครื่องมือแปลงโค้ด Java เป็น Objective-C ในชื่อ J2ObjC ผ่านมาเกือบ 3 ปีก็ได้เวลาของไมโครซอฟท์กันบ้าง

ไมโครซอฟท์ออกเครื่องมือแปลงโค้ด จาก Java เป็น C#, C++ และ Objective C++ (โดยในส่วนของ C++ และ Objective C++ จะมีการรองรับในเร็วๆ นี้) ในชื่อ JUniversal มาพร้อมกับไลบรารี JSimple และสามารถใช้ร่วมกันกับ J2ObjC ในการแปลงเป็น Objective-C ได้

ช่วงหลายปีที่ผ่านมานี้ เราเห็นโครงการพัฒนาด้านประสิทธิภาพการประมวลผล JavaScript ของเบราว์เซอร์ค่ายต่างๆ โดยโครงการที่โดดเด่นคือ asm.js ที่ริเริ่มจากฝั่ง Mozilla

ฝั่งของแอปเปิลที่สร้าง Safari อยู่บนโครงการ WebKit ก็มีความเคลื่อนไหวในเรื่องนี้เช่นกัน โดยใช้ชื่อโครงการว่า FTLJIT ย่อมาจาก (Fourth Tier LLVM JIT)

ไมโครซอฟท์ปล่อยรุ่นพรีวิวของ .NET Native (ชื่อเดิม Project N ) เทคโนโลยีด้านคอมไพเลอร์ตัวใหม่สำหรับแพลตฟอร์ม .NET แล้ว บริษัทเคลมว่า .NET Native จะช่วยให้แอพแบบ Metro (Windows Store apps) เริ่มต้นทำงานเร็วขึ้นร้อยละ 60 และใช้หน่วยความจำน้อยลงกว่าเดิมร้อยละ 15-20

หลักการทำงานคือ .NET Native จะคอมไพล์โค้ดภาษา C# เป็นโค้ดแบบ native ที่ทำงานคล้าย C++ ซึ่งทำให้ได้ประสิทธิภาพระดับภาษา C++ จากการเขียนโค้ดภาษา C#

บริษัทยังกล่าวว่าได้ใช้ .NET Native คอมไพล์แอพของตัวเองบ้างแล้ว อาทิ Wordament และ Fresh Paint

Chrome Beta ปรับปรุงการประมวลผล JavaScript ในเอนจิน V8 เสียใหม่ โดยโอนภาระงานส่วนการรีดประสิทธิภาพ (optimizing compilation) ของโค้ดไปทำงานแบบแบ็คกราวนด์ ผลคือตัวแอพหลักที่อยู่ฉากหน้าจะยังตอบสนองดีเหมือนปกติ (responsive)

เดิมทีเอนจิน V8 จะทำหน้าที่ปรับแต่งโค้ดแล้วค่อยประมวลผล ซึ่งมีจุดอ่อนว่าถ้าโค้ดมีขนาดใหญ่ (เช่น เกม) อาจส่งผลต่อประสิทธิภาพโดยรวม (เช่น เฟรมเรตตกลง)

กูเกิลจึงเปลี่ยนมาใช้วิธีแปลงโค้ดแบบขนาน (concurrent compilation) แทน ทำให้ประสิทธิภาพโดยรวมของการประมวลผลดีขึ้นเพราะไม่ต้องรอกัน

ข่าวนี้ต้องย้อนกันไกลหน่อยนะครับ เริ่มจากปี 2010 Facebook เปิดตัว HipHop for PHP ตัวแปลภาษา PHP เป็นไบนารีเพื่อเร่งความเร็วของ PHP โดยจะแปลงเป็น C++ ก่อนแล้วค่อยคอมไพล์ปกติอีกครั้ง

ไมโครซอฟท์โชว์เดโมของ Project N ซึ่งเป็นเทคโนโลยีด้านคอมไพเลอร์ตัวใหม่สำหรับแพลตฟอร์ม .NET

ในเดโมของไมโครซอฟท์ได้ลองคอมไพล์แอพ FreshPaint บน Windows Store ด้วย Project N และได้ผลว่าแอพทำงานได้เร็วกว่าเวอร์ชันปกติ เทคนิคเบื้องหลัง Project N ไม่ใช่การทำ JIT (just-in-time) แต่เป็นการ optimization (ที่ไม่ได้เปิดเผยรายละเอียดว่าทำอย่างไรบ้าง)

Project N มีเป้าหมายเพื่อให้แอพ .NET/C# บน Windows 8 และ Windows RT ทำงานได้เร็วขึ้น และน่าจะเปิดให้คนทั่วไปใช้งานได้ในปีหน้า 2014

ที่มา - ZDNet

โครงการคอมไพเลอร์โอเพนซอร์ส GCC กำลังหารือกันว่าจะปิดการทำงานของคอมไพเลอร์ภาษา Java (GCJ) เนื่องจากไม่ค่อยได้พัฒนาแล้วในช่วงหลัง (เหตุเพราะงานพัฒนาสาย Java ย้ายไปอยู่ในโครงการ OpenJDK แทน)

ตามแผนของ GCC จะไม่ทิ้งคอมไพเลอร์ภาษา Java แต่จะปิดการทำงานมาเป็นดีฟอลต์แทน (รวมถึงไม่คอมไพล์ GCJ ในขั้นตอนของการคอมไพล์ GCC ทั้งชุดด้วย) และปรับสถานะของคอมไพเลอร์ Java เป็น maintenance mode ไม่ใช่ active development

ในโอกาสเดียวกัน ทางโครงการ GCC ยังหารือว่าจะยกระดับของคอมไพเลอร์ภาษาใดมาเป็นเปิดใช้โดยดีฟอลต์แทน ข้อเสนอมีทั้งภาษา Go และ ADA ครับ

ที่มา - Phoronix

Android NDK นั้นปกติแล้วจะมาพร้อมกับ GCC สำหรับการคอมไพล์โค้ดลง ARM และ x86 แม้นักพัฒนาจะไม่นิยมคอมไพล์แบบ x86 กันนัก เพราะเครื่องที่ใช้งานได้มีน้อย แต่อินเทลก็ยังคงพยายามดึงให้นักพัฒนาหันมาคอมไพล์โค้ดเป็น x86 เพื่อให้ได้ประสิทธิภาพสูงสุด และมีปัญหากับชิปของอินเทลให้น้อยลง

ล่าสุดอินเทลปล่อย Intel C++ Compiler v13.0 for Android ออกมาให้ใช้งานได้ฟรี โดยใช้แทนที่คอมไพล์เลอร์ใน NDK ได้เลย โดยปกติ Intel C++ Compiler นั้นราคาค่อนข้างแพง ตัวเริ่มต้นนั้นอยู่ที่ 699 ดอลลาร์หรือประมาณสองหมื่นกว่าบาท อินเทลระบุว่าช่วงให้ดาวน์โหลดฟรีนี้จะจำกัดเฉพาะช่วงแนะนำเท่านั้น

Nvidia ประกาศเข้าซื้อบริษัท The Portland Group หรือ PGI ผู้ผลิตคอมไพล์เลอร์สำหรับคอมพิวเตอร์ประสิทธิภาพสูง และเป็นผู้สร้างส่วนขยายให้ภาษา Fortran เข้าใช้งาน CUDA ได้ โดยเป็นการเข้าซื้อมาจาก STMicroelectronics โดยไม่เปิดเผยมูลค่า

ทีมซอฟต์แวร์ของ Nvidia มีจำนวนคนอยู่แล้วประมาณ 2,400 คน แต่ยังไม่มีซอฟต์แวร์สำหรับคอมพิวเตอร์ประสิทธิภาพสูง การซื้อครั้งนี้เป็นการรวมทีมเข้ามาทำงานร่วมกัน เพราะ Nvidia เองก็บุกตลาดอย่างหนัก และมีลูกค้าเป็นคอมพิวเตอร์ในรายการ Top 500 มากขึ้นเรื่อยๆ

สำหรับ ARM นั้น PGI มีประสบการณ์ทำคอมไพล์เลอร์ให้ ARM แต่ Nvidia ระบุว่าจะไม่มีการเปิดเผยแผนการสินค้าใดๆ

นักพัฒนาของ LLVM คู่แข่ง GCC (อ่านรายละเอียดได้ใน ข่าวเก่า ) ได้ประกาศเปิดตัว LLVM 3.3 ที่รองรับภาษา C++11 อย่างเป็นทางการ โดย frontend ของ LLVM ที่ใช้คอมไพล์ภาษา C/C++ ชื่อ Clang จะรองรับ AArch64 (ชื่อในกลุ่ม open-source ของ ARMv8), AMD R600 GPU, S390 และบางส่วนของ IBM System Z โดยนักพัฒนาได้กล่าวว่า LLVM 3.3 นี้เป็น "คอมไพเลอร์ที่รองรับมาตรฐาน C++11 รวมทั้งไลบราลี่สำคัญ ๆ ของ C++11 อย่าง std::regex"

Clang ยังมีเครื่องมือ C++11 migration เพื่อช่วยนักพัฒนาอัพเกรดโค้ดของพวกเขาเพื่อรองรับมาตรฐานใหม่อีกด้วย