»Massiv« ny udgave af Swift byder på masser af parallelisering

Illustration: Bigstock/Arepiv
Apples sprog til Mac og Ios, som nu også kan afvikles på Linux og Windows, lander i version 5.5 med mange nyheder.

Med kun syv år på bagen kan Apples bud på et moderne sprog, Swift, indtage 15.-pladsen på indekset Tiobe, der måler sprogs popularitet.

Succesen er tæt parret med et andet sprogs fald fra tronen, nemlig Objective-C, som i mange år var Apples bud på et systemsprog til Macs og Iphones. Swift blev designet som en afløser, og projektet må sige at være lykkedes.

Swift ligner på mange punkter andre unge og moderne sprog, men har taget sit eget valg når det handler om håndtering af hukommelse. Her benyttes hverken garbage collection eller låne-tjekker som i Rust, men Automatic Reference Counting, hvor kørselsmiljøet holder øje med, hvor mange referencer, der er til et sted i lagret.

Når der ikke er flere referencer, kan hukommelsen frigives. Det er smart, men der er en ulempe: Hvis to objekter i en datastruktur peger på hinanden, frigives hukommelsen ikke. For at undgå hukommelseslækager findes der to slags referencer: almindelige og ‘svage’. De svage referencer tæller ikke med, og på denne måde kan en linked list, hvor den ene retning i strukturen udgøres af svage pointere, deallokeres et element af gangen.

Det giver ikke pauser i programudførelsen som med garbage collection, men som i C er det programmørens ansvar at undgå hukommelseslækager.

Derudover byder sproget på stærke typer med typeinferens, klasser som i de fleste objektorienterede sprog og værdityper som structs og enums. Og kan også afvikles på Linux og Windows.

Masser af parallelisering i Swift 5.5

Swift udkommer med én større udgivelse hvert halve år. Den nye Swift 5.5 er en »massiv« udgivelse, skriver udvikler Ted Kremenek fra sprogets kernehold i et blogindlæg.

Han fremhæver især nyhederne til flertrådet programmering. Det drejer sig om nye faciliteter, herunder async/await, som kendes fra Javascript og andre sprog. Hertil kommer asynkrone lister eller sequences, som det hedder i Swift.

Det har udmøntet sig i en ny protokol (som er det, der ofte kaldes interfaces i andre sprog), AsyncSequence, der giver mulighed for at vente på hvert element i stedet for hele resultatet. Den kan benyttes med den sædvanlige for-in-syntaks.

To andre nye typer, AsyncStream og AsyncThrowingStream, skaber et bindeled mellem async/await og continuations, som er en programstump, der kan stoppe og startes, og returnere en værdi.

AsyncStream implementerer den førnævnte AsyncSequence, så dens elementer kan også gennemløbes med for-in-syntaks.

Også i samme boldgade findes ‘struktureret concurrency’, som ifølge forslaget bag giver de nødvendige værktøjer til at skære arbejdet op i mindre opgaver, der kan køre samtidigt, og give opgaver mulighed for at vente på, at de er indbyrdes færdige samt mulighed for effektivt at styre den overordnede fremgang i en opgave.

Det kan minde om future- eller promise-baserede biblioteker i andre sprog, hvor asynkron og samtidig udførsel kan sættes sammen på mange måder med stor fleksibilitet, men med den forskel at referencer til opgaverne ikke lækker ud af virkefeltet, skriver udviklerne. Det sidste forhold skulle gøre det muligt at skabe mange optimeringer i compiler og runtime, som ikke kan opnås med future-modellen.

Og der er endnu mere parallelisering i version 5.5. Det handler om actors, som er et komponent der afvikles i sin egen tråd, med en slags ind- og udbakke til meddelelser til andre komponenter. Det har været en succes i sproget Erlang og findes også i en række andre sprog.

Der er mange flere nyheder i Swift 5.5, og det kan man læse mere om i blogindlægget fra udviklerne.

Mere parallelisme i fremtiden

I fremtiden ligger version seks, og her fastholdes fokus på parallelisme, har udviklerholdet tidligere bekendtgjordt:

»Det, der kommer til at adskille Swift 6 fra Swift 5.x-udgivelserne, vil være en betydelig ændring i sprogets muligheder. Denne forandring er foreløbigt bedre understøttelse af concurrency (parallelisme) samt fremskridt imod en ny model for ejerskab af hukommelse.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (16)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Lasse Schou

