Re: [Rd] Manipulating single-precision (float) arrays in .Call functions

From: Simon Urbanek <simon.urbanek_at_r-project.org>
Date: Tue, 19 Jul 2011 09:32:54 -0400

On Jul 19, 2011, at 7:48 AM, Matthew Dowle wrote:

> 
> "Prof Brian Ripley" <ripley_at_stats.ox.ac.uk> wrote in message 
> news:alpine.LFD.2.02.1107190640280.28269_at_gannet.stats.ox.ac.uk...
>> On Mon, 18 Jul 2011, Alireza Mahani wrote:
>> 

>>> Simon,
>>>
>>> Thank you for elaborating on the limitations of R in handling float
>>> types. I
>>> think I'm pretty much there with you.
>>>
>>> As for the insufficiency of single-precision math (and hence limitations
>>> of
>>> GPU), my personal take so far has been that double-precision becomes
>>> crucial
>>> when some sort of error accumulation occurs. For example, in differential
>>> equations where boundary values are integrated to arrive at interior
>>> values,
>>> etc. On the other hand, in my personal line of work (Hierarchical
>>> Bayesian
>>> models for quantitative marketing), we have so much inherent uncertainty
>>> and
>>> noise at so many levels in the problem (and no significant error
>>> accumulation sources) that single vs double precision issue is often
>>> inconsequential for us. So I think it really depends on the field as well
>>> as
>>> the nature of the problem.
>> 
>> The main reason to use only double precision in R was that on modern CPUs 
>> double precision calculations are as fast as single-precision ones, and 
>> with 64-bit CPUs they are a single access.
>> So the extra precision comes more-or-less for free.
> 
> But, isn't it much more of the 'less free' when large data sets are considered? If a double matrix takes 3GB, it's 1.5GB in single.
> That might alleviate the dreaded out-of-memory error for some users in some circumstances. On 64bit, 50GB reduces to 25GB

I'd like to see your 50Gb matrix in R ;) - you can't have a float matrix bigger than 8Gb, for doubles it is 16Gb so you don't gain anything in scalability. IMHO memory is not a strong case these days when hundreds GB of RAM are affordable...

Also you would not complain about pointers going from 4 to 8 bytes in 64-bit thus doubling your memory use for string vectors...

Cheers,
Simon

> and that might make the difference between getting
> something done, or not. If single were appropriate, of course.
> For GPU too, i/o often dominates iiuc.
> 
> For space reasons, is there any possibility of R supporting single
> precision (and single bit logical to reduce memory for logicals by
> 32 times)? I guess there might be complaints from users using
> single inappropriately (or worse, not realising we have an instable
> result due to single).
> 
> Matthew
> 
>> You also under-estimate the extent to which stability of commonly used 
>> algorithms relies on double precision.  (There are stable single-precision 
>> versions, but they are no longer commonly used.  And as Simon said, in 
>> some cases stability is ensured by using extra precision where available.)
>> 
>> I disagree slightly with Simon on GPUs: I am told by local experts that 
>> the double-precision on the latest GPUs (those from the last year or so) 
>> is perfectly usable.  See the performance claims on 
>> http://en.wikipedia.org/wiki/Nvidia_Tesla of about 50% of the SP 
>> performance in DP.
>> 

>>>
>>> Regards,
>>> Alireza
>>>
>>>
>>> --
>>> View this message in context:
>>> http://r.789695.n4.nabble.com/Manipulating-single-precision-float-arrays-in-Call-functions-tp3675684p3677232.html
>>> Sent from the R devel mailing list archive at Nabble.com.
>>>
>>> ______________________________________________
>>> R-devel_at_r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>> 
>> -- 
>> Brian D. Ripley,                  ripley_at_stats.ox.ac.uk
>> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
>> University of Oxford,             Tel:  +44 1865 272861 (self)
>> 1 South Parks Road,                     +44 1865 272866 (PA)
>> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
>> 
> 
> ______________________________________________
> R-devel_at_r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 

______________________________________________
R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Tue 19 Jul 2011 - 13:35:54 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Tue 19 Jul 2011 - 15:00:10 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive