Re: [Moses-support] Support for XML Markup with Confusion Network Input

[James H. Cross III]

I will do that. Thanks, Hieu!

On Wed, Jul 22, 2015 at 1:46 PM, Hieu Hoang  wrote:
> it should be threadsafe these days. if you find out otherwise, i'll do my
> best to fix it
>
> Don't use IRSTLM or the old binary phrase-table.
>
>
> On 23/07/2015 00:26, James H. Cross III wrote:
>>
>> Hi:
>>
>> I also noticed that decoding with lattice input is not known to be
>> thread safe ( http://www.statmt.org/moses/?n=Moses.Optimize ). Does
>> this concern also extend to confusion network input?
>>
>> Thanks again,
>> James
>>
>>
>> On Wed, Jul 22, 2015 at 12:22 PM, James H. Cross III
>>  wrote:
>>>
>>> Definitely at least placeholders and constraints on reordering.
>>>
>>> On Wed, Jul 22, 2015 at 11:46 AM, Hieu Hoang  wrote:

 sounds ok. the xml markup is used for a number of things (forced
 translation, placeholders, constraint on reordering). Which
 functionality do
 you want to implement?

 On 22/07/2015 22:20, James H. Cross III wrote:
>
> Hi Hieu:
>
> Thanks for the response! I would like to look into adding this
> functionality myself.
>
> After a first pass, it looks like a good starting point would be
> adding functionality for interpreting XML (e.g., where an input line
> could contain a single XML tag rather than a word column) to the
> ConfusionNet class, and then adding functionality to enforce the
> decoding constraints to the TranslationOptionCollectionConfusionNet
> class. Let me know if this impression seems correct to you.
>
> Any other advice or caveats regarding this undertaking would also be
> much appreciated!
>
> Thanks,
> James
>
> On Wed, Jul 22, 2015 at 5:22 AM, Hieu Hoang 
> wrote:
>>
>> i guess lack of interest. XML markup is usually used by more
>> application-focused users who don't usually use complicated things
>> like
>> confusion networks, and confusion networks are used mainly by
>> researchers
>> who don't use xml markups
>>
>>
>> On 18/07/2015 00:35, James H. Cross III wrote:
>>>
>>> Hi:
>>>
>>> Is it still the case that XML markup is not supported for confusion
>>> network (or lattice) input? If not, are the reasons for not
>>> supporting
>>> this feature because implementing it imposes particular difficulties
>>> or simply due to lack of interest?
>>>
>>> Thanks,
>>> James
>>> ___
>>> Moses-support mailing list
>>> Moses-support@mit.edu
>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>
>> --
>> Hieu Hoang
>> Researcher
>> New York University, Abu Dhabi
>> http://www.hoang.co.uk/hieu
>>
 --
 Hieu Hoang
 Researcher
 New York University, Abu Dhabi
 http://www.hoang.co.uk/hieu

>
> --
> Hieu Hoang
> Researcher
> New York University, Abu Dhabi
> 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] Support for XML Markup with Confusion Network Input

[Hieu Hoang]

it should be threadsafe these days. if you find out otherwise, i'll do 
my best to fix it

Don't use IRSTLM or the old binary phrase-table.


On 23/07/2015 00:26, James H. Cross III wrote:
> Hi:
>
> I also noticed that decoding with lattice input is not known to be
> thread safe ( http://www.statmt.org/moses/?n=Moses.Optimize ). Does
> this concern also extend to confusion network input?
>
> Thanks again,
> James
>
>
> On Wed, Jul 22, 2015 at 12:22 PM, James H. Cross III
>  wrote:
>> Definitely at least placeholders and constraints on reordering.
>>
>> On Wed, Jul 22, 2015 at 11:46 AM, Hieu Hoang  wrote:
>>> sounds ok. the xml markup is used for a number of things (forced
>>> translation, placeholders, constraint on reordering). Which functionality do
>>> you want to implement?
>>>
>>> On 22/07/2015 22:20, James H. Cross III wrote:
 Hi Hieu:

 Thanks for the response! I would like to look into adding this
 functionality myself.

 After a first pass, it looks like a good starting point would be
 adding functionality for interpreting XML (e.g., where an input line
 could contain a single XML tag rather than a word column) to the
 ConfusionNet class, and then adding functionality to enforce the
 decoding constraints to the TranslationOptionCollectionConfusionNet
 class. Let me know if this impression seems correct to you.

 Any other advice or caveats regarding this undertaking would also be
 much appreciated!

 Thanks,
 James

 On Wed, Jul 22, 2015 at 5:22 AM, Hieu Hoang  wrote:
> i guess lack of interest. XML markup is usually used by more
> application-focused users who don't usually use complicated things like
> confusion networks, and confusion networks are used mainly by researchers
> who don't use xml markups
>
>
> On 18/07/2015 00:35, James H. Cross III wrote:
>> Hi:
>>
>> Is it still the case that XML markup is not supported for confusion
>> network (or lattice) input? If not, are the reasons for not supporting
>> this feature because implementing it imposes particular difficulties
>> or simply due to lack of interest?
>>
>> Thanks,
>> James
>> ___
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
> --
> Hieu Hoang
> Researcher
> New York University, Abu Dhabi
> http://www.hoang.co.uk/hieu
>
>>> --
>>> Hieu Hoang
>>> Researcher
>>> New York University, Abu Dhabi
>>> http://www.hoang.co.uk/hieu
>>>

-- 
Hieu Hoang
Researcher
New York University, Abu Dhabi
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] Support for XML Markup with Confusion Network Input

