Floating point performance

Hi, I'm trying to investigate floating point performance on an iPhone device vs. using fixed point math. Does the iPhone have a FPU? Are there any papers in the developer iPhone reference library that talk about this subject ( I did a search but nothing seemed to come up ). Anybody have any thoughts / comments about this?
Any help would be great! Thanks!

Unfortunately the ARM documentation is lousy and it is hard to estimate what would happen vis-a-vis the thumb compile switch. I suspect apple tested it thoroughly and determined a majority of apps would benefit with it ON. But hey go ahead and try it and please let us know.
the FPU in the arm is reasonably powerful, but somehow I doubt that the GCC compiler will generate any code worth a snot in terms of taking advantage of it, likely you will have to dip into assembler to use it to advantage.
I am a long time Microsoft Intel assembler fan - gotta love one of the best macro assemblers even written by anybody. You can get a 4 times increase in your app if you hand code it, but most of us are limited by the operating system and memory vs. pure CPU. I suspect gamers will find the iPhone frustrating as we are all doing Objective-C which is a super high overhead language, although not as bad as Java, which is a language best suited for snails.

Similar Messages

Niagara II Floating Point Operations

Niagara II has much improved floating point performance over Niagara I, however I'm wondering if performance of floating point intensive threads could be improved, by amalgamating the floating point processing from each core to a dedicated unit that can execute in parallel, the instructions from all threads, such that if a single core, experiences a floating point intensive load, the floating point load aggregate over the entire processor is better optimized?

pfirmst wrote:
Niagara II has much improved floating point performance over Niagara I, however I'm wondering if performance of floating point intensive threads could be improved, by amalgamating the floating point processing from each core to a dedicated unit that can execute in parallel, the instructions from all threads, such that if a single core, experiences a floating point intensive load, the floating point load aggregate over the entire processor is better optimized?I'm not a hardware designer, but I think there are two problems with this approach.
a. There would probably need to be extra interconnect and arbitration to get from the issue pipeline to the shared floating-point units and back again with the result. This would tend to add latency to the floating-point instruction execution and would probably be bad for performance. For example, the floating-point latency on T1 is about 26 cycles and on T2 it's about 6 cycles.
b. In order to get more floating-point performance from a single thread, the issue logic would also need to be changed to be able to issue more floating-point instructions in a single cycle (i.e. superscalar issue). This would be good for single thread performance, but would require more complexity and space, and may impact the number of cores/threads that can fit on a single chip. The correlary is that since each T2 core can only issue two floating-point instructions per cycle (one from each of two threads), each core could make use of at most two floating-point units.
On CMT chips, sharing is good, because it leads to higher efficiency and utilization,
but too much sharing can also hurt performance. There needs to be balance in the design.
Peter.

128-bit floating point numbers on new AMD quad-core Barcelona?

There's quite a lot of buzz over at Slashdot about the new AMD quad core chips, announced yesterday:
http://hardware.slashdot.org/article.pl?sid=07/02/10/0554208
Much of the excitement is over the "new vector math unit referred to as SSE128", which is integrated into each [?!?] core; Tom Yager, of Infoworld, talks about it here:
Quad-core Opteron? Nope. Barcelona is the completely redesigned x86, and it’s brilliant
Now here's my question - does anyone know what the inputs and the outputs of this coprocessor look like? Can it perform arithmetic [or, God forbid, trigonometric] operations [in hardware] on 128-bit quad precision floats? And, if so, will LabVIEW be adding support for it? [Compare here versus here.]
I found a little bit of marketing-speak blather at AMD about "SSE 128" in this old PDF Powerpoint-ish presentation, from June of 2006:
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/PhilHesterAMDAnalystDayV2.pdf
WARNING: PDF DOCUMENT
Page 13: "Dual 128-bit SSE dataflow, Dual 128-bit loads per cycle"
Page 14: "128-bit SSE and 128-bit Loads, 128b FADD, 128 bit FMUL, 128b SSE, 128b SSE"
etc etc etc
While it's largely just gibberish to me, "FADD" looks like what might be a "floating point adder", and "FMUL" could be a "floating point multiplier", and God forbid that the two "SSE" units might be capable of computing some 128-bit cosines. But I don't know whether that old paper is even applicable to the chip that was released yesterday, and I'm just guessing as to what these things might mean anyway.
Other than that, though, AMD's main website is strangely quiet about the Barcelona announcement. [Memo to AMD marketing - if you've just released the greatest thing since sliced bread, then you need to publicize the fact that you've just released the greatest thing since sliced bread...]

I posted a query over at the AMD forums, and here's what I was told.
I had hoped that e.g. "128b FADD" would be able to do something like the following:
/* "quad" is a hypothetical 128-bit quad precision */
/* floating point number, similar to "long double" */
/* in recent versions of C++:                       */
quad x, y, z;
x = 1.000000000000000000000000000001;
y = 1.000000000000000000000000000001;
/* the hope was that "128b FADD" could perform the */
/* following 128-bit addition in hardware:          */
z = x + y;
However, the answer I'm getting is that "128b FADD" is just a set of two 64-bit adders running in parallel, which are capable of adding two vectors of 64-bit doubles more or less simultaneously:
double x[2], y[2], z[2];
x[0] = 1.000000000000000000000000000001;
y[0] = 1.000000000000000000000000000001;
x[1] = 2.000000000000000000000000000222;
y[1] = 2.000000000000000000000000000222;
/* Apparently the coordinates of the two "vectors" x & y       */
/* can be sent to "128b FADD" in parallel, and the following   */
/* two summations can be computed more or less simultaneously: */
z[0] = x[0] + y[0];
z[1] = x[1] + y[1];
Thus e.g. "128b FADD", working in concert with "128b FMUL", will be able to [more or less] halve the amount of time it takes to compute a dot product of vectors whose coordinates are 64-bit doubles.
So this "128-bit" circuitry is great if you're doing lots of linear algebra with 64-bit doubles, but it doesn't appear to offer anything in the way of greater precision for people who are interested in precision-sensitive calculations.
By the way, if you're at all interested in questions of precision sensitivity & round-off error, I'd highly recommend Prof Kahan's page at Cal-Berzerkeley:
http://www.cs.berkeley.edu/~wkahan/
PDF DOCUMENT: How JAVA's Floating-Point Hurts Everyone Everywhere
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
PDF DOCUMENT: Matlab's Loss is Nobody's Gain
http://www.cs.berkeley.edu/~wkahan/MxMulEps.pdf

The BIG failure of the floating point computation

The Big failure of the floating point computation .... Mmmm
You are writing some code .. writing a simple function ... and using type Double for your computation.
You are then expecting to get a result from your function that is at least close to the exact value ...
Are you right ??
Let see this from an example.
In my example, I will approximate the value of pi. To do so, I will inscribe a circle into a polygon, starting with an hexagon, and compute the half perimeter of the polygon. this will give me an approximation for pi.
Then I will in a loop doubling the number of sides of that polygon. Therefore, each iteration will give me a better approximation.
I will perform this twice, using the same algorithm and the same equation ... with the only difference that I will write that equation in two different form
Since I don't want to throw at you equations and algorithm without explanation, here the idea:
(I wrote that with Word to make it easier to read)
====================
Simple enough ...
It is important to understand that the two forms of the equation are mathematically always equal for a given value of "t" ... Since it is in fact the exact same equation written in two different way.
Now let put these two equations in code
Public Class Form1
Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
RichTextBox1.Font = New Font("Consolas", 9)
RichTextBox2.Font = New Font("Consolas", 9)
TextBox1.Font = New Font("Consolas", 12)
TextBox1.TextAlign = HorizontalAlignment.Center
TextBox1.Text = "3.14159265358979323846264338327..."
Dim tt As Double
Dim Pi As Double
'===============================================================
'Using First Form of the equation
'===============================================================
'start with an hexagon
tt = 1 / Math.Sqrt(3)
Pi = 6 * tt
PrintPi(Pi, 0, RichTextBox1)
'Now we will double the number of sides of the polygon 25 times
For n = 1 To 25
tt = (Math.Sqrt((tt ^ 2) + 1) - 1) / tt
Pi = 6 * (2 ^ n) * tt
PrintPi(Pi, n, RichTextBox1)
Next
'===============================================================
'Using Second Form of the equation
'===============================================================
'start with an hexagon
tt = 1 / Math.Sqrt(3)
Pi = 6 * tt
PrintPi(Pi, 0, RichTextBox2)
'Now we will double the number of sides of the polygon 25 times
For n = 1 To 25
tt = tt / (Math.Sqrt((tt ^ 2) + 1) + 1)
Pi = 6 * (2 ^ n) * tt
PrintPi(Pi, n, RichTextBox2)
Next
End Sub
Private Sub PrintPi(t As Double, n As Integer, RTB As RichTextBox)
Dim S As String = t.ToString("#.00000000000000")
RTB.AppendText(S & " " & Format((6 * (2 ^ n)), "#,##0").PadLeft(13) & " sides polygon")
Dim i As Integer = 0
While S(i) = TextBox1.Text(i)
i += 1
End While
Dim CS = RTB.GetFirstCharIndexFromLine(RTB.Lines.Count - 1)
RTB.SelectionStart = CS
RTB.SelectionLength = i
RTB.SelectionColor = Color.Red
RTB.AppendText(vbCrLf)
End Sub
End Class
The results:
The text box contains the real value of PI.
The set of results on the left were obtain with the first form of the equation .. on the right with the second form of the equation
The red digits show the digits that are exact for pi.
On the right, where we used the second form of the equation, we see that the result converge nicely toward Pi as the number of sides of the polygon increases.
But on the left, with the first form of the equation, we see the after just a few iterations, the function stop converging and then start diverging from the expected value.
What is wrong ... did I made an error in the first form of the equation?
Well probably not since this first form of the equation is the one you will find in your math book.
So, what up here ??
The problem is this:
What is happening is that at each iteration when using the first form, I subtract 1 from the radical, This subtraction always gives a result smaller than 1. Since the type double has a fixed number of digits on the left of the decimal
point, at each iteration I am loosing precision caused by rounding.
And after only 25 iterations, I have accumulate such a big rounding error that even the digit on the left of the decimal point is wrong.
When using the second form of the equation, I am adding 1 to the radical, therefore the value grows and I get no lost of precision.
So, what should we learn from this ?
Well, ... we should at least remember that when using floating point to compute a formula, even a simple one, as I show here, we should always check the exactitude of the result. There are some functions that a floating point is unable to evaluate.

I manually (yes, manually) did the computations with calc.exe. It has a higher accuracy. PI after 25 iterations is 3.1415926535897934934541990520762.
This means tt = 0.000000015604459512183037864437694609544 compared to 0.0000000138636291675699 computed by the code.
Armin
Manually ...
You did better than Archimedes.
He only got to the 96 sides polygon and gave up. Than he said that PI was 3.1427

Precision operation (Float point) on FPGA 2011

Dear Experts....
For my application I have to perform demodulation operation on FPGA. I want to store an array of double precision number. When I am trying to perform any double precision number operation I am getting this error "Wire:Type not supported in current target" From forums I came to know that on FPGA in Labview 2011 I cannot have double precision operation. What is alternative?? Please help me with this. Due to this issue my work has been delayed due to this problem..
Thanks... Kindly guide...
Solved!
Go to Solution.

Dear Mathan, thanks for your reply.... I have already gone throught the link you sent, but for my application I have to have array of floating points number. I can not have integer numbers. Here I have attached my vi. I have to mix a signal of 20 Mhz with sin and cos signal to achieve demodulation. So for Sin and Cos values I have to have floating point. Is ther any way to overcome this problem?
Attachments:
fpga.vi ‏30 KB

Dtrace Floating Point gives error on x86

When I try to create a floating point constant in dtrace x86:
BEGIN
printf ("%f", 1.0);
exit (1);
I get the error:
dtrace: failed to compile script special.d: line 3: floating-point constants are not permitted
Am I using the floating point constant incorrectly, or are floating point constants not permitted in the x86 platform.
Thanks,
Chip

Then what is meant at the bottom of page 48 of the
Solaris Dynamic Tracing Guide where it talks about
floating-point constants?
ChipSorry for not making that sufficiently clear. We are reserving that syntax for possible future use, but you cannot specify floating-point constants at present, and you cannot perform floating-point arithmetic in D. The only legal use of floating-point is that you can trace one or more data objects or structures that contain floating-point values and format the results using printf() and the various %f, %g formats.
-Mike

BigDecimal vs floating points...

Hi all,
I know its probably been asked amillion times before but I need to finally fully understand and get my head around the two.
Firstly here are some bits I've been told by different people and read in different places (alot of people seem to think differently which is what confuses me):
- I've read that if you are wanting precision for currency for example that floating point shouldnt be used because of its accuracy down to the fact it cant represent every decimal number.
- The some people have told me that it doesnt matter and theres not much point ,ost the time in BigDecimal all you need to do is correct the floating point with formatting.
- I've asked about this before but people just seem to give me a short answer to it but without actually explaining why or where they get it from, you cant just assume an answer based on nothing...
I'm building some engineering software that has a general accuracy of 3 decmial places (millimeters from meters) and my first thought is that if currency at 2 decimal places requires BigDecimal then I surely require it (I cant afford to be missing off mm for every calculation, theres alot!) but the problem is this has resulted in me building pretty much the whole application with BigDecimal which you can probably imagine brings up thoughts about performance and memory uptake, I do calculations with BigDecimal, store data in BigDecimal and infact the only thing I do in double is the graphical display as the accuracy isnt so important.
My last question is if this is an ok way to build an accurate application it makes me start to wonder why is floating points used more than BigDecimals, surely most numbers are required to be accurate in applications especially of an enterprise scale?
Thanks,
Ken

MarksmanKen wrote:
So your a big user of BigDecimal as well then? Thats good to know someone else thinks in similar ways, I was starting to feel like abit of an idiot for using them so extensively lolNot at all. The idiots are the people who use primitives rather than BigDecimal "because they're faster" even though they've never actually experienced any performance problems. Of course, there are lots of cases where the speed of a primitive is preferable, but on the whole those guys know perfectly well who they are and what they're doing.
My program is very calculation heavy and I've not had any real performance issues yet but I was wondering if the performance gain would be significant enough while keeping the accuracy.Testing will show you the way. Don't let any "we tested this calculation a million times using primitives and the same one using BigDecimal, and it showed a remarkable 3 seconds quicker using primitives" sidetrack you, either. All that matters is that your actual production code is performant enough for your application. Generally speaking, anything involving currency will probably be better using BigDecimal, or, really, a Money class which happens to use BigDecimal under the covers. Quite why enterprise-targeted languages don't have some sort of native Money or Currency class out-of-the-box remains a mystery, to be honest.

Floating-point addition unit

Hello All,
I am very new to NI and I am looking for an example of floating-point addition unit. Basically, I am looking for some example to perform addition of two floating point number (single or double precision). -- just how to create floating-point addition unit using logical gates model (i.e. AND, OR, XOR, etc)
Thank you!
Leo
Message Edited by smuStudent on 12-05-2005 11:51 PM

Most (if not all) of us, when we want to do floating point math just put the Add function onto the block diagram. I would suggest you google for floating point gates or something similar. You can create subVIs that make up the basic functions such as a full adder and then link them together as needed.
Attachments:
Full Adder.JPG ‏9 KB

Question in floating point operation

Hi,
I have question in java floating point operation.
public class test
     public static void main(String args[])
          double d1 = 243.35 ;
          double d2 = 2.3 ;
          System.out.println(d1 * d2) ;
          System.out.println((float)d1 * (float)d2) ;
The result is,
java version "1.4.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06)
Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode)
5.597049999999999E8
5.5970502E8
Though the multiplication does not result irrational number like 1/3, the result of the first statement is not accurate enough. In our project, this multiplication involves with money and we cannot ignore this.
Can anyone suggest why this is happening? Do I need to convert all the numbers to float to avoid this...Or Is it a bug?
~ Sathiya Dhanapal.

The underlying problem is that not all numbers can be represented exactly in a floating point representation. But if you perform all calculations using doubles and then round to two fractional digits at the end you should get a "correct" result UNLESS you have used ill-conditioned formulas introducing other kinds of arithmetic errors.
There's another way around this when it comes to counting money and that's to use integers (long or int). You convert every number to the lowest monetary unit (like a cent or whatever). Every money-amount can now be represented exactly but you still have to be careful because the rounding problem is still there (What do you do with the last cent when you split 100 cents in 3).
In your example the "more correct" you've got from using floats instead of doubles is only an illusion. The result has been implictly rounded becasuse fewer bits have been used. If you round the double result to the same precision as the float result, they're the same.
The important lesson in all this is TO KNOW WHEN TO ROUND.

No floating point?

Im told that j2ME can't perform floating-point! Is that true? Had anyone seen article regarding this? thans!

Hi,
this is defined in JSR for MIDP 1.0 (2.0 supports floats, if I'm not mistaken). You can download JSR 037 at http://www.jcp.org/aboutJava/communityprocess/final/jsr037/index.html.
Peter

32 bit floating point ... SLOW...

Hi,
I ran a little test because i found Motion took too much time exporting with 32 bit floating point.
I made a single layer, animated text in Motion with my Quad ( 2.5 G RAM)
When i exported 32 bit floating point QT Animation in Motion, it was very very slow and the CPU were running at 10 to 15%.
When i export 8 bit floating point, it is much faster but CPU run at about 20%.
BUT
In FCP, when i render 8 bit Motion project and .mov (from 8 bit), or 32 bit Motion projet and .mov (from 32 bit), they all render pretty fast...
8 bit Motion prj 45% CPU
.mov from Motion 8 bit 30% CPU
32 bit Motion prj 45% CPU
.mov from Motion 32 bit 60% CPU
Why that much difference ?
I dont understand why the CPU are running higher with a .mov (QT Animation) that has been created in 32 bit floating point ?
I thought that once it has been created (self contained) it did not matter...
thanks

32 bit floating point refers to how it will be rendered. Has nothing to do with the format itself. You're OK ... just edit.
32-bit floating point allows audio calculations, such as fader levels and effects processing, to be
performed at very high resolution with a minimum of error, which preserves the quality of your digital audio.
Jerry

Is Pr Floating Point Intensive? (Intel AVX)

Before I get this discussion started, I want to stave off the non-Adobe responses that will consist of things like: "This is a user forum for help and Adobe devs rarely post." Or "Submit a feature request here" ... I've already submitted the feature request, and I know that some Adobe devs do frequent this forum. So... save it. :-) Follow the discussion if you're interested in learning, otherwise, move along.
Question: is Pr floating point (FP) intensive? How about AME? The reason I ask is that Intel chips that are Sandy Bridge and newer have something called AVX instruction sets available, that can and do significantly increase FP performance. A small write-up is here, and there are other bits of info availabe on places like Wikipedia.
I know there are other NLEs that do make use of AVX, and benefit from it quite a bit. Is it something worth pushing Adobe for? Or is the application more integer based, where AVX won't really help much at all?
Discuss.

Very interesting question. I look forward to hearing what the Adobe folks have to say. I don't know if any of them will be around today, and I know Mark has a cold, but my guess is that you will hear something relatively soon. Thanks for bringing this up.
Edit: The link in the initial post didn't work but I think this might be what he was pointing to:
http://software.intel.com/en-us/intel-isa-extensions#pid-16007-1495
By the way, Jason, don't be surprised if this gets migrated to the hardware forum since it is specific to certain hardware.

Can the N8 handle FPU (floating point unit) apps?

I've come across a few apps that have an FPU version which, for devices which can handle it, offers greater performance over standard (non-FPU) version. I've seen mentioned that the E73, N95 8GB and 5800XM can handle FPU, but can't find anything said about whether the N8 can handle FPU or not. Any ideas? I can't find any instrument/chromatic tuners that have been developed specifically for S^3, so am looking at S60 versions, such as "Chromatic Tuner v0.25".

I'm sorry, but neither of you have actually answered my question. I know most S60v5 apps will work with S^3...that's not what I asked! I'm asking about apps that have been writen for devices that can manage FPU (floating point unit operations)
The app you linked to in the ovi store is a different app - I'm being quite specific about the app I'm asking about. The following link is for it's download location, and contains description of the non-FPU vs FPU versions.
http://hqh.unlink.org/s60/index.php?p=download
Anyone able to help?

SQL Loader and Floating Point Numbers

Hi
I have a problem loading floating point numbers using SQL Loader. If the number has more than 8 significant digits SQL Loader rounds the number i.e. 1100000.69 becomes 1100000.7. The CTL file looks as follows
LOAD DATA
INFILE '../data/test.csv' "str X'0A'"
BADFILE '../bad/test.bad'
APPEND
INTO TABLE test
FIELDS TERMINATED BY "," OPTIONALLY ENCLOSED BY '"'
Amount CHAR
and the data file as follows
"100.15 "
"100100.57 "
"1100000.69 "
"-2000000.33"
"-100000.43 "
the table defined as follows
CREATE TABLE test
Amount number(15,4)
) TABLESPACE NNUT050M1;
after loading a select returns the following
100.15
100100.57
1100000.7
-2000000
-100000.4
Thanks in advance
Russell

Actually if you format the field to display as (say) 999,999,999.99, you will see the correct numbers loaded via SQL Loader.
null

R6002 - floating point not loaded / C++ Runtime Error

Good Evening,
I have been having this problem with Adobe Bridge for a while and tonight sat down to try and solve it. Fresh version of Windows XP reinstalled all programs and this is still happening! Any Ideas?
This error only occurs with Adobe Bridge, I can load Photoshop etc.. all fine.
Error:
"Runtime Error!
Program: C:\ProgramFiles\Adobe\Adobe Bridge CS3\Bridge.exe
R6002
- floating point not loaded"
Here is a print screen..
http://images.unbrokenphotography.co.uk/BridgeError.jpg

Is there are answer to this problem? This error message is appearing on an entire lab full of computers. We are running Web Premium CS4
I have tried to reset the Bridge Preferences:
Hold down the Ctrl key and click on Bridge icon to start.
Should get a reset window with 3 options.
Choose the first option
I still get "Runtime Error! Program: C:\Prgram Files\Adobe\Adobe Bridge CS4\Bridge.exe R6002 -floating point support not loaded"

Floating point performance

Similar Messages

Maybe you are looking for