Re: [Moses-support] Faster decoding with multiple moses instances

[Vincent Nguyen]

After many tests, as mentioned before I had made these changes in EMS
score-settings = "--GoodTuring --MinScore 2:0.001"
and
pop limit cube pruning at 400 (instead of 5000 in EMS )

speed is much much higher (without impact on translation)

Le 05/10/2015 17:20, Philipp Koehn a écrit :

Hi,

with regard to pruning ---

the example EMS config files have

[TRAINING]
score-settings = "--GoodTuring --MinScore 2:0.0001"

which carries out threshold pruning during phrase table construction, 
going a good way towards avoiding too many translation options per phrase.


-phi

On Mon, Oct 5, 2015 at 11:08 AM, Barry Haddow > wrote:


Hi Hieu

That's exactly why I took to pre-pruning the phrase table, as I
mentioned on Friday. I had something like 750,000 translations of
the most common word, and it took half-an-hour to get the first
sentence translated.

cheers - Barry


On 05/10/15 15:48, Hieu Hoang wrote:

what pt implementation did you use, and had it been pre-pruned so
that there's a limit on how many target phrase for a particular
source phrase? ie. don't have 10,000 entries for 'the' .

I've been digging around multithreading in the last few weeks.
I've noticed that the compact pt is VERY bad at handling unpruned
pt.
Cores   
1   5   10  15  20  25
Unprunedcompact pt  143 42  32  38  52  62
probing pt  245 58  33  25  24  21
Pruned  compact pt  119 24  15  10  10  10
probing pt  117 25  25  10  10  10



Hieu Hoang
http://www.hoang.co.uk/hieu

On 5 October 2015 at 15:15, Michael Denkowski
> wrote:

Hi all,

Like some other Moses users, I noticed diminishing returns
from running Moses with several threads.  To work around
this, I added a script to run multiple single-threaded
instances of moses instead of one multi-threaded instance. In
practice, this sped things up by about 2.5x for 16 cpus and
using memory mapped models still allowed everything to fit
into memory.

If anyone else is interested in using this, you can prefix a
moses command with scripts/generic/multi_moses.py.  To use
multiple instances in mert-moses.pl ,
specify --multi-moses and control the number of parallel
instances with --decoder-flags='-threads N'.

Below is a benchmark on WMT fr-en data (2M training
sentences, 400M words mono, suffix array PT, compact
reordering, 5-gram KenLM) testing default stack decoding vs
cube pruning without and with the parallelization script
(+multi):

---
1cpu   sent/sec
stack  1.04
cube   2.10
---
16cpu  sent/sec
stack  7.63
+multi12.20
cube   7.63
+multi18.18
---

--Michael

___
Moses-support mailing list
Moses-support@mit.edu 
http://mailman.mit.edu/mailman/listinfo/moses-support




___
Moses-support mailing list
Moses-support@mit.edu 
http://mailman.mit.edu/mailman/listinfo/moses-support



The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

___
Moses-support mailing list
Moses-support@mit.edu 
http://mailman.mit.edu/mailman/listinfo/moses-support

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.




___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support


___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

[Moses-support] KenLM poison

[徐同学]

Hi,

Yes, you are right. I released some space, and it’s working now. 
The error message could have been clearer anyway.
Thank you, Ken.

Best,
Fangting


> 
> Message: 2
> Date: Mon, 5 Oct 2015 15:15:20 +0100
> From: Kenneth Heafield <mo...@kheafield.com>
> Subject: Re: [Moses-support] KenLM poison
> To: moses-support@mit.edu
> Message-ID: <561285f8.2030...@kheafield.com>
> Content-Type: text/plain; charset=UTF-8
> 
> Hi,
> 
>   I'm still betting it's out of disk space writing the ARPA.
> Multithreaded exception handling is annoying.  This is there to prevent
> deadlock.
> 
> Kenneth
> 
> On 10/05/2015 01:52 PM, ??? wrote:
>> Dear all,
>> 
>> I?m building the baseline system, and some error occurred during the
>> last step of LM training process as the first attached file shows. 
>> 
>> I checked another case of ?Last input should have been poison?, but that
>> one has more detailed information ?no space left on device?, while mine
>> has nothing but that sentence.
>> 
>> The exact command I use for Kenlm is: 
>> $MOSES/bin/lmplz -o 3 < ~/es-fi/OpenSubtitles2013.es-fi.true.fi
>> <http://opensubtitles2013.es-fi.true.fi/> > OpenSubtitles2013.es-fi.arpa.fi
>> <http://opensubtitles2013.es-fi.arpa.fi/>
>> 
>> As mosesdecoder is installed at the administrator?s directory instead of
>> my own, "~/mosesdecoder "is replaced by $MOSES. 
>> 
>> my corpus(the language pair is Spanish to Finnish) was downloaded from
>> Opus(http://opus.lingfil.uu.se/OpenSubtitles2013.php) in the Moses format.
>> 
>> The downloaded profile contains three files:  OpenSubtitles2013.es-fi.es
>> <http://OpenSubtitles2013.es>, OpenSubtitles2013.es
>> <http://OpenSubtitles2013.es>-fi.fi <http://OpenSubtitles2013.fi>,
>> and OpenSubtitles2013.es <http://OpenSubtitles2013.es>-fi.ids. 
>> 
>> The tokenization, truecasing and cleaning are all completed with the
>> ?es" and ?fi? files. Is it possible if the error has something to do
>> with the ?ids? file? 
>> 
>> Here attaches the output of LM process, and the command I used for
>> corpus preparation. 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>> 
> 
> 
> --
> 
> Message: 3
> Date: Mon, 5 Oct 2015 10:15:45 -0400
> From: Michael Denkowski <michael.j.denkow...@gmail.com>
> Subject: [Moses-support] Faster decoding with multiple moses instances
> To: Moses Support <moses-support@mit.edu>
> Message-ID:
>   <CA+-GegK2xqzHz2G39eRe=3vsbfjttocwtfongmsr4dgagza...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi all,
> 
> Like some other Moses users, I noticed diminishing returns from running
> Moses with several threads.  To work around this, I added a script to run
> multiple single-threaded instances of moses instead of one multi-threaded
> instance.  In practice, this sped things up by about 2.5x for 16 cpus and
> using memory mapped models still allowed everything to fit into memory.
> 
> If anyone else is interested in using this, you can prefix a moses command
> with scripts/generic/multi_moses.py.  To use multiple instances in
> mert-moses.pl, specify --multi-moses and control the number of parallel
> instances with --decoder-flags='-threads N'.
> 
> Below is a benchmark on WMT fr-en data (2M training sentences, 400M words
> mono, suffix array PT, compact reordering, 5-gram KenLM) testing default
> stack decoding vs cube pruning without and with the parallelization script
> (+multi):
> 
> ---
> 1cpu   sent/sec
> stack  1.04
> cube   2.10
> ---
> 16cpu  sent/sec
> stack  7.63
> +multi12.20
> cube   7.63
> +multi18.18
> ---
> 
> --Michael
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> http://mailman.mit.edu/mailman/private/moses-support/attachments/20151005/ec781c46/attachment-0001.html
> 
> --
> 
> Message: 4
> Date: Mon, 5 Oct 2015 15:24:51 +0100
> From: Hieu Hoang <hieuho...@gmail.com>
> Subject: Re: [Moses-support] Do debugging in the decoder?
> To: Matthias Huck <mh...@inf.ed.ac.uk>
> Cc: moses-support <moses-support@mit.edu>
> Message-ID:
>   <caekmkbi5d3lhvyfd8zfynm0xuxdybrdge+jgx8ng-y6zgwv...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> You can use gdb to 

Re: [Moses-support] Do debugging in the decoder?

[Yuqi Zhang]

Thanks a lot,  Matthias and Hieu!

I have the debug version in Eclipse already and can compiled it without
errors.
I could follow the debugging until to decoder(translation):

 pool.Submit(task); // in Exportinterface.cpp

I didn't find a way to see what happen in the 'translation' task, e.g. how
a source segment looks for its translations in PT. Is there a way to let me
know what happened in 'translation' task?

Thanks!

Best regards,

Yuqi

2015-10-05 1:07 GMT+02:00 Hieu Hoang :

> i think it might be
>./bjam  variant=debug
> not
>   ./bjam ... --variant=debug
>
> Also, please git pull. There was a minor compile error when using this
> option, which has now been fixed
>
> https://github.com/moses-smt/mosesdecoder/commit/72bef00781de9821f2cff227ca7417939041d4e1
>
>
> On 04/10/2015 23:25, Matthias Huck wrote:
>
>> Hi Yuqi,
>>
>> You can build a debug compile by calling bjam with:
>>
>> --variant=debug
>>
>> Cheers,
>> Matthias
>>
>>
>> On Sun, 2015-10-04 at 23:05 +0200, Yuqi Zhang wrote:
>>
>>> Hello,
>>>
>>>
>>> How can I debug the decoder?
>>>
>>>
>>> Must I turn off the pre-compile signal "WITH_THREADS"?
>>> Can it be turned off? (Since I have a try, but some head files
>>> regarding threads are always included.)
>>> Or is there any other way to allow me to get into the decoder?
>>>
>>>
>>> Thanks a lot!
>>>
>>>
>>> Best regards,
>>> Yuqi
>>>
>>>
>>>
>>>
>>> ___
>>> Moses-support mailing list
>>> Moses-support@mit.edu
>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>
>>
>>
>>
> --
> Hieu Hoang
> http://www.hoang.co.uk/hieu
>
>
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] (no subject)