[James H. Cross III]

Hi:

I also noticed that decoding with lattice input is not known to be
thread safe ( http://www.statmt.org/moses/?n=Moses.Optimize ). Does
this concern also extend to confusion network input?

Thanks again,
James


On Wed, Jul 22, 2015 at 12:22 PM, James H. Cross III
 wrote:
> Definitely at least placeholders and constraints on reordering.
>
> On Wed, Jul 22, 2015 at 11:46 AM, Hieu Hoang  wrote:
>> sounds ok. the xml markup is used for a number of things (forced
>> translation, placeholders, constraint on reordering). Which functionality do
>> you want to implement?
>>
>> On 22/07/2015 22:20, James H. Cross III wrote:
>>>
>>> Hi Hieu:
>>>
>>> Thanks for the response! I would like to look into adding this
>>> functionality myself.
>>>
>>> After a first pass, it looks like a good starting point would be
>>> adding functionality for interpreting XML (e.g., where an input line
>>> could contain a single XML tag rather than a word column) to the
>>> ConfusionNet class, and then adding functionality to enforce the
>>> decoding constraints to the TranslationOptionCollectionConfusionNet
>>> class. Let me know if this impression seems correct to you.
>>>
>>> Any other advice or caveats regarding this undertaking would also be
>>> much appreciated!
>>>
>>> Thanks,
>>> James
>>>
>>> On Wed, Jul 22, 2015 at 5:22 AM, Hieu Hoang  wrote:

 i guess lack of interest. XML markup is usually used by more
 application-focused users who don't usually use complicated things like
 confusion networks, and confusion networks are used mainly by researchers
 who don't use xml markups


 On 18/07/2015 00:35, James H. Cross III wrote:
>
> Hi:
>
> Is it still the case that XML markup is not supported for confusion
> network (or lattice) input? If not, are the reasons for not supporting
> this feature because implementing it imposes particular difficulties
> or simply due to lack of interest?
>
> Thanks,
> James
> ___
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
 --
 Hieu Hoang
 Researcher
 New York University, Abu Dhabi
 http://www.hoang.co.uk/hieu

>>
>> --
>> Hieu Hoang
>> Researcher
>> New York University, Abu Dhabi
>> 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] Support for XML Markup with Confusion Network Input

[James H. Cross III]

Definitely at least placeholders and constraints on reordering.

On Wed, Jul 22, 2015 at 11:46 AM, Hieu Hoang  wrote:
> sounds ok. the xml markup is used for a number of things (forced
> translation, placeholders, constraint on reordering). Which functionality do
> you want to implement?
>
> On 22/07/2015 22:20, James H. Cross III wrote:
>>
>> Hi Hieu:
>>
>> Thanks for the response! I would like to look into adding this
>> functionality myself.
>>
>> After a first pass, it looks like a good starting point would be
>> adding functionality for interpreting XML (e.g., where an input line
>> could contain a single XML tag rather than a word column) to the
>> ConfusionNet class, and then adding functionality to enforce the
>> decoding constraints to the TranslationOptionCollectionConfusionNet
>> class. Let me know if this impression seems correct to you.
>>
>> Any other advice or caveats regarding this undertaking would also be
>> much appreciated!
>>
>> Thanks,
>> James
>>
>> On Wed, Jul 22, 2015 at 5:22 AM, Hieu Hoang  wrote:
>>>
>>> i guess lack of interest. XML markup is usually used by more
>>> application-focused users who don't usually use complicated things like
>>> confusion networks, and confusion networks are used mainly by researchers
>>> who don't use xml markups
>>>
>>>
>>> On 18/07/2015 00:35, James H. Cross III wrote:

 Hi:

 Is it still the case that XML markup is not supported for confusion
 network (or lattice) input? If not, are the reasons for not supporting
 this feature because implementing it imposes particular difficulties
 or simply due to lack of interest?

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

>>> --
>>> Hieu Hoang
>>> Researcher
>>> New York University, Abu Dhabi
>>> http://www.hoang.co.uk/hieu
>>>
>
> --
> Hieu Hoang
> Researcher
> New York University, Abu Dhabi
> 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] Support for XML Markup with Confusion Network Input

[Hieu Hoang]

sounds ok. the xml markup is used for a number of things (forced 
translation, placeholders, constraint on reordering). Which 
functionality do you want to implement?

On 22/07/2015 22:20, James H. Cross III wrote:
> Hi Hieu:
>
> Thanks for the response! I would like to look into adding this
> functionality myself.
>
> After a first pass, it looks like a good starting point would be
> adding functionality for interpreting XML (e.g., where an input line
> could contain a single XML tag rather than a word column) to the
> ConfusionNet class, and then adding functionality to enforce the
> decoding constraints to the TranslationOptionCollectionConfusionNet
> class. Let me know if this impression seems correct to you.
>
> Any other advice or caveats regarding this undertaking would also be
> much appreciated!
>
> Thanks,
> James
>
> On Wed, Jul 22, 2015 at 5:22 AM, Hieu Hoang  wrote:
>> i guess lack of interest. XML markup is usually used by more
>> application-focused users who don't usually use complicated things like
>> confusion networks, and confusion networks are used mainly by researchers
>> who don't use xml markups
>>
>>
>> On 18/07/2015 00:35, James H. Cross III wrote:
>>> Hi:
>>>
>>> Is it still the case that XML markup is not supported for confusion
>>> network (or lattice) input? If not, are the reasons for not supporting
>>> this feature because implementing it imposes particular difficulties
>>> or simply due to lack of interest?
>>>
>>> Thanks,
>>> James
>>> ___
>>> Moses-support mailing list
>>> Moses-support@mit.edu
>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>
>> --
>> Hieu Hoang
>> Researcher
>> New York University, Abu Dhabi
>> http://www.hoang.co.uk/hieu
>>

-- 
Hieu Hoang
Researcher
New York University, Abu Dhabi
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] Support for XML Markup with Confusion Network Input

[James H. Cross III]

Hi Hieu:

Thanks for the response! I would like to look into adding this
functionality myself.

After a first pass, it looks like a good starting point would be
adding functionality for interpreting XML (e.g., where an input line
could contain a single XML tag rather than a word column) to the
ConfusionNet class, and then adding functionality to enforce the
decoding constraints to the TranslationOptionCollectionConfusionNet
class. Let me know if this impression seems correct to you.

Any other advice or caveats regarding this undertaking would also be
much appreciated!

Thanks,
James

On Wed, Jul 22, 2015 at 5:22 AM, Hieu Hoang  wrote:
> i guess lack of interest. XML markup is usually used by more
> application-focused users who don't usually use complicated things like
> confusion networks, and confusion networks are used mainly by researchers
> who don't use xml markups
>
>
> On 18/07/2015 00:35, James H. Cross III wrote:
>>
>> Hi:
>>
>> Is it still the case that XML markup is not supported for confusion
>> network (or lattice) input? If not, are the reasons for not supporting
>> this feature because implementing it imposes particular difficulties
>> or simply due to lack of interest?
>>
>> Thanks,
>> James
>> ___
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>
> --
> Hieu Hoang
> Researcher
> New York University, Abu Dhabi
> 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] Performance issues using Moses Server with Moses 3

[Oren]

Yes, we use a lot of RAM in our setup. But the improved response time
justifies it.

Our language is on a nfs, bit we've been working this way with moses 1 for
some time with no problems (ten different machines using the same language
model file over nfs). Same for the reordering model. Neither of them is in
memory. Raising these models into memory will require raising our already
excessive RAM requirements...

Thanks again for the help.

