| 1 |
On Wed, Nov 16, 2011 at 2:58 PM, Pandu Poluan <pandu@××××××.info> wrote: |
| 2 |
> |
| 3 |
> On Nov 16, 2011 2:26 PM, "Michael Mol" <mikemol@×××××.com> wrote: |
| 4 |
>> |
| 5 |
>> On Wed, Nov 16, 2011 at 2:11 AM, Stéphane Guedon <stephane@××××××××××.eu> |
| 6 |
>> wrote: |
| 7 |
>> > On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote: |
| 8 |
>> >> And if you're adventurous, add USE "graphite", reemerge gcc, and |
| 9 |
>> >> reemerge |
| 10 |
>> >> world :) |
| 11 |
>> > |
| 12 |
>> > what does "graphite" add ? |
| 13 |
>> |
| 14 |
>> Thanks for reminding me; I meant to look it up when I got home. |
| 15 |
>> |
| 16 |
>> shortcircuit:1@serenity~ |
| 17 |
>> Wed Nov 16 02:16 AM |
| 18 |
>> !501 #1 j0 ?0 $ euse -i graphite |
| 19 |
>> global use flags (searching: graphite) |
| 20 |
>> ************************************************************ |
| 21 |
>> no matching entries found |
| 22 |
>> |
| 23 |
>> local use flags (searching: graphite) |
| 24 |
>> ************************************************************ |
| 25 |
>> |
| 26 |
>> [snip] |
| 27 |
>> |
| 28 |
>> [- ] graphite |
| 29 |
>> sys-devel/gcc: Add support for the framework for loop optimizations |
| 30 |
>> based on a polyhedral intermediate representation |
| 31 |
>> |
| 32 |
>> So, a new, experimental optimization model and framework inside your |
| 33 |
>> compiler. If it's specifically for optimizing on loops, I'll venture a |
| 34 |
>> guess it's going to be mostly effective for graphics libraries and |
| 35 |
>> apps. I've got some slightly riskier educated guesses on how it works |
| 36 |
>> and what some numeric side effects and consequences might be, but they |
| 37 |
>> scare me, so I think I'll leave it to someone who actually knows more |
| 38 |
>> about it... |
| 39 |
>> |
| 40 |
> |
| 41 |
> I've been using USE "graphite" since gcc-4.5.3-r1 appeared. Upstream says |
| 42 |
> that graphite is stable, feature-complete, and production-ready since 4.5.3. |
| 43 |
> |
| 44 |
> To fully taste the effect of graphite, I even went the torturous route of |
| 45 |
> emerging gcc + libtool + binutils (in that order) twice, followed by a |
| 46 |
> wholesale-rebuild of everything (emerge --emptytree), then tarballed the |
| 47 |
> result to my own "stage3.1" tarball to spare me the *huge* amount of time |
| 48 |
> required. |
| 49 |
> |
| 50 |
> I've deployed 3 systems with USE "graphite", and they *felt* snappier. |
| 51 |
> emerge's *felt* slower, though. (no objective tests, I know). |
| 52 |
> |
| 53 |
> I use Gentoo as a gatewall, and there I did a wholesale-rebuild one more |
| 54 |
> time, this time specifying CFLAGS "-march=native"... and I just couldn't be |
| 55 |
> happier with the resulting performance :-) |
| 56 |
> |
| 57 |
> Rgds, |
| 58 |
> |
| 59 |
|
| 60 |
I might be wrong but don't you need to have the gcc's options for |
| 61 |
graphite enabled to actually make use of the graphite framework? (You |
| 62 |
might be using them but you haven't mentioned it.) |
| 63 |
|
| 64 |
//Fredric |
| 65 |
|
| 66 |
//Fredric |
Archives