[Rico Sennrich]

Hello Sanjanasri,

Basically, you can forget all results that you obtained without tuning. 
They are not a meaningful indicator of the quality of NPLM. If you add a 
new language model, the weight of the other language models, translation 
models etc. needs to be balanced accordingly, and that is what tuning does.


If you do tuning every time you add/remove/change a model, you can 
modify your moses.ini any way you want, and you do not need to specify 
all models during training. But again, don't make conclusions without 
tuning for each modified moses.ini. I know this will slow down your 
experiments, but that's the only way to produce new knowlege.


setting num_hidden to zero is a bit of a hack, because NPLM normally has 
two hidden layers (and num_hidden gives the size of the first hidden 
layer). If we want to use NPLM in decoding, we only want one hidden 
layer for speed, hence num_hidden=0 [output_embedding_dimension is the 
size of the remaining hidden layer]. The vocabulary size thing was a 
guess. I don't know what the best vocabulary size would be for you, but 
I tend to recommend smaller vocabularies if you have less data.


best wishes,
Rico


On 05/10/15 17:14, Sanjanashree Palanivel wrote:

Dear Rico,

Thanks a lot.  I will increase the number of hidden layers, 
currently the parameter num_hidden is fixed as Zero. I did not tune 
the system just working with baseline. Will do tuning too. But, why 
smaller vocabulary size, what is the reason?. It should be my mistake, 
the testset may not be an disjoint set i guess.I will check. I got two 
more doubts. Please clarify.



 1) Can I use two or more LMs (specifically NPLMs with different 
vocabulary size)  in moses.ini file or should i use LMs that are used 
in training phase. Ex: Can I use SRILM or RANDLM directly to moses.ini 
file without specifying in training phase.


 2) I just did little tinkering in moses.ini file for English-Hindi MT 
System to understand the influence of LM. I trained the system with 
KENLM of order 3. But, in *.ini file, the replaced the lm to 5-order 
KENLM binary file. Let me name the *.ini file as dummy 5-KENLM. The 
Bleu of Score of dummy 5-KENLM (14.72) is higher than the 3-order 
KENLM (12.53) , though the Bleu score is lesser than the model 
actually trained with 5-KENLM (17.43).  I understand, what i modified 
in *.ini does not make any sense. But, I wish to know,  why score is 
higher for dummy 5-KENLM than 3-KENLM.




On Mon, Oct 5, 2015 at 7:07 PM, Rico Sennrich > wrote:


Hi Sanjanasri,

1) your corpus is very small, and you may have to use more
iterations of NPLM training and smaller vocabulary sizes. Just to
double-check, are you tuning your systems? MERT (or PRO or MIRA)
should normally ensure that adding a model doesn't make BLEU go down.

2) I'm not sure which perplexity is for which model, but lower
perplexity is better, so this makes sense.

3) a perplexity of 3 is *extremely* low. Do you have overlap
between your test set and your training set? This would be an
unrealistic test setting, and would explain why KenLM does so much
better (because backoff n-gram models are good at memorizing things).

best wishes,
Rico



On 05.10.2015 09:27, Sanjanashree Palanivel wrote:

Dear Rico,

 I tried using KENLM and NPLM for three language
pairs. And I came across series of questions . I am listing it
one by one. It would be great if you could guide me.


1) I did testing for NPLM with different vocabulary sizes and
training epochs. But, the bleu score, I gained from NPLM
integrated with KENLM is smaller than the one I trained with
KENLM. In all the three language pairs I get a standard
difference of three.

Eg: English to Hindi (KENLM-17.43, NPLM+KENLM-14.27)
  Tamil to Hindi (KENLM-16.66,NPLM+KENLM-13.53)
   Marathi to Hindi (KENLM-29.42,NPLM+KENLM-25.76)

 The sentence count is 103502. unigram count is 89919. I gave
