fmmap weergawe 2.0.0

Ek het omtrent twee maande gelede fmmap op my webjoernaal bekendgestel. fmmap is ’n Python-module wat in die plek van die ingeboude mmap-module gebruik kan word en beter werkverrigting bied. Ek het weergawe 2.0.0 onlangs vrygestel en wou sommige van die afgelope twee maande se verbeterings deel.

Ek het ’n .rfind()-metode geïmplementeer wat gewoonlik heelwat vinniger is as die ingeboude implementasie. Daar is ’n skrip op github om die werkverrigting van .find() en .rfind() met CPython te vergelyk. Toekomstige weergawes gee waarskynlik nog meer aandag aan werkverrigting.

Vergeleke met die aanvang op my Linux-werkstasie, word die projek nou getoets op ’n klomp bedrystelsels:

  • Linux
  • FreeBSD, NetBSD, OpenBSD
  • Solaris (ek het op illumos/OpenIndiana getoets)
  • macOS
  • Windows

Die stelsels vir kontinue integrasie toets tans op Ubuntu 16.04 en 18.04, macOS 10.15 en Windows Server 2019. Verder toets ek met die hand op Mageia 7, RHEL 7, FreeBSD 11.3, NetBSD 8.2, OpenBSD 6.6, OpenIndiana 5.11, macOS 10.14 en Windows 10. Die stelsels vir kontinue integrasie en heelwat van die Unix-stelsels word op virtuele masjiene getoets.

Die projek ondersteun nou platforms wat nie die soekfunksies in die C-biblioteek het wat fmmap gebruik nie. Dit was nodig om Solaris, macOS en Windows te ondersteun.

Adviesparameters vir madvise(2) op alle ondersteunde platforms is bygevoeg — om hulle beskikbaar te maak in ouer Python-weergawes, maar om ook stelselspesifieke waardes te ondersteun wat nie deur CPython ondersteun word nie.

Die projek ondersteun nou Python weergawes 3.4–3.9. Nie alle kombinasies van bedryfstelsel en Python-weergawe word getoets nie, maar uit die 7 × 6-matriks (bedryfstelsel × Python-weergawes, 42 kombinasies) word 23 kombinasies getoets. Alhoewel daar ruimte is vir verbetering, is heelwat van die ongetoetste kombinasies vir Python 3.4 (wat deur meeste platforms nie ondersteun word nie) en vir Python 3.9 (wat nog nie amptelik vrygestel is nie). As dié twee weergawes geïgnoreer word, word 20 uit die 28 kombinasies getoets.

Ek het nog ’n paar dinge in gedagte vir die toekoms. Alhoewel ek meestal tevrede is met die soekspoed, is daar steeds ruimte vir verbetering weens die wisselende spoedeienskappe van die funksies in die C-biblioteke. (Ek het deur die relevante implementasies van al die C-biblioteke met beskikbare kode gelees.) Ek is onseker of verdere werk aan werkverrigting die moeite werd is, maar miskien is betekenisvolle verbeteringe steeds moontlik. Alhoewel soekspoed die aanvanklike rede vir die projek was, oorweeg ek ook op die programmeerkoppelvlak (API) effens uit te brei om enkele gebruike van geheue-afbeelding te ondersteun.

Django compression middleware genoem in die Django speed handbook

’n Rukkie terug het ’n kollega my verwys na die Django speed handbook. Hierdie gids vir Django-werkverrigting het raad vir verskillende vlakke van ’n tipiese Django-toepassing: die databasis, die netwerk en die voorkant. Dit lyk na ’n versameling goeie advies vir Django-programmeerders om hulle webwerwe vinniger te maak.

My projek, Django compression middleware, word aanbeveel vir die saampersing van antwoorde vanaf die bediener. Dit was lekker toe ek sien dat daar verwys word na my projek as “the excellent django-compression-middleware library”. Dankie Shibel K. Mansour!

Bekendstelling van fmmap

Ek het onlangs kode wat nog rondgelê het, afgestof en nou kan ek fmmap bekendstel. Dit is ’n Python-module wat in die plek van die ingeboude mmap-module gebruik kan word en bied beter werkverrigting. Self het ek spesifiek in ’n vinniger .find()-metode belanggestel. Die “f” in fmmap verwys dalk na “find”, “fast”, of iemand se naam.