On Wednesday, July 22, 2015, Barry Haddow 
wrote:

>  Hi Oren
>
> I'm not aware of any threading problems with PhraseDictionaryMemory, but
> not many people use it since it takes up too much memory. Moses command
> line runs multi-threaded using a thread pool.
>
> Is your language model on a local file system? Running it over nfs can be
> bad. What about your reordering model? Are you using the compact or the
> memory version?
>
> cheers - Barry
>
> On 22/07/15 15:09, Oren wrote:
>
> We have no swapping issues. I was asking if the use of an in-memory
> translation model might cause multithreading problems.
>
>
>  I'm not sure how to replicate the problem on cmd moses, since it's
> purely a multithreading issue. Ca you run cmd moses multithreaded?
>
>  I can't attach the complete moses.ini because it's on a separate
> network... But I copied below the stuff that looked relevant. I also tried
> to change the [threads] setting to 18, with no apparent effect.
>
>  [input-factors]
> 0
>
>  [mapping]
> 0 T 0
>
>  [distortion-limit]
> 6
>
>  [feature]
> UnknownWordPenalty
> WordPenalty
> PhrasePenalty
> PhraseDictionaryMemory name=TranslationModel0 num-features=4
> path=/phrase-table.gz input-factor=0 output-factor=0
> LexicalReordering 
> Distortion
> KENLM lazyken=0 name=LM0 path= order=5
>
>  [threads]
> 6
>
>  [weight]
>
>  
>
> On Tuesday, July 21, 2015, Hieu Hoang  wrote:
>
>> is it possible you can make your moses.ini file available for us to see?
>>
>> do you know if the same problem occurs if you use the command line moses,
>> rather than mosesserver?
>>
>>
>>  Hieu Hoang
>> Researcher
>>  New York University, Abu Dhabi
>>  http://www.hoang.co.uk/hieu
>>
>> On 21 July 2015 at 18:07, Barry Haddow 
>> wrote:
>>
>>>
>>> On 21/07/15 14:51, Oren wrote:
>>>
>>> I am using the in-memory mode, using about 50GB of RAM. (No swap issues
>>> as far as I can tell.) Could that cause issues?
>>>
>>>
>>> Yes, swapping would definitely cause issues - was that your question?
>>>
>>>
>>>
>>>  I looked at the commit you linked to, but it doesn't seem to be
>>> something configurable beyond the -threads switch. Am I missing something?
>>>
>>>
>>> The commit enables you to set the maximum number of connections to be
>>> the same as the maximum number of threads.
>>>
>>>
>>> On Tuesday, July 21, 2015, Barry Haddow 
>>> wrote:
>>>
  Hi Oren

 Does your host have 18 threads available? It could also be that
 xmlrpc-c is limiting the number of connections - this can now be 
 configured:

 https://github.com/moses-smt/mosesdecoder/commit/b3baade7f022edbcea2969679a40616683f63523

 Slowdowns in Moses are often caused by disk access bottlenecks. You can
 use --minphr-memory and --minlexr-memory to make sure that the phrase and
 reordering tables are loaded in to memory, rather than being access
 on-demand. Make sure your host has enough RAM and is not swapping. As I
 mentioned before there are various ways to make your models smaller (
 http://www.statmt.org/moses/?n=Advanced.RuleTables), which can make a
 big difference to speed depending on your setup.

 cheers - Barry

 On 21/07/15 09:30, Oren wrote:

 Hi Barry,

  Thanks for the quick response.

  I added the switch "-threads 18" to the command to raise moses
 server. The slowness issue persists but in a different form. Most requests
 return right away, even under heavy load, but some requests (about 5%) take
 far longer - about 15-20 seconds.

  Perhaps there are other relevant switches?

  Thanks again.

 On Monday, July 20, 2015, Barry Haddow 
 wrote:

>  Hi Oren
>
> The threading model is different. In v1, the server created a new
> thread for every request, v3 uses a thread pool. Try increasing the number
> of threads.
>
> Also, make sure you use the compact phrase table and KenLM as they are
> normally faster, and pre-pruning your phrase table can help,
>
> cheers - Barry
>
> On 20/07/15 12:01, Oren wrote:
>
> Hi all,
>
>  We are in the process of migrating from Moses 1 to Moses 3. We have
> noticed a significant slowdown when sending many requests at once to Moses
> Server. The first request will actually finish about 25% faster that a
> single request using Moses 1, but as more requests accumulate there is a
> marked slowdown, until requests take 5 times longer or more.
>
>  Is this a known issue? Is it spe

Re: [Moses-support] Performance issues using Moses Server with Moses 3

[Oren]

I am using the in-memory mode, using about 50GB of RAM. (No swap issues as
far as I can tell.) Could that cause issues?

I looked at the commit you linked to, but it doesn't seem to be something
configurable beyond the -threads switch. Am I missing something?

On Tuesday, July 21, 2015, Barry Haddow  wrote:

>  Hi Oren
>
> Does your host have 18 threads available? It could also be that xmlrpc-c
> is limiting the number of connections - this can now be configured:
>
> https://github.com/moses-smt/mosesdecoder/commit/b3baade7f022edbcea2969679a40616683f63523
>
> Slowdowns in Moses are often caused by disk access bottlenecks. You can
> use --minphr-memory and --minlexr-memory to make sure that the phrase and
> reordering tables are loaded in to memory, rather than being access
> on-demand. Make sure your host has enough RAM and is not swapping. As I
> mentioned before there are various ways to make your models smaller (
> http://www.statmt.org/moses/?n=Advanced.RuleTables), which can make a big
> difference to speed depending on your setup.
>
> cheers - Barry
>
> On 21/07/15 09:30, Oren wrote:
>
> Hi Barry,
>
>  Thanks for the quick response.
>
>  I added the switch "-threads 18" to the command to raise moses server.
> The slowness issue persists but in a different form. Most requests return
> right away, even under heavy load, but some requests (about 5%) take far
> longer - about 15-20 seconds.
>
>  Perhaps there are other relevant switches?
>
>  Thanks again.
>
> On Monday, July 20, 2015, Barry Haddow  > wrote:
>
>>  Hi Oren
>>
>> The threading model is different. In v1, the server created a new thread
>> for every request, v3 uses a thread pool. Try increasing the number of
>> threads.
>>
>> Also, make sure you use the compact phrase table and KenLM as they are
>> normally faster, and pre-pruning your phrase table can help,
>>
>> cheers - Barry
>>
>> On 20/07/15 12:01, Oren wrote:
>>
>> Hi all,
>>
>>  We are in the process of migrating from Moses 1 to Moses 3. We have
>> noticed a significant slowdown when sending many requests at once to Moses
>> Server. The first request will actually finish about 25% faster that a
>> single request using Moses 1, but as more requests accumulate there is a
>> marked slowdown, until requests take 5 times longer or more.
>>
>>  Is this a known issue? Is it specific to Moses Server? What can we do
>> about it?
>>
>>  Thanks!
>>
>>  Oren.
>>
>>
>> ___
>> Moses-support mailing 
>> listMoses-support@mit.eduhttp://mailman.mit.edu/mailman/listinfo/moses-support
>>
>>
>>
>
> ___
> Moses-support mailing listmoses-supp...@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] Performance issues using Moses Server with Moses 3

[Oren]

We have no swapping issues. I was asking if the use of an in-memory
translation model might cause multithreading problems.


I'm not sure how to replicate the problem on cmd moses, since it's purely a
multithreading issue. Ca you run cmd moses multithreaded?

I can't attach the complete moses.ini because it's on a separate network...
But I copied below the stuff that looked relevant. I also tried to change
the [threads] setting to 18, with no apparent effect.

[input-factors]
0

[mapping]
0 T 0

[distortion-limit]
6

[feature]
UnknownWordPenalty
WordPenalty
PhrasePenalty
PhraseDictionaryMemory name=TranslationModel0 num-features=4
path=/phrase-table.gz input-factor=0 output-factor=0
LexicalReordering 
Distortion
KENLM lazyken=0 name=LM0 path= order=5

[threads]
6

[weight]



On Tuesday, July 21, 2015, Hieu Hoang > wrote:

> is it possible you can make your moses.ini file available for us to see?
>
> do you know if the same problem occurs if you use the command line moses,
> rather than mosesserver?
>
>
> Hieu Hoang
> Researcher
> New York University, Abu Dhabi
> http://www.hoang.co.uk/hieu
>
> On 21 July 2015 at 18:07, Barry Haddow  wrote:
>
>>
>> On 21/07/15 14:51, Oren wrote:
>>
>> I am using the in-memory mode, using about 50GB of RAM. (No swap issues
>> as far as I can tell.) Could that cause issues?
>>
>>
>> Yes, swapping would definitely cause issues - was that your question?
>>
>>
>>
>>  I looked at the commit you linked to, but it doesn't seem to be
>> something configurable beyond the -threads switch. Am I missing something?
>>
>>
>> The commit enables you to set the maximum number of connections to be the
>> same as the maximum number of threads.
>>
>>
>> On Tuesday, July 21, 2015, Barry Haddow 
>> wrote:
>>
>>>  Hi Oren
>>>
>>> Does your host have 18 threads available? It could also be that xmlrpc-c
>>> is limiting the number of connections - this can now be configured:
>>>
>>> https://github.com/moses-smt/mosesdecoder/commit/b3baade7f022edbcea2969679a40616683f63523
>>>
>>> Slowdowns in Moses are often caused by disk access bottlenecks. You can
>>> use --minphr-memory and --minlexr-memory to make sure that the phrase and
>>> reordering tables are loaded in to memory, rather than being access
>>> on-demand. Make sure your host has enough RAM and is not swapping. As I
>>> mentioned before there are various ways to make your models smaller (
>>> http://www.statmt.org/moses/?n=Advanced.RuleTables), which can make a
>>> big difference to speed depending on your setup.
>>>
>>> cheers - Barry
>>>
>>> On 21/07/15 09:30, Oren wrote:
>>>
>>> Hi Barry,
>>>
>>>  Thanks for the quick response.
>>>
>>>  I added the switch "-threads 18" to the command to raise moses server.
>>> The slowness issue persists but in a different form. Most requests return
>>> right away, even under heavy load, but some requests (about 5%) take far
>>> longer - about 15-20 seconds.
>>>
>>>  Perhaps there are other relevant switches?
>>>
>>>  Thanks again.
>>>
>>> On Monday, July 20, 2015, Barry Haddow 
>>> wrote:
>>>
  Hi Oren

 The threading model is different. In v1, the server created a new
 thread for every request, v3 uses a thread pool. Try increasing the number
 of threads.

 Also, make sure you use the compact phrase table and KenLM as they are
 normally faster, and pre-pruning your phrase table can help,

 cheers - Barry

 On 20/07/15 12:01, Oren wrote:

 Hi all,

  We are in the process of migrating from Moses 1 to Moses 3. We have
 noticed a significant slowdown when sending many requests at once to Moses
 Server. The first request will actually finish about 25% faster that a
 single request using Moses 1, but as more requests accumulate there is a
 marked slowdown, until requests take 5 times longer or more.

  Is this a known issue? Is it specific to Moses Server? What can we do
 about it?

  Thanks!

  Oren.


 ___
 Moses-support mailing 
 listMoses-support@mit.eduhttp://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
>>
>>
>
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] Performance issues using Moses Server with Moses 3

[Barry Haddow]

Hi Oren

I'm not aware of any threading problems with PhraseDictionaryMemory, but 
not many people use it since it takes up too much memory. Moses command 
line runs multi-threaded using a thread pool.


Is your language model on a local file system? Running it over nfs can 
be bad. What about your reordering model? Are you using the compact or 
the memory version?


cheers - Barry

On 22/07/15 15:09, Oren wrote:
We have no swapping issues. I was asking if the use of an in-memory 
translation model might cause multithreading problems.



I'm not sure how to replicate the problem on cmd moses, since it's 
purely a multithreading issue. Ca you run cmd moses multithreaded?


I can't attach the complete moses.ini because it's on a separate 
network... But I copied below the stuff that looked relevant. I also 
tried to change the [threads] setting to 18, with no apparent effect.


[input-factors]
0

[mapping]
0 T 0

[distortion-limit]
6

[feature]
UnknownWordPenalty
WordPenalty
PhrasePenalty
PhraseDictionaryMemory name=TranslationModel0 num-features=4 
path=/phrase-table.gz input-factor=0 output-factor=0

LexicalReordering 
Distortion
KENLM lazyken=0 name=LM0 path= order=5

[threads]
6

[weight]



On Tuesday, July 21, 2015, Hieu Hoang > wrote:


is it possible you can make your moses.ini file available for us
to see?

do you know if the same problem occurs if you use the command line
moses, rather than mosesserver?


Hieu Hoang
Researcher
New York University, Abu Dhabi
http://www.hoang.co.uk/hieu

On 21 July 2015 at 18:07, Barry Haddow
 wrote:


On 21/07/15 14:51, Oren wrote:

I am using the in-memory mode, using about 50GB of RAM. (No
swap issues as far as I can tell.) Could that cause issues?


Yes, swapping would definitely cause issues - was that your
question?




I looked at the commit you linked to, but it doesn't seem to
be something configurable beyond the -threads switch. Am
I missing something?


The commit enables you to set the maximum number of
connections to be the same as the maximum number of threads.



On Tuesday, July 21, 2015, Barry Haddow
 wrote:

Hi Oren

Does your host have 18 threads available? It could also
be that xmlrpc-c is limiting the number of connections -
this can now be configured:

https://github.com/moses-smt/mosesdecoder/commit/b3baade7f022edbcea2969679a40616683f63523

Slowdowns in Moses are often caused by disk access
bottlenecks. You can use --minphr-memory and
--minlexr-memory to make sure that the phrase and
reordering tables are loaded in to memory, rather than
being access on-demand. Make sure your host has enough
RAM and is not swapping. As I mentioned before there are
various ways to make your models smaller
(http://www.statmt.org/moses/?n=Advanced.RuleTables),
which can make a big difference to speed depending on
your setup.

cheers - Barry

On 21/07/15 09:30, Oren wrote:

Hi Barry,

Thanks for the quick response.

I added the switch "-threads 18" to the command to raise
moses server. The slowness issue persists but in a
different form. Most requests return right away, even
under heavy load, but some requests (about 5%) take far
longer - about 15-20seconds.

Perhaps there are other relevant switches?

Thanks again.

On Monday, July 20, 2015, Barry Haddow
 wrote:

Hi Oren

The threading model is different. In v1, the server
created a new thread for every request, v3 uses a
thread pool. Try increasing the number of threads.

Also, make sure you use the compact phrase table and
KenLM as they are normally faster, and pre-pruning
your phrase table can help,

cheers - Barry

On 20/07/15 12:01, Oren wrote:

Hi all,

We are in the process of migrating from Moses 1 to
Moses 3. We have noticed a significant slowdown
when sending many requests at once to Moses Server.
The first request will actually finish about 25%
faster that a single request using Moses 1, but as
more requests accumulate there is a marked
slowdown, until requests take 5 times longer or more.

Is this a known issue? Is it specific to Moses
Server? What can we do about it?

Thanks!

Oren.


___
Moses-support mailing list
Mo

Re: [Moses-support] BLEU result on baseline EMS experiment

[Vincent Nguyen]

shouldn't the Belu score be more in the 50's for a test set close to the 
corpus ?
I meant by "real text" that I have a corpus of translations (fr to eng) 
made by translators, typically the kind of text I would like to test 
with Moses.


so my question is : should I use these texts to 1) train or 2) tune my 
model ?


