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
<[email protected]>wrote:

> 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
> reflected reality better,
>
> cheers - Barry
>
>
> On 10/08/12 15:47, Jonathan Clark wrote:
>
>> 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 Lane's sentence splitting.
>>
>> Will modifying the format of these output lines with a prefix cause
>> trouble
>> for anyone?
>>
>>
>>
>> On Fri, Aug 10, 2012 at 10:41 AM, Marcin Junczys-Dowmunt<junczys@amu.**
>> edu.pl <[email protected]>
>>
>>> wrote:
>>> 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 accurate, it does at least seem to be well-proportioned. That is,
>>>> very short sentences that are processed very quickly report a small
>>>> number here, and very long sentences that are processed very slowly
>>>> report a large number here.
>>>>
>>>> On Fri, Aug 10, 2012 at 10:29 AM, Marcin Junczys-Dowmunt
>>>> <[email protected]>  wrote:
>>>>
>>>>> 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 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 the
>>>>>> Collecting Options time.
>>>>>>
>>>>>> On Fri, Aug 10, 2012 at 10:13 AM, Jonathan Clark<[email protected]>
>>>>>>
>>>>> wrote:
>>>
>>>> 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 patch for this I can push, but I just
>>>>>>>
>>>>>> want to
>>>
>>>> make sure I'm not missing something. This is broken, right?
>>>>>>>
>>>>>>> Jon
>>>>>>>
>>>>>> ______________________________**_________________
>>> Moses-support mailing list
>>> [email protected]
>>> http://mailman.mit.edu/**mailman/listinfo/moses-support<http://mailman.mit.edu/mailman/listinfo/moses-support>
>>>
>>>
>>
>> ______________________________**_________________
>> Moses-support mailing list
>> [email protected]
>> http://mailman.mit.edu/**mailman/listinfo/moses-support<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
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support

Reply via email to