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: Help. First request to MosesServer very slow
(Marcos Fernandez)
2. Problem faced in SMT Approach MT SYSTEM using MOSES
(Vishal Goyal (????? ????))
3. Re: Help. First request to MosesServer very slow
(Marcin Junczys-Dowmunt)
4. Reg : Segmentation Fault while loading (Kunal Sachdeva)
----------------------------------------------------------------------
Message: 1
Date: Mon, 10 Mar 2014 09:22:08 +0000 (UTC)
From: Marcos Fernandez <marcos.fernandez.lopez@usc.es>
Subject: Re: [Moses-support] Help. First request to MosesServer very
slow
To: moses-support@mit.edu
Message-ID: <loom.20140310T101759-565@post.gmane.org>
Content-Type: text/plain; charset=us-ascii
> Hi Marcos
>
> I think the problem is that the rules (or phrase pairs) are now cached
> on a per thread basis. This is good for command-line Moses as it uses a
> pool of threads, and having per-thread caches means that there is no
> locking on the caches, as there used to be.
Barry, I am not sure that that is the cause, because in that case my "20
short sentences" file would get translated much faster with command-line
Moses, however it takes 4.5 seconds to translate it. This is, 2 seconds
(measured) for loading tables in memory, and the same 2.5 seconds than with
MosesServer to translate the file. And the behaviour is also the same as
before, the first sentence in the file takes much longer than the rest.
However, what you say perhaps could be the cause of the difference in time
between using a different xmlrpc ServerProxy object for each request
(probably, in this case xmlrpc executes each request in a different thread),
or reusing one only ServerProxy for all the requests (where there would be
only one thread, so it could take advantage of the cache).
What I understand then, is that the cache stores information of the
previously translated sentences to accelerate the translation of the next
ones. But that does not eliminate the problem of the first slower request.
As you can see, I am finding that issue even in command-line Moses (not with
the first "request", but with the first sentence in a file).
I am thinking that perhaps I have no problem, and this is just the usual way
in which Moses works. Just to make sure:
1. would you say that a time of 2-3 seconds for translating (spa-eng) a
single sentence (~15-20 words) could be a normal response time (discounting
the time of loading tables)? (Intel Xeon with 32GB RAM)
2. if now you write 3 similar sentences in a file, and execute Moses
(command-line, serial) over this file, would you expect it to take a much
shorter time (perhaps the half) than the sum of the times for the 3 single
sentences?
If the answer is yes to both (specially the second), then I am probably
worrying in vain. My worries started when I read the "MTMonkey" paper:
http://ufal.mff.cuni.cz/~pecina/files/pbml-2013.pdf
Here the authors use the approach of creating a new ServerProxy instance
each time a request is sent to MosesServer (the worst case scenario for me),
and they get great results, so I thought they were not experiencing that
overhead for every request. But perhaps they just used sentences that get
translated very fast even with that overhead.
Well, in the case that this is the usual way of working for Moses, if what
Kenneth suggests is possible, that would eliminate the overhead almost
completely for MosesServer. I mean, there would still be an overhead for the
first request that each thread serves after the server is just launched, but
never more, because the caches would be filled with useful information from
that point on. I think that this would be extremely interesting for web
translating services, or to do web-page translations "on the fly".
However, I don't see a way to avoid that overhead in command-line Moses, as
it "dies" after each execution.
Marcos.
> mosesserver, afaik, creates a new thread for each connection, so it
> can't take advantage of the cache. This is done in the xmlrpc-c library
> so we don't have much control over it. If you dig around in the xmlrpc-c
> documentation (or code!) you might find a way to control the threading
> policy.
>
> I just spoke to Marcin about the problem, and we're not sure if loading
> the compact phrase table into memory would help, as you still would need
> the higher level cache (in PhraseDictionary). But you could try this anyway.
>
> cheers - Barry
>
> On 06/03/14 17:20, Marcos Fernandez wrote:
> > Hi, I am having an issue with MosesServer.
> >
> > I am using compact phrase and reordering table, and KENLM.
> >
> > The problem is this (I'll explain with an example):
> >
> > - I have one file with 20 very short sentences. I split and tokenize
> > them and send one XMLPRC request per sentence to MosesServer
> > - If I create just one XMLRPC ServerProxy instance and I use it to send
> > all the requests through it, all the sentences get translated in approx
> > 2.5 sec. The problem is that the first sentence takes almost 2 seconds
> > to get translated, while the other 19 are much faster
> > - If I create one ServerProxy instance per request, the translation time
> > rises to 30 sec (now every sentence takes almost 2 sec)
> >
> > I don't understand the reason of that delay for the first request. I
> > have followed the source of this delay to the function:
> >
> > GetTargetPhraseCollectionLEGACY(const Phrase& src)
> >
> > in the file: ...TranslationModel/PhraseDictionary.cpp
> >
> > It seems that for the first request it's needed to look for something
> > in the phrase table, while for subsequent requests it can be retrieved
> > (most of the times) from a cache.
> >
> > But, as the sentences in my file are not related one to another in any
> > way, the information on this cache can not be sentence-dependent, so why
> > wouldn't it be possible for the cache to be preloaded with the
> > information needed?
> >
> > I think that perhaps I have something misconfigured, because I have seen
> > other people using the approach of creating one ServerProxy object for
> > each XMLRPC request (which would facilitate things a lot for me), so I
> > don't think they are experiencing this overhead. Perhaps using the
> > compact formats can have something to do with it?
> >
> > Any help would be much appreciated. I paste below my moses.ini, if that
> > helps:
> >
> > Thanks :)
> >
> > ### MOSES CONFIG FILE ###
> > ###################
> >
> > # input factors
> > [input-factors]
> > 0
> >
> > # mapping steps
> > [mapping]
> > 0 T 0
> >
> > # translation tables: table type (hierarchical(0), textual (0), binary
> > (1)), source-factors, target-factors, number of scores, file
> > # OLD FORMAT is still handled for back-compatibility
> > # OLD FORMAT translation tables: source-factors, target-factors, number
> > of scores, file
> > # OLD FORMAT a binary table type (1) is assumed
> > [ttable-file]
> > 12 0 0 5 /opt/moses-compiling/modelos/es-en/phrase-model/phrase-table
> >
> > # no generation models, no generation-file section
> >
> > # language models: type(srilm/irstlm), factors, order, file
> > [lmodel-file]
> > 8 0 5
> > /opt/moses-compiling/modelos/es-en/lm/13-19-03gen_intec_head8m_sb5LM.kenlm
> >
> >
> > # limit on how many phrase translations e for each phrase f are loaded
> > # 0 = all elements loaded
> > [ttable-limit]
> > 10
> >
> > # distortion (reordering) files
> > [distortion-file]
> > 0-0 wbe-msd-bidirectional-fe-allff 6
> > /opt/moses-compiling/modelos/es-en/phrase-model/reordering-table
> >
> > # distortion (reordering) weight
> > [weight-d]
> > 0.097107
> > 0.150373
> > -0.0551767
> > -0.0307787
> > 0.114613
> > 0.214587
> > 0.0467398
> >
> > # language model weights
> > [weight-l]
> > 0.0442748
> >
> >
> > # translation model weights
> > [weight-t]
> > 0.00370888
> > 0.0425665
> > 0.0719956
> > 0.0202699
> > 0.071147
> >
> > # no generation models, no weight-generation section
> >
> > # word penalty
> > [weight-w]
> > 0.0366626
> >
> > [distortion-limit]
> > 6
> >
> > [v]
> > 0
> >
> >
>
------------------------------
Message: 2
Date: Mon, 10 Mar 2014 20:52:41 +0530
From: Vishal Goyal(????? ????) <vishal.pup@gmail.com>
Subject: [Moses-support] Problem faced in SMT Approach MT SYSTEM using
MOSES
To: Maxim Khalilov <maxkhalilov@gmail.com>
Cc: moses-support <moses-support@mit.edu>, corpora <corpora@uib.no>,
"mt-list@eamt.org" <mt-list@eamt.org>, Ajit Kumar <ajit8671@gmail.com>
Message-ID:
<CADAAq5x=SoXqbiJ355cjMRGpfWMTP8fngANK+fcXsrOPyx0m0A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
> Hello All,
> Greetings. We have developed SMT Approach based Hindi to Punjabi MT System
> using Moses. Now We have hosted on the Linux server and hosted required
> tool kits including MOSES etc.
>
> We are facing a problem that When small text is given as input for
> translation, it will translate but when it get number of requests for
> translations in one go, It gets busy and Only starts doing transliteration
> rather than translation...
> It has been developed using CGI-Perl and has been installed at
> http://tdil-dc.in/hi2pu
>
> Please help us in solving our problem.
>
> Thanks in anticipation...
> Ajit- Please remain in contact with replies from the researchers of this
> group...
>
>
>
>
--
*Regards,*
Vishal Goyal,
Ph.D., M.Tech., MCA, M.C.S.D.
Assistant Professor(Stage III) and Placement Coordinator,
Department of Computer Science,
Punjabi University Patiala-147002
[*Online Hindi to Punjabi Machine Translation Tool -*
http://h2p.learnpunjabi.org ]
*[Research Cell: An International Journal of Engineering Sciences,
http://ijoes.vidyapublications.com <http://ijoes.vidyapublications.com>]*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20140310/bae54b53/attachment-0001.htm
------------------------------
Message: 3
Date: Mon, 10 Mar 2014 15:29:58 +0000
From: Marcin Junczys-Dowmunt <junczys@amu.edu.pl>
Subject: Re: [Moses-support] Help. First request to MosesServer very
slow
To: moses-support@MIT.EDU
Message-ID: <531DDA76.2060500@amu.edu.pl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Marcos,
the command line tool behaviour you are describing is actually
consistent with what Barry said. You would see this lag before the first
couple of translations and later it would disappear. Usually you do not
use the command line tool for only 4 sentences, but for a couple of
hundreds or thousands. For instance if you would create a file that
contains the same sentences say 10 times you would only see the lag for
the first. Your problem is, that MosesSever basically destroys the cache
after each request, so for each new request it has to fill it again.
Hence the delay.
Best,
Marcin
W dniu 10.03.2014 09:22, Marcos Fernandez pisze:
>> Hi Marcos
>>
>> I think the problem is that the rules (or phrase pairs) are now cached
>> on a per thread basis. This is good for command-line Moses as it uses a
>> pool of threads, and having per-thread caches means that there is no
>> locking on the caches, as there used to be.
> Barry, I am not sure that that is the cause, because in that case my "20
> short sentences" file would get translated much faster with command-line
> Moses, however it takes 4.5 seconds to translate it. This is, 2 seconds
> (measured) for loading tables in memory, and the same 2.5 seconds than with
> MosesServer to translate the file. And the behaviour is also the same as
> before, the first sentence in the file takes much longer than the rest.
>
> However, what you say perhaps could be the cause of the difference in time
> between using a different xmlrpc ServerProxy object for each request
> (probably, in this case xmlrpc executes each request in a different thread),
> or reusing one only ServerProxy for all the requests (where there would be
> only one thread, so it could take advantage of the cache).
>
> What I understand then, is that the cache stores information of the
> previously translated sentences to accelerate the translation of the next
> ones. But that does not eliminate the problem of the first slower request.
> As you can see, I am finding that issue even in command-line Moses (not with
> the first "request", but with the first sentence in a file).
>
> I am thinking that perhaps I have no problem, and this is just the usual way
> in which Moses works. Just to make sure:
>
> 1. would you say that a time of 2-3 seconds for translating (spa-eng) a
> single sentence (~15-20 words) could be a normal response time (discounting
> the time of loading tables)? (Intel Xeon with 32GB RAM)
> 2. if now you write 3 similar sentences in a file, and execute Moses
> (command-line, serial) over this file, would you expect it to take a much
> shorter time (perhaps the half) than the sum of the times for the 3 single
> sentences?
>
> If the answer is yes to both (specially the second), then I am probably
> worrying in vain. My worries started when I read the "MTMonkey" paper:
> http://ufal.mff.cuni.cz/~pecina/files/pbml-2013.pdf
>
> Here the authors use the approach of creating a new ServerProxy instance
> each time a request is sent to MosesServer (the worst case scenario for me),
> and they get great results, so I thought they were not experiencing that
> overhead for every request. But perhaps they just used sentences that get
> translated very fast even with that overhead.
>
> Well, in the case that this is the usual way of working for Moses, if what
> Kenneth suggests is possible, that would eliminate the overhead almost
> completely for MosesServer. I mean, there would still be an overhead for the
> first request that each thread serves after the server is just launched, but
> never more, because the caches would be filled with useful information from
> that point on. I think that this would be extremely interesting for web
> translating services, or to do web-page translations "on the fly".
>
> However, I don't see a way to avoid that overhead in command-line Moses, as
> it "dies" after each execution.
>
> Marcos.
>
>
>> mosesserver, afaik, creates a new thread for each connection, so it
>> can't take advantage of the cache. This is done in the xmlrpc-c library
>> so we don't have much control over it. If you dig around in the xmlrpc-c
>> documentation (or code!) you might find a way to control the threading
>> policy.
>>
>> I just spoke to Marcin about the problem, and we're not sure if loading
>> the compact phrase table into memory would help, as you still would need
>> the higher level cache (in PhraseDictionary). But you could try this anyway.
>>
>> cheers - Barry
>>
>> On 06/03/14 17:20, Marcos Fernandez wrote:
>>> Hi, I am having an issue with MosesServer.
>>>
>>> I am using compact phrase and reordering table, and KENLM.
>>>
>>> The problem is this (I'll explain with an example):
>>>
>>> - I have one file with 20 very short sentences. I split and tokenize
>>> them and send one XMLPRC request per sentence to MosesServer
>>> - If I create just one XMLRPC ServerProxy instance and I use it to send
>>> all the requests through it, all the sentences get translated in approx
>>> 2.5 sec. The problem is that the first sentence takes almost 2 seconds
>>> to get translated, while the other 19 are much faster
>>> - If I create one ServerProxy instance per request, the translation time
>>> rises to 30 sec (now every sentence takes almost 2 sec)
>>>
>>> I don't understand the reason of that delay for the first request. I
>>> have followed the source of this delay to the function:
>>>
>>> GetTargetPhraseCollectionLEGACY(const Phrase& src)
>>>
>>> in the file: ...TranslationModel/PhraseDictionary.cpp
>>>
>>> It seems that for the first request it's needed to look for something
>>> in the phrase table, while for subsequent requests it can be retrieved
>>> (most of the times) from a cache.
>>>
>>> But, as the sentences in my file are not related one to another in any
>>> way, the information on this cache can not be sentence-dependent, so why
>>> wouldn't it be possible for the cache to be preloaded with the
>>> information needed?
>>>
>>> I think that perhaps I have something misconfigured, because I have seen
>>> other people using the approach of creating one ServerProxy object for
>>> each XMLRPC request (which would facilitate things a lot for me), so I
>>> don't think they are experiencing this overhead. Perhaps using the
>>> compact formats can have something to do with it?
>>>
>>> Any help would be much appreciated. I paste below my moses.ini, if that
>>> helps:
>>>
>>> Thanks :)
>>>
>>> ### MOSES CONFIG FILE ###
>>> ###################
>>>
>>> # input factors
>>> [input-factors]
>>> 0
>>>
>>> # mapping steps
>>> [mapping]
>>> 0 T 0
>>>
>>> # translation tables: table type (hierarchical(0), textual (0), binary
>>> (1)), source-factors, target-factors, number of scores, file
>>> # OLD FORMAT is still handled for back-compatibility
>>> # OLD FORMAT translation tables: source-factors, target-factors, number
>>> of scores, file
>>> # OLD FORMAT a binary table type (1) is assumed
>>> [ttable-file]
>>> 12 0 0 5 /opt/moses-compiling/modelos/es-en/phrase-model/phrase-table
>>>
>>> # no generation models, no generation-file section
>>>
>>> # language models: type(srilm/irstlm), factors, order, file
>>> [lmodel-file]
>>> 8 0 5
>>> /opt/moses-compiling/modelos/es-en/lm/13-19-03gen_intec_head8m_sb5LM.kenlm
>>>
>>>
>>> # limit on how many phrase translations e for each phrase f are loaded
>>> # 0 = all elements loaded
>>> [ttable-limit]
>>> 10
>>>
>>> # distortion (reordering) files
>>> [distortion-file]
>>> 0-0 wbe-msd-bidirectional-fe-allff 6
>>> /opt/moses-compiling/modelos/es-en/phrase-model/reordering-table
>>>
>>> # distortion (reordering) weight
>>> [weight-d]
>>> 0.097107
>>> 0.150373
>>> -0.0551767
>>> -0.0307787
>>> 0.114613
>>> 0.214587
>>> 0.0467398
>>>
>>> # language model weights
>>> [weight-l]
>>> 0.0442748
>>>
>>>
>>> # translation model weights
>>> [weight-t]
>>> 0.00370888
>>> 0.0425665
>>> 0.0719956
>>> 0.0202699
>>> 0.071147
>>>
>>> # no generation models, no weight-generation section
>>>
>>> # word penalty
>>> [weight-w]
>>> 0.0366626
>>>
>>> [distortion-limit]
>>> 6
>>>
>>> [v]
>>> 0
>>>
>>>
>
>
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
------------------------------
Message: 4
Date: Mon, 10 Mar 2014 21:31:06 +0530
From: Kunal Sachdeva <kunal.sachdeva.90@gmail.com>
Subject: [Moses-support] Reg : Segmentation Fault while loading
To: moses-support@MIT.EDU
Message-ID:
<CAOF+9ddr-saD4XEF1oNECpLcWHQYrxRtvNdzWKrsj7_3h65UrA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello all,
i tried to clean my phrase table my removing some characters from phrases,
like
' ' ' ' comments Remain Rolland ||| - - ??????? ????? ?? ||| 0.112086
2.80203e-05 0.0373621 8.65407e-07 2.718 0.030868 ||| 0-1 0-2 1-2 2-2 4-2
3-3 4-3 4-4 ||| 1 3 1
changed to ====>
comments Remain Rolland ||| - - ??????? ????? ?? ||| 0.112086 2.80203e-05
0.0373621 8.65407e-07 2.718 0.030868 ||| 0-1 0-2 1-2 2-2 4-2 3-3 4-3 4-4
||| 1 3 1
so when now i am try to decode a sentence, i get an eroor
Reading /home/seecat/WMT/eng-hin/WMT_new/model/temp1.gz
----5---10---15---20---25---30---35---40---45---50---55---60---65---70---75---80---85---90---95--100
*******Segmentation fault (core dumped)
this error doesn't come always, when i try to use it with -v(verbose)
option.
It will be great, if someone could help me.
Regards,
Kunal Sachdeva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20140310/a6c76d1d/attachment.htm
------------------------------
_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support
End of Moses-support Digest, Vol 89, Issue 19
*********************************************
Subscribe to:
Post Comments (Atom)
0 Response to "Moses-support Digest, Vol 89, Issue 19"
Post a Comment