Ok, this is weird. We just ran the intel+tcmalloc debug variant and it
completed as normal. Also noticed no tcmalloc debug messages though.
> On Feb 4, 2016, at 12:01 PM, moses-support-requ...@mit.edu wrote:
>
> Send Moses-support mailing list submissions to
> moses-support@mit.edu
>
> T
I prepared all files for incremental training experiment , now my question is
how to set weights in the moses.ini ??
PhraseDictionaryBitextSampling name=PT0 output-factor=0
path=/home/marwa/moses3/post1/post2/corp. L1=en L2=ar smooth=0 prov=1
PT0= g+ s g1jr2 0 j+0.2 1 -1 0.2 I wrote the above
Kenneth,
Here’s a backtrace from gdb-ia from the intel+tcmalloc release variant. We’re
building a debug version now, once it’s ready, I’ll send along that backtrace
if it’s any different.
-Jeremy
Intermezzo: Calculating Huffman code sets
Creating Huffman codes for 471366 target phrase
I can haz backtrace? It's clearly calculating a huge amount to allocate
somewhere which is leading to tcmalloc returning NULL but that's not
tcmalloc's fault.
On 02/04/2016 03:47 PM, Marcin Junczys-Dowmunt wrote:
> I've been using it with and without tcmalloc with no problems, the part
> where it
I've been using it with and without tcmalloc with no problems, the part
where it crashes for is not multi-threading anyway. I guess it's the
intel compiler, no idea why though.
W dniu 2016-02-04 16:37, Jeremy Gwinnup napisał(a):
> Uli,
>
> I sent the phrase-table to Marcin yesterday to test
Uli,
I sent the phrase-table to Marcin yesterday to test - He was able to binarize
the table successfully. Here, we’ve been compiling moses with the Intel
compiler. We built the same checkout with gcc and using processPhraseTableMin
from that build we were able to successfully binarize the phra
Hi Uli,
By now we think this particular error might be caused by Jeremy using
the intel compiler instead of g++.
Duplicate entries will cause crashes due to the minimal perfect hash
function used, it should die with an error message about collisions
then. The duplicate entries coming from the
I've had processPhraseTableMin crash when the phrase table contains
duplicate entries (can't remember if there was an unreasonable memory
allocation involved). Is Marcin using the exact same phrase table? Can you
check if the phrase table has duplicate entries?
To crash or not to crash could also
