Moses-support Digest, Vol 98, Issue 38

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: Moses machine translation performance tuning (Martin Li?ka)
2. Re: Moses machine translation performance tuning (Barry Haddow)
3. Re: Moses machine translation performance tuning (Martin Li?ka)


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

Message: 1
Date: Fri, 12 Dec 2014 15:33:25 +0100
From: Martin Li?ka <marxin.liska@gmail.com>
Subject: Re: [Moses-support] Moses machine translation performance
tuning
To: Hieu Hoang <Hieu.Hoang@ed.ac.uk>
Cc: moses-support <moses-support@mit.edu>
Message-ID:
<CAObPJ3Nr6VsdDnEXfid01DbNPqS6S3hzbUV3fado913_8Lmt1Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Fully agree with your, there must be a potential trade-off between
spent time and speed up benefit.
As I read perf reports, I haven't seen any other std::set critical
place where unordered_set would worth for replacement.

Martin


On 12 December 2014 at 15:10, Hieu Hoang <Hieu.Hoang@ed.ac.uk> wrote:
>
>
> On 12 December 2014 at 13:53, Martin Li?ka <marxin.liska@gmail.com> wrote:
>>
>> On 12 December 2014 at 14:19, Hieu Hoang <Hieu.Hoang@ed.ac.uk> wrote:
>> > thanks for that.
>> >
>> > Can you tell me what LTO is?
>>
>> Hello.
>>
>> It's Link-Time Optimization, briefly, idea is to emit intermediate
>> language for all translation units (cpp file)
>> to object files. And during linking, all these object files are
>> collected and a compiler can optimize
>> entire program (called inter-procedural optimizations). Classic
>> compilation approach emits assembly language
>> for all TUs (translation units), where optimizations are performed
>> locally on these units.
>>
>> It brings few percents, would be interesting to identify why Moses is
>> not so beneficial about it.
>>
>> And there's one more interesting approach: profile-guided
>> optimization, where you compile a program twice:
>> 1) first time, you annotate functions with special profiling
>> instructions which count number of executions
>> of a branch, function, etc. This training can be run on test suite.
>> 2) second compilation benefits from these hints (statistic collected
>> data) and can produce faster code.
>> Even if you have quite poor testsuite, there data are much better that
>> embedded heuristics.
>>
>> >
>> > From the results, you get a 2% improvement by not using dynanic cast,
>> > and
>> > another 2.65% by using unordered set? Is that correct
>>
>> You are right.
>>
>> >
>> > The biggest use of set are the stacks (classes
>> > ChartHypothesisCollection,
>> > HypothesisStack). We can change that to unordered_set but that'll
>> > require
>> > redoing the state information classes of all stateful FF. It's a big job
>> > to
>> > redo
>>
>> In general, all std::sets that do not require any particular order can
>> be replaced
>> with unordered_set, where a potential speed-up can occur.
>
>
> Our data structures implicitly implement operator< which is required to add
> them to std::set
>
> To use unordered set, they would need to implement operator= and hash().
>
> They are a few dozen of these datastructures. That's why its a big job and
> having an estimate of the speedup would be useful before we embark on it
>>
>>
>> Martin
>>
>> >
>> > However, it would be good to measure how much time the stack operation
>> > takes
>> > so we can size up the enemy :)
>> >
>> >
>> > On 12 December 2014 at 12:45, Martin Li?ka <marxin.liska@gmail.com>
>> > wrote:
>> >>
>> >> Hello.
>> >>
>> >> As part of my SUSE Hackweek project ([1]), I've spent couple of days
>> >> playing with Moses performance tuning. I cooperated with Ale? and our
>> >> effort produced two patches that have been just merged to mainline. If
>> >> you are interested in more details, please visit my blog post: [2].
>> >> I would be really happy if my blog post would become a kick-off for
>> >> further performance tuning.
>> >>
>> >> Thanks,
>> >> Martin Li?ka,
>> >> SUSE Labs
>> >>
>> >> [1] https://hackweek.suse.com/11/projects/284
>> >> [2] http://marxin.github.io/posts/moses-performance-tuning/
>> >>
>> >> _______________________________________________
>> >> Moses-support mailing list
>> >> Moses-support@mit.edu
>> >> http://mailman.mit.edu/mailman/listinfo/moses-support
>> >
>> >
>> >
>> > --
>> > Hieu Hoang
>> > Research Associate
>> > University of Edinburgh
>> > http://www.hoang.co.uk/hieu
>> >
>>
>
>
> --
> Hieu Hoang
> Research Associate
> University of Edinburgh
> http://www.hoang.co.uk/hieu
>



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