Geheue-afbeelding (Eng. memory mapping) is ’n benadering om lêertoegang soos ’n skikking te laat werk. Daar word nie eksplisiet gelees of geskryf na die lêer nie. Tydens toegang tot hierdie gedeelte van die geheue bestuur die bedryfstelsel die toevoer en afvoer na die onderliggende lêer soos nodig. Dit kan in sommige gevalle lei tot beter werkverrigting.

Toe ek mmap ’n paar jaar gelede in ’n eie program probeer het, het dit met werkverrigting gehelp. Toe sien ek dat die .find()-metode in CPython, alhoewel dit in C geïmplimenteer is, ’n naïewe algoritme gebruik, en ek wou sien of ek werkverrigting verder kon verbeter. Eers het ek probeer om sommige van glibc se algoritmes in ’n Cython-module te implementeer, maar het uiteindelik die beste werkverrigting gekry deur die geoptimeerde funksies in glibc te gebruik. Die hele proses het ook my kennis van die C-funksies vir stringe en geheue verbeter en verfris.

Nou het ek besluit om die kode na ’n eie projek te skuif. ’n Volledige plaasvervanger vir die ingeboude mmap-module het vir my na die beste manier gelyk om hierdie aan ander beskikbaar te stel. Dit bring natuurlik al die voordele en minder aangename oorhoofse koste van projekinfrastruktuur, toetse, kontinue integrasie, en die herontdekking van Python-verpakking in die ewig veranderende omgewing. Omdat ek ’n kindklas van die ingeboude klas maak, het ek gedink ek hoef net die dele van belang te implementeer. In ’n poging om alles goed te doen, kry ek die standaardbiblioteek (CPython) se toetse om my implementasie mee te toets. Die toetse van die PyPy-projek is nie presies dieselfde nie. Dus gooi ek dit sommer ook in die pot. Dit blyk toe ’n goeie idee te wees, omdat dit ’n paar foute uitgewys het wat die standaardbiblioteek nie gewys het nie.

Die toetssuite van die standaardbiblioteek ontwikkel oor tyd, en die huidige weergawe in git is gemik op die komende vrystelling (Python 3.9). In my poging om ’n goeie burger van die Python-wêreld te wees, probeer ek om so veel Python-weergawes as moontlik te ondersteun. Elke Python-weergawe voeg egter toetse by wat weens foutregstellings, funksionaliteit en koppelvlakveranderinge nie werk op vorige weergawes nie. Ek kan dus nie met ouer Python-weergawes (nie eens Python 3.8) op die toetssuite toets sonder moeite nie. Gevolglik word my projek om een funksie aan die wêreld te bied ’n hele projek vir die terugplasing van al die jongste funksionaliteit. Volgens die toetssuite werk dit nou in Python 3.5 – 3.8 en ek sal die een oorblywende probleem op Python 3.4 maklik as deel van ’n verbeterde weergawe van .rfind() regmaak.

Ek het nog nie werkverrigting oordentelik gemeet nie, maar .find() is dalk aansienlik vinniger met fmmap. Die presiese werkverrigting hang aansienlik af van die C-biblioteek. Laat weet hoe goed dit werk!

My praatjie by PostgresConfZA

Ek het vandag ’n praatjie aangebied oor PostgreSQL-werkverrigting in die amaGama-projek by Suid-Afrika se Postgres-kongres. Die praatjie het agtergrond gegee oor vertaalgeheuestelsels en ook bespreek hoe die amaGama-projek PostgreSQL se volteksfunksionaliteit gebruik.

Soos mens in die opsomming kan lees, kon ek ’n reuseverbetering aan die databasis se werkverrigting maak. Gebruikers van die weergawe wat ons huisves, baat al reeds vir die afgelope paar weke by die verbeterde werkverrigting.

’n Interessante aspek van hierdie werk is hoe die gedeeltelik oorvleuelende parsiële indekse gekomplementeer word deur die beter fisiese uitleg op die skyf (bereik met die CLUSTER-opdrag). Die werkverrigting is beter in beide die geval van warm of koue kasgeheue.

