1 |
Does this also apply to ppc architecture? There must be more to |
2 |
consider for ppc, ie. more registers than x86, etc. |
3 |
|
4 |
On Thu, 22 Jul 2004 01:44:36 -0400, Colin Kingsley <ckingsley@×××××.com> wrote: |
5 |
> true, you could, but it would be much neater to use -O3 and disable |
6 |
> stuff using -fno-whatever. Also, this would have the benefit of |
7 |
> remaining usefull even if a new version of gcc had a diferent set of |
8 |
> optimisations in -O3. |
9 |
> |
10 |
> but thats just my oppinion:) |
11 |
> |
12 |
> |
13 |
> |
14 |
> |
15 |
> On Wed, 21 Jul 2004 21:16:43 -0400, Douglas Breault Jr. |
16 |
> <genkreton@×××××××.net> wrote: |
17 |
> > You could just enable -O2 and the following: -frename-registers and -fweb. -O3 is simply -O2 plus those 3 options. |
18 |
> > |
19 |
> > |
20 |
> > |
21 |
> > On Wed, 21 Jul 2004 20:50:01 -0400 |
22 |
> > Adam Petaccia <adam@×××××××××.com> wrote: |
23 |
> > |
24 |
> > > With gcc, is there a way to enable all -O3 options but function |
25 |
> > > inlines? Would -fno-inline work or something like that? |
26 |
> > > |
27 |
> > > Mario Domenech Goulart wrote: |
28 |
> > > |
29 |
> > > >Hello, |
30 |
> > > > |
31 |
> > > >There's an interesting discussion in the OpenBSD mailing |
32 |
> > > >list about the use of inline. |
33 |
> > > > |
34 |
> > > >Here's the beginning of the thread about this topic: |
35 |
> > > > |
36 |
> > > >,----[ http://www.sigmasoft.com/cgi-bin/wilma_hiliter/openbsd-tech/200407/msg00175.html ] |
37 |
> > > >| inline considered harmful. |
38 |
> > > >| |
39 |
> > > >| * To: tech@×××××××.org |
40 |
> > > >| * Subject: inline considered harmful. |
41 |
> > > >| * From: Artur Grabowski <art@××××××××.org> |
42 |
> > > >| * Date: 21 Jul 2004 03:54:46 +0200 |
43 |
> > > >| * User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
44 |
> > > >| |
45 |
> > > >| Today we did a bunch of removal of inline functions in the kernel. |
46 |
> > > >| It all started to make floppies fit, but now it's a quest. |
47 |
> > > >| |
48 |
> > > >| If you think that I'm crazy doing this because it might hurt your |
49 |
> > > >| precious performance, go back to your vax and leave the performance |
50 |
> > > >| tuning to people who have a cache. |
51 |
> > > >| |
52 |
> > > >| Every single inline we removed today (and there are more in the |
53 |
> > > >| pipeline and even more waiting to be fixed) shrunk the code and MADE |
54 |
> > > >| IT FASTER. Yes, modern cpus have something called "cache". The cache |
55 |
> > > >| prefers the code to be smaller, rather than free from function calls. |
56 |
> > > >| Yes, some cpus have expensive function call overhead. Don't use them. |
57 |
> > > >| i386 has quite expensive function calls, on the other hand it doesn't |
58 |
> > > >| have any relevant amount of registers either. So a function call |
59 |
> > > >| instead of the same function inlined can potentially make the job |
60 |
> > > >| easier for the register allocator in the compiler which could eat the |
61 |
> > > >| overhead. At the same time the instruction cache can run the same code |
62 |
> > > >| in the same place, instead of loading it from main memory 4711 times. |
63 |
> > > >| And guess what? The stack on i386 is in the cache too, so the function |
64 |
> > > >| call overhead isn't that bad anyway. |
65 |
> > > >| |
66 |
> > > >| I'm tired of seeing code where everything is made inline just because |
67 |
> > > >| someone acted on a meme that hasn't been true for over a decade. Bloat, |
68 |
> > > >| bloat and more bloat. Since people can't use inline correctly (it does |
69 |
> > > >| have valid and correct uses), from now on inline in the OpenBSD kernel |
70 |
> > > >| is considered to be a bug until proven otherwise. So. Next time I see |
71 |
> > > >| code that adds to the bloat with inlines, I expect performance figures |
72 |
> > > >| and kernel size comparisons that show that the inline actually |
73 |
> > > >| contributes anything. Otherwise the code does not go in. |
74 |
> > > >| |
75 |
> > > >| There's still a lot of work to be done in the kernel (yes, macros can |
76 |
> > > >| be evil too, just see nfs), so send diffs. And there's a whole |
77 |
> > > >| unexplored field in userland too. |
78 |
> > > >| |
79 |
> > > >| //art |
80 |
> > > >`---- |
81 |
> > > > |
82 |
> > > >Mario |
83 |
> > > > |
84 |
> > > > |
85 |
> > > >-- |
86 |
> > > >gentoo-performance@g.o mailing list |
87 |
> > > > |
88 |
> > > > |
89 |
> > > > |
90 |
> > > > |
91 |
> > > |
92 |
> > > -- |
93 |
> > > gentoo-performance@g.o mailing list |
94 |
> > > |
95 |
> > |
96 |
> > |
97 |
> > |
98 |
> |
99 |
|
100 |
-- |
101 |
gentoo-performance@g.o mailing list |