also in terms of language model, can we make it evolve with new texts to 
make it better in time ?






Le 22/07/2015 14:28, Hieu Hoang a écrit :

it looks ok, your bleu score is 22.68 for this test set.

I don't know what you mean by real text.

Hieu Hoang
Researcher
New York University, Abu Dhabi
http://www.hoang.co.uk/hieu

On 21 July 2015 at 23:45, Vincent Nguyen > wrote:


here is what I got

make sense ?


MT evaluation scorer began on 2015 Jul 20 at 23:27:39
command line:
/home/moses/mosesdecoder/scripts/generic/mteval-v13a.pl
 -c
-c -s /home/moses/working/data/dev/newstest2011-src.fr.sgm -r
/home/moses/working/data/dev/newstest2011-ref.en.sgm -t
/home/moses/working/evaluation/newstest2011.detokenized.sgm.3
   Evaluation of any-to-en translation using:
 src set "newstest2011" (110 docs, 3003 segs)
 ref set "newstest2011" (1 refs)
 tst set "newstest2011" (1 systems)

length ratio: 0.994844739625875 (74296/74681), penalty (log):
-0.00518197480348868
NIST score = 6.8964  BLEU score = 0.2268 for system "Edinburgh"

#


Individual N-gram scoring
 1-gram   2-gram   3-gram   4-gram   5-gram   6-gram 7-gram