vocabulary size as 89000,89700,89850 with validation size
200,200,100 respectively and with different learning rate and
epocs. However, I am getting Bleu score of NPLM and KENLM is lesser.


2)The Bleu score of the model having perplexity about 385 has
higher Bleu score than the one having pp around 564 .  Is this
rite model. I mean the model with lower perplexity seems to give
better Bleu score. Where am I doing worng.


3) I used query script for KENLM model. I found perplexity to
3.4xx. But, the Bleu score of KENLM alone in decoding phase gives
Blue of 16.66 for English to HIndi MT. But, when combined with
NPLM I get only 13.53.

On Sun, Sep 20, 2015 at 8:07 PM, Sanjanashree Palanivel
> wrote:

Dear Rico,

Thanks a lot for your excellent guidance.

On Sat, Sep 

[Moses-support] Sixth Workshop on Patent and Scientific Literature Translation (PSLT 2015)

[Takashi Tsunakawa]

Dear Moses-support ML members,

I introduce the Call for Participation of The 6th Workshop on Patent and 
Scientific Literature Translation (PSLT 2015) held at MT Summit XV.

[Apologize for multiple copies]

CALL FOR PARTICIPATION
-- The 6th Workshop on Patent and Scientific Literature Translation 
(PSLT 2015) –

Held as a part of Machine Translation Summit XV
Miami, Florida, USA
October 30, 2015
WORKSHOP WEBSITE: http://www.aamtjapio.com/pslt2015

REGISTRATION: Registration to the workshop is available via Machine 
Translation Summit XV website: http://www.amtaweb.org/mt-summit-xv/

PROGRAM:
  9:00- 9:10   Opening

  9:10-10:30   Session 1 (MT in Patent Organizations)
 9:10- 9:50   [Invited talk] Bruno Pouliquen (World Intellectual 
Property Organization)
  Full-text Patent Translation at WIPO: Scalability, 
Quality and Usability
 9:50-10:30   [Invited talk] Kei Kato (Japan Patent Office)
  Initiatives of the Japan Patent Office on Machine 
Translation

10:50-11:50   Session 2 (Effective Use of Patent MT)
10:50-11:30   [Invited talk] John Tinsley (Iconic Translation 
Machines Ltd.)
  Improving Translator Productivity with MT: A Patent 
Translation Case Study
11:30-11:50   Xiaona Ren, Yongpeng Wei and Rile Hu
  Simplify Sentence Structure for Improving Human 
Post-editing Efficiency on Chinese-to-English Patent Machine Translation

13:20-15:00   Session 3 (Challenges for Advanced Patent MT)
13:20-14:00   [Invited talk] Stefan Riezler (Heidelberg University)
  Response-Based Learning for Patent Translation
14:00-14:20   John Richardson, Toshiaki Nakazawa and Sadao Kurohashi
  Enhancing Function Word Translation with Syntax-Based 
Statistical Post-Editing
14:20-14:40   Hongzheng Li, Kai Zhao, Renfen Hu, Yun Zhu and Yaohong Jin
  A Hybrid System for Chinese-English Patent Machine 
Translation
14:40-15:00   Zi Long, Takehito Utsuro, Tomoharu Mitsuhashi and 
Mikio Yamamoto
  Collecting Bilingual Technical Terms from Patent 
Families of Character-Segmented Chinese Sentences and Morpheme-Segmented 
Japanese Sentences

15:20-16:40   Session 4 (Beyond Patent Translation)
15:20-16:00   [Invited talk] Toshiaki Nakazawa (Japan Science and 
Technology Agency)
  Promoting Science and Technology Exchange using 
Machine Translation
16:00-16:20   Keisuke Noguchi and Takashi Ninomiya
  Resampling Approach for Instance-based Domain 
Adaptation from Patent Domain to Newspaper Domain in Statistical Machine 
Translation
16:20-16:40   Takashi Tsunakawa and Hiroyuki Kaji
  Towards Cross-lingual Patent Wikification

16:40-16:50   Closing

PROGRAM COMMITTEE:
Hiroyuki Kaji [Co-chiar] (Shizuoka University, Japan)
Katsuhito Sudoh [Co-chiar] (NTT, Japan)
Key-Sun Choi (KAIST, Korea)
Hiroshi Echizen-ya (Hokkai-Gakuen University, Japan)
Terumasa Ehara (Ehara NLP Research Laboratory, Japan)
Isao Goto (NHK, Japan)
Kinji Hanawa (Japan Patent Information Organization, Japan)
Takayuki Hayakawa (Japan Patent Information Organization, Japan)
Munpyo Hong (Sungkyunkwan University, Korea)
Eduard Hovy (Carnegie Mellon University, USA)
Kenji Imamura (National Institute of Information and Communications 
Technology, Japan)
Hideki Isozaki (Okayama Prefectural University, Japan)
Hiroaki Kawai (Japan Patent Information Organization, Japan)
Philipp Koehn (Johns Hopkins University, USA)
Akira Kumano (Toshiba Solutions Corporation, Japan)
Sadao Kurohashi (Kyoto University, Japan)
Jong-Hyeok Lee (Pohang University of Science and Technology, Korea)
Bente Maegaard (University of Copenhagen, Denmark)
Toshimichi Moriya (Japan Patent Information Organization, Japan)
Toshiaki Nakazawa (Japan Science and Technology Agency, Japan)
Takashi Ninomiya (Ehime University, Japan)
Tadaaki Oshio (Japan Patent Information Organization, Japan)
Svetlana Sheremetyeva (Lanaconsult, Denmark)
Sayori Shimohata (Oki Electric Industry Co., Ltd., Japan)
Jun-ichi Tsujii (Artificial Intelligence Research Center, AIST, Japan)
Takashi Tsunakawa (Shizuoka University, Japan)
Takehito Utsuro (University of Tsukuba, Japan)
Andy Way (Dublin City University, Ireland)
Shoichi Yokoyama (Yamagata University, Japan)
Jiajun Zhang (Chinese Academy of Sciences, China)




-- 
Takashi Tsunakawa

Kaji Laboratory,
College of Informatics, Shizuoka University

t...@inf.shizuoka.ac.jp




___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

[Moses-support] KenLM poison

[徐同学]