Ek glo ’n video sal mettertyd beskikbaar gemaak word. Geluk aan die organiseerders vir ’n baie aangename geleentheid!

(Nuut in Oktober 2020: ’n video van die praatjie is nou beskikbaar.)

Fris en vars amaGama

Ek het onlangs weer begin werk om die bediener en diens van die amaGama-vertaalgeheue te verbeter. Die projek verskaf ’n vertaalgeheuestelsel wat deur vertaalprogramme soos Pootle en Virtaal gebruik word. Die webdiens wat die Translate-projek huisves, bevat vertalings van verskeie populêre vry en oopbronsagtewarepakkette. Dit verskaf aan vertalers in meer as ’n honderd tale voorstelle vanuit vorige vertaalwerk in die lokalisering van vry en oopbronsagteware. Verskeie areas van amaGama benodig werk en ek wou mooi prioritiseer sodat ek ’n redelike aantal doelwitte bereik.

Eerstens het die bediener self nie die nodige aandag geniet die afgelope ruk nie. Die diens het glad nie gereageer nie, en ’n klomp bywerkings was nodig. Ek het reeds die bedryfstelsel opgegradeer, maar die stelselkonfigurasie moes ook hersien word. Gebruikers van Virtaal sal bly wees om te hoor dat ek die nodige veranderinge geïmplementeer het sodat die amaGama-inprop in Virtaal weer werk. Op die bediener werk dinge nou ten minste so goed as vantevore, en beter in ’n paar opsigte.

Werkverrigting van die diens was vir baie jare al inkonsekwent. Daar is verskeie redes, insluitend die bedieneropstelling en die kode self. Ek het al verskeie kere versoeke gesien wat meer as tien sekondes neem. ’n Vertaalgeheueantwoord wat só laat kom sal nie sommer nuttig wees nie. Teen daardie tyd het ek waarskynlik al die hele segment van nuuts af vertaal en aanbeweeg. Ek glo meeste gebruikers wil ’n antwoord in minder as ’n sekonde hê. Aangesien netwerkwagtyd op sigself langer as dit kan neem, moet die webdiens self regtig so vinnig as moontlik wees.

Ek hoop om binnekort te skryf oor interessante veranderinge aan die kode vir beter werkverrigting, maar ek het reeds dinge verbeter met eenvoudige veranderinge aan die opstelling. Terwyl sekere databasisnavrae stadig is, help die gelyktydige hantering van ander navrae dat ander gebruikers meestal ongeaffekteerd is, en daardeur word die impak van swak werkverrigting in een versoek beperk. Voorheen het die bediener slegs een versoek op ’n slag hanteer—ek het geen idee hoekom dit so opgestel is nie. Sommige versoeke neem steeds meer as 10 sekondes, maar dit gebeur nie meer so gereeld nie. Die stadige antwoorde verdien ’n skryfstuk of twee op sigself, en ek werk nog hieraan. (Bywerking: Ek het intussen hieroor gepraat by PostgresConfZA.)

Die huidige databasis (die geheue van vertalings) op die bediener is nou al redelik oud. Ek het ook begin werk aan vars data. Dit is amper ’n hele projek op sigself! Baie projekte het hulle weergawebeheerstelsels in die afgelope paar jare geskuif, en in ’n paar gevalle kan ek sommige dinge wat ons vantevore ingesluit het in die databasis nie meer maklik kry nie. As daar spesifieke projekte is wat iemand dink in amaGama ingesluit moet word, kontak my gerus.

Nog ’n doel van al my werk is om te belê in dinge wat toekomstige bydraes vergemaklik. Die bedieneropstelling is eenvoudiger, die opstelling van die webdiens is uit die kode geskuif, ens. Hopelik beteken dit dat ’n klein groep vrywilligers (al is dit so klein as net ekke) hierdie vir nog ’n hele ruk aan die gang kan hou.

Django compression middleware ondersteun nou Zstandard

Ek dink ek het die eerste keer van Zstandard (zstd) gehoor in ’n joernaalinskrywing deur Gregory Szorc. Ek sien toe op ’n stadium dat zstd ook in IANA se content coding registry vir HTTP geregistreer is, en ek probeer toe uit te vind hoeveel van die web-ekosisteem reeds daarvoor ondersteuning het. Soos ek onthou was daar op daardie stadium slegs aanvanklike steun vir zstd in Nginx, en niks anders nie.

Dinge lyk nog nie veel beter nie, maar zstd het steeds verbeter en is deur heelwat projekte opgeneem vir toepassings buite die web. Toe ek onlangs kyk, sien ek een HTTP-kliënt, wget2, wat sê dat dit zstd ondersteun. Ek besluit toe om Django compression middleware uit te brei met ondersteuning vir zstd en dit te toets met wget2. Met wget2 kan ek seker maak dat ten minste een webkliënt die middelware se afvoer kan hanteer.

Ek het ’n paar dae gelede weergawe 0.3.0 van Django compression middleware vrygestel met ondersteuning vir zstd. Aangesien ek nie van enige webblaaiers weet wat dit al ondersteun nie verwag ek nie dat veel mense hieroor opgewonde sal wees nie. Daar is nog nie eens inligting op die Can I use …-webwerf oor zstd nie (github-verslag). Ek sien hierdie egter as my klein bydrae tot die ekosisteem.

Dit is nie duidelik dat Zstandard ’n aansienlike verbetering oor die alternatiewe is in alle gevalle nie, maar my toetswerk op verskeie HTML- en JSON-lêers dui daarop dat dit meestal die selfde of beter as Brotli is, en eintlik altyd beter as gzip (met die verstekwaardes wat ek tans gebruik). “Beter” beteken in hierdie geval ’n kleiner afvoer wat in die selfde of korter tyd gelewer word.

Django compression middleware ondersteun nou zstd, Brotli en gzip.

Verstaan die internet jou taal?

Ek het vanoggend ’n advertensie op die radio gehoor waar ’n seun met sy pa praat oor een of ander besigheid. Hy verwys sy pa na die webadres, en—aangesien die advertensie in Afrikaans is en hy die adres in Engels spel—noem hy “Die internet verstaan nie Afrikaans nie”. Ek probeer te dink hoekom die skrywer van die advertensie gedink het dit sal dinge verbeter om daardie stukkie in die dialoog in te sluit.

Ek moet natuurlik meestal saamstem—die Internet verstaan nie Afrikaans nie, maar dit verstaan ook nie Engels of enige ander taal nie. Miskien het die organisasie bloot sleg gevoel omdat hulle nie ’n Afrikaanse teenwoordigheid op die web het nie, of weet dalk nie hoe maklik dit is om nog ’n domein te registreer as ’n alias vir die hoofwerf nie.

Uit ’n ander hoek gesien, programme wat inligting op die web verwerk kan ongelooflike dinge doen met die inligting op die web—in Engels, Afrikaans en ander tale. Ek ignoreer nie die feit dat tegnologiesteun vir tale nie gelyk is nie, maar domeinname is net karakters—mens kan daar intik net wat mens wil (ek ignoreer natuurlik die kompleksiteite van Internasionale Domeinname).

Ek werk met taaldata vir my brood en botter, dus was dit ’n jammer herinnering aan die algemene persepsies oor taal en tegnologie. Ek hoop luisteraars kon dit bevraagteken, of ten minste begin dink oor hoe dit verander kan word.

My referaat by OLC / DEASA

Ek het gister ’n referaat gelewer by die Open Learning Conference van Distance Education Association of Southern Africa. Die titel van my artikel is “Re-evaluation of multilingual terminology”. Ek het die punt probeer maak dat terminologiehulpbronne as meer as blote verwysingsbronone kan dien. Ek het konkrete voorbeelde gegee van hoe dit ook kan help met konsepsuele modellering.

Ontologie-ingenieurswese is ’n belangrike deel van die veld van natuurliketaalverwerking, maar ek ontmoet steeds gereeld akademici wat dink die hoogste doel waarna ons moet streef is terme met vertalings (moontlik met definisies). My voorlegging was ’n poging om ’n breër visie te gee.