[R-SIG-Mac] Performance Issues.

[Simon Urbanek]

On May 17, 2006, at 6:25 AM, Ken Beath wrote:

>
> On 17/05/2006, at 8:00 PM, Simon Urbanek <simon.urbanek at r-
> 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 <iano at apple.com>
> Subject: Re: No Accelerate.framework threading on Intel
> To: scitech at lists.apple.com
> Message-ID: <EBED1267-00B7-4A04-9A0C-E621621E46B8 at apple.com>
> 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 at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
>