8-gram   9-gram
 --   --   --   --   --   -- --
--   --
  NIST:  5.2752   1.3399   0.2499   0.0273   0.0041   0.0005 0.
0.   0.  "Edinburgh"

  BLEU:  0.5883   0.2887   0.1636   0.0972   0.0589   0.0364 0.0230
0.0146   0.0093  "Edinburgh"

#

Cumulative N-gram scoring
 1-gram   2-gram   3-gram   4-gram   5-gram   6-gram 7-gram
8-gram   9-gram
 --   --   --   --   --   -- --
--   --
  NIST:  5.2752   6.6151   6.8650   6.8923   6.8964   6.8969 6.8970
6.8970   6.8970  "Edinburgh"

  BLEU:  0.5853   0.4100   0.3013   0.2268   0.1730   0.1333 0.1037
0.0811   0.0637  "Edinburgh"
MT evaluation scorer ended on 2015 Jul 20 at 23:28:01
___
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] decoding-graph-backoff

[Saumitra Yadav]

Sir/Ma'am,
I'm trying to use multiple phrase tables for translation in Moses decoder,
with preference to 1st phrase-table, but was getting a segmentation fault
while loading 1st phrase table, so just switched the positions of
phrase-tables in moses configuration file and it was working , now the
table i want to give preference is 2nd in list , can i use

