The results I posted were from experiments with moses-cmd and not from my
thread pool version of mosesserver, although the results were similar.

I looked the in the archives, and can find no explanation for the new cache
approach (global to per-thread).  What use case is improved with this
approach?


On Thu, Jun 26, 2014 at 9:19 AM, Hieu Hoang <[email protected]> wrote:

> Is the performance ok with the command line version? Can you push your
> thread pool changes to a new branch.
>
> I'll take a look at it when I get the chance
>
>
> On 25 June 2014 16:25, Mike Ladwig <[email protected]> wrote:
>
>> I'm trying to move from the moses 1.x release to 2.x, but have
>> encountered large performance issues. On my workstation (Scientific Linux
>> 6.5), using the same spa-eng data to create two systems I get performance
>> roughly 3x slower on release 2.1.1.
>>
>> I started by comparing moseserver between the 1.x and 2.x releases.
>>  After discovering the "single phrase cache per thread" issue, I rewrote
>> mosesserver using a thread pool but only got a 10-20% improvement.
>>
>> Thinking I might not really have fixed mosesserver, I tried comparing
>> unmodified moses-cmd speed between releases.   The values are in words per
>> minute for a 2000 line, 48k word file.
>>
>>               1T         4T       8T
>> Rel 1:   4850   16492   19500
>> Rel 2:   1742    5324      6559
>>
>> Any suggestions?
>>
>> Regards,
>> mike.
>>
>> _______________________________________________
>> Moses-support mailing list
>> [email protected]
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>>
>
>
> --
> Hieu Hoang
> Research Associate
> University of Edinburgh
> http://www.hoang.co.uk/hieu
>
>
_______________________________________________
Moses-support mailing list
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support

Reply via email to