1 |
On 25/02/2013 23:21, Rich Freeman wrote: |
2 |
> On Mon, Feb 25, 2013 at 5:11 PM, Diego Elio Pettenò |
3 |
> <flameeyes@×××××××××.eu> wrote: |
4 |
>> Of course dealing with flags _per functions_ is not possible, as flags |
5 |
>> apply at the very least to a translation unit... |
6 |
> |
7 |
> A translation unit can contain a single function, or a bunch of |
8 |
> functions that you want to apply the flag to. |
9 |
|
10 |
Which is a different story altogether. By the way just so you know, as |
11 |
you seem to talk a lot about things you understand only partially, if |
12 |
you want performance so badly you want to use -ffast-math, you're not |
13 |
going to split translation units so much. |
14 |
|
15 |
> Maybe it wasn't a great example - I wasn't the one who first brought |
16 |
> it up in the thread. |
17 |
|
18 |
No, an example of _how building a whole package with -ffast-math_ was |
19 |
brought up, and you turned it into "something that it should apply to" |
20 |
(which is false, and stupid to say). |
21 |
|
22 |
Note also how you can't defend your original statement, so I maintain my |
23 |
point: you're speaking of things you don't know. |
24 |
|
25 |
> If you add a randomly distributed 1% error to hundreds of small |
26 |
> calculations you end up with a 1% error in the result, roughly |
27 |
> speaking. The exact impact can in fact be calculated using |
28 |
> propagation of error. Of course, if -ffast-math introduces a |
29 |
> non-uniform bias and the calculations are sensitive to that then that |
30 |
> could carry things further off. |
31 |
|
32 |
On the distribution of errors introduced by -ffast-math I have no data. |
33 |
On the other hand, I know that if you start changing 1% of the |
34 |
calculation in a single piece of software, what you end up with is |
35 |
rarely "within 1%" of the intended result. |
36 |
|
37 |
Software does not work like a single equation. Ever heard of fuzzing? |
38 |
You know why it works? Because a single different bit can have cascade |
39 |
effects. |
40 |
|
41 |
> 2. If individual packages DO carefully use -ffast-math and that |
42 |
> breaks, it might be a valid bug, and may or may not be a blocker |
43 |
> depending on real-world impact. That doesn't mean users sticking it |
44 |
> in their CFLAGS - it means the ebuild or upstream build system |
45 |
> carefully applied the flag appropriately. |
46 |
|
47 |
This is arguable — I'm not going to dig down how many packages I found |
48 |
with -O3 (or even worse -O9), just for the sake of being "faster" and |
49 |
sometimes going slower than if built with -O2 (loops unrolling and |
50 |
inlining are not always a good idea). |
51 |
|
52 |
But, as you correctly say this time, right now we only have one _valid_ |
53 |
report: mednafen — which I'm surprised uses -ffast-math (given it's an |
54 |
emulator). So the question is whether that's a showstopper for them or |
55 |
not — and how serious is the performance difference between the two. |
56 |
|
57 |
Anything else, is noise. |
58 |
|
59 |
-- |
60 |
Diego Elio Pettenò — Flameeyes |
61 |
flameeyes@×××××××××.eu — http://blog.flameeyes.eu/ |