[decoding-graph-backoff]
 1
 3
in configuration file for backoff so that moses uses 2nd table and uses 1st
table only for words it couldn't find in 2nd phrase-table?

Regards,
Saumitra Yadav
M.Tech.
Department Of Computer Science And Technology
Goa University
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support

Re: [Moses-support] BLEU result on baseline EMS experiment

[Hieu Hoang]

it looks ok, your bleu score is 22.68 for this test set.

I don't know what you mean by real text.

Hieu Hoang
Researcher
New York University, Abu Dhabi
http://www.hoang.co.uk/hieu

On 21 July 2015 at 23:45, Vincent Nguyen  wrote:

> here is what I got
>
> make sense ?
>
>
> MT evaluation scorer began on 2015 Jul 20 at 23:27:39
> command line: /home/moses/mosesdecoder/scripts/generic/mteval-v13a.pl -c
> -c -s /home/moses/working/data/dev/newstest2011-src.fr.sgm -r
> /home/moses/working/data/dev/newstest2011-ref.en.sgm -t
> /home/moses/working/evaluation/newstest2011.detokenized.sgm.3
>Evaluation of any-to-en translation using:
>  src set "newstest2011" (110 docs, 3003 segs)
>  ref set "newstest2011" (1 refs)
>  tst set "newstest2011" (1 systems)
>
> length ratio: 0.994844739625875 (74296/74681), penalty (log):
> -0.00518197480348868
> NIST score = 6.8964  BLEU score = 0.2268 for system "Edinburgh"
>
> # 
>
> Individual N-gram scoring
>  1-gram   2-gram   3-gram   4-gram   5-gram   6-gram 7-gram
> 8-gram   9-gram
>  --   --   --   --   --   -- --
> --   --
>   NIST:  5.2752   1.3399   0.2499   0.0273   0.0041   0.0005 0.
> 0.   0.  "Edinburgh"
>
>   BLEU:  0.5883   0.2887   0.1636   0.0972   0.0589   0.0364 0.0230
> 0.0146   0.0093  "Edinburgh"
>
> # 
> Cumulative N-gram scoring
>  1-gram   2-gram   3-gram   4-gram   5-gram   6-gram 7-gram
> 8-gram   9-gram
>  --   --   --   --   --   -- --
> --   --
>   NIST:  5.2752   6.6151   6.8650   6.8923   6.8964   6.8969 6.8970
> 6.8970   6.8970  "Edinburgh"
>
>   BLEU:  0.5853   0.4100   0.3013   0.2268   0.1730   0.1333 0.1037
> 0.0811   0.0637  "Edinburgh"
> MT evaluation scorer ended on 2015 Jul 20 at 23:28:01
> ___
> 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] Support for XML Markup with Confusion Network Input

[Hieu Hoang]

i guess lack of interest. XML markup is usually used by more 
application-focused users who don't usually use complicated things like 
confusion networks, and confusion networks are used mainly by 
researchers who don't use xml markups

On 18/07/2015 00:35, James H. Cross III wrote:
> Hi:
>
> Is it still the case that XML markup is not supported for confusion
> network (or lattice) input? If not, are the reasons for not supporting
> this feature because implementing it imposes particular difficulties
> or simply due to lack of interest?
>
> Thanks,
> James
> ___
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
>

-- 
Hieu Hoang
Researcher
New York University, Abu Dhabi
http://www.hoang.co.uk/hieu

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