Mozilla følger Google og dropper Microsoft-compiler

Illustration: Mozilla Firefox
En stor og vigtig milepæl, siger browserproducenten.

Mozillas udviklere erstatter compileren til Windows-versionen af ​​Firefox-browseren, hvilket medfører en overgang fra Microsoft Visual C ++ (MSVC) til open source-compileren Clang.

Det fremgår af en meddelelse i Developer Forum.

Først og fremmest vedrører overgangen den eksperimentelle, såkaldte 'natlige' udgave af Firefox, men på lang sigt er målet en overgang også for den officielle udgivelse af browseren.

Der er blandt andet støtte til optimeringsteknikker som LTO (link-time optimering) og PGO (profilstyret optimering).

Forventer bedre ydelse

Udviklerne ser frem til, at det blandt andet vil være lettere at integrere Rust-kode i projekterne, såvel som forbedret ydelse på lang sigt.

»For øjeblikket giver ydelsen et blandet billede. Det går op i visse tests og ned i andre. Så snart vi får understøttelse af LTO og PGO, forventer jeg, at Clang giver os en mærkbar bedre ydelse,« skriver Mozilla-udvikleren David Major.

Google står bag betydelige dele af udviklingen, der aktiverede dette, men Microsoft har også bidraget med vigtig kode, har Arstechnica tidligere skrevet. Virksomheder som Apple, Sony, Intel, ARM og AMD er også bidragydere til Clang-projektet.

Firefox har været et open source-projekt siden oprettelsen i 2004.

Det er nemmere for et projekt, der udvikler software til mange platforme, at benytte en og samme compiler. Bl.a. fordi udviklerne kan undgå eller reducere mængden af ​​compiler-specifik kode.

Denne artikel stammer fra Digi.no.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Sune Marcher

Kunne dette mon være starten på enden for MSVC?
Er LLVM bare bedre?
Hvad med GCC?


Det er svært at sige entydigt, da det kommer an på hvad du bygger :)

Jeg synes generelt MSVC har rigtigt god codegen, hvor GCC og LLVM så i enkelte tilfælde gør noget uforudset, og lige dér får genereret bedre kode.

Det ville være dejligt men jeg tror det er lidt overoptimistisk.


Hvorfor dejligt?

Jeg tror ikke monokultur vil være sundt for lige netop C/C++ – med alt det ID/US/UD beaviour der er i standarderne, tror jeg det er ret sundt at der er flere implementationer af compiler såvel som standard library.

Yeah, det gør portability lidt mere besværligt, men det er i forvejen et grundvilkår for C/C++, med mindre du laver noget der er så simpelt at du kun anvender libc/libc++.

  • 2
  • 0
Jonas Finnemann Jensen

Disclaimer: Indtil for en måned siden arbejdede jeg for Mozilla på taskcluster, der automatisere infrastruktur for test of release pipelines.

Hvorfor dejligt?

Mozilla bygger Firefox for Windows på Windows, hvorimod både Linux og OS X builds kører på Linux i en docker container.

Windows og OS X er nogle af de værste platform at skulle automatisere.
Fordi vi ikke rigtig har en god historie for containerization. I Mozillas nuværende CI/release setup, findes der Dockerfiles i mozilla-central der specificere hvordan build og tests environments skal opbygges. Det vil sige at man kan tilpasse build/test environments ved at ændrer i kildekode og prøve tilpasningerne af med et push til try (test branch med mange hoveder).

Alt hvad man kan gøre for at flytte konfiguration ind under source control ved siden af Firefox kildekoden er en god ting. Windows og OS X testing er en blocker, da man mangler gode container løsninger.
(docker for windows giver dig ikke lige frem et windows skrivebords miljø, men der er derimod nemt at kører xorg under docker på Linux).

Note: man kunne selvfølgelig bruge fulde VMs, istedet for containers, men overhead a meget højere - og det er lidt begrænset med skyer som har nested virtualization (hvilket også er langsomt). Så skal man på packet.net eller scaleway, da de tilbyder bare-metal. Det sker nok også en dag :)

Det medfører dog også andre problemer, da man så kommer til at mangle object storage som S3. Hos Mozilla replikeres artifacts mellem forskellige regions hos AWS, når der bliver hentet i en anden EC2 region. Dette holder cross-region transfer cost under kontrol. Og i en sky object storage kan man selvfølgelig bruge en caching-proxy, men det er igen flere ting der skal bygges, vedligholdes, skaleres og opdateres.

