Zig 0.15.1 laidienā atkļūdošanas režīma kompilācija notiek piecas reizes ātrāk. Iemesls ir viens: uz x86_64 mašīnām Zig tagad pēc noklusējuma lieto savu pašrakstīto koda ģeneratoru, nevis LLVM. Izņēmums ir NetBSD, OpenBSD un Windows, kur linkera trūkumu dēļ pagaidām paliek LLVM.
Laidienā ievietots piecu mēnešu darbs — 647 revīzijas no 162 dažādiem autoriem. Divas lielas izmaiņas izceļas: jaunais x86 dzinējs un standarta bibliotēkas ievadizvades pārrakstīšana, ko kopiena iesaukusi par “Writergate”.
Kāpēc pašrakstītais dzinējs ir tik daudz ātrāks
LLVM ir liels C++ projekts, ko Zig līdz šim izmantoja mašīnkoda ģenerēšanai. Tas dod labi optimizētu bināro failu, bet atkļūdošanas laikā, kad optimizācija nav vajadzīga, LLVM patērē lielu daļu kompilācijas laika. Zig komanda gadiem raksta savu aizmugurdzinēju tieši šim gadījumam — ātri saģenerēt strādājošu, neoptimizētu kodu.
Rezultāts ir aptuveni pieckārtīgs kompilācijas paātrinājums lielākajā daļā gadījumu salīdzinājumā ar LLVM. Dzinējs vairs nav eksperiments: pēc Zig laidiena piezīmēm tas nokārto lielāku daļu valodas uzvedības testu nekā LLVM aizmugure — 1984 no 2008 pret 1977 no 2008. Tas nozīmē, ka atsevišķas valodas konstrukcijas jaunais dzinējs apstrādā pareizi tur, kur LLVM ceļš klupa.
Kas grib veco uzvedību, to atgriež ar karogu. Optimizētiem izlaides būvējumiem LLVM joprojām ir noklusējums, tāpēc gala binārā faila ātrums nemainās. Mainās izstrādātāja cikls — laiks no koda saglabāšanas līdz palaišanai.
Writergate: ievadizvade pārrakstīta no nulles
Otra lielā izmaiņa skar katru programmu, kas kaut ko lasa vai raksta. Vecais Zig lietoja ģeneriskus lasītājus un rakstītājus — katrs avots definēja savu tipu. Jaunajā pieejā ir divi konkrēti tipi: std.Io.Reader un std.Io.Writer. Buferēšana tagad ir iebūvēta pēc noklusējuma, nevis atsevišķs slānis virsū.
Līdzi pārrakstīti arī std.fs.File.Reader un std.fs.File.Writer. HTTP klients un serveris vairs nav piesaistīti tīkla slānim, un TLS klients atdalīts no std.net. Praksē tas nozīmē, ka HTTP kodu var lietot arī pāri transportam, kas nav parastā ligzda.
Buferēšana pēc noklusējuma maina to, kā jāraksta kods. Vecajā pieejā katrs izsaukums write varēja aiziet tieši uz sistēmas izsaukumu, un ātrumam programmētājs pats aptina rakstītāju buferī. Tagad buferis ir daļa no std.Io.Writer, un mazie ieraksti salasās kopā, pirms tie aiziet uz failu vai ligzdu. Kods, kas agrāk pieņēma nebuferētu uzvedību un pats izsauca izskalošanu īstajā brīdī, jāpārskata.
Kopienā izmaiņu nodēvēja par “Writergate”, jo kopā ar valodas izmaiņām un standarta bibliotēkas izgriezumiem tā salauž lielu daudzumu esošā koda. Pāreja uz 0.15.1 nav klusa versijas maiņa.
Kas izmests no valodas
Zig turpina griezt lieko. No valodas izņemts atslēgvārds usingnamespace, kā arī async un await kopā ar @frameSize. Asinhronā ievadizvade Zig pasaulē pēdējos gados tika pārdomāta no jauna, un vecie atslēgvārdi šai jaunajai pieejai vairs neder.
Standarta bibliotēkā izmaiņas jūt uzreiz. std.ArrayList tagad prasa skaidru Managed galotni, ja gribi versiju, kas glabā savu piešķīrēju. Pavisam izmesti std.fifo.LinearFifo, std.RingBuffer un std.BoundedArray. Kods, kas uz tiem paļāvās, nekompilēsies, kamēr to nepārraksta.
Aarch64 dzinējs nāk nākamais
Pašrakstītais x86 dzinējs ir tālāk par pārējiem, bet ne vienīgais. Aarch64 aizmugure, kas apkalpo Apple Silicon un ARM serverus, pašlaik nokārto 1656 no 1972 uzvedības testiem — 84 procentus. Tā vēl ir izstrādē, bet Zig komandas plāns ir to padarīt par noklusējumu turpmākajos laidienos, tāpat kā tagad ar x86.
Būvēšanas pusē zig init dabūja jaunus veidņu failus, un --watch režīms sāka strādāt uz macOS, izmantojot File System Events saskarni. Līdz šim automātiskā pārbūve pēc faila izmaiņas macOS lietotājiem strādāja nepilnīgi.
Kam kompilācijas ātrums svarīgs
Zig lieto projekti, kuros pārbūve notiek desmitiem reižu stundā. JavaScript izpildvide Bun ir rakstīta Zig valodā, tāpat termināļa emulators Ghostty un datubāze TigerBeetle. Šādos projektos katra sekunde starp koda saglabāšanu un testa palaišanu summējas dienas garumā. Pieckārtīgs atkļūdošanas kompilācijas paātrinājums šeit ir taustāms ieguvums, nevis skaitlis uz papīra.
Tieši tāpēc pašrakstītais dzinējs bija Zig komandas prioritāte. LLVM paliek izlaides būvējumiem, kur svarīgs ir gala koda ātrums, bet ikdienas darbā izstrādātājs strādā atkļūdošanas režīmā, un tur uzvar ātrā pārbūve.
Ko darīt tiem, kas jaunina
Atkļūdošanas paātrinājumu dabū bez piepūles — pietiek jaunināt uz 0.15.1 uz x86_64 Linux vai macOS. Sāpes ir Writergate un izmestie tipi. Projektiem, kas aktīvi lasa failus, atver ligzdas vai lieto ArrayList, kompilators pēc jaunināšanas parādīs virkni kļūdu. Zig kopienas forumā Ziggit jau krājas migrācijas piemēri un biežāko kļūdu labojumi.
Valoda joprojām ir pirms 1.0, un šis laidiens to atgādina skaidri: lauztā saderība ir cena par to, ka standarta bibliotēka un kompilators tiek sakārtoti pirms stabilās versijas. Kas grib mierīgu API, tam vēl jāpagaida. Kas grib ātru kompilāciju jau tagad, tam x86 dzinējs to dod.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.