Dear all,I’m building the baseline system, and some error occurred during the last step of LM training process as the first attached file shows. I checked another case of “Last input should have been poison”, but that one has more detailed information “no space left on device”, while mine has nothing but that sentence.The exact command I use for Kenlm is: $MOSES/bin/lmplz -o 3 < ~/es-fi/OpenSubtitles2013.es-fi.true.fi > OpenSubtitles2013.es-fi.arpa.fiAs mosesdecoder is installed at the administrator’s directory instead of my own, "~/mosesdecoder "is replaced by $MOSES. my corpus(the language pair is Spanish to Finnish) was downloaded from Opus(http://opus.lingfil.uu.se/OpenSubtitles2013.php) in the Moses format. The downloaded profile contains three files:  OpenSubtitles2013.es-fi.es, OpenSubtitles2013.es-fi.fi, and OpenSubtitles2013.es-fi.ids. The tokenization, truecasing and cleaning are all completed with the “es" and “fi” files. Is it possible if the error has something to do with the “ids” file? Here attaches the output of LM process, and the command I used for corpus preparation. fangting@phon:~/lm$ $MOSES/bin/lmplz -o 3 < 
~/es-fi/OpenSubtitles2013.es-fi.true.fi > OpenSubtitles2013.es-fi.arpa.fi
=== 1/5 Counting and sorting n-grams ===
Reading /home/fangting/es-fi/OpenSubtitles2013.es-fi.true.fi
5---10---15---20---25---30---35---40---45---50---55---60---65---70---75---80---85---90---95--100
tcmalloc: large alloc 2531827712 bytes == 0x2ffce000 @ 

Unigram tokens 44622536 types 1102478
=== 2/5 Calculating and sorting adjusted counts ===
Chain sizes: 1:13229736 2:1146485248 3:2149659904
tcmalloc: large alloc 2149662720 bytes == 0x2ffce000 @ 
Statistics:
1 1102478 D1=0.698134 D2=1.05351 D3+=1.36696
2 8382723 D1=0.802872 D2=1.11671 D3+=1.34474
3 17631891 D1=0.75173 D2=1.35452 D3+=1.59193
Memory estimate for binary LM:
type     MB
probing 521 assuming -p 1.5
probing 574 assuming -r models -p 1.5
trie    243 without quantization
trie    148 assuming -q 8 -b 8 quantization 
trie    226 assuming -a 22 array pointer compression
trie    131 assuming -a 22 -q 8 -b 8 array pointer compression and 
quantization
=== 3/5 Calculating and sorting initial probabilities ===
Chain sizes: 1:13229736 2:134123568 3:352637820
5---10---15---20---25---30---35---40---45---50---55---60---65---70---75---80---85---90---95--100

=== 4/5 Calculating and writing order-interpolated probabilities ===
Chain sizes: 1:13229736 2:134123568 3:352637820
5---10---15---20---25---30---35---40---45---50---55---60---65---70---75---80---85---90---95--100

Chain sizes: 1:13229736 2:65424996 3:122671872
=== 5/5 Writing ARPA model ===
Last input should have been poison.
terminate called without an active exception
AbortedCorpus Preparation 

cd ~/es-fi

Tokenisation
$MOSES/scripts/tokenizer/tokenizer.perl -l es < 
~/es-fi/OpenSubtitles2013.es-fi.es > ~/es-fi/OpenSubtitles2013.es-fi.tok.es

$MOSES/scripts/tokenizer/tokenizer.perl -l fi < 
~/es-fi/OpenSubtitles2013.es-fi.fi > ~/es-fi/OpenSubtitles2013.es-fi.tok.fi

Training truecaser
$MOSES/scripts/recaser/train-truecaser.perl --model  ~/es-fi/truecase-model.es 
--corpus ~/es-fi/OpenSubtitles2013.es-fi.tok.es

$MOSES/scripts/recaser/train-truecaser.perl --model  ~/es-fi/truecase-model.fi 
--corpus ~/es-fi/OpenSubtitles2013.es-fi.tok.fi

Truecasing
$MOSES/scripts/recaser/truecase.perl --model ~/es-fi/truecase-model.es < 
~/es-fi/OpenSubtitles2013.es-fi.tok.es > ~/es-fi/OpenSubtitles2013.es-fi.true.es

$MOSES/scripts/recaser/truecase.perl --model ~/es-fi/truecase-model.fi < 
~/es-fi/OpenSubtitles2013.es-fi.tok.fi > ~/es-fi/OpenSubtitles2013.es-fi.true.fi

Cleaning
$MOSES/scripts/training/clean-corpus-n.perl 
~/es-fi/OpenSubtitles2013.es-fi.true es fi 
~/es-fi/OpenSubtitles2013.es-fi.clean 1 80

Language model training (doesn’t work)
cd lm
/opt/irstlm/bin/add-start-end.sh < ~/es-fi/OpenSubtitles2013.es-fi.true.fi > 
OpenSubtitles2013.es-fi.sb.fi

export IRSTLM=/opt/irstlm; /opt/irstlm/bin/build-lm.sh -i 
OpenSubtitles2013.es-fi.sb.fi -t ./tmp -p -s improved-kneser-ney -o 
OpenSubtitles2013.es-fi.lm.fi

Change to KenLM
$MOSES/bin/lmplz -o 3 < ~/es-fi/OpenSubtitles2013.es-fi.true.fi > 
OpenSubtitles2013.es-fi.arpa.fi
___
Moses-support mailing list

Re: [Moses-support] Do debugging in the decoder?

[Matthias Huck]

Hi Yuqi,

I don't know. But maybe something like running a profiler on a
small-scale setup and printing the call graph would be more convenient
anyway? If you don't just want to try and read the source code right
away. 

Maybe someone else has better suggestions.

Cheers,
Matthias


On Mon, 2015-10-05 at 09:59 +0200, Yuqi Zhang wrote:
> Thanks a lot,  Matthias and Hieu!
> 
> 
> I have the debug version in Eclipse already and can compiled it
> without errors. 
> I could follow the debugging until to decoder(translation):
> 
> 
>  pool.Submit(task); // in Exportinterface.cpp
> 
> I didn't find a way to see what happen in the 'translation' task, e.g.
> how a source segment looks for its translations in PT. Is there a way
> to let me know what happened in 'translation' task? 
> 
> Thanks!
> 
> Best regards,
> 
> Yuqi
> 
> 
> 
> 2015-10-05 1:07 GMT+02:00 Hieu Hoang :
> i think it might be
>./bjam  variant=debug
> not
>   ./bjam ... --variant=debug
> 
> Also, please git pull. There was a minor compile error when
> using this option, which has now been fixed
> 
> https://github.com/moses-smt/mosesdecoder/commit/72bef00781de9821f2cff227ca7417939041d4e1
> 
> 
> On 04/10/2015 23:25, Matthias Huck wrote:
> Hi Yuqi,
> 
> You can build a debug compile by calling bjam with:
> 
> --variant=debug
> 
> Cheers,
> Matthias
> 
> 
> On Sun, 2015-10-04 at 23:05 +0200, Yuqi Zhang wrote:
> Hello,
> 
> 
> How can I debug the decoder?
> 
> 
> Must I turn off the pre-compile signal
> "WITH_THREADS"?
> Can it be turned off? (Since I have a try, but
> some head files
> regarding threads are always included.)
> Or is there any other way to allow me to get
> into the decoder?
> 
> 
> Thanks a lot!
> 
> 
> Best regards,
> Yuqi
> 
> 
> 
> 
> ___
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
> 
> 
> 
> 
> 
> 


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

[Moses-support] Faster decoding with multiple moses instances

[Michael Denkowski]

Hi all,

Like some other Moses users, I noticed diminishing returns from running
Moses with several threads.  To work around this, I added a script to run
multiple single-threaded instances of moses instead of one multi-threaded
instance.  In practice, this sped things up by about 2.5x for 16 cpus and
using memory mapped models still allowed everything to fit into memory.

If anyone else is interested in using this, you can prefix a moses command
with scripts/generic/multi_moses.py.  To use multiple instances in
mert-moses.pl, specify --multi-moses and control the number of parallel
instances with --decoder-flags='-threads N'.

Below is a benchmark on WMT fr-en data (2M training sentences, 400M words
mono, suffix array PT, compact reordering, 5-gram KenLM) testing default
stack decoding vs cube pruning without and with the parallelization script
(+multi):

---
1cpu   sent/sec
stack  1.04
cube   2.10
---
16cpu  sent/sec
stack  7.63
+multi12.20
cube   7.63
+multi18.18
---

--Michael
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] Faster decoding with multiple moses instances

