MathGroup Archive 2010

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: disappointing CUDA speed

  • To: mathgroup at
  • Subject: [mg114218] Re: disappointing CUDA speed
  • From: Fred Klingener <gigabitbucket at>
  • Date: Sat, 27 Nov 2010 03:38:10 -0500 (EST)
  • References: <ico21b$ne4$>

On Nov 26, 5:26 am, Bill Rowe <readn... at> wrote:
> On 11/25/10 at 5:56 AM, gianluca.go... at (Gianluca Gorni)
> wrote:
> >I have a 1 year old Apple MacBookPro. I installed the
> >cudadriver_3.1.17_macos and then tried the first examples in the
> >documentation:
> >Needs["CUDALink`"] CUDAQ[]
> >True
> >randM = RandomReal[1, {3000, 3000}]; AbsoluteTiming[randM.randM;]
> >{2.688389,Null}
> >AbsoluteTiming[CUDADot[randM, randM];]
> >{7.328353,Null}
> >Quite a letdown. Did I do something wrong?
> >CUDAInformation[] {1 -> {"Name" -> "GeForce 9400M",
> No, you didn't do something wrong. The problem is the limited
> capability of the GeForce 9400M. In particular, the GeForce
> 9400M doesn't support double precision. Using RandomReal you
> have made a matrix of double precision reals, the default
> machine precision number in Mathematica.

I'm facing the same type-matching problem in OpenCL on a comparable
(float, no double) GeForce 8600M GT.

There has to be some some set of Mathematica-to-OpenCL-and-back
functions to do the job. The docs for MathLink (guide/
MathLinkCFunctionsForExchangingReals) show a set of functions for
doing the conversion in the C program, but are these functions headed
in the OpenCLFunctionLoad[] form too?

Fred Klingener

  • Prev by Date: Re: understanding code
  • Next by Date: Re: Can't read a package
  • Previous by thread: Re: disappointing CUDA speed
  • Next by thread: Re: disappointing CUDA speed