Når det nytter noget...
For fjorten år siden købte jeg en lille bitte laptop og derfor kører Firefox3 bedre idag.
Det er jeg ret stolt af.
Den lille bitte laptop var en Gateway 2000 Handbook 486. og den havde "kun" 4MB ram og en lillebitte langsom 2.5" harddisk på 130MB.
Det var fire gange mere RAM end en Vax 11/780 havde i orginalkonfiguration, men FreeBSD kørte ikke synderligt godt, til trods for at den malloc(3) implementering vi havde arvet fra BSD4.4-lite beskrev sig selv som:
Citat:
This is a very fast storage allocator.[...]This is designed for use in a virtual memory environment.
På vej til og fra arbejde i Oakland, sad jeg i BART med min lille "critter" og prøvede at finde ud af hvad der egentlig foregik.
Noget koderi senere var "phkmalloc" født og endte med et paper til USENIX/FreeNIX konference i New Orleans 1998.
Den overhead der gav mest genlyd under mit foredrag, eller rettere: den der fik hele rummet til at blive tavse som graven, var en håndskreven liste af de programmer phkmalloc havde afsløret kodefejl i.
Det første program på listen var fsck(8) og der var adskellige setuid og netværksdæmoner blandt de 20-30 programmer.
Undervejs havde jeg fået flyttet målpælene et pænt stykke, ikke kun hvad angår en performance i VM systemer der fik NetScape til at importere phkmalloc i deres browser, noget jeg første opdagede da den flere år efter blev open source.
Men vigtigere var det lykkedes at sætte en ny standard indenfor sikkerhed hvor phkmalloc satte nye normer for hvad en produktionsmalloc skulle finde sig i af kodefejl, før den brokker sig.
Det gik så galt at phkmalloc fik et ufortjent ry for ligefrem at beskytte imod fejlagtig brug og det gjorde en gut jeg aldrig har mødt så vred, at han brugte seks måneder på at bevise at en sikkerhedsfejl i CVS faktisk godt kunne udnyttes selvom man brugte phkmalloc.
Men der var én ting phkmalloc ikke var god til: multi-thread programmer.
Jeg mener mig lovligt undskyldt, dem existerede der stort set ikke nogen af i 1994 og der var endnu færrere multi-CPU systemer at køre dem på, men ti år senere så verden meget anderledes ud.
Jeg gad ikke skrive en memory-allokator igen ti år efter, men det havde Jason Evans mod på og så fik vi jemalloc der er et utroligt kompetent stykke arbejde.
Og den har Firefox adopteret.
Hvis jeg havde siddet hos en eller anden UNIX leverandør og skrevet en god malloc, så havde deres kunder naturligvis draget fordel af det.
Med Open Source bliver god kode til fordel for flere.
Det bliver jeg naturligvis ikke rig af, men der er så mange andre værdier end penge her i livet.
phk
Om Poul-Henning KampKommentarer (7)
Anerkendelse er dyr at købe, men kan til tider erhverve ved at donere sin egen tid.
Ikke at jeg har skrevet noget ala phkmalloc. Er dog kommet med på FreeBSD teamet.
Som du nævte, du skrev noget det blev brugt, men du brændte ikke for at skrive "ver. 2".
Jeg har det lidt på samme måde, dog er geomgui aldrig nået ver. 1.0.
Jeg har ingen ide om der er nogen som rent faktisk bruger geomgui, da hvis noget bruger programmet måske kunne inspirere mig til at gøre noget ved det.
/Søren
-
0 -
0
Ja, det virker som om listen over ting som computerverdenen kan takke phk for er ved at være ret lang. Keep up the good work :)
-
0
-
0
Et godt spørgsmål vdr. virtuel memory er hvordan sprog, der benytter "garbage colletede" hukommelseshåndtering undgår situationer, hvor hukommelse, der er paged ud til disk skal hentes ind i hukommelsen for at blive undersøgt og evt frigivet igen!?
Jeg husker et gammelt reklame-korstog fra Don Box, hvor han viser hvordan C# (der jo anvender garbage colletion) er en faktor ti (eller mere) hurtigere end C++ for et lille demo eksempel, hvor koden i de to sprog er ens på overfladen (brug af new allokatoren). Jeg undersøgte koden, og kom frem til at det var en best-case scenario for C#; C++'s stack allokering var altid en faktor ti hurtigere en C#, mens C++'s new allokator er ca en faktor 100 langsommere en stakken.
Et andet resultat er at "garbage colletede" sprog kører langsommere jo mere hukommelse du allokere...se mere her: http://frigaard.homelinux.org/pub/the_toll_of_garbage_collection.pdf
I samme forbindelse skrev jeg en "Garbage collector" til brug i C++, der dog ikke virker i multitrådet kode...
mvh
.carsten
-
0
-
0
Et godt spørgsmål vdr. virtuel memory er hvordan sprog, der benytter "garbage colletede" hukommelseshåndtering undgår situationer, hvor hukommelse, der er paged ud til disk skal hentes ind i hukommelsen for at blive undersøgt og evt frigivet igen!?
En af de første ting der mangler her, er en måde at fortælle kernen at man ikke skal bruge indholdet mere.
I FreeBSD lavede vi to options til madvise(2): MADV_DONTNEED der betyder at indholdet af siderne ikke skal bruges mere og MADV_FREE der siger at hverken indholdet eller siderne skal bruges mere.
På den måde kan man i free(3) forhindre kernen i at page sider ind/ud som applikationen ikke længere har interesse i.
Desværre virker det kun på VM-page niveau (4K) så det er kun store objekter der kan drage nytte deraf.
Poul-Henning
PS: Den sjove historie er så, at så snart RAM priserne begyndte at falde, holdt de op med at virke helt efter hensigten og de er først blevet fixet her for et par uger siden igen :-)
-
0
-
0
Optimering af free(3) hjælper vist ikke det basale problem en fx. mark-sweep garbage-collector har, at den skal kværne hele adresserummet igennem, hvorved alting pages ind først.
-
0
-
0
Optimering af free(3) hjælper vist ikke det basale problem en fx. mark-sweep garbage-collector har, at den skal kværne hele adresserummet igennem, hvorved alting pages ind først.
Det er faktisk ikke helt rigtigt. I VM systemer bør et fornuftigt design skille "sideværts" referencer ud fra lokale data i en struktur.
På den måde slipper man for at page 3-4 strukturer af 4K ind, blot for at flytte et element lidt op ad listen.
De sideværts referencer samler man i en lille struktur der allokeres separat, dem kan man så pakke 20-40 stykker af sammen i en VM page.
Poul-Henning
-
0
-
0
dem existerede der stort set ikke nogen af i 1994 og der var endnu færrere multi-CPU systemer at køre dem på
Det afhænger lidt af om du snakker mærker eller udbredelse.
Vi købte selv en Stratus/Olivetti CPS32/IBM System 88 i 1987 til decentral børshandel.
http://en.wikipedia.org/wiki/Stratus_Technologies
Ud over det der står var et af target customers også bilfabrikker hvor alting skal køre 24/7.
Det var en redundant 4 processor (SMP) kværn med VOS som OS, der ovenikøbet kunne opdateres on the fly. VOS kunne også køre multitasking, som vi i dag kalder multithreading.
Og ja, jeg kender godt forskel på multiprocessing og multitasking.
Af hensyn til support på SNA valgte vi den model med IBM som frontplade.
-
0
-
0
