Moses-support Digest, Vol 108, Issue 39

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
(Marcin Junczys-Dowmunt)


----------------------------------------------------------------------

Message: 1
Date: Sun, 11 Oct 2015 18:24:18 +0200
From: Marcin Junczys-Dowmunt <junczys@amu.edu.pl>
Subject: Re: [Moses-support] Faster decoding with multiple moses
instances
To: Hieu Hoang <hieuhoang@gmail.com>, moses-support@mit.edu
Message-ID: <561A8D32.7030306@amu.edu.pl>
Content-Type: text/plain; charset="utf-8"

So, shall I merge with master then?

W dniu 09.10.2015 o 18:14, Hieu Hoang pisze:
> I appeared to have screwed up. THe unblockpt branch is large number of
> threads. It downside is that it appears to use more memory so
> multi_moses.py bring down the server @ high threadcount. Can't win
> them all
>
>
> 1 5 10 15 20 25 30 35
> 49 real4m56.474s real1m17.770s real0m50.482s real0m49.970s
> real0m50.851s real0m52.411s real0m54.263s 0m55.137s
> Baseline (master) user4m39.099s user5m39.706s user6m32.275s
> user7m54.693s user8m7.420s user8m7.606s user8m26.099s 8m8.707s
>
> sys0m17.379s sys0m35.081s sys0m55.350s sys1m13.207s
> sys1m21.048s sys1m25.325s sys1m26.464s 1m28.651s
>
>
>
>
>
>
>
>
>
> 50 real4m52.220s real1m16.839s real0m45.847s real0m38.332s
> real0m36.764s real0m36.254s real0m36.254s 0m36.833s
> (49) + unblockpt user4m34.703s user5m38.984s user6m14.616s
> user7m14.220s user8m45.198s user9m49.285s user9m49.285s 11m51.531s
>
> sys0m17.484s sys0m34.341s sys0m57.122s sys1m34.292s
> sys2m19.347s sys3m34.444s sys3m34.444s 4m55.236s
>
>
>
>
>
>
>
>
>
> 51
> real1m16.387s real0m41.680s real0m38.793s real0m31.237s Crashed
> Crashed Crashed
> (50) + multi_moses
> user5m6.564s user5m21.844s user5m44.855s user6m21.015s
>
>
>
>
> sys0m40.458s sys0m57.749s sys1m16.392s sys1m44.173s
>
>
>
>
>
>
>
>
>
>
>
> 52
> real1m32.930s real0m49.833s real0m49.833s real0m28.860s
> real0m30.364s
>
> (49) + multi_moses
> user5m2.480s user5m14.156s user5m14.156s user6m22.374s
> user6m40.412s
>
>
>
> sys0m35.557s sys0m53.235s sys0m53.235s sys1m41.948s sys2m14.619s
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 53 real4m36.515s real1m13.842s real0m44.441s real0m36.498s
> real0m34.639s real0m33.218s real0m33.003s 0m33.482s
> (50) + probing user4m20.862s user5m20.037s user6m0.768s
> user6m56.545s user8m21.316s user9m20.490s user10m22.638s 10m50.360s
>
> sys0m15.712s sys0m35.746s sys0m53.254s sys1m19.331s
> sys1m54.006s sys2m40.239s sys3m43.040s 3m59.816s
>
>
>
> On 08/10/2015 21:00, Marcin Junczys-Dowmunt wrote:
>> I have a branch, "unblockpt", those locks are gone and caches are
>> thread-local. Hieu claims there is still not speed up.
>>
>> W dniu 08.10.2015 o 21:56, Kenneth Heafield pisze:
>>> Good point. I now blame this code from
>>> moses/TranslationModel/CompactPT/TargetPhraseCollectionCache.h
>>>
>>> Looks like a case for a concurrent fixed-size hash table. Failing that,
>>> banded locks instead of a single lock? Namely an array of hash tables,
>>> each of which is independently locked.
>>>
>>> /** retrieve translations for source phrase from persistent cache **/
>>> void Cache(const Phrase &sourcePhrase, TargetPhraseVectorPtr tpv,
>>> size_t bitsLeft = 0, size_t maxRank = 0) {
>>> #ifdef WITH_THREADS
>>> boost::mutex::scoped_lock lock(m_mutex);
>>>

Tweet