Moses-support Digest, Vol 98, Issue 37

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


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

Message: 1
Date: Fri, 12 Dec 2014 13:45:55 +0100
From: Martin Li?ka <marxin.liska@gmail.com>
Subject: [Moses-support] Moses machine translation performance tuning
To: moses-support@mit.edu
Message-ID:
<CAObPJ3PGb6YcGjQfFDXVNYLVTtUw3u9bgqAzDA3XzriDG7SuWg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

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/



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

Message: 2
Date: Fri, 12 Dec 2014 13:19:47 +0000
From: Hieu Hoang <Hieu.Hoang@ed.ac.uk>
Subject: Re: [Moses-support] Moses machine translation performance
tuning
To: Martin Li?ka <marxin.liska@gmail.com>
Cc: moses-support <moses-support@mit.edu>
Message-ID:
<CAEKMkbi24OMxpvmFEEUdGr=+Fv2f2iqGLeQjo6YoVqUuK2W4yA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

thanks for that.

Can you tell me what LTO is?

>From the results, you get a 2% improvement by not using dynanic cast, and
another 2.65% by using unordered set? Is that correct

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20141212/19a749f2/attachment-0001.htm

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

Message: 3
Date: Fri, 12 Dec 2014 14:53:31 +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:
<CAObPJ3POO87VCJ14W8Au2+egC-deySCeQ-0yqhY5MihGnEJjNA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

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.

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
>



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

Message: 4
Date: Fri, 12 Dec 2014 14:10:17 +0000
From: Hieu Hoang <Hieu.Hoang@ed.ac.uk>
Subject: Re: [Moses-support] Moses machine translation performance
tuning
To: Martin Li?ka <marxin.liska@gmail.com>
Cc: moses-support <moses-support@mit.edu>
Message-ID:
<CAEKMkbh=3RcWJowb0CrNqUMskR6qxo6Xox1Oq+CFbnTOF+vNzA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/mailman/private/moses-support/attachments/20141212/3fe26418/attachment.htm

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

_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support


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

Tweet