You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mxnet.apache.org by GitBox <gi...@apache.org> on 2019/12/09 08:19:53 UTC

[GitHub] [incubator-mxnet] cjolivier01 removed a comment on issue #10856: Failed OpenMP assertion when loading MXNet compiled with DEBUG=1

cjolivier01 removed a comment on issue #10856: Failed OpenMP assertion when loading MXNet compiled with DEBUG=1
URL: https://github.com/apache/incubator-mxnet/issues/10856#issuecomment-562871044
 
 
   Chris, I'm trying to understand the situation better exactly because I think
   this bug is important and I would like to address it. Therefore I asked you a
   question, expecting your answer would be helpful to solve this problem.
   Unfortunately it seems to me that your answer misses the point of my question.
   
   Let me reiterate the question and provide more background information.
   
   1) It is my understanding that Intel OpenMP and LLVM OpenMP runtime differ
   essentially only in the compiler used to compile them [1]
   
   2) It is my understanding that it is generally accepted that GCC does not work
   well with anything but gomp. GCC wants to force the use of libgomp at the linker
   stage and this leads to a undefined situation that can cause problems like the
   one we observe. Specifically, Stackoverflow describes the problem for Intel OMP
   at [2].
   
   3) There is no reason for compiling MXNet + LLVM OpenMP using the GCC compiler.
   If we want LLVM OpenMP or Intel OpenMP, we can compile with LLVM. If we want
   gomp, we can compile with GCC. Doing anything else seems to be only asking for
   trouble. Thus I suggest we use always use the compiler provided OpenMP.
   
   4) You state that my suggestion equals commenting out the assertion instead of
   fixing the problem. It is my understanding, that the problem only occurs when 2
   OpenMP libraries are linked. However, according to [2], linking 2 OpenMP
   libraries is a "recipe for disaster". Why do we need to go with the "recipe for
   disaster", based on the solution I suggest in point 3).
   
   I fully understand that I don't have anywhere near your experience with OpenMP.
   Therefore, help out to clarify any specific wrong conclusions or assumptions in
   above point. Keep in mind:
   
   > Those who are asked should be responsive and helpful, within the context of
   > our shared goal of improving Apache project code.
   https://www.apache.org/foundation/policies/conduct#specific-guidelines
   
   [1]: https://software.intel.com/en-us/forums/intel-c-compiler/topic/793552
   [2]: https://stackoverflow.com/a/26149633/2560672
   
   Your previous answer has not addressed my code change suggestion. The code
   change is specifically about avoiding to have 2 OpenMP runtimes. You have at no
   point justified why you think we need to have 2 runtimes at the same time. You
   must provide a technical justification showing why having only 1 runtime would
   be bad, or your veto is considered invalid according to Apache's rules.
   
   > To prevent vetos from being used capriciously, they must be accompanied by a
   > technical justification showing why the change is bad (opens a security
   > exposure, negatively affects performance, etc. ). A veto without a
   > justification is invalid and has no weight.
   https://www.apache.org/foundation/voting.html
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services