[Rd] Fwd: R/MKL Intel 2018 Compatibility

William Dunlap wdunlap at tibco.com
Mon Jan 8 16:54:15 CET 2018


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]]



More information about the R-devel mailing list