Hi,
In my view, the threading design of the server is a bug. How about a
producer-consumer queue with multiple producers (a client connection)
and consumers (decoding threads). Each client connection owns a
producer-consumer queue as a return channel so that decoder threads can
return their result. Or we could use boost futures.
Kenneth
On 03/06/14 10:30, Barry Haddow wrote:
> 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.
>
> 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
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support
