| 1 |
Simon Stelling wrote: |
| 2 |
> Luca Barbato wrote: |
| 3 |
>> Alternatives: |
| 4 |
>> |
| 5 |
>> - as PPC we provide a default cflags & use tuned per certain cpu |
| 6 |
>> families using profiles, amd64 could provide a nocona profile that bans |
| 7 |
>> 3dnow* useflags. |
| 8 |
> |
| 9 |
> Not really. There are athlon64s and opterons with and without sse3 support. The |
| 10 |
> users who have an sse3-enabled CPU mostly stick -msse3 into their CFLAGS, as |
| 11 |
> they expect the flag to do what it says. The problem is even worse for x86: |
| 12 |
> You'd have to provide own profiles for: |
| 13 |
> |
| 14 |
> * i386 |
| 15 |
|
| 16 |
there is already isn't it? |
| 17 |
|
| 18 |
> * pentium-mmx,k6 |
| 19 |
|
| 20 |
people know what they are |
| 21 |
|
| 22 |
> * athlon xp,pentium3 |
| 23 |
|
| 24 |
ditto |
| 25 |
|
| 26 |
> * pentium4,athlon64/opteron (starting from 'Paris' core),celeron (starting from |
| 27 |
> 'willamette' core) |
| 28 |
|
| 29 |
those are relatively new |
| 30 |
|
| 31 |
> * celeron D/M, core solo/duo,core 2 duo, core 2 extreme,athlon64 (starting from |
| 32 |
> venice stepping E3 or san diego stepping E4), athlon64 X2, athlon64 FX (starting |
| 33 |
> from san diego stepping E4), sempron (starting from palermo stepping E3), |
| 34 |
|
| 35 |
Don't complain with me about marketing |
| 36 |
|
| 37 |
> pentium4 (starting from 'prescott') |
| 38 |
|
| 39 |
and so on... |
| 40 |
|
| 41 |
> etc... |
| 42 |
> |
| 43 |
> and now you want to let your pentium4(paris)-server, which is running 24/7, |
| 44 |
> compile a binpkg for your pentium4(prescott), using SSE3 |
| 45 |
> |
| 46 |
> have fun 8-) |
| 47 |
|
| 48 |
I take the base profile and turn sse3 useflag on, tune the cflags |
| 49 |
properly and then I issue the emerge -B foo as usual |
| 50 |
|
| 51 |
specific profiles are good just for disoriented users that need |
| 52 |
something working quickly, people knowing their system and what they |
| 53 |
want would be much happy with the useflags. |
| 54 |
|
| 55 |
Having better descriptions for flags could be of help too. |
| 56 |
|
| 57 |
Keep in mind that discover what your cpu or another cpu could take as |
| 58 |
cflags or simdflags requires the same (look at the arch faq about it, |
| 59 |
parse the cpuinfo, google a bit) |
| 60 |
|
| 61 |
> I'm not sure whether I understand this correctly. If we use flameeyes logic |
| 62 |
> anyway, why keeping the use flags? |
| 63 |
> |
| 64 |
|
| 65 |
Because you may not want all the flags the gcc guess would set for a |
| 66 |
reason or another (and there are many, including having gcc-X.ugly doing |
| 67 |
the worst with -msimd_du_jour but having some nicely tuned routines for |
| 68 |
that simd triggered by --enable-simd_du_jour) |
| 69 |
|
| 70 |
lu |
| 71 |
|
| 72 |
-- |
| 73 |
|
| 74 |
Luca Barbato |
| 75 |
|
| 76 |
Gentoo/linux Gentoo/PPC |
| 77 |
http://dev.gentoo.org/~lu_zero |
| 78 |
|
| 79 |
-- |
| 80 |
gentoo-dev@g.o mailing list |
Archives