[Philipp Koehn]

Hi,

great - that will be very useful.

Since you just ran the comparison - do you have any numbers on "still
allowed everything to fit into memory", i.e., how much more memory is used
by running parallel instances?

-phi

On Mon, Oct 5, 2015 at 10:15 AM, Michael Denkowski <
michael.j.denkow...@gmail.com> wrote:

> Hi all,
>
> Like some other Moses users, I noticed diminishing returns from running
> Moses with several threads.  To work around this, I added a script to run
> multiple single-threaded instances of moses instead of one multi-threaded
> instance.  In practice, this sped things up by about 2.5x for 16 cpus and
> using memory mapped models still allowed everything to fit into memory.
>
> If anyone else is interested in using this, you can prefix a moses command
> with scripts/generic/multi_moses.py.  To use multiple instances in
> mert-moses.pl, specify --multi-moses and control the number of parallel
> instances with --decoder-flags='-threads N'.
>
> Below is a benchmark on WMT fr-en data (2M training sentences, 400M words
> mono, suffix array PT, compact reordering, 5-gram KenLM) testing default
> stack decoding vs cube pruning without and with the parallelization script
> (+multi):
>
> ---
> 1cpu   sent/sec
> stack  1.04
> cube   2.10
> ---
> 16cpu  sent/sec
> stack  7.63
> +multi12.20
> cube   7.63
> +multi18.18
> ---
>
> --Michael
>
> ___
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] (no subject)

[Rico Sennrich]

Hi Sanjanasri,

1) your corpus is very small, and you may have to use more iterations of 
NPLM training and smaller vocabulary sizes. Just to double-check, are 
you tuning your systems? MERT (or PRO or MIRA) should normally ensure 
that adding a model doesn't make BLEU go down.


2) I'm not sure which perplexity is for which model, but lower 
perplexity is better, so this makes sense.


3) a perplexity of 3 is *extremely* low. Do you have overlap between 
your test set and your training set? This would be an unrealistic test 
setting, and would explain why KenLM does so much better (because 
backoff n-gram models are good at memorizing things).


best wishes,
Rico


On 05.10.2015 09:27, Sanjanashree Palanivel wrote:

Dear Rico,

 I tried using KENLM and NPLM for three language 
pairs. And I came across series of questions . I am listing it one by 
one. It would be great if you could guide me.



1) I did testing for NPLM with different vocabulary sizes and training 
epochs. But, the bleu score, I gained from NPLM integrated with KENLM 
is smaller than the one I trained with KENLM. In all the three 
language pairs I get a standard difference of three.


Eg: English to Hindi (KENLM-17.43, NPLM+KENLM-14.27)
  Tamil to Hindi (KENLM-16.66,NPLM+KENLM-13.53)
   Marathi to Hindi (KENLM-29.42,NPLM+KENLM-25.76)

 The sentence count is 103502. unigram count is 89919. I gave 
vocabulary size as 89000,89700,89850 with validation size 200,200,100 
respectively and with different learning rate and epocs. However, I am 
getting Bleu score of NPLM and KENLM is lesser.



2)The Bleu score of the model having perplexity about 385 has higher 
Bleu score than the one having pp around 564 .  Is this rite model. I 
mean the model with lower perplexity seems to give better Bleu score. 
Where am I doing worng.



3) I used query script for KENLM model. I found perplexity to 3.4xx. 
But, the Bleu score of KENLM alone in decoding phase gives Blue of 
16.66 for English to HIndi MT. But, when combined with NPLM I get only 
13.53.


On Sun, Sep 20, 2015 at 8:07 PM, Sanjanashree Palanivel 
> wrote:


Dear Rico,

Thanks a lot for your excellent guidance.

On Sat, Sep 19, 2015 at 9:10 PM, Rico Sennrich
> wrote:

Hi Sanjanasri,

we have seen improvements in BLEU from having both KENLM and
NPLM in our system. Things can go wrong during training though
(e.g. a bad choice of hyperparameters (vocabulary size, number
of training epochs)). I recommend using a development set
during NPLM training, and comparing perplexity scores with
those obtained from KENLM.

maybe somebody else can help you with the phrase table
normalization. NPLM doesn't have binarization.

best wishes,
Rico


On 19/09/15 08:11, Sanjanashree Palanivel wrote:

Dear Rico,

I did necessary changes and I trained language
model succesfully. The language model of nplm gives me lesser
BLEU score when compared to KENLM. But, when I used two
models together accuracy is greater than the one I got in
NPLM alone but lesser than KENLM. I am just trying to tune it
by changing the parameters. So far the accuracy is getting
improved but not close to KENLM accuracy.  Is that worthy to
do because its taking quite a long time to train.

 I also tried to binarize the phrase table following this
http://www.statmt.org/moses/?n=Advanced.RuleTables#ntoc3, and
compilation with moses is done succesfully. But. when i run
processPhraseTableMin -threads 3 -in train/model/phrase-table.gz
-nscores 4 -out binarised-model/phrase-table
I am getting segmentation fault. I dont know what is worng. Is there 
something todo with threads
Also how to binarize nplm model

On Fri, Sep 18, 2015 at 11:27 AM, Sanjanashree Palanivel
> wrote:

Dear Rico,

 Thanks a lot. Will do the necessary changes


