Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
CFLAGS for various Athlons?
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
dannysauer
n00b
n00b


Joined: 23 Sep 2004
Posts: 60
Location: Lincoln, IL

PostPosted: Wed Oct 05, 2005 6:26 pm    Post subject: CFLAGS for various Athlons? Reply with quote

I have a few machines that are running either Athlon MPs or Athlon XPs, and it's getting irritating building separate binaries for each one. I'd like to build one binary for all of those machines - what's the most agressive -march= argument I can use that'll work across both of those? Alternatively, where are those friggin' things documented so I can look this up myself? :)

Thanks.
Back to top
View user's profile Send private message
Mattwolf7
n00b
n00b


Joined: 14 Mar 2004
Posts: 73

PostPosted: Wed Oct 05, 2005 6:34 pm    Post subject: Reply with quote

Aren't MPs just XPs that allow dual processor setups?

Post your /proc/cpuinfo

here is mine it is an AMD Athlon XP 2500+

Code:
matt@karma ~ $ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 10
model name      : AMD Athlon(tm)
stepping        : 0
cpu MHz         : 1102.519
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips        : 2170.88


by the way it is underclocked right now cause i was having heat issues
Back to top
View user's profile Send private message
slycordinator
Advocate
Advocate


Joined: 31 Jan 2004
Posts: 3065
Location: Korea

PostPosted: Wed Oct 05, 2005 6:37 pm    Post subject: Reply with quote

Both are i686 so you could to "mcpu=i686" I believe.
Back to top
View user's profile Send private message
dannysauer
n00b
n00b


Joined: 23 Sep 2004
Posts: 60
Location: Lincoln, IL

PostPosted: Wed Oct 05, 2005 6:56 pm    Post subject: Re: CFLAGS for various Athlons? Reply with quote

Hooray for Google! :(

http://gcc.gnu.org/ml/gcc/2002-12/msg00235.html
and
http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html

Apparently, both -march=athlon-mp and -march=athlon-xp both imply -mcpu=athlon -m3dnow -msse (where -mtune is the same thing as -mcpu, except that -mcpu is deprecated in gcc 3.4+).

However, I'm still not entirely clear on what to do here. It looks like I can use -mcpu=athlon -m3dnow -msse on both. Great. So I also use -mfpmath=sse. However, the manual says that the code will only be scheduled optimally for the athlon, but there will be no non-386-compatible code generated without a -march switch. So, do I just use -march=athlon, or should I semi-randomly choose between -march=athlon-xp / -march=athlon-mp since they're pretty much the same thing?

It *appears* that merely including -msse and -m3dnow (as well as -mfpmath=sse) in conjunction with -march=athlon should get what I want - maximum processor-specific compile-time tuning for both my Athlon XP and MPs, but I'd be interested in hearing from someone who's not just pulling that out of their butt after 15 minutes of searching and reading. :)
Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


Joined: 23 Jun 2004
Posts: 1556
Location: .se

PostPosted: Wed Oct 05, 2005 6:56 pm    Post subject: Reply with quote

-march=athlon is the best you can use that would work on both. The only thing you would miss on the athlon-xp is sse.

Edit:
-march=athlon includes -mmmx and -m3dnow but not -msse because the athlon-mp doesn't have it.

Edit2: :)
I was wrong, athlon-mp does have sse so you can use -march=athlon-xp for both (which is the same as -march=athlon-mp)
Back to top
View user's profile Send private message
dannysauer
n00b
n00b


Joined: 23 Sep 2004
Posts: 60
Location: Lincoln, IL

PostPosted: Wed Oct 05, 2005 7:04 pm    Post subject: Reply with quote

The mp has that extra "mp" cpuflag, while the other machines are actually Semprons (which I was told are supposed to use -march=athlon-xp, and that makes sense as AMD is marketing their "budget" XPs under the Sempron name without actually changing much beyond the CPU ID). So, marketing-wise, I'm not working with any XPs - and they're both actually mp capable. Here's some cpuinfo goodness though, for what it's worth:

Code:
midnight src # cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 8
model name      : AMD Athlon(TM) MP 2400+
stepping        : 1
cpu MHz         : 2016.854
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips        : 3964.92

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 8
model name      : AMD Athlon(TM) MP 2400+
stepping        : 1
cpu MHz         : 2016.854
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips        : 4022.27


