Re: IOS floating point performance
Re: IOS floating point performance
- Subject: Re: IOS floating point performance
- From: Trygve Inda <email@hidden>
- Date: Thu, 08 Aug 2013 06:29:20 -0700
- Thread-topic: IOS floating point performance
>
> On 8 Aug, 2013, at 3:28 PM, Kevin Meaney <email@hidden> wrote:
>
>> I could well be wrong as I'm working from ancient memory but I believe c
>> upgrades floats to doubles to perform calculations and then if result is
>> stored in a float it will chuck away precision at time of assignment to the
>> float.
>>
>> I would repeat the recommendations of other to try using vlib.
>>
>> I gather from original question when OP referred to narrowing down to a few
>> functions that this was achieved by profiling.
>>
>> Kevin
>>
>
> shouldn't do that as long as one uses the correct functions, ie sinf() and
> cosf(). Indeed if you just use sin() and cos() it will upgrade them to doubles
> and then cast them back down again, getting yet slower in the process than it
> was before.
>
> Without seeing the algorithm it's hard to say for sure but the OPs comment
> that float gave 'completely wrong answers' feels a bit odd. You'd have to have
> a very long string of calculations for the error between floats and doubles to
> add up to something which is 'completely wrong'. Could happen, but I'd look
> for bugs before discarding floats totally. I'd also probably look see if
> there's another algorithm, or if you can seed one day with the data from the
> previous/next one and start close to the right answer.
>
> Regrettably OpenCL hasn't made it to iOS yet, dumping massively parallel
> calculations like this onto the GPU can work wonders although I'm not
> well-enough versed with it to say whether the trig performance on a GPU sucks
> enough to make it not worthwhile.
>
> One last option is not to require a month at a time to be calculated. Much
> like populating UITableViews, if you can focus on the day someone's looking at
> right now and get that one done first, you can always calculate a few likely
> next ones in the background. App looks super responsive, under the water it's
> paddling like a crazed duck but always prioritizing the thing you need on
> screen right now. That is sometimes just a matter of changing the UI a bit.
>
> Another last option is to pre-calculate a load of this data, see if there is a
> bulk of the calculation which is say independent of the user's location, work
> that out and cache it, then finish the calculation off for the user's actual
> position. Again this all depends on exactly what you're trying to do.
>
I am looking at caching things and I did find one stray time-waster:
[[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar]
This is called from C (not Cocoa) so I am looking at the best way to do this
once and pass the NSCalendar object to where it is needed.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden