As of e99576a, these changes are committed.
If you want in-order timings for all the sentences, you can do: moses
$args |& egrep '^Line' | sort
Jon
On Fri, Aug 10, 2012 at 10:56 AM, Barry Haddow
wrote:
> Hi Jonathon
>
> I remember when I tried to make the "phrase table loading" messages fit
Hi Jonathon
I remember when I tried to make the "phrase table loading" messages fit
better to what was happening in the decoder, some of the regression
tests broke. I'm not sure if they rely on the timing messages being in a
particular format. But yes, it would be great if the timing messages
Also, there is currently no way of relating these stats back to the actual
sentence they came from when using multiple threads as far as I can tell.
Shall I also prefix each of these stats with the line number that the
source sentence came from? This should be useful for timing analysis such
as Lan
That's fine by me.
On Fri, Aug 10, 2012 at 10:42 AM, Jonathan Clark wrote:
> To me, the total time would be reported in the "translation time", which
> actually does seem to implement that (minus threading bugs).
>
> Moses seems to differentiate between doing lookups in the phrase table or
> gram
To me, the total time would be reported in the "translation time", which
actually does seem to implement that (minus threading bugs).
Moses seems to differentiate between doing lookups in the phrase table or
grammar (collecting options) and searching over those options (which also
includes lookups
Reminds me of http://xkcd.com/552/
W dniu 10.08.2012 16:37, Lane Schwartz pisze:
> Well, it may be mostly bogus, but it's not *totally* bogus. :)
>
> I use this number when I perform more advanced corpus splitting (see
> my upcoming MT Marathon paper!), and while I can't claim to know that
> it's
Well, it may be mostly bogus, but it's not *totally* bogus. :)
I use this number when I perform more advanced corpus splitting (see
my upcoming MT Marathon paper!), and while I can't claim to know that
it's accurate, it does at least seem to be well-proportioned. That is,
very short sentences that
I've never used the numbers because they never seemed accurate. It'd be
nice if they were.
On Fri, 10 Aug 2012 16:29:10 +0200, Marcin Junczys-Dowmunt
wrote:
> I on the other hand always had the impression that the time reported
> there is a total bogus, especially for multi-threaded decodi
I on the other hand always had the impression that the time reported
there is a total bogus, especially for multi-threaded decoding.
W dniu 10.08.2012 16:26, Lane Schwartz pisze:
> Not sure what it's supposed to be, but I like having some result that
> reports the total per-sentence processing ti
Not sure what it's supposed to be, but I like having some result that
reports the total per-sentence processing time, including both
collecting options and search.
I'd just always assumed that the search time reported was that number,
I figured that to get just the search time you could subtract t
Hi all,
I just noticed that the moses time reporting is rather misleading.
We see lines:
Collecting options took 13.390 seconds
Search took 13.390 seconds
Translation took 13.390 seconds
However, the "Search took X seconds" count also includes collecting
options, which seems wrong. I have a pat
11 matches
Mail list logo