On Thu, Sep 17, 2015 at 1:54 PM, Rico Sennrich
> wrote:

Hi Sanjanasri,

if you first compiled moses without the option
'--with-nplm', and then add the option later, the
build system isn't smart enough to know which files
it needs to recompile. if you change one of the
compile options, use the option '-a' to force
recompilation from scratch.

best wishes,
Rico




On 16/09/15 06:30, Sanjanashree Palanivel wrote:

Dear Rico,


I did the following steps


 

Re: [Moses-support] KenLM poison

[Kenneth Heafield]

Hi,

I'm still betting it's out of disk space writing the ARPA.
Multithreaded exception handling is annoying.  This is there to prevent
deadlock.

Kenneth

On 10/05/2015 01:52 PM, 徐同学 wrote:
> Dear all,
> 
> I’m building the baseline system, and some error occurred during the
> last step of LM training process as the first attached file shows. 
> 
> I checked another case of “Last input should have been poison”, but that
> one has more detailed information “no space left on device”, while mine
> has nothing but that sentence.
> 
> The exact command I use for Kenlm is: 
> $MOSES/bin/lmplz -o 3 < ~/es-fi/OpenSubtitles2013.es-fi.true.fi
>  > OpenSubtitles2013.es-fi.arpa.fi
> 
> 
> As mosesdecoder is installed at the administrator’s directory instead of
> my own, "~/mosesdecoder "is replaced by $MOSES. 
> 
> my corpus(the language pair is Spanish to Finnish) was downloaded from
> Opus(http://opus.lingfil.uu.se/OpenSubtitles2013.php) in the Moses format.
>  
> The downloaded profile contains three files:  OpenSubtitles2013.es-fi.es
> , OpenSubtitles2013.es
> -fi.fi ,
> and OpenSubtitles2013.es -fi.ids. 
> 
> The tokenization, truecasing and cleaning are all completed with the
> “es" and “fi” files. Is it possible if the error has something to do
> with the “ids” file? 
> 
> Here attaches the output of LM process, and the command I used for
> corpus preparation. 
> 
> 
> 
> 
> 
> 
> 
> ___
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
> 
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] Do debugging in the decoder?

[Hieu Hoang]

You can use gdb to put breakpoints on the code and step through it.

I personally use Eclipse+CDT to do my debugging, it's just a front end to
gdb. You can see this video by Dominik to see how to set up Eclipse with
moses
   https://vimeo.com/129306919

Hieu Hoang
http://www.hoang.co.uk/hieu

On 5 October 2015 at 15:13, Matthias Huck  wrote:

> Hi Yuqi,
>
> I don't know. But maybe something like running a profiler on a
> small-scale setup and printing the call graph would be more convenient
> anyway? If you don't just want to try and read the source code right
> away.
>
> Maybe someone else has better suggestions.
>
> Cheers,
> Matthias
>
>
> On Mon, 2015-10-05 at 09:59 +0200, Yuqi Zhang wrote:
> > Thanks a lot,  Matthias and Hieu!
> >
> >
> > I have the debug version in Eclipse already and can compiled it
> > without errors.
> > I could follow the debugging until to decoder(translation):
> >
> >
> >  pool.Submit(task); // in Exportinterface.cpp
> >
> > I didn't find a way to see what happen in the 'translation' task, e.g.
> > how a source segment looks for its translations in PT. Is there a way
> > to let me know what happened in 'translation' task?
> >
> > Thanks!
> >
> > Best regards,
> >
> > Yuqi
> >
> >
> >
> > 2015-10-05 1:07 GMT+02:00 Hieu Hoang :
> > i think it might be
> >./bjam  variant=debug
> > not
> >   ./bjam ... --variant=debug
> >
> > Also, please git pull. There was a minor compile error when
> > using this option, which has now been fixed
> >
> https://github.com/moses-smt/mosesdecoder/commit/72bef00781de9821f2cff227ca7417939041d4e1
> >
> >
> > On 04/10/2015 23:25, Matthias Huck wrote:
> > Hi Yuqi,
> >
> > You can build a debug compile by calling bjam with:
> >
> > --variant=debug
> >
> > Cheers,
> > Matthias
> >
> >
> > On Sun, 2015-10-04 at 23:05 +0200, Yuqi Zhang wrote:
> > Hello,
> >
> >
> > How can I debug the decoder?
> >
> >
> > Must I turn off the pre-compile signal
> > "WITH_THREADS"?
> > Can it be turned off? (Since I have a try, but
> > some head files
> > regarding threads are always included.)
> > Or is there any other way to allow me to get
> > into the decoder?
> >
> >
> > Thanks a lot!
> >
> >
> > Best regards,
> > Yuqi
> >
> >
> >
> >
> > ___
> > Moses-support mailing list
> > Moses-support@mit.edu
> >
> http://mailman.mit.edu/mailman/listinfo/moses-support
> >
> >
> >
> >
> >
> >
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] Faster decoding with multiple moses instances

[Hieu Hoang]

what pt implementation did you use, and had it been pre-pruned so that
there's a limit on how many target phrase for a particular source phrase?
ie. don't have 10,000 entries for 'the' .

I've been digging around multithreading in the last few weeks. I've noticed
that the compact pt is VERY bad at handling unpruned pt.
Cores   1 5 10 15 20 25 Unpruned compact pt 143 42 32 38 52
62   probing pt 245 58 33 25 24 21 Pruned compact pt 119 24 15 10 10
10   probing
pt 117 25 25 10 10 10

Hieu Hoang
http://www.hoang.co.uk/hieu

On 5 October 2015 at 15:15, Michael Denkowski  wrote:

> Hi all,
>
> Like some other Moses users, I noticed diminishing returns from running
> Moses with several threads.  To work around this, I added a script to run
> multiple single-threaded instances of moses instead of one multi-threaded
> instance.  In practice, this sped things up by about 2.5x for 16 cpus and
> using memory mapped models still allowed everything to fit into memory.
>
> If anyone else is interested in using this, you can prefix a moses command
> with scripts/generic/multi_moses.py.  To use multiple instances in
> mert-moses.pl, specify --multi-moses and control the number of parallel
> instances with --decoder-flags='-threads N'.
>
> Below is a benchmark on WMT fr-en data (2M training sentences, 400M words
> mono, suffix array PT, compact reordering, 5-gram KenLM) testing default
> stack decoding vs cube pruning without and with the parallelization script
> (+multi):
>
> ---
> 1cpu   sent/sec
> stack  1.04
> cube   2.10
> ---
> 16cpu  sent/sec
> stack  7.63
> +multi12.20
> cube   7.63
> +multi18.18
> ---
>
> --Michael
>
> ___
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] Faster decoding with multiple moses instances

[Michael Denkowski]

Hi Philipp,

