Performance Issues.

On 17/05/2006, at 8:00 PM, Simon Urbanek <simon.urbanek at r-
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.

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.

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