I have just heard that the iphone cannot do double natively thereby making them much slower that regular float.
Is this true? Evidence?
I am very interested in the issue because my program needs high precision calculations, and I will have to compromise on speed.
The iPhone can do both single and double precision arithmetic in hardware. On the 1176 (original iPhone and iPhone3G), they operate at approximately the same speed, though you can fit more single-precision data in the caches. On the Cortex-A8 (iPhone3GS, iPhone4 and iPad), single-precision arithmetic is done on the NEON unit instead of VFP, and is substantially faster.
Make sure to turn off thumb mode in your compile settings for armv6 if you are doing intensive floating-point computation.
This slide show gives insight in why there isn't good floating point and why there is (the vector floating point unit). Apparently, it is important you check the "thumb mode" which influences whether or not floating point support is on. This is not always an improvement. It shows how to find the right instructions in the assembly code.
It also depends on what version of the phone you want to run your code. The most recent one seems "more capable" in doing floating point math.
EDIT: here's an interesting read on floating point optimizations on the ARM with VFP and NEON SSE.
The ARM1176JZF-S manual says that it supports double precision floating point numbers. You should be in good shape. Here's a link to the PDF documentation. Later iPhones are Cortex chips, and certainly shouldn't be less capable.
Related
I understand that there can be a .000000000000001 margin of error for double math and this is be made worse by multiplication to make the margin of error larger. With that said, is it possible to round off every calculation to a significant digit (maybe 4 decimal places) to achieve consistency across all platforms? Would it simply be more efficient using decimal math or will decimal math require similar rounding?
I will be using this for my lockstep RTS game which requires a deterministic physics engine for synchronous multiplayer. I'm using C#. Some calculations and some calculations I wish to perform include Sqrt, Sin, and Pow of the System.Math library.
I've actually been thinking about the whole matter in the wrong way. Instead of trying to minimize errors with greater accuracy (and more overhead), I should just use a type that stores and operates deterministically. I used the answer here: Fixed point math in c#? which helped me create a fixed point type that works perfectly and efficiently.
I'm building a library for iphone (speex, but i'm sure it will apply to a lot of other libs too) and the make script has an option to use fixed point instead of floating point.
As the iphone ARM processor has the VFP extension and performs very well floating point calculations, do you think it's a better choice to use the fixed point option ?
If someone already benchmarked this and wants to share , i would really thank him.
Well, it depends on the setup of your application, here is some guidelines
First try turning on optimization to 0s (Fastest Smallest)
Turn on Relax IEEE Compliance
If your application can easily process floating point numbers in contiguous memory locations independently, you should look at the ARM NEON intrinsic's and assembly instructions, they can process up to 4 floating point numbers in a single instruction.
If you are already heavily using floating point math, try to switch some of your logic to fixed point (but keep in mind that moving from an NEON register to an integer register results in a full pipeline stall)
If you are already heavily using integer math, try changing some of your logic to floating point math.
Remember to profile before optimization
And above all, better algorithms will always beat micro-optimizations such as the above.
If you are dealing with large blocks of sequential data, NEON is definitely the way to go.
Float or fixed, that's a good question. NEON is somewhat faster dealing with fixed, but I'd keep the native input format since conversions take time and eventually, extra memory.
Even if the lib offers a different output formats as an option, it almost alway means lib-internal conversions. So I guess float is the native one in this case. Stick to it.
Noone prevents you from micro-optimizing better algorithms. And usually, the better the algorithm, the more performance gain can be achieved through micro-optimizations due to the pipelining on modern machines.
I'd stay away from intrinsics though. There are so many posts on the net complaining about intrinsics doing something crazy, especially when dealing with immediate values.
It can and will get very troublesome, and you can hardly optimize anything with intrinsics either.
As the title, I'm finding vector/matrix library in C optimized for iPhone/iPod processors.
Or just generally fast.
---(edit)---
I'm sorry for unclear question.
I'm looking for fast lib for commercial games for iPhone/iPod. So GPL lib cannot be used.
However, I'll stop finding fastest lib, it maybe meaningless.
Now(2010.06.26) Accelerate framework included on iOS4, so vDSP/BLAS functions are available.
This utilizes hardware feature (CPU or SIMD) to accelerate floating point operations, so superior speed (2~4.5x average, 8x maximum) and less energy(0.25x maximum) consuming can be gained by using this.
Thanks people for other answers.
Depends very much on your needs, if you're just using straight floating point math you will probably find that the compiler will use software floating point, which will be very slow. So step one is making sure that youuse the hardware floating point unit that is available in the iPhone processor.
Step two is using an already well established library, there are several, Hassan already provided you with a link to the GNU GSL which is nice.
The next step would be to take advantage of the VFP SIMD like abilities. The VFP is not actually SIMD, but does provide SIMD like instructions for which the individual operations are perform consequtively. The advantage of still using these instructions is that your program text will be shorter, allowing better use of the instruction cache and less problems when missing branch predictions and so forth. I am however not aware of any vector library taking advantage of the VFP, you'd have to do a good search and possible write your own if it's not available.
Finally, if you still need more speed, you'll want to use the true SIMD unit in the iPhone processor. However this unit is not a floating point unit, but an integer unit. So, assuming you do want real numbers, you'll be stuck with fixed point, it depends on your application whether you can get away with that. Again I am not aware of any vector library providing fixed point arithmetic using the SIMD unit provided by the iPhone processor, so again you'd need a thorough search and possibly get your hands dirty yourself.
I am converting some Int16s and Int32s to float and then back again.
I'm just using a straight cast, but doing this 44100 times per second (any guesses what its for? :) )
Is a cast efficient? Can it be done any faster?
P.S Compile for thumb is turned off.
There are only two ways to know.
1) Read the code the compiler generates for promoting ints to floats in your case.
2) Measure the performance of the code the compiler generates vs. other options.
To do the former, set the SDK to Device and the Active Architecture to arm, and choose Build > Show Assembly Code. Then read the compiler-generated code.
If you are smarter than a compiler then you can write your own assembly code and use it instead. Odds are you aren't.
If you are doing an operation many, many times, Instruments will do a good job at showing you how many processor samples it's taking. But Jim's point is valid, and you shouldn't dismiss it as unhelpful: in an operation involving math on floating-point numbers, compiler type promotion is the least of your worries. Chips are built to do that in two or three cycles, and compilers usually manage to make that happen. But the effects processing you're doing will probably take thousands of cycles. The promotion will be lost in the noise.
Is a cast efficient? In your case, I'd guess it's efficient enough.
Can it be done faster? Maybe...but would it be worth the effort? Have you benchmarked it and discovered a performance problem due to the cast operations?
If you're doing anything mathematically nontrivial with the floating point sample data,
I'd be really surprised if the casts turned out to be a significant bottleneck!
I always thought it's double, until I accidently hit floo+ESC and it told me there is a floorl(<#long double #>) function. So long double is the solution to all big inaccuracy problems? ;-)
Or is there even something more precise than that?
One thing to be aware of is that long double simply acts as double on the iPhone hardware. You don't get any additional precision from the larger type. It will give you more precision in the Simulator, because you're running on a Mac there, so that can confuse you.
As is noted here (and by other commenters), NSDecimal or NSDecimalNumber is the way to go for precision (up to 34 digits), and calculations performed using it are done with true decimal math, not binary floating point. This avoids many of the errors that you see with normal IEEE 754 math.
I think long double is the limit, but it really depends what you want to do. Have you actually been running into inaccuracy problems?
For even more precision look at the NSDecimalNumber class. As the other comment says - have you found any inaccuracy problems. Also more accuracy will be slower.
Adding more precision is one approach to solving the problem, but the real problem sometimes (usually?) lies in the way you are performing the computation. In that case, I proscribe a healthy dose of RTFM. Any primer on FP arithmetic will cover why certain forms of equations are disastrous and how to avoid the gaping maw of oblivion.