Fwd: R/MKL Intel 2018 Compatibility

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: R/MKL Intel 2018 Compatibility

Guillaume Collange
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Picture1.png (128K) Download Attachment
Picture2.png (134K) Download Attachment
Picture3.png (135K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: R/MKL Intel 2018 Compatibility

Tomas Kalibera
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
>
>
>
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: R/MKL Intel 2018 Compatibility

R devel mailing list
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 <[hidden email]>
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
> >
> >
> >
> >
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel