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
(Michael Denkowski)
2. Re: Faster decoding with multiple moses instances
(Michael Denkowski)
3. Re: Faster decoding with multiple moses instances (Vincent Nguyen)
4. Re: Faster decoding with multiple moses instances
(Marcin Junczys-Dowmunt)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 Oct 2015 14:26:09 -0400
From: Michael Denkowski <michael.j.denkowski@gmail.com>
Subject: Re: [Moses-support] Faster decoding with multiple moses
instances
To: vnguyen@neuf.fr, Moses Support <moses-support@mit.edu>
Message-ID:
<CA+-GegJ5bNrMnX8jkXJnpijqLXs5DwY_hi5+d93OQ=nQ=wt5qA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Vincent,
I'm using cube pruning with the following options for all data points:
[search-algorithm]
1
[cube-pruning-deterministic-search]
true
[cube-pruning-pop-limit]
2000
[stack]
2000
Best,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20151008/320bc9ab/attachment-0001.html
------------------------------
Message: 2
Date: Thu, 8 Oct 2015 15:24:58 -0400
From: Michael Denkowski <michael.j.denkowski@gmail.com>
Subject: Re: [Moses-support] Faster decoding with multiple moses
instances
To: Vincent Nguyen <vnguyen@neuf.fr>, Moses Support
<moses-support@mit.edu>
Message-ID:
<CA+-GegJ9K0wyEycajaxUMkshw2iCn379W0WxsWbZfFjrA2UVyg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Vincent,
That definitely helps. I reran everything comparing the original 2000/2000
to your suggestion of 400/400. There isn't much difference for a single
multi-threaded instance, but there's about a 30% speedup when using all
single-threaded instances:
pop limit & stack
procs/threads 2000 400
1x16 5.46 5.68
2x8 7.58 8.70
4x4 9.71 11.24
8x2 12.50 15.87
16x1 14.08 18.52
There wasn't any degradation to BLEU/TER/Meteor but this is just one data
point and a fairly simple system. I would be curious to see how things
work out in other users' systems.
Best,
Michael
On Thu, Oct 8, 2015 at 2:34 PM, Vincent Nguyen <vnguyen@neuf.fr> wrote:
> out of curiosity, what gain do you get with 400 for both stack and cube
> pruning ?
>
>
> Le 08/10/2015 20:26, Michael Denkowski a ?crit :
>
>> Hi Vincent,
>>
>> I'm using cube pruning with the following options for all data points:
>>
>> [search-algorithm]
>> 1
>>
>> [cube-pruning-deterministic-search]
>> true
>>
>> [cube-pruning-pop-limit]
>> 2000
>>
>> [stack]
>> 2000
>>
>> Best,
>> Michael
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20151008/95515420/attachment-0001.html
------------------------------
Message: 3
Date: Thu, 8 Oct 2015 21:30:07 +0200
From: Vincent Nguyen <vnguyen@neuf.fr>
Subject: Re: [Moses-support] Faster decoding with multiple moses
instances
To: Michael Denkowski <michael.j.denkowski@gmail.com>, Moses Support
<moses-support@mit.edu>
Message-ID: <5616C43F.6080804@neuf.fr>
Content-Type: text/plain; charset="utf-8"
to my experience, below 400 I started to lose some BLEU point slightly.
Another thing to tune is the score-setting when building table.
score-settings = "--GoodTuring --MinScore 2:0.001"
standard value is 0.0001
I did not notice any BLEU score decrease with 0.001
But might be not relevant with MMAPTS
Le 08/10/2015 21:24, Michael Denkowski a ?crit :
> Hi Vincent,
>
> That definitely helps. I reran everything comparing the original
> 2000/2000 to your suggestion of 400/400. There isn't much difference
> for a single multi-threaded instance, but there's about a 30% speedup
> when using all single-threaded instances:
>
> pop limit & stack
> procs/threads 2000 400
> 1x16 5.46 5.68
> 2x8 7.58 8.70
> 4x4 9.71 11.24
> 8x2 12.50 15.87
> 16x1 14.08 18.52
>
> There wasn't any degradation to BLEU/TER/Meteor but this is just one
> data point and a fairly simple system. I would be curious to see how
> things work out in other users' systems.
>
> Best,
> Michael
>
> On Thu, Oct 8, 2015 at 2:34 PM, Vincent Nguyen <vnguyen@neuf.fr
> <mailto:vnguyen@neuf.fr>> wrote:
>
> out of curiosity, what gain do you get with 400 for both stack and
> cube pruning ?
>
>
> Le 08/10/2015 20:26, Michael Denkowski a ?crit :
>
> Hi Vincent,
>
> I'm using cube pruning with the following options for all data
> points:
>
> [search-algorithm]
> 1
>
> [cube-pruning-deterministic-search]
> true
>
> [cube-pruning-pop-limit]
> 2000
>
> [stack]
> 2000
>
> Best,
> Michael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20151008/f42a6ca4/attachment-0001.html
------------------------------
Message: 4
Date: Thu, 8 Oct 2015 21:30:49 +0200
From: Marcin Junczys-Dowmunt <junczys@amu.edu.pl>
Subject: Re: [Moses-support] Faster decoding with multiple moses
instances
To: moses-support@mit.edu
Message-ID: <5616C469.4000908@amu.edu.pl>
Content-Type: text/plain; charset="windows-1252"
We did quite a bit of experimenting with that, usually there is hardly
any measureable quality loss until you get below 1000. Good enough for
deployment systems. It seems however you can get up 0.4 BLEU increase
when going really high (about 5000 and beyond) with larger distortion
limits. But that's rather uninteresting for commercial applications.
W dniu 08.10.2015 o 21:24, Michael Denkowski pisze:
> Hi Vincent,
>
> That definitely helps. I reran everything comparing the original
> 2000/2000 to your suggestion of 400/400. There isn't much difference
> for a single multi-threaded instance, but there's about a 30% speedup
> when using all single-threaded instances:
>
> pop limit & stack
> procs/threads 2000 400
> 1x16 5.46 5.68
> 2x8 7.58 8.70
> 4x4 9.71 11.24
> 8x2 12.50 15.87
> 16x1 14.08 18.52
>
> There wasn't any degradation to BLEU/TER/Meteor but this is just one
> data point and a fairly simple system. I would be curious to see how
> things work out in other users' systems.
>
> Best,
> Michael
>
> On Thu, Oct 8, 2015 at 2:34 PM, Vincent Nguyen <vnguyen@neuf.fr
> <mailto:vnguyen@neuf.fr>> wrote:
>
> out of curiosity, what gain do you get with 400 for both stack and
> cube pruning ?
>
>
> Le 08/10/2015 20:26, Michael Denkowski a ?crit :
>
> Hi Vincent,
>
> I'm using cube pruning with the following options for all data
> points:
>
> [search-algorithm]
> 1
>
> [cube-pruning-deterministic-search]
> true
>
> [cube-pruning-pop-limit]
> 2000
>
> [stack]
> 2000
>
> Best,
> 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/20151008/d68b8be5/attachment.html
------------------------------
_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support
End of Moses-support Digest, Vol 108, Issue 25
**********************************************
Subscribe to:
Post Comments (Atom)
0 Response to "Moses-support Digest, Vol 108, Issue 25"
Post a Comment