Anyways, min pointe var at frihed til at bygge under Linux giver rigtig mange muligheder i automation. Bare installationen af MSVC kan nemt blive noget rod, da man sikkert ikke må distribuere den.

  • 9
  • 0
Sune Marcher

Jonas, jeg kan sagtens se det giver mening for Mozilla at flytte til én compiler – min "hvorfor" gik på at Maciej synes det ville være dejligt, hvis MSVC forsvandt.

Flyttet vil vel ikke gøre testsituationen lettere, though? Der er stadig en masse platformsspecifikt til macOS og Windows.

  • 2
  • 0
Jonas Finnemann Jensen

Der er nok noget om at en monokultur for C++ ikke er ideelt. Men på den anden side kunne vi måske godt klarer os uden en lukket compiler der er begrænset til Windows.

Note. der er selvfølgelig ingen risiko for at MSVC forsvinder. Der er sikkert alt for meget software som specifikt kræver den compiler.

Men at forskellige open source projekter begynder at have et brugbart alternativ på Windows er ikke skidt.

Ind til videre har man jo fravalgt mingw på Windows fordi der var performance problemer.

Flyttet vil vel ikke gøre testsituationen lettere, though?

Nej, tests vil nok altid være et problem.. men i det mindste skal der ikke installeres en compiler længere :)

  • 6
  • 0
Troels Henriksen

Det har været lidt irriterende at skrive portabel C når Microsoft i mange år afviste at understøtte C99 og (senere) C11 i MSVC. Det er blevet lidt bedre på det sidste, men det kan jo gå galt igen, og det kan være de blot strategisk har valgt at understøtte den lille håndfuld manglende features jeg selv stødte ind i. Clang og GCC har derimod været ret hurtige til at følge med (det er heller ikke det store der er sket i de sprogrevisioner).

Jeg synes en mangfoldighed af implementeringer er vigtigt, men jeg synes det er vigtigere at de udbredte implementeringer opdateres i forhold til de nyeste standarder.

  • 1
  • 0
Sune Marcher

Det har været lidt irriterende at skrive portabel C når Microsoft i mange år afviste at understøtte C99 og (senere) C11 i MSVC.


Well, det hedder jo trods alt Visual C++, og det er klart på C++ der har været fokus.

Jeg har aldrig savnet C99 og nyere, og ville til enhver tid hellere anvende et subset af C++ i stedet - men det er self. lidt ærgerligt hvis man gerne vil inkorporere C99/C11 i sit projekt. Jeg tænker at kundebasen nok har det på samme måde - ellers havde MS nok gjort mere ud af C support.

Det stod også sløjt til med at få understøttet C++ features i en årrække, men der har de heldigvis oppet sig gevaldigt.

Jeg synes en mangfoldighed af implementeringer er vigtigt, men jeg synes det er vigtigere at de udbredte implementeringer opdateres i forhold til de nyeste standarder.


De burde nok have ladet være med at lave noget som helst C99 - og meld ud at det var planen - indtil de var klar til at committe sig til at gøre det ordentligt.

  • 1
  • 0
Troels Henriksen

Det havde været endnu bedre hvis de bare havde holdt helt op med at understøtte C, så det ville blive kotyme for programmører på Windows at have adgang til en bedre (og mere opdateret) C-oversætter. At have en let tilgængelig (men forældet) mulighed skævvrider hele økosystemet. Det samme gjorde sig gældende i de tvivlsomme gamle IE6-dage.

  • 3
  • 0
Sune Marcher

Det havde været endnu bedre hvis de bare havde holdt helt op med at understøtte C, så det ville blive kotyme for programmører på Windows at have adgang til en bedre (og mere opdateret) C-oversætter.


Igen: hvis der havde været nok interesse i det...

Og der er / har også været Intel, Borland, Watcom og MinGW compilerne (plus det løse) på Windows så du kan ikke rigtigt sammenligne det med IE6, IMHO.

Med alt det sagt, så er jeg super glad for LLVM projektet. Det er fedt at have en moderne, ret høj-kvalitet og modulært opbygget compiler toolchain suite tilgængelig som opensource.

Men jeg ønsker ikke at hverken GCC eller MSVC skal dø.

  • 1
  • 0
Log ind eller Opret konto for at kommentere