Send Moses-support mailing list submissions to
moses-support@mit.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.mit.edu/mailman/listinfo/moses-support
or, via email, send a message with subject or body 'help' to
moses-support-request@mit.edu
You can reach the person managing the list at
moses-support-owner@mit.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Moses-support digest..."
Today's Topics:
1. Re: Faster decoding with multiple moses instances (Philipp Koehn)
2. Re: Faster decoding with multiple moses instances (Hieu Hoang)
3. Re: Faster decoding with multiple moses instances
(Michael Denkowski)
4. Re: Faster decoding with multiple moses instances (Barry Haddow)
----------------------------------------------------------------------
Message: 1
Date: Mon, 5 Oct 2015 10:26:39 -0400
From: Philipp Koehn <phi@jhu.edu>
Subject: Re: [Moses-support] Faster decoding with multiple moses
instances
To: Michael Denkowski <michael.j.denkowski@gmail.com>
Cc: Moses Support <moses-support@mit.edu>
Message-ID:
<CAAFADDD2tV=0QmVniFigsHXt9f=16fUPrTSNGHqSSETu8+_Esw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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.denkowski@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
> +multi 12.20
> cube 7.63
> +multi 18.18
> ---
>
> --Michael
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20151005/da9d7de3/attachment-0001.html
------------------------------
Message: 2
Date: Mon, 5 Oct 2015 15:48:03 +0100
From: Hieu Hoang <hieuhoang@gmail.com>
Subject: Re: [Moses-support] Faster decoding with multiple moses
instances
To: Michael Denkowski <michael.j.denkowski@gmail.com>
Cc: Moses Support <moses-support@mit.edu>
Message-ID:
<CAEKMkbi6XBhede0uP2=L1+HL1pH7YrqDa5dfMy67NDswvWhRNQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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.denkowski@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
> +multi 12.20
> cube 7.63
> +multi 18.18
> ---
>
> --Michael
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20151005/109dcda0/attachment-0001.html
------------------------------
Message: 3
Date: Mon, 5 Oct 2015 11:05:59 -0400
From: Michael Denkowski <michael.j.denkowski@gmail.com>
Subject: Re: [Moses-support] Faster decoding with multiple moses
instances
To: Philipp Koehn <phi@jhu.edu>
Cc: Moses Support <moses-support@mit.edu>
Message-ID:
<CA+-Geg+jGUwhTFBvS=nWM3Oso7m3htBzi8A1xFJfarJngPjcqw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <phi@jhu.edu> 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.denkowski@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
>> +multi 12.20
>> cube 7.63
>> +multi 18.18
>> ---
>>
>> --Michael
>>
>> _______________________________________________
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20151005/4ef07ef3/attachment-0001.html
------------------------------
Message: 4
Date: Mon, 05 Oct 2015 16:08:56 +0100
From: Barry Haddow <bhaddow@inf.ed.ac.uk>
Subject: Re: [Moses-support] Faster decoding with multiple moses
instances
To: Hieu Hoang <hieuhoang@gmail.com>, Michael Denkowski
<michael.j.denkowski@gmail.com>
Cc: Moses Support <moses-support@mit.edu>
Message-ID: <56129288.300@inf.ed.ac.uk>
Content-Type: text/plain; charset="iso-8859-1"
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.denkowski@gmail.com <mailto:michael.j.denkowski@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 <http://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
> +multi 12.20
> cube 7.63
> +multi 18.18
> ---
>
> --Michael
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20151005/a2f7d5c2/attachment.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://mailman.mit.edu/mailman/private/moses-support/attachments/20151005/a2f7d5c2/attachment.pl
------------------------------
_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support
End of Moses-support Digest, Vol 108, Issue 11
**********************************************
Subscribe to:
Post Comments (Atom)
0 Response to "Moses-support Digest, Vol 108, Issue 11"
Post a Comment