Code:
zipper ~ # cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 8
model name      : AMD Sempron(tm)  2800+
stepping        : 1
cpu MHz         : 1991.240
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse pni syscall mp mmxext 3dnowext 3dnow
bogomips        : 3932.16
Back to top
View user's profile Send private message
dannysauer
n00b
n00b


Joined: 23 Sep 2004
Posts: 60
Location: Lincoln, IL

PostPosted: Wed Oct 05, 2005 7:11 pm    Post subject: Reply with quote

nxsty:

Ok, that agrees with what I found, pretty much. I'll go with
Code:
-march=athlon -msse -m3dnow -mfpmath=sse
(among others) and see how that works. That should be identical to -march=athlon-xp, but when I come back to it in a few momths, I'll know what I did this way. If I use athlon-xp on the mp machines, I'm apt to wonder what I was thinking (and yes, comments in the file to remind myself, those are out of the question!). :)
Back to top
View user's profile Send private message
yngwin
Retired Dev
Retired Dev


Joined: 19 Dec 2002
Posts: 4572
Location: Suzhou, China

PostPosted: Wed Oct 05, 2005 7:44 pm    Post subject: Reply with quote

You could use -march=athlon -mtune=athlon-xp -msse
Don't use -mfpmath=sse that's actually slower on the Athlon-XP (and I guess the MP and Sempron as well), just don't set that flag at all. Other flags that could be helpful are -falign-jumps=16 -falign-loops=16 -falign-functions=64 -mno-push-args -maccumulate-outgoing-args
_________________
"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF
Back to top
View user's profile Send private message
dannysauer
n00b
n00b


Joined: 23 Sep 2004
Posts: 60
Location: Lincoln, IL

PostPosted: Wed Oct 05, 2005 8:25 pm    Post subject: Reply with quote

yngwin wrote:
You could use -march=athlon -mtune=athlon-xp -msse
Don't use -mfpmath=sse that's actually slower on the Athlon-XP (and I guess the MP and Sempron as well), just don't set that flag at all. Other flags that could be helpful are -falign-jumps=16 -falign-loops=16 -falign-functions=64 -mno-push-args -maccumulate-outgoing-args


I normally build with -Os, which disables the alignment optimizations.

maccumulate-outgoing-args implies mno-push-args, and generates larger code size. While both the alignment options and the argument handling options almost always result in slightly faster code, they also increase memory usage which makes it more likely that I'll run beyond the physical memory limit and start swapping. I tend to not go for optimizations that will run me out of memory in exchange for an imperceptible speed increase... :)

Thanks for pointing out the -mfpmath=sse thing, though. Do you have any benchmarks or documentation to back that up? I believe you, but was unable to find anything to either agree or disagree (I'm curious as to why it's slower).
Back to top
View user's profile Send private message
yngwin
Retired Dev
Retired Dev


Joined: 19 Dec 2002
Posts: 4572
Location: Suzhou, China

PostPosted: Thu Oct 06, 2005 6:59 pm    Post subject: Reply with quote

