1 |
On Nov 18, 2011 11:35 PM, "Pandu Poluan" <pandu@××××××.info> wrote: |
2 |
> |
3 |
> |
4 |
> On Nov 18, 2011 10:41 PM, "Fredric Johansson" <fredric.miscmail@×××××.com> |
5 |
wrote: |
6 |
> > |
7 |
> > On Wed, Nov 16, 2011 at 2:58 PM, Pandu Poluan <pandu@××××××.info> wrote: |
8 |
> > > |
9 |
|
10 |
-----snip |
11 |
|
12 |
> > > |
13 |
> > > I've been using USE "graphite" since gcc-4.5.3-r1 appeared. Upstream |
14 |
says |
15 |
> > > that graphite is stable, feature-complete, and production-ready since |
16 |
4.5.3. |
17 |
> > > |
18 |
> > > To fully taste the effect of graphite, I even went the torturous |
19 |
route of |
20 |
> > > emerging gcc + libtool + binutils (in that order) twice, followed by a |
21 |
> > > wholesale-rebuild of everything (emerge --emptytree), then tarballed |
22 |
the |
23 |
> > > result to my own "stage3.1" tarball to spare me the *huge* amount of |
24 |
time |
25 |
> > > required. |
26 |
> > > |
27 |
> > > I've deployed 3 systems with USE "graphite", and they *felt* snappier. |
28 |
> > > emerge's *felt* slower, though. (no objective tests, I know). |
29 |
> > > |
30 |
> > > I use Gentoo as a gatewall, and there I did a wholesale-rebuild one |
31 |
more |
32 |
> > > time, this time specifying CFLAGS "-march=native"... and I just |
33 |
couldn't be |
34 |
> > > happier with the resulting performance :-) |
35 |
> > > |
36 |
> > > Rgds, |
37 |
> > > |
38 |
> > |
39 |
> > I might be wrong but don't you need to have the gcc's options for |
40 |
> > graphite enabled to actually make use of the graphite framework? (You |
41 |
> > might be using them but you haven't mentioned it.) |
42 |
> > |
43 |
> |
44 |
> Yes. There are some CFLAGS incantations to add to fully utilize graphite, |
45 |
else the optimizations would be marginal at best. |
46 |
> |
47 |
> That said, turning on the CFLAGS flags was a *very* involved process: |
48 |
> |
49 |
> 1. By default, "graphite" is disabled. So you can't directly turn on the |
50 |
graphite-related CFLAGS option. You must first enable USE "graphite" and |
51 |
re-emerge gcc (or upgrade, if you're still using <gcc-4.5.3). This will |
52 |
pull in ppl and cloog-ppl. |
53 |
> |
54 |
> 2. I don't know if libtool and binutils need to be remerged, but I did it |
55 |
just to be safe. |
56 |
> |
57 |
> 3. Now that gcc has been compiled with graphite support, you can turn on |
58 |
the CFLAGS flags necessary to fully utilize graphite. WARNING: some flags |
59 |
recommended by upstream *might* make some programs run worse; be careful. |
60 |
(I won't have access to my servers so I can't tell you which ones exactly). |
61 |
> |
62 |
> 4. At this point, I want gcc itself to be optimized. So, I remerged gcc |
63 |
and libtool and binutils (in that order). Might be unnecessary, but I'm |
64 |
anal like that :-) |
65 |
> |
66 |
> 5. Finally, universe-remerge (emerge --emptytree). |
67 |
> |
68 |
> As you can see, steps 4 & 5 are optional. And they indeed took a |
69 |
*humongous* time to complete. But I am quite satisfied with the result. |
70 |
Everything felt snappier compared to older boxen that haven't been |
71 |
graphite-ed :-) |
72 |
> |
73 |
> Of course, YMMV. |
74 |
> |
75 |
|
76 |
Okay, found a forum thread discussing graphite and the proper CFLAGS: |
77 |
|
78 |
http://forums.gentoo.org/viewtopic-t-850087.html |
79 |
|
80 |
IIRC my CFLAGS looks very similar to the once @genstorm uses (scroll down |
81 |
to approximately 80% down the page). |
82 |
|
83 |
Now I never experienced *any* emerge failure, provided that I don't go |
84 |
higher than MAKEOPTS="-j3". Set it higher and several packages failed |
85 |
during compile. I don't know whose fault is that, but you've been warned |
86 |
;-) |
87 |
|
88 |
Rgds, |