Hvis artiklen mest er en øvelse i at opfinde danske oversættelser, som meget få i branchen nogensinde bruger, kan jeg foreslå at fuldende den med: - garbage collection: skraldeopsamling - future/promise: fremtid/løfte - compiler: kompilator

Eksempel: “Vi må hellere justere skraldeopsamleren, så lige-til-tiden kompilatoren ikke kaster stak-oversvømmelses-undtagelser pga. hukommelseslækage”.

Jeg tænker der er en redaktionel årsag til det, men er jeg den eneste der synes det er tungt at skulle læse alle de kreative danske oversættelser?

  • 9
  • 2
#3 Troels Henriksen

garbage collection: skraldeopsamling

Her er den etablerede (relativt...) danske oversættelse "spildopsamling". Lidt sært at man ikke benyttede denne, men oversatte borrow checking. En compiler er en "oversætter" - som i mine øjne faktisk er et bedre ord end compiler.

Jeg er normalt tilhænger af at oversætte til danske begreber, men man skal passe på. Det bliver nemt noget rod.

Stack overflow oversættes forresten som "stakoverløb".

  • 5
  • 0
#4 Torben Mogensen Blogger

Her er desværre ikke en etableret dansk betegnelse, men "automatisk referencetælling" er et godt bud.

Ulempen ved denne metode er ikke kun, at cykliske strukturer (uden svage referencer til at bryde cyklerne) ikke opsamles, men også, at det er relativt dyrt: Hvis du laver en sætning

p = q;

hvor p og q har referencetyper og er allokeret i registre, så forventer du, at det oversættes til en enkel MOV instruktion. Men med referencetælling bliver det til noget i stil med

tmp = p->count; tmp --; if (tmp==0) free(p); else p->count = tmp; p = q; tmp = p->count; tmp++; p->count = tmp;

Det er 4+ lagerreferencer (for free(p) bruger adskillige) og et betinget hop, der er svært at forudsige.

Man kan bruge statisk analyse til at reducere omkostningerne -- man kan ofte se, at en given variabel p altid peger på objekter med præcis en reference, og derfor kalde free(p) uden at læse dets referencetal -- men det er stadig langt dyrere en f.eks. generationel, kopierende spildopsamling.

Fordelen er, som nævnt, at man undgår pauser til spildopsamlig. Men det er en sandhed med modifikationer: Når et objekt frigøres med kald til free(), skal alle (ikke-svage) referencer ud fra dette objekt følges, og de refererede objekters referencetal skal tælles ned. Det kan give en kaskade af frigørelser, som med meget lange lister eller store træer kan tage meget lang tid. Man kan køre free() i en anden tråd end resten af programmet for at undgå lange pauser, men det kan man også med spildopsamling. Så fordelen ved referencetælling er til at overse.

I øvrigt blander artiklen flertrådighed (concurrency) men parallelisme. Det er to helt forskellige begreber, for du kan godt have flere tråde på en enkelt kerne, og du kan godt have parallelisme i en enkelt tråd.

  • 1
  • 1
#5 Michael Cederberg

Det er interessant at Apple fortsætter med at pushe Automatic Reference Counting (ARC). ARC har altid slået mig som en mystisk mellemting mellem manuel memory management og garbage collection (GC). På den ene side undgår man hængende pointere og de fleste memory leaks. Memory forbruget er også betydeligt mindre end hvis GC skal fungere godt.

Men vi er efterhånden i den situation af selv mobile devices har meget memory og mange cores. ARC løser således et problem der bliver mindre og mindre. I praksis kan man fint rende ind i memory leaks med ARC - specielt hvis man bruger 3. part libraries uden helt at forstå alle detaljerne. For så kan cykliske memory referencer fint dukket op.

Værre er det hvordan ARC performer i et multiprocessor setup. Jeg er ikke i tvivl om at når man bare kører på en enkelt thread så vil det fungere fint (specielt hvis Apple også har en avanceret cache på deres ARM processorer).

Men hvis der er tale om objekter der bruges meget ofte på tværs af CPU'er så vil de mange increment/decrement operation på ref-counteren kunne blive ganske dyre. Disse skal implementeres som interlocked increment/decrement somå ARM er noget med load + store conditionally + loop omkring. Det giver en masse flow i CPU'en omkring cache coherency m.m. Efterhånden som antallet af kerner vokser og programmer bliver mere parallelle (andre tilføjelser til Swift går klart i den retning) så kan ARC blive ganske dyrt.

En god compiler og et godt kan sikkert eliminere mange af disse up/down på ref count men ARC er efterhånden et anti-pattern i mine øjne. GC gør memory management til et meget lille problem og hvis der er memory nok er det den mest effektive måde at håndtere memory. Manuel memory management er fantastisk til at reducere memory forbug. ARC ... en hund i et spil kegler?

PS: I mine øjne er det også et anti-pattern at oversætte computer science termer til dansk. Det gør ikke teksten mere læselig.

  • 4
  • 1
#6 Peter Stricker

Jeg er normalt tilhænger af at oversætte til danske begreber

Både du og Torben Mogensen (#4 ovenfor) skriver ofte nogle indlæg som rammer mine interesser. Derfor læser jeg dem altid med stor interesse. Men det kan ofte være pinefuldt at forsøge at forstå, hvad I mener. Når I bruger "danske" betegnelser for begreber, der er ganske godt kendte og meget lette at søge på, såfremt man søger på den engelske originalbetegnelse, så skal man lige "oversætte" tilbage til et kendt engelsk udtryk.

Når jeg sætter "danske" i anførselstegn, så skyldes det at mange af jeres oversættelser aldrig er nået ud til det brede publikum udenfor DIKU. Jeg har langt nemmere ved at læse et indlæg som Michael Cederbergs (#5), hvor de få danske oversættelser ikke virker søgte og dermed heller ikke er meningsforstyrrende.

Automatic reference counting Her er desværre ikke en etableret dansk betegnelse, men "automatisk referencetælling" er et godt bud.

Ovenstående er et godt eksempel på en unødvendig og søgt oversættelse. Torben, hvis dine studerende, når de forlader DIKU, ikke er i stand til at forstå "Automatic reference counting" uden at det skal oversættes til dansk, så er det altså ikke dine studerende, der har fejlet.

  • 7
  • 3
#7 Michael Cederberg

Når jeg sætter "danske" i anførselstegn, så skyldes det at mange af jeres oversættelser aldrig er nået ud til det brede publikum udenfor DIKU.

He he ... på DTU forsøgte man også. Nedenfor er et uddrag af danske betegnelse som vi lærte i kurus 4501 (Mikrodatamatsystemer) i1988(?). Bagefter brugte vi dem aldrig mere og det var også håbløst fordi alle lærebøger derefter var på engelsk. I øvrigt er det værd at huske at læger bruger latinske betegnelser når de skriver internt ... for at undgå misforståelser.

  • Baggrundslager
  • Bibliotekssystem
  • Blød disk
  • Centralenhed
  • Datamat
  • Hård disk
  • Indlæseenhed/udlæseenhed
  • Knudepunkt (et datamatsystem i et datamatnetværk)
  • Linjeskriver
  • Lænkeprogram
  • Materiel (aka hardware)
  • Oktet (aldrig sige en byte)
  • Ordrekode
  • Ordresæt
  • Procesdirigent
  • 4
  • 0
#9 Palle Simonsen

håndtaget på toppen af stakken

Mener du ikke pegepinden til toppen af stakken - når man tænker mit forslag igennem på dansk er den ligeså meningsløs :)

Men ellers helt enig med Peter Stricker - thumpsUp^10

I min dagligdag arbejder jeg ofte på tværs af landegrænser og der bruger vi engelske udtryk - jeg kan slet ikke forestille mig det kaos og den forvirring der ville være, hvis kollegaer og projektdeltagere fra mange forskellige lande insisterede på at anvende landespecifikke udtryk.

  • 1
  • 1
#10 Troels Henriksen

Mener du ikke pegepinden til toppen af stakken - når man tænker mit forslag igennem på dansk er den ligeså meningsløs :)

Det hedder "stakpegeren".

jeg kan slet ikke forestille mig det kaos og den forvirring der ville være, hvis kollegaer og projektdeltagere fra mange forskellige lande insisterede på at anvende landespecifikke udtryk.

Jeg kæmper ikke (seriøst) for at man altid bør bruge danske begreber, men du behøver ikke gå så vidt i din modstand: Der er selvfølgelig ingen der mener at man bør bruge danske begreber når man kommunikerer på engelsk. Min egen interesse i danske begreber er delvist udfordringen i at lege med sproget, og delvist at jeg subjektivt synes det lyder bedre når man skal bøje ordene. "Stack pointerne" lyder skrækkeligt i mine ører; "stakpegerne" lyder fint.