Unfortunately I don't have a precise measurement.  If anyone knows of a
good way to benchmark a process tree with lots of memory mapping the same
files, I would be glad to run it.

--Michael

On Mon, Oct 5, 2015 at 10:26 AM, Philipp Koehn  wrote:

> Hi,
>
> great - that will be very useful.
>
> Since you just ran the comparison - do you have any numbers on "still
> allowed everything to fit into memory", i.e., how much more memory is used
> by running parallel instances?
>
> -phi
>
> On Mon, Oct 5, 2015 at 10:15 AM, Michael Denkowski <
> michael.j.denkow...@gmail.com> wrote:
>
>> Hi all,
>>
>> Like some other Moses users, I noticed diminishing returns from running
>> Moses with several threads.  To work around this, I added a script to run
>> multiple single-threaded instances of moses instead of one multi-threaded
>> instance.  In practice, this sped things up by about 2.5x for 16 cpus and
>> using memory mapped models still allowed everything to fit into memory.
>>
>> If anyone else is interested in using this, you can prefix a moses
>> command with scripts/generic/multi_moses.py.  To use multiple instances in
>> mert-moses.pl, specify --multi-moses and control the number of parallel
>> instances with --decoder-flags='-threads N'.
>>
>> Below is a benchmark on WMT fr-en data (2M training sentences, 400M words
>> mono, suffix array PT, compact reordering, 5-gram KenLM) testing default
>> stack decoding vs cube pruning without and with the parallelization script
>> (+multi):
>>
>> ---
>> 1cpu   sent/sec
>> stack  1.04
>> cube   2.10
>> ---
>> 16cpu  sent/sec
>> stack  7.63
>> +multi12.20
>> cube   7.63
>> +multi18.18
>> ---
>>
>> --Michael
>>
>> ___
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>>
>
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] Faster decoding with multiple moses instances

[Kenneth Heafield]

https://github.com/kpu/usage

This injects code into shared executables that makes them print usage
statistics on termination to stderr.  grep stderr, collate.

Kenneth

On 10/05/2015 04:05 PM, Michael Denkowski wrote:
> Hi Philipp,
> 
> Unfortunately I don't have a precise measurement.  If anyone knows of a
> good way to benchmark a process tree with lots of memory mapping the
> same files, I would be glad to run it.
> 
> --Michael
> 
> On Mon, Oct 5, 2015 at 10:26 AM, Philipp Koehn  > wrote:
> 
> Hi,
> 
> great - that will be very useful.
> 
> Since you just ran the comparison - do you have any numbers on
> "still allowed everything to fit into memory", i.e., how much more
> memory is used by running parallel instances?
> 
> -phi
> 
> On Mon, Oct 5, 2015 at 10:15 AM, Michael Denkowski
>  > wrote:
> 
> Hi all,
> 
> Like some other Moses users, I noticed diminishing returns from
> running Moses with several threads.  To work around this, I
> added a script to run multiple single-threaded instances of
> moses instead of one multi-threaded instance.  In practice, this
> sped things up by about 2.5x for 16 cpus and using memory mapped
> models still allowed everything to fit into memory.
> 
> If anyone else is interested in using this, you can prefix a
> moses command with scripts/generic/multi_moses.py.  To use
> multiple instances in mert-moses.pl ,
> specify --multi-moses and control the number of parallel
> instances with --decoder-flags='-threads N'.
> 
> Below is a benchmark on WMT fr-en data (2M training sentences,
> 400M words mono, suffix array PT, compact reordering, 5-gram
> KenLM) testing default stack decoding vs cube pruning without
> and with the parallelization script (+multi):
> 
> ---
> 1cpu   sent/sec
> stack  1.04
> cube   2.10
> ---
> 16cpu  sent/sec
> stack  7.63
> +multi12.20
> cube   7.63
> +multi18.18
> ---
> 
> --Michael
> 
> ___
> Moses-support mailing list
> Moses-support@mit.edu 
> http://mailman.mit.edu/mailman/listinfo/moses-support
> 
> 
> 
> 
> 
> ___
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
> 
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] Faster decoding with multiple moses instances

[Michael Denkowski]

Hi Hieu,

I'm using the memory mapped suffix array phrase table
(PhraseDictionaryBitextSampling).  I can run a test with compact PT as well.

--Michael

On Mon, Oct 5, 2015 at 10:48 AM, Hieu Hoang  wrote:

> what pt implementation did you use, and had it been pre-pruned so that
> there's a limit on how many target phrase for a particular source phrase?
> ie. don't have 10,000 entries for 'the' .
>
> I've been digging around multithreading in the last few weeks. I've
> noticed that the compact pt is VERY bad at handling unpruned pt.
> Cores   1 5 10 15 20 25 Unpruned compact pt 143 42 32 38
> 52 62   probing pt 245 58 33 25 24 21 Pruned compact pt 119 24 15 10 10 10
>   probing pt 117 25 25 10 10 10
>
> Hieu Hoang
> http://www.hoang.co.uk/hieu
>
> On 5 October 2015 at 15:15, Michael Denkowski <
> michael.j.denkow...@gmail.com> wrote:
>
>> Hi all,
>>
>> Like some other Moses users, I noticed diminishing returns from running
>> Moses with several threads.  To work around this, I added a script to run
>> multiple single-threaded instances of moses instead of one multi-threaded
>> instance.  In practice, this sped things up by about 2.5x for 16 cpus and
>> using memory mapped models still allowed everything to fit into memory.
>>
>> If anyone else is interested in using this, you can prefix a moses
>> command with scripts/generic/multi_moses.py.  To use multiple instances in
>> mert-moses.pl, specify --multi-moses and control the number of parallel
>> instances with --decoder-flags='-threads N'.
>>
>> Below is a benchmark on WMT fr-en data (2M training sentences, 400M words
>> mono, suffix array PT, compact reordering, 5-gram KenLM) testing default
>> stack decoding vs cube pruning without and with the parallelization script
>> (+multi):
>>
>> ---
>> 1cpu   sent/sec
>> stack  1.04
>> cube   2.10
>> ---
>> 16cpu  sent/sec
>> stack  7.63
>> +multi12.20
>> cube   7.63
>> +multi18.18
>> ---
>>
>> --Michael
>>
>> ___
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>>
>
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] Faster decoding with multiple moses instances

[Barry Haddow]

Hi Hieu

That's exactly why I took to pre-pruning the phrase table, as I 
mentioned on Friday. I had something like 750,000 translations of the 
most common word, and it took half-an-hour to get the first sentence 
translated.


cheers - Barry

On 05/10/15 15:48, Hieu Hoang wrote:
what pt implementation did you use, and had it been pre-pruned so that 
there's a limit on how many target phrase for a particular source 
phrase? ie. don't have 10,000 entries for 'the' .


I've been digging around multithreading in the last few weeks. I've 
noticed that the compact pt is VERY bad at handling unpruned pt.

Cores   
1   5   10  15  20  25
Unprunedcompact pt  143 42  32  38  52  62
probing pt  245 58  33  25  24  21
Pruned  compact pt  119 24  15  10  10  10
probing pt  117 25  25  10  10  10



Hieu Hoang
http://www.hoang.co.uk/hieu

On 5 October 2015 at 15:15, Michael Denkowski 
> 
wrote:


Hi all,

Like some other Moses users, I noticed diminishing returns from
running Moses with several threads.  To work around this, I added
a script to run multiple single-threaded instances of moses
instead of one multi-threaded instance.  In practice, this sped
things up by about 2.5x for 16 cpus and using memory mapped models
still allowed everything to fit into memory.

If anyone else is interested in using this, you can prefix a moses
command with scripts/generic/multi_moses.py.  To use multiple
instances in mert-moses.pl , specify
--multi-moses and control the number of parallel instances with
--decoder-flags='-threads N'.

Below is a benchmark on WMT fr-en data (2M training sentences,
400M words mono, suffix array PT, compact reordering, 5-gram
KenLM) testing default stack decoding vs cube pruning without and
with the parallelization script (+multi):

---
1cpu   sent/sec
stack  1.04
cube   2.10
---
16cpu  sent/sec
stack  7.63
+multi12.20
cube   7.63
+multi18.18
---

--Michael

___
Moses-support mailing list
Moses-support@mit.edu 
http://mailman.mit.edu/mailman/listinfo/moses-support




___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support


The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] Faster decoding with multiple moses instances

[Philipp Koehn]

Hi,

with regard to pruning ---

the example EMS config files have

[TRAINING]
score-settings = "--GoodTuring --MinScore 2:0.0001"

which carries out threshold pruning during phrase table construction, going
a good way towards avoiding too many translation options per phrase.

-phi

On Mon, Oct 5, 2015 at 11:08 AM, Barry Haddow  wrote:

> Hi Hieu
>
> That's exactly why I took to pre-pruning the phrase table, as I mentioned
> on Friday. I had something like 750,000 translations of the most common
> word, and it took half-an-hour to get the first sentence translated.
>
> cheers - Barry
>
>
> On 05/10/15 15:48, Hieu Hoang wrote:
>
> what pt implementation did you use, and had it been pre-pruned so that
> there's a limit on how many target phrase for a particular source phrase?
> ie. don't have 10,000 entries for 'the' .
>
> I've been digging around multithreading in the last few weeks. I've
> noticed that the compact pt is VERY bad at handling unpruned pt.
> Cores   1 5 10 15 20 25 Unpruned compact pt 143 42 32 38
> 52 62   probing pt 245 58 33 25 24 21 Pruned compact pt 119 24 15 10 10 10
>   probing pt 117 25 25 10 10 10
>
> Hieu Hoang
> http://www.hoang.co.uk/hieu
>
> On 5 October 2015 at 15:15, Michael Denkowski <
> michael.j.denkow...@gmail.com> wrote:
>
>> Hi all,
>>
>> Like some other Moses users, I noticed diminishing returns from running
>> Moses with several threads.  To work around this, I added a script to run
>> multiple single-threaded instances of moses instead of one multi-threaded
>> instance.  In practice, this sped things up by about 2.5x for 16 cpus and
>> using memory mapped models still allowed everything to fit into memory.
>>
>> If anyone else is interested in using this, you can prefix a moses
>> command with scripts/generic/multi_moses.py.  To use multiple instances in
>> mert-moses.pl, specify --multi-moses and control the number of parallel
>> instances with --decoder-flags='-threads N'.
>>
>> Below is a benchmark on WMT fr-en data (2M training sentences, 400M words
>> mono, suffix array PT, compact reordering, 5-gram KenLM) testing default
>> stack decoding vs cube pruning without and with the parallelization script
>> (+multi):
>>
>> ---
>> 1cpu   sent/sec
>> stack  1.04
>> cube   2.10
>> ---
>> 16cpu  sent/sec
>> stack  7.63
>> +multi12.20
>> cube   7.63
>> +multi18.18
>> ---
>>
>> --Michael
>>
>> ___
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>>
>
>
> ___
> Moses-support mailing 
> listMoses-support@mit.eduhttp://mailman.mit.edu/mailman/listinfo/moses-support
>
>
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> ___
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] Faster decoding with multiple moses instances

[Marcin Junczys-Dowmunt]

Very bad unpruned and with mulithreading! :)

Is this with the nonblockpt branch? I am slowly running out of ideas
what might be the cause of this. Frequent vector realloaction?


On 05.10.2015 16:48, Hieu Hoang wrote:
> what pt implementation did you use, and had it been pre-pruned so that 
> there's a limit on how many target phrase for a particular source 
> phrase? ie. don't have 10,000 entries for 'the' .
>
> I've been digging around multithreading in the last few weeks. I've 
> noticed that the compact pt is VERY bad at handling unpruned pt.
>   Cores   
>   1   5   10  15  20  25
> Unpruned  compact pt  143 42  32  38  52  62
>   probing pt  245 58  33  25  24  21
> Prunedcompact pt  119 24  15  10  10  10
>   probing pt  117 25  25  10  10  10
>
>
>
> Hieu Hoang
> http://www.hoang.co.uk/hieu
>
> On 5 October 2015 at 15:15, Michael Denkowski 
> > 
> wrote:
>
> Hi all,
>
> Like some other Moses users, I noticed diminishing returns from
> running Moses with several threads.  To work around this, I added
> a script to run multiple single-threaded instances of moses
> instead of one multi-threaded instance.  In practice, this sped
> things up by about 2.5x for 16 cpus and using memory mapped models
> still allowed everything to fit into memory.
>
> If anyone else is interested in using this, you can prefix a moses
> command with scripts/generic/multi_moses.py.  To use multiple
> instances in mert-moses.pl , specify
> --multi-moses and control the number of parallel instances with
> --decoder-flags='-threads N'.
>
> Below is a benchmark on WMT fr-en data (2M training sentences,
> 400M words mono, suffix array PT, compact reordering, 5-gram
> KenLM) testing default stack decoding vs cube pruning without and
> with the parallelization script (+multi):
>
> ---
> 1cpu   sent/sec
> stack  1.04
> cube   2.10
> ---
> 16cpu  sent/sec
> stack  7.63
> +multi12.20
> cube   7.63
> +multi18.18
> ---
>
> --Michael
>
> ___
> Moses-support mailing list
> Moses-support@mit.edu 
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>
>
>
> ___
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support

___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support