Hi Tom,
yes, that's right. In multithreaded moses / moses_chart, the translations, n-best, and trace output for sentence n are all queued until the output from sentence n-1 has been written. The queueing doesn't happen for the logging output that goes to stderr -- it's written immediately -- so it will appear out of order and out of sync with the rest of the output.
Phil,
Re "output to stderr will be messed up"... do you mean that the order and timing of stderr output will be out of synch with the output to stdout? I found this to be the case with multi-threaded moses and therefore stderr output can not be used to monitor progress and/or control workflows.
Tom
On Tue, 13 Sep 2011 19:27:47 +0000 (GMT), Phil Williams <[email protected]> wrote:
I think GENERAL:cores sets the maximum number of active EMS steps, it doesn't change the number of threads used for decoding. You need to set the decoder's -threads N option in TUNING:decoder-settings and/or EVALUATION:decoder-settings.A caveat is that the output to stderr will be messed up, though that's true for multi-threaded moses as well.Phil
On 13 Sep, 2011,at 08:11 PM, Hieu Hoang wrote:Is it as simple as setting the
[GENERAL]
cores = 8
in the config file, and making sure the decoding was compiled with threads?
_______________________________________________
Moses-support mailing list
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support_______________________________________________
Moses-support mailing list
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support
_______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