Man kan tage det for vidt. Uncleftish beholding er en berømt/berygtet tekst der beskriver atomteori på engelsk, men næsten udelukkende via ord der kun har germanniske rødder - alt det græske og latinske er fjernet. Det bliver selvfølgelig hurtigt fjollet, men jeg må indrømme at det visse steder giver en ret smuk konsistens i tekstens lyd (et dejligt selvmodsigende udtryk).

  • 1
  • 1
#11 Peter Stricker

delvist at jeg subjektivt synes det lyder bedre når man skal bøje ordene. "Stack pointerne" lyder skrækkeligt i mine ører; "stakpegerne" lyder fint

Du har absolut ret i at det kræver tilvænning at læse engelske udtryk med danske bøjninger. Af og til bruger man så også den engelske bøjning af ordet midt i en sætning hvor resten er på dansk. Og det lyder så lige så forfærdeligt, hvis ikke værre. Men det er en vanesag, og man kan godt vænne sig til både at skrive og læse på dansk med engelske udtryk blandet ind i teksten med en rimelig blanding af både engelske ord med danske bøjninger og engelske ord med engelske bøjninger uden at det går ud over læsbarheden af teksten.

Jeg har lige genlæst Michaels indlæg #5 med et kritisk blik på anvendelsen af engelske udtryk, og selvom der både optræder engelske ord med engelske bøjninger (memory leaks) og engelske ord med danske bøjninger (ref-counteren), og ord der er oversat til dansk (kerner), så er der ikke nogen steder i teksten, hvor jeg synes at det forstyrrer min læsning af hans indlæg. Det kan de tekniske termer til gengæld godt gøre hvis der optræder nogle, jeg ikke er fortrolig med, i en tekst jeg læser. Men så vil jeg helt klart foretrække at udtrykket er på engelsk, så jeg ikke skal gætte mig til hvad udtrykket er en oversættelse af.

Og for at vende tilbage til "Stack pointerne" kontra "stakpegerne", så vil jeg klart foretrække den første udgave uanset at den måske får en lavere stilkarakter end din oversættelse.

  • 2
  • 1
#13 Torben Mogensen Blogger

Torben, hvis dine studerende, når de forlader DIKU, ikke er i stand til at forstå "Automatic reference counting" uden at det skal oversættes til dansk, så er det altså ikke dine studerende, der har fejlet.

Vi bruger generelt lærebøger/noter på engelsk, men bruger ofte danske ord til forelæsninger, der afholdes på dansk. Dermed lærer de studerende både de danske og de engelske begreber, ganske ligesom læger lærer både "lungebetændelse" og "pneunomia", "livmoder" og "uterus", osv. Vi nævner selvfølgelig de engelske ækvivalenser, når vi bruger danske ord (hvor det ikke er oplagt -- vi behøver ikke at fortælle, at en stak er "a stack".

Noterne om spildopsamlig (GC) er på engelsk, og forelæsningerne er også, da kurset er defineret til at være engelsksproget. Hele kandidatuddannelsen er engelsksproget (af hensyn til udenlandske studerende), så det er ikke de engelske begreber, der forsømmes, det er de danske.

  • 1
  • 1
#14 Torben Mogensen Blogger

Jeg krummer tæer, hver gang nogen snakker om noder i en graf. Det er ikke musik, vi snakker om. Det hedder "knuder", hvis du taler dansk, men du må selvfølgelig gerne sige "nodes in a graph". Ligeledes bør man i dansk tale sige "tegnsæt" i stedet for "karaktersæt" (gys!), mens man selvfølgelig siger "character set" på engelsk.

Jeg bruger dog ikke "geled" som oversættelse af "array", selv om det ville være korrekt, da det næppe forstås uden forklaring. Dansk EDB-Ordbog fra 1970 foreslår, at "array" oversættes til "sæt", hvilket jeg synes er helt forfejlet -- det mangler den ordnede opstilling i geled. Men ordet "geled" er ved at forsvinde fra almindelig dansk tale -- jeg har snakket med danske studerende, der ikke kendte ordet i den almindelige danske betydning. Jeg bruger nogen gange "tabel" som oversættelse af "array", da det er mere almindeligt kendt og dækker almindelig brug af datastrukturen.

  • 2
  • 0
#15 Eskild Nielsen

Først - man kan godt på engelsk se octet brugt, fx i internationale standarder og anbefalinger.

Og man kan undertiden møde bytes der ikke er 8 bit brede men fx 6 eller 9

Til gengæld er det lidt mere sandsynligt at bittene i en byte har en binær vægt end bittene i en octet, som kun behøver at dele adressen i lageret

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