On May 17, 2006, at 6:25 AM, Ken Beath wrote: > > On 17/05/2006, at 8:00 PM, Simon Urbanek <[EMAIL PROTECTED] > project.org> wrote: >> >> We had a discussion about this earlier, it started with >> https://stat.ethz.ch/pipermail/r-sig-mac/2006-March/002722.html >> >> What it boils down to is that ptATLAS can give you a good speed-up, >> but it can also screw you up by calling malloc/free all the time - it >> depends on the task. For single core CPUs it's definitely better to >> use R's own BLAS. For Core Duos it depends on the size of the problem >> - for bigger problems ptATLAS is better, for smaller problems >> internal BLAS may be better. >> >> In a quiet minute I'll try to run our benchmarks with Lea's allocator >> and see if it would make sense to use it for OS X. >> > > > A posting from the Scitech mailing list may be of interest. >
Yes, thanks, I know - that's why we started the whole discussion in the first place. On i686 vecLib is just single-threaded ATLAS so it's the worst solution of all (it exhibits the same malloc/free problem as ptATLAS but without any speed up potential) - that's why the CRAN binary supplies ptATLAS. So the real options don't include vecLib, we are talking ptATLAS vs. internal BLAS here. Of course, we hope that Apple will supply a more reasonable vecLib at some point - they did a very good job with vecLib and G5 - but that's probably a distant future. Cheers, Simon > Date: Thu, 4 May 2006 13:14:35 -0700 > From: Ian Ollmann <[EMAIL PROTECTED]> > Subject: Re: No Accelerate.framework threading on Intel > To: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > Accelerate's BLAS is currently not threaded on Intel. The version > that is currently out was tuned for the developer preview machines > -- Pentium 4, uniprocessor. On those machines, threading just got > mapped to hyperthreading which didn't do much but slow it down. > > The other parts of Accelerate.framework should generally be in much > better shape. We're working hard to patch up the remaining holes. > > _______________________________________________ > R-SIG-Mac mailing list > R-SIG-Mac@stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > > _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