Message: 2
Date: Fri, 12 Dec 2014 14:54:08 +0000
From: Barry Haddow <bhaddow@staffmail.ed.ac.uk>
Subject: Re: [Moses-support] Moses machine translation performance
tuning
To: Martin Li?ka <marxin.liska@gmail.com>, moses-support@mit.edu
Message-ID: <548B0190.1060905@staffmail.ed.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Martin

Interesting work - thanks for sharing.

I was just curious about this comment:

> Moses::Hypothesis::EvaluateWhenApplied method is dominated by
> calculation of bit intervals. More precisely, for a given set
> represented in bits: 010011, we would like identify consecutive zero
> chunks: <3-4> and <6-6>. I am not familiar with any vector instruction
> solution which can help
Where is the calculation of bit intervals done? If this is a big issue,
could they be precalculated somehow? Bit vectors start off as all
zeroes, then each time a bit is flipped, the a zero chunk is split,

cheers - Barry

On 12/12/14 12:45, Martin Li?ka wrote:
> Hello.
>
> As part of my SUSE Hackweek project ([1]), I've spent couple of days
> playing with Moses performance tuning. I cooperated with Ale? and our
> effort produced two patches that have been just merged to mainline. If
> you are interested in more details, please visit my blog post: [2].
> I would be really happy if my blog post would become a kick-off for
> further performance tuning.
>
> Thanks,
> Martin Li?ka,
> SUSE Labs
>
> [1] https://hackweek.suse.com/11/projects/284
> [2] http://marxin.github.io/posts/moses-performance-tuning/
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support


--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



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

Message: 3
Date: Fri, 12 Dec 2014 16:15:10 +0100
From: Martin Li?ka <marxin.liska@gmail.com>
Subject: Re: [Moses-support] Moses machine translation performance
tuning
To: Barry Haddow <bhaddow@staffmail.ed.ac.uk>
Cc: moses-support <moses-support@mit.edu>
Message-ID:
<CAObPJ3PnPFFxqWDJmKTnhx29ieN1xbB-y6ZcgL_RaTkOfo17Jg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On 12 December 2014 at 15:54, Barry Haddow <bhaddow@staffmail.ed.ac.uk> wrote:
> Hi Martin
>
> Interesting work - thanks for sharing.
>
> I was just curious about this comment:
>
>> Moses::Hypothesis::EvaluateWhenApplied method is dominated by calculation
>> of bit intervals. More precisely, for a given set represented in bits:
>> 010011, we would like identify consecutive zero chunks: <3-4> and <6-6>. I
>> am not familiar with any vector instruction solution which can help
>
> Where is the calculation of bit intervals done? If this is a big issue,
> could they be precalculated somehow? Bit vectors start off as all zeroes,
> then each time a bit is flipped, the a zero chunk is split,
>
> cheers - Barry

Hello Barry.

This calculation is processed in
https://github.com/moses-smt/mosesdecoder/blob/master/moses/SquareMatrix.cpp#L40,
Mentioned function takes words bitmap, calculates consecutive zero
chunks and calls GetScore for each of these chunks.

I am not sure it can beneficial to have a list of these chunks
maintained after each flip operation.

Martin


>
>
> On 12/12/14 12:45, Martin Li?ka wrote:
>>
>> Hello.
>>
>> As part of my SUSE Hackweek project ([1]), I've spent couple of days
>> playing with Moses performance tuning. I cooperated with Ale? and our
>> effort produced two patches that have been just merged to mainline. If
>> you are interested in more details, please visit my blog post: [2].
>> I would be really happy if my blog post would become a kick-off for
>> further performance tuning.
>>
>> Thanks,
>> Martin Li?ka,
>> SUSE Labs
>>
>> [1] https://hackweek.suse.com/11/projects/284
>> [2] http://marxin.github.io/posts/moses-performance-tuning/
>>
>> _______________________________________________
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://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


End of Moses-support Digest, Vol 98, Issue 38
*********************************************

Tweet