Dear all, I would like to submit an issue that we are facing. Indeed, in our environment, we are optimizing the R code to speed up some mathematical calculations as matrix products using the INTEL libraries ( MKL) ( https://software.intel.com/en-us/mkl ) With the last version of the MKL libraries Intel 2018, we are facing to an issue with *all INTERNAL command* that are executing in R. The R console is freezing executing a process at 100% and never stop!!! It?s really an issue for us. As example, we can reproduce the error with *crossprod. Crossprod *which is a wrapper of BLAS GEMM (optimized with MKL libraries), in this function it seems that variables are not protected ( PROTECT(); UNPROTECT() ), see the screenshot below, which is a recommendation for external commands: Picture1 *RECOMMANDATION* *Picture2* *Code of CROSSPROD* Picture 3 If we are recoding the CROSSPROD function with PROTECTT No more issues? Do you have any idea to solve this bug? Any recommendations? Thank you by advance for your help. Best regards, Guillaume Collange -- Guillaume Collange -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture1.png Type: image/png Size: 95784 bytes Desc: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20180108/62b1680d/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture2.png Type: image/png Size: 100803 bytes Desc: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20180108/62b1680d/attachment-0001.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture3.png Type: image/png Size: 101400 bytes Desc: not available URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20180108/62b1680d/attachment-0002.png>
Hi Guillaume,
In principle, mycrossprod function does not need to PROTECT "ans",
because it does not call any allocating function after allocating
"ans"
("dgemm" in particular should not allocate from the R heap). So it is
surprising that PROTECTion makes a difference in your case. I agree
there is no harm protecting defensively. R itself calls dgemm with the R
object for the result protected when calculating matrix products, but
there it is needed because there is further allocation when setting up
attributes for the result.
Best
Tomas
On 01/08/2018 02:41 PM, Guillaume Collange wrote:> Dear all,
>
>
>
> I would like to submit an issue that we are facing.
>
>
>
> Indeed, in our environment, we are optimizing the R code to speed up some
> mathematical calculations as matrix products using the INTEL libraries (
> MKL) ( https://software.intel.com/en-us/mkl )
>
>
>
> With the last version of the MKL libraries Intel 2018, we are facing to an
> issue with *all INTERNAL command* that are executing in R. The R console is
> freezing executing a process at 100% and never stop!!! It?s really an issue
> for us.
>
>
>
> As example, we can reproduce the error with *crossprod. Crossprod *which is
> a wrapper of BLAS GEMM (optimized with MKL libraries), in this function it
> seems that variables are not protected ( PROTECT(); UNPROTECT() ), see the
> screenshot below, which is a recommendation for external commands:
>
>
>
> Picture1
>
>
> *RECOMMANDATION*
>
> *Picture2*
>
> *Code of CROSSPROD*
>
> Picture 3
>
>
>
> If we are recoding the CROSSPROD function with PROTECTT
>
> No more issues?
>
>
>
>
>
> Do you have any idea to solve this bug? Any recommendations?
>
>
>
>
>
> Thank you by advance for your help.
>
>
>
>
>
> Best regards,
>
> Guillaume Collange
>
>
>
>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
The x and y passed to dgemm in that code are pointers to the same memory, thus breaking Fortran's no-aliasing rule. Is it possible the MKL depends on the caller following that rule? You might try dsyrk() instead of dgemm. Bill Dunlap TIBCO Software wdunlap tibco.com On Mon, Jan 8, 2018 at 6:57 AM, Tomas Kalibera <tomas.kalibera at gmail.com> wrote:> Hi Guillaume, > > In principle, mycrossprod function does not need to PROTECT "ans", > because it does not call any allocating function after allocating "ans" > ("dgemm" in particular should not allocate from the R heap). So it is > surprising that PROTECTion makes a difference in your case. I agree > there is no harm protecting defensively. R itself calls dgemm with the R > object for the result protected when calculating matrix products, but > there it is needed because there is further allocation when setting up > attributes for the result. > > Best > Tomas > > > On 01/08/2018 02:41 PM, Guillaume Collange wrote: > > Dear all, > > > > > > > > I would like to submit an issue that we are facing. > > > > > > > > Indeed, in our environment, we are optimizing the R code to speed up some > > mathematical calculations as matrix products using the INTEL libraries ( > > MKL) ( https://software.intel.com/en-us/mkl ) > > > > > > > > With the last version of the MKL libraries Intel 2018, we are facing to > an > > issue with *all INTERNAL command* that are executing in R. The R console > is > > freezing executing a process at 100% and never stop!!! It?s really an > issue > > for us. > > > > > > > > As example, we can reproduce the error with *crossprod. Crossprod *which > is > > a wrapper of BLAS GEMM (optimized with MKL libraries), in this function > it > > seems that variables are not protected ( PROTECT(); UNPROTECT() ), see > the > > screenshot below, which is a recommendation for external commands: > > > > > > > > Picture1 > > > > > > *RECOMMANDATION* > > > > *Picture2* > > > > *Code of CROSSPROD* > > > > Picture 3 > > > > > > > > If we are recoding the CROSSPROD function with PROTECTT > > > > No more issues? > > > > > > > > > > > > Do you have any idea to solve this bug? Any recommendations? > > > > > > > > > > > > Thank you by advance for your help. > > > > > > > > > > > > Best regards, > > > > Guillaume Collange > > > > > > > > > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel[[alternative HTML version deleted]]