Closed albbas closed 6 years ago
Date: 2017-03-12 09:58:47 +0100
From: Lene Antonsen <
Kompileringa av sme tar veldig lang tid no, spesielt etter de siste forbedringene i taggflytting. Hvis jeg har forstått det rett, så er det antall ordformer som krever taggflytting som tar tid?
Vi burde se på muligheter for å forkorte tida, her er et forslag fra meg, som kanskje har noe for seg, kanskje ikke:
Vi kunne gjøre slik som for propernoun, dvs at for de mest frekvente kombinasjonene av tagg og fortsettelsenleksikonene lages egne forts.leksikoner, f.eks. GOAHTI-A-hum, og at +Sem/Hum da legges til direkte i affix-fila: +N+Sem/Hum, evt +N+NomAg+Sem/Hum som så sendes videre til neste fortsettelsesleksikon for morfologi.
Sem/Dummytag og Sem/Hum dominerer både for substantiver og adjektiver, så disse to ville være kandidater:
grep 'Sem/' src/morphology/stems/nouns.lexc | tr '+:' '\n' | grep Sem |sort | uniq -c | sort -nr 20344 Sem/Dummytag 10132 Sem/Hum 4563 Sem/Org
grep 'Sem/' src/morphology/stems/adjectives.lexc | tr '+:' '\n' | grep Sem |sort | uniq -c | sort -nr 5617 Sem/Dummytag 3543 Sem/Hum 66 Sem/Plc
Fordelinga av Sem/Dummytag og Sem/Hum på fortsettelsesleksikoner:
grep 'Sem/Dummy' src/morphology/stems/nouns.lexc | sed 's/% /%/g' |tr -s ' ' | cut -d ' ' -f2 |sort | uniq -c | sort -nr |less 4146 GOAHTI-A 2489 JOHTOLAT 1681 GOAHTI-U 1614 GOAHTI-I 1595 LUONDU 1112 AIGI 1017 GAHPIR 630 MALIS ...
grep 'Sem/Hum' src/morphology/stems/nouns.lexc | sed 's/% /%/g' |tr -s ' ' | cut -d ' ' -f2 |sort | uniq -c | sort -nr |less 1942 GOAHTI-A 1833 ACTOR 1220 EADDJI-NomAg 722 GAHPIRLONG 700 JOHTOLAT 588 FALIS ...
grep 'Sem/Dummy' src/morphology/stems/adjectives.lexc | sed 's/% /%/g' |tr -s ' ' | cut -d ' ' -f2 |sort | uniq -c | sort -nr |less 754 ETNOLOGALAS 594 AGAdj 474 AHKASAS 287 DABALAS ...
grep 'Sem/Hum' src/morphology/stems/adjectives.lexc | sed 's/% /%/g' |tr -s ' ' | cut -d ' ' -f2 |sort | uniq -c | sort -nr |less 488 AHKASAS 421 AGAdj 248 JEAGOHEAPMI 213 BOAKKAS 173 EADDJI ...
Date: 2017-03-12 22:36:35 +0100
From: Trond Trosterud <
Her er eit anna forslag:
Viss eg forstår det riktig er ein viktig grunn til sme-tidsbruk at Make skal sjekke for nye semtaggar for kvar kompilering. Eit alternativ er å lausrive denne sjekkinga frå standard-make, slik at dei som lagar nye semtaggar skriv ./configure --enable-semtags && make for å generere nye semtagfilter (alle kan sjølvsagt gjere det same, men andvaret ligg på semantikarane).
På denne måten slepp vi at make sjekkar for nye semtaggar kvar gong.
Ei anna sak kan evt. vere å kutte ned på kompileringsstiar (forenkle og optimalisere lexc-koden)
Date: 2017-03-13 16:40:57 +0100
From: Sjur Nørstebø Moshagen <
(In reply to Trond Trosterud from comment #1)
Her er eit anna forslag:
Viss eg forstår det riktig er ein viktig grunn til sme-tidsbruk at Make skal sjekke for nye semtaggar for kvar kompilering. Eit alternativ er å lausrive denne sjekkinga frå standard-make, slik at dei som lagar nye semtaggar skriv ./configure --enable-semtags && make for å generere nye semtagfilter (alle kan sjølvsagt gjere det same, men andvaret ligg på semantikarane).
På denne måten slepp vi at make sjekkar for nye semtaggar kvar gong.
Trond sitt forslag vil fungera, men eg ville ha gjort det sik at semtaggfilteret blir laga automatisk, og at ein aktivt må slå det av. Det er nokre grunnar til det:
Ei anna sak kan evt. vere å kutte ned på kompileringsstiar (forenkle og optimalisere lexc-koden)
Mm, men det er eit separat prosjekt. Hovudutfordringa der er å gjera twolc-reglane enklare, og det er ikkje trivielt å få til. Det beste alternativet der er å reversera fst-ane før intersect - då går den proseessen mykje raskare. Det gjer ein ved å bruka denne opsjonen:
--enable-reversed-intersect
Med reversed-intersect blir hfst mykje raskare enn Xerox (i alle fall for den operasjonen). Eit anna triks er å bruka foma som fst-format, då slepp hfst det ekstra arbeidet med å handtera vekter, og foma er i seg sjløv eit raskt verkty. Ein slår på dette slik:
--with-backend-format=foma
Date: 2017-03-13 16:46:16 +0100
From: Lene Antonsen <
Bare til opplysning, det er ikke lenger snakk om noen minutter å vente, men minst en halvtime, eller kanskje en hel time, for å kompilere for apertium
Date: 2017-03-13 17:13:24 +0100
From: Sjur Nørstebø Moshagen <
(In reply to Lene Antonsen from comment #3)
Bare til opplysning, det er ikke lenger snakk om noen minutter å vente, men minst en halvtime, eller kanskje en hel time, for å kompilere for apertium
Når eg prata om nokre minutt, så gjaldt det spesifikt for semtagg-regexen.
Total kompileringstid etter 'make clean' er for meg:
$ time make -j [...] real 10m13.211s user 18m0.533s sys 0m57.369s
med denne konfigurasjonen:
./configure --with-hfst --without-xfst --enable-alignment --enable-reversed-intersect --enable-apertium --with-backend-format=foma
Ti minutt er framleis ein del meir enn det vi ynsjer oss, men langt i frå ein halvtime eller meir.
Date: 2017-03-13 17:22:01 +0100
From: Sjur Nørstebø Moshagen <
På maskina mi er kompileringstida for filteret for å flytta semantiske taggar:
$ time make reorder-semantic-tags.hfst HRGX2FST reorder-semantic-tags.hfst
real 2m50.741s user 2m49.509s sys 0m0.673s
Dvs at om vi kan hoppa over denne delen så burde heile kompileringstida for hfst for apertium bli på ca 7,5min.
På maskina mi, og med det oppsettet eg brukte i den førre kommentaren min.
Date: 2017-03-13 23:09:43 +0100
From: Trond Trosterud <
Vi har litt ulike kompileringstider, her er min sme (utan twolc-endringar):
$ ./configure --with-hfst --enable-apertium --enable-reversed-intersect $ time make -j3
real 95m1.134s user 163m15.313s sys 6m11.807s
Date: 2017-03-13 23:11:17 +0100
From: Trond Trosterud <
(In reply to Trond Trosterud from comment #6)
Vi har litt ulike kompileringstider, her er min sme (utan twolc-endringar): (dette er på 16 GB RAM, 2,6 GHz, dvs. 15" -macen)
Date: 2017-03-14 08:01:51 +0100
From: Trond Trosterud <
For referanse, sma: $ ./configure --with-hfst --enable-apertium --enable-reversed-intersect time make j3
real 12m31.300s user 24m21.118s sys 0m38.778s tf-hsl-m0016:sma ttr000$
Date: 2017-03-14 08:31:16 +0100
From: Sjur Nørstebø Moshagen <
Vi har faktisk ein vesentleg skilnad i kompileringstid:
for sma:
$ ./configure --without-xfst --with-hfst --enable-apertium --enable-reversed-intersect $ make clean $ time make -j
real 3m2.343s user 6m57.861s sys 0m15.309s
Tre minutt er heilt ok etter mi meining.
Kvifor er det då så stor skilnad? Eg ser to ting som du gjer ulikt meg:
1) du har ikkje med '--without-xfst', dvs at du kompilerer xerox-fst-ar samtidig = fleire filer å kompilera = lengre tid
2) du avgrensar deg til '-j3' i staden for '-j', dvs at du berre tillet make å byggja tre ting parallelt istf så mange som du har prosessorkjerner til. Eg har åtte prosessorkjerner, og kan byggja åtte filer samtidig - det er sjølvsagt at det får konsekvensar for samla byggjetid.
Attåt dette er det sjølvsagt skilnader i maskinvare. Eg har:
2,7 GHz Intel Core i7 med 16 Gb RAM (1600 MHz, DDR3)
dvs litt raskare enn maskina di, men ikkje så mykje at det burde bety mykje i denne samanhengen.
Date: 2017-03-17 13:00:07 +0100
From: Lene Antonsen <
(In reply to Trond Trosterud from comment #6)
Vi har litt ulike kompileringstider, her er min sme (utan twolc-endringar):
$ ./configure --with-hfst --enable-apertium --enable-reversed-intersect $ time make -j3
real 95m1.134s user 163m15.313s sys 6m11.807s
Jeg har for sme ./configure --with-hfst --enable-apertium --enable-reversed-intersect
real 49m8.136s user 103m45.715s sys 1m14.088s
Det er for lenge, synes jeg
Date: 2017-03-17 13:51:27 +0100
From: Lene Antonsen <
Jeg har for sme ./configure --with-hfst --enable-apertium --enable-reversed-intersect
real 49m8.136s user 103m45.715s sys 1m14.088s
Forskjellen med og uten xfst, er ikke så stor:
./configure --with-hfst --without-xfst --enable-apertium --enable-reversed-intersect
real 45m25.717s user 93m54.222s sys 1m3.298s
Date: 2017-03-17 15:33:38 +0100
From: Sjur Nørstebø Moshagen <
(In reply to Lene Antonsen from comment #11)
Jeg har for sme ./configure --with-hfst --enable-apertium --enable-reversed-intersect
real 49m8.136s user 103m45.715s sys 1m14.088s
Forskjellen med og uten xfst, er ikke så stor:
./configure --with-hfst --without-xfst --enable-apertium --enable-reversed-intersect
real 45m25.717s user 93m54.222s sys 1m3.298s
Eg mistenkjer at du i begge tilfelle byggjer med kommandoen:
$ make
og ikkje:
$ make -j
Trond skreiv at han bruker:
$ make -j3
Kan de begge prøva å bruka 'make -j' og sjå kor lang tid det tek? Skilnaden mellom med og utan -j er at utan så blir alle fst-ar bygde sekvensielt, dvs ein fst må bli ferdig før bygginga går til neste. Med -j så kan make laga mange ting samtidig, men med -j3 blir det avgrensa til 3 ting samtidig. Med standardkonfigurasjonen kan ein byggja fem fst-ar samtidig i src/-katalogen, og med dei fleste konfigurasjonane blir det meir enn det. make -j betyr difor mykje for å redusera byggjetida.
Date: 2017-03-17 16:39:56 +0100
From: Lene Antonsen <
Eg mistenkjer at du i begge tilfelle byggjer med kommandoen:
$ make
og ikkje:
$ make -j
Jeg glemte å skrive at jeg bruker make -j
Date: 2017-03-24 15:46:49 +0100
From: Lene Antonsen <
Jeg glemte å skrive at jeg bruker make -j
Jeg har 2,8 GHs Intel Core i7, 16 GB 1600 MHz DDR3 Dvs det samme som sjur (?). Hva er årsaka til at det er så stor forskjell i kompileringstid?
Date: 2017-04-11 10:59:19 +0200
From: Linda Wiechetek <
Ble det bestemt nå om man må slå av eller på nye semtagger? For min del passer det bedre å slå av ved behov, men det viktigaste er å vite ka vi må gjøre for å få med alt. Legger ikkje til tagger så ofte, da blir det lett å glemme hele prosessen.
Date: 2017-04-26 15:49:30 +0200
From: Lene Antonsen <
Trond og jeg testa Sjur sin configure med Foma, etter å ha tatt make clean, og det gjorde virkelig forskjell på kompileringstid. Dessverre viste det seg at dette ikke fungerer for Apertium, fordi det brukes vekting for å velge leksikaliserte sammensetninger framfor dynamisk sammensetning.
Så oppsettet som Sjur foreslår med å hoppe over biten med å generere regex for semtaggflytting, bortsett fra når det er nye semtagger, ville være veldig nyttig. Kanskje kunne vi sjekke inn selve regex-fila også, slik at det bare er en person som trenger å generere denne?
Date: 2017-12-12 09:22:15 +0100
From: Lene Antonsen <
Jeg minner om denne. Tagger i riktig rekkefølge og kompileringstid er veldig viktig for MT-arbeidet. Vi strever fremdeles med å få tagger i riktig rekkefølge, se bz 2340. Jeg har et forslag, nemlig å legge inn +N foran semtaggen i leksikonet, dvs kinoeahket+CmpN/SgN+CmpN/SgG+Sem/Time:kino#eahked GAHPIR ;
=> kinoeahket+CmpN/SgN+CmpN/SgG+N+Sem/Time:kino#eahked GAHPIR ; eller enda mer leselig:
kinoeahket+N+Sem/Time+CmpN/SgN+CmpN/SgG:kino#eahked GAHPIR ;
og selvfølgelig fjerne +N fra fortsettelsesleksikonet. Vil dette føre til at vi får ned kompileringstiden?
Jeg sette opp prioriteten av denne diskusjonen.
Date: 2017-12-12 18:41:35 +0100
From: Trond Trosterud <
Eg har ikkje tida her og no (og det varierer litt), men som regel tar sme-kompilering rundt ein time. Alle tiltak for å få ned kompileringstida er svært velkomne, og viss vi får den ned ved å flytte samtlege POS-taggar frå affixes inn i stems vil de vere verd det. For fin har vi det allereie slik.
Date: 2018-05-07 08:01:10 +0200
From: Sjur Nørstebø Moshagen <
Fiksa i innsjekkingane 162089-162094.
Det fungerer no slik at dei automatisk genererte filtra for semantiske taggar berre blir regenererte når det er faktiske endringar i taggane, dvs det er fjerna, lagt til eller endra taggar. I alle andre tilfelle blir ikkje filtra bygde på nytt, og dermed heller ikkje kompilerte.
I og med at det ikkje er kvar dag nokon legg til nye semantiske taggar burde dette vera ei ok løysing, som samtidig framleis held automatikken på plass, dvs at filtra alltid blir bygde på nytt når det trengst.
Date: 2018-05-07 08:02:44 +0200
From: Sjur Nørstebø Moshagen <
(In reply to Lene Antonsen from comment #16)
Trond og jeg testa Sjur sin configure med Foma, etter å ha tatt make clean, og det gjorde virkelig forskjell på kompileringstid. Dessverre viste det seg at dette ikke fungerer for Apertium, fordi det brukes vekting for å velge leksikaliserte sammensetninger framfor dynamisk sammensetning.
Dette er no endra i innsjekkingane 162130-162135. Dvs at vekta blir lagt til fyrst etter at kompileringa er ferdig med foma-formatet.
Eller sagt på ein annan måte:
Kompileringa bruker foma-format heilt til vi treng vekter, og resten går i eit vekt-venleg format.
Slik ser analysen ut no (giella-taggar):
$ echo biilabiila | hfst-lookup -q analyser-mt-gt-desc.und.hfstol
biilabiila biila+N+Cmp/SgNom+Cmp#biila+N+Sem/Veh+Sg+Nom 10,000000
biilabiila biila+N+Cmp/SgNom+Cmp#biila+N+Sg+Nom 10,000000
biilabiila biila+N+Sem/Veh+Cmp/SgNom+Cmp#biila+N+Sem/Veh+Sg+Nom
10,000000
biilabiila biila+N+Sem/Veh+Cmp/SgNom+Cmp#biila+N+Sg+Nom 10,000000
Ved å nytta denne konfigurasjonen:
./configure --with-hfst --without-xfst --enable-alignment --enable-reversed-intersect --enable-apertium --with-backend-format=foma
burde du få den raskaste kompileringa som er mogleg for nordsamisk med hfst. Hjå meg tek det (etter touch src/morphology/lexicon.tmp.lexc):
real 6m50.312s user 17m1.061s sys 0m58.244s
Hm, nei: om du berre vil ha apertium, så kan du i tillegg gjera dette:
./configure --with-hfst --without-xfst --enable-alignment --enable-reversed-intersect --enable-apertium --with-backend-format=foma --disable-analysers --disable-generators
Då blir ikkje dei vanlege analysatorane og generatorane laga, og apertium-kompileringa er så rask som det er mogleg. Det tek hjå meg:
real 4m11.164s user 6m26.661s sys 0m22.149s
Så oppsettet som Sjur foreslår med å hoppe over biten med å generere regex for semtaggflytting, bortsett fra når det er nye semtagger, ville være veldig nyttig. Kanskje kunne vi sjekke inn selve regex-fila også, slik at det bare er en person som trenger å generere denne?
Slik eg skreiv i kommentar 19, så er det òg på plass no, og det bidreg til trivelege kompileringstider.
Fint om de testar, og skriv her kva for kompileringstider de får.
Date: 2018-05-07 09:13:03 +0200
From: Trond Trosterud <
Bøttemac (3,7 GHz E5, 32GB ram): Dobbelt så dyr, men lang frå dobbelt så rask:
./configure --with-hfst --without-xfst --enable-alignment --enable-reversed-intersect --enable-apertium --with-backend-format=foma real 16m16.016s user 42m58.273s sys 0m32.365s
Med optimal konfigurering: ./configure --with-hfst --without-xfst --enable-alignment --enable-reversed-intersect --enable-apertium --with-backend-format=foma --disable-analysers --disable-generators real 8m37.577s user 12m2.387s sys 0m8.614s
Date: 2018-05-07 09:35:58 +0200
From: Sjur Nørstebø Moshagen <
(In reply to Trond Trosterud from comment #21)
Bøttemac (3,7 GHz E5, 32GB ram): Dobbelt så dyr, men lang frå dobbelt så rask:
Merk at eg i min fartstest ikkje tok make clean, berre touch src/morphology/lexicon.tmp.lexc, for å simulera det vanlegaste senariet: twolc er uendra, men leksikonet er oppdatert. Ut frå det du skriv verkar det som om twolc-kompileringa er med i bygginga, og då tek det jo så klart lenger tid.
Date: 2018-09-27 14:54:54 +0200
From: Lene Antonsen <
Jeg mener å huske at vi blei enige om å legge +N etter lemma. I smj er det nå masse analyser med semtaggen foran +N, og grunnen er i affixfilene fordi +N ikke er første tagg der. For Korp går det bra siden Ciprian skal filtrere bort taggene, men for all MT med smj som kildespråk blir det problemer.
This issue was created automatically with bugzilla2github
Bugzilla Bug 2355
Date: 2017-03-12T09:58:47+01:00 From: Lene Antonsen <>
To: Sjur Nørstebø Moshagen <>
CC: linda.wiechetek, thomas.omma, trond.trosterud
Last updated: 2018-09-27T14:54:54+02:00