I don't understand why you're so concerned about space and memory, unless you use an old box with very limited harddisk space and limited ram. I use -O2 -finline-functions (the only extra one in -O3 that's worth using on x86, as I understand it).

I don't have any documentation ready, but I do read up on what knowledgeable users, both on this forum and elsewhere, say and recommend, and I follow up on their links, as well as the GCC doumentation. I don't claim to be an expert, but following the advice of experts and reading on the subject whenever I come across it, has led me to use these flags, with good result. I have a stable and speedy system that I am content with.
_________________
"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF
Back to top
View user's profile Send private message
dannysauer
n00b
n00b


Joined: 23 Sep 2004
Posts: 60
Location: Lincoln, IL

PostPosted: Sun Oct 09, 2005 3:46 am    Post subject: Reply with quote

yngwin wrote:
I don't understand why you're so concerned about space and memory, unless you use an old box with very limited harddisk space and limited ram. I use -O2 -finline-functions (the only extra one in -O3 that's worth using on x86, as I understand it).

I don't have any documentation ready, but I do read up on what knowledgeable users, both on this forum and elsewhere, say and recommend, and I follow up on their links, as well as the GCC doumentation. I don't claim to be an expert, but following the advice of experts and reading on the subject whenever I come across it, has led me to use these flags, with good result. I have a stable and speedy system that I am content with.


The size of the executable isn't due to a concern with drive space (the difference is negligable at that level) or really with RAM. I use -Os on my modern SMP systems rather than -O2, because the only difference is that -Os doesn't use the alignment optimizations. Those aligmnet optimizations do things like inserting extra space before function calls, loop jump targets, etc. While that can result in a very small performance increase (basically due to simplified mathematical operations), it also spreads code out. That spreading out of code increases the chance of cache misses. On a uniprocessor system with a modern processer that has lots of on-chip cache, that's not a huge deal. However, on an SMP system with separate chips - and thus separate on-chip caches - the performance hits of cache misses can be pretty sigificant - significant enough to outweigh the minor alignment benefit. Having to fetch stuff from system memory is *way* slower than fetching from processor cache - it's like the difference between swapping and fitting in to physical memory. It's this space concern that's the main reason why it's a bad idea to buld everything with -O3 (well, that and -funroll-loops results in slower code when the number of iterations isn't know in advance, which is the case in lots of loops that I write - and presumably in other coders' stuff).

I guess I'm technically worrying about memory, after all, but I'm really worrying about L1 and L2 cache usage, rather than system memory. And there's not much you can do to increase the size of the on-chip cache, which is typically on the order of 128-512K. My pretty current Athlon MP system, for example, has 1.5GB RAM, but the chips only have 256K of cache. When you're tyring to fit as much code as possible into 256K, it's worthwhile to worry about space. Not to mention that compilation time is slightly improved over -O2, and significantly improved over -O3. Referring to is as optimizing for size is deceptive, though, since people do usually think of system memory and drive space first - forgetting about the cache which is arguably more important. :)

That said, I was able to find more information on the SSE thing which agreed - basically the SSE implementation on the Athlons isn't all that awesome - it's more for compatability. The Athlons do, however, have a kick-ass 387 unit (which is what's used in place of SSE).
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5350
Location: France, Old Europe

PostPosted: Sun Oct 09, 2005 1:34 pm    Post subject: Reply with quote

Quote:
Referring to is as optimizing for size is deceptive, though, since people do usually think of system memory and drive space first - forgetting about the cache which is arguably more important.

refering to it as size optimisation is perfectly accurate. Any erroneous assumptions anyone may make about how and where that is relevant is only self-deception. Hwvr. thanks for emphasising the effect of the code size in relation to the cache, obviously important.
Quote:

That said, I was able to find more information on the SSE thing which agreed - basically the SSE implementation on the Athlons isn't all that awesome - it's more for compatability. The Athlons do, however, have a kick-ass 387 unit (which is what's used in place of SSE).


That's why its best to let the compiler decide rather than forcing the issue with -mfpmath .

See also:
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Optimize-Options.html
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options

Obviously add -pipe to just about any system to speed up the compile time by using pipes.


There is info on AMD's site about processor diffs but I cant find the link. As I recall Semperons have SSE2 that athlon-xp does not. Maybe relevant to what you are trying to achieve.

I also find this useful to get around 2G file limits on ftp progs, although it does create an issue with mod_perl I have seen no other probs.
-D_FILE_OFFSET_BITS=64

Thanks for your resumé, I'd never looked thoroughly into -Os, I did not realise it was so close to the -O2 that I generally use. I may do some tests.


8)
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5350
Location: France, Old Europe

PostPosted: Sun Oct 09, 2005 1:39 pm    Post subject: Reply with quote

@Mattwolf7:

suggest you search for my comments in the gentoo overclocking thread, you're probably running that thing at about half what it is capable!

I find I can knock about 10 C off typical athlon-xp temps just by lapping in the heatsink, and you are a long way from typical.

Sound like you have lousy thermal contact.

HTH 8)
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86
Back to top
View user's profile Send private message
yngwin
Retired Dev
Retired Dev


Joined: 19 Dec 2002
Posts: 4572
Location: Suzhou, China

PostPosted: Sun Oct 09, 2005 3:19 pm    Post subject: Reply with quote

OK, now I understand your reasoning. But as I understood it, those alignment optimizations are fine-tuned for the Athlon XP (don't know about other procesors) to make optimum use of its cache, and are actually promoted by AMD themselves. (If you search or dig through the Cflags Central thread you might find the link.)
_________________
"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF
Back to top
View user's profile Send private message
dannysauer
n00b
n00b


Joined: 23 Sep 2004
Posts: 60
Location: Lincoln, IL

PostPosted: Sun Oct 09, 2005 3:44 pm    Post subject: Reply with quote

yngwin wrote:
OK, now I understand your reasoning. But as I understood it, those alignment optimizations are fine-tuned for the Athlon XP (don't know about other procesors) to make optimum use of its cache, and are actually promoted by AMD themselves. (If you search or dig through the Cflags Central thread you might find the link.)


"Optimum" in this case probably refers to execution speed, not space. The alignment optimizations use padding, and padding wastes space, period. My concern, like I said, is more directed to my SMP systems than the uniprocessor systems. In an SMP system, if the processor looks for code that's not in its cache, in addition to having to fetch the information from the next level up of memory, it *also* has to wait for the other processor to finish whatever it's doing / free up locks, etc. If there are lots of cache misses, then the other processor could *also* be fetching from memory. So, the cache miss is now a little more than twice as expensive than it would be on a uniprocessor system. It's sort of like moving a uniprocesor system to system RAM that's only half as fast. That can pretty quickly negate any gain you get from slightly easier math operations when calculating jump targets.

Of course, that's just a pessimistic generalization - it's plausible that using -O2 won't cause noticable performance differences, and likely that a difference either way won't be felt under typical use. Since I'm generalizing tuning for both SMP and uniproc systems, the odds are in favor of -Os being better for me than -O2. Were I using just uniproc systems (or mostly uni systems), I'd more than likely use -O2, though.
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5350
Location: France, Old Europe

PostPosted: Sun Oct 09, 2005 5:00 pm    Post subject: Reply with quote

Optimum in any domain is always relative to what you are trying to do and once you are down scratching around the sub 1% performance gain you really need to define exactly what use you are targetting your system for.


dannysauer: your reasoning sounds good, how about running a couple of tests? Could be interesting.

8)
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86
Back to top
View user's profile Send private message
Mattwolf7
n00b
n00b


Joined: 14 Mar 2004
Posts: 73

PostPosted: Tue Oct 11, 2005 3:14 am    Post subject: Reply with quote

Thanks Gentree, i underclocked it cause i was having hard locks on it. But I figured out that my graphics card isn't in very tight and the card keeps slipping out and causing the lock.

I was runing my 2500+ at 3200+ by clocking the memory up from 333mhz to 400mhz, so i thought it was something with that so i just kicked it down to 200mhz. I'm just too lazy to reboot and kick it back up 8)

(plus i've had it like this for 2 weeks and haven't really missed the speed all that much, but next reboot i'll fix it [damn linux never needing reboots... :D ])
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5350
Location: France, Old Europe

PostPosted: Tue Oct 11, 2005 7:04 pm    Post subject: Reply with quote

My benchmark for this sort of thing is emerge gftp, (cos it's small).

I was quite amazed at how much difference these options make to the binaries.

Here's with Os then O2:

Code:
bash-3.00#ls -ail /usr/bin/gftp*
1722399 -rwxr-xr-x  1 root root    333 Oct 11 20:40 /usr/bin/gftp
1722397 -rwxr-xr-x  1 root root 243472 Oct 11 20:40 /usr/bin/gftp-gtk
1722388 -rwxr-xr-x  1 root root 149316 Oct 11 20:40 /usr/bin/gftp-text
bash-3.00#ls -ail /usr/bin/gftp*
1722385 -rwxr-xr-x  1 root root    333 Oct 11 20:45 /usr/bin/gftp
1722381 -rwxr-xr-x  1 root root 309040 Oct 11 20:45 /usr/bin/gftp-gtk
1722372 -rwxr-xr-x  1 root root 186180 Oct 11 20:45 /usr/bin/gftp-text


the Os compile took almost 52s against 50.1 with Os. ie -2%; small but nice.

Thanks for getting me interested in this , if files typically coming out 20% smaller I'll probably rebuild this machine on -Os

I'm just doing xorg to see if I can see an speed up as well.
8)
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86
Back to top
View user's profile Send private message
mr666white
n00b
n00b


Joined: 24 Aug 2004
Posts: 52

PostPosted: Wed Oct 12, 2005 12:24 pm    Post subject: Reply with quote

Does anyone know where the Socket 754 Semprons fit into the scheme of things, They show up as as an unknown Hammer processor in /proc/cpuinfo, and I am led to believe they are essentially an athalon 64 with less cache and the 64 bit extentions disabled. I can't post my cpuinfo at the moment as the machiene is currently out on loan, but I can get it if this would help.

Currently I'm treating it as an Athalon XP.
_________________
www.technomancer.me.uk
Back to top
View user's profile Send private message
dannysauer
n00b
n00b


Joined: 23 Sep 2004
Posts: 60
Location: Lincoln, IL

PostPosted: Wed Oct 12, 2005 12:45 pm    Post subject: Reply with quote

mr666white wrote:
Does anyone know where the Socket 754 Semprons fit into the scheme of things, They show up as as an unknown Hammer processor in /proc/cpuinfo, and I am led to believe they are essentially an athalon 64 with less cache and the 64 bit extentions disabled. I can't post my cpuinfo at the moment as the machiene is currently out on loan, but I can get it if this would help.

Currently I'm treating it as an Athalon XP.


It's a K8/Athlon64 with a smaller cache and 64-bit addressing disabled. I'd treat it like an Athlon XP with sse2 (so add -msse2) from the compiler's point of view, though. :)
Back to top
View user's profile Send private message
dannysauer
n00b
n00b


Joined: 23 Sep 2004
Posts: 60
Location: Lincoln, IL

PostPosted: Wed Oct 12, 2005 12:47 pm    Post subject: Reply with quote

Gentree wrote:
My benchmark for this sort of thing is


Cool - I'm glad you've got a it more time for this than I do presently. The amusing thing is that a big part of my job is benchmarking/tuning new hardware, but I haven't had time to run tests on my own machines. :(
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5350
Location: France, Old Europe

PostPosted: Wed Oct 12, 2005 1:09 pm    Post subject: Reply with quote

Quote:
and I am led to believe they are essentially an athalon 64 with less cache and the 64 bit extentions disabled.


http://www.xbitlabs.com/articles/cpu/display/sempron-2600_2.html

That is, the new Sempron 2600+, 2800+ and 3000+ for Socket 754 are manufactured with 90nm tech process, but are based on the stepping D0 core, so they don’t yet support the SSE3 instruction set.

That is, some of the new Sempron models have a smaller L2 cache (128KB, to be exact) than the Sempron 3100+ has (i.e. 256KB).

Or you could always try looking on AMD's site:
http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_11599_11604,00.html
*SSE2 support is available only with the 754-pin package

8)
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86
Back to top
View user's profile Send private message
mr666white
n00b
n00b


Joined: 24 Aug 2004
Posts: 52

PostPosted: Wed Oct 12, 2005 1:20 pm    Post subject: Reply with quote

My sempron is one of the first 3100+, so i think it based on the old 130nm core. I guess athalon-xp is the way to go for my cflags. As a slight aside, what would happen if I configured the kernel for a k8/hammer rather than an athalon(-xp)/k7?
_________________
www.technomancer.me.uk
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5350
Location: France, Old Europe

PostPosted: Wed Oct 12, 2005 2:01 pm    Post subject: Reply with quote

http://www.ocinside.de/index_e.html

very handy site for getting the low-down on you extact CPU model, you'll need to pull it out and look at the serial number.

If you want to try -march and -mtune for athlon 64 best check /proc/cpuinfo for sse? in flags and explicitly add or disable in cflags. This seems to be the main compatability diff on these families , obviously the cache size etc. is irrelevant in this context.

As for the kernel I think it is probably safe to try and you will either a get a kernel that will boot or no. Since it is basically a hamstrung Hammer core it should be safe but dont say I advised you to do it :wink:
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86
Back to top
View user's profile Send private message
playfool
l33t
l33t


Joined: 01 Jun 2004
Posts: 688
Location: Århus, Denmark

PostPosted: Thu Oct 13, 2005 3:05 am    Post subject: Reply with quote

I know several people build Athlon-MP setups using Athlon-XP and some clever hardware hacking, to the best of my knowledge the chips are very similar and since not many MP chips are required and they are built by the same specs - I assume that the odds that a given set of XPs would work as MPs with the correct gates connected are quite high. (I'm not encouraging this it will void warrenty and can make your system go boom - if you break it you get to keep both pieces)

Anyways, I guess this means you can rely on the fact that both cpus have basically the same charactaristics, so the performance drop by using -march=i686 -mtune=athlon-xp would be minimal

There's the basic guide - remember to research the specifics for your athlon core type and don't complain if things become unstable - the cores are probably untested before shipping at the new setting or could be marked down for failing the specific mp test.

http://www.cpuheat.wz.cz/html/AXP_multiplier/AXP_Multiplier.htm
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum