Re: [gentoo-user] mtune=k6-2 and a *small* upgrade
Shawn Haggett wrote: There's two points that come to mind. 1) mtune is a request for the compiler to make the code more suited to the given processor, but without breaking compatibility. march is telling the compiler, do everything you can to make this code fastest on this processor. From the GCC docs for 4.2.3: -mtune=cpu-type: Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. -march=cpu-type: Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type. So mtune shouldn't be using any instructions that are in K-6 that weren't in a 386. 2) I believe x86 hardware never goes backwards. That is, if a new feature is added, all future versions of the chip have that feature, just with more added. Of course Intel and AMD both have their separate additions, but since your staying with AMD, moving to a new processor shouldn't break anything (even if you had used march). Disclaimer: I'm not an expert on hardware architectures or compilers, so I might be wrong. Shawn Thanks Shawn, that's probably the best answer I'm going to get, I doubt many of the AMD chip designers hang around here... :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] mtune=k6-2 and a *small* upgrade
On Tuesday 08 April 2008, Anthony Metcalf wrote: But what else? Will mtune=k6-2 make executables that will run on an Athlon 64? Anyone tried this? Would I get to a point where I could make -e world and have a nice working system? k6 is 32 bit right? There's no sane upgrade path to amd64, looks like you are in for a reinstall -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] mtune=k6-2 and a *small* upgrade
Alan McKinnon wrote: On Tuesday 08 April 2008, Anthony Metcalf wrote: � � But what else? Will mtune=k6-2 make executables that will run on an Athlon 64? Anyone tried this? Would I get to a point where I could make -e world and have a nice working system? k6 is 32 bit right? There's no sane upgrade path to amd64, looks like you are in for a reinstall Yes, 32bit, and Athlon 64s ran x86 last I heard :) The 64bit argument is one I will have to consider more deeply, but certainly in the near term, I won't gain anything from it, as I don't do *any* of the things the extended memory range is good for, and don't need more than 4GB RAM... Later when I upgrade to a phenom, and stick 1GB RAM per core in there, then yeah, I will probably recompile into 64bit, but that can be done in a chroot, and migrated fairly easily I would expect, so long as the system is running. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] mtune=k6-2 and a *small* upgrade
On Tue, 08 Apr 2008 15:43:16 +0100, Anthony Metcalf wrote: Later when I upgrade to a phenom, and stick 1GB RAM per core in there, then yeah, I will probably recompile into 64bit, but that can be done in a chroot, and migrated fairly easily I would expect, so long as the system is running. The chroot will be running on a 32 bit kernel. At some time you will have to reinstall to get 64 bit, only you can decide when is the best time to get it done with. -- Neil Bothwick Mr. Worf, scan that ship. Aye Captain. 300 dpi? signature.asc Description: PGP signature
Re: [gentoo-user] mtune=k6-2 and a *small* upgrade
On Tuesday 08 April 2008, Anthony Metcalf wrote: Alan McKinnon wrote: On Tuesday 08 April 2008, Anthony Metcalf wrote: � � But what else? Will mtune=k6-2 make executables that will run on an Athlon 64? Anyone tried this? Would I get to a point where I could make -e world and have a nice working system? k6 is 32 bit right? There's no sane upgrade path to amd64, looks like you are in for a reinstall Yes, 32bit, and Athlon 64s ran x86 last I heard :) The 64bit argument is one I will have to consider more deeply, but certainly in the near term, I won't gain anything from it, as I don't do *any* of the things the extended memory range is good for, and don't need more than 4GB RAM... Later when I upgrade to a phenom, and stick 1GB RAM per core in there, then yeah, I will probably recompile into 64bit, but that can be done in a chroot, and migrated fairly easily I would expect, so long as the system is running. OK, so it's 32 bit on an amd64 you'll be doing I would reconfigure the kernel and include things that you know ought to be there. Then move the disks over and see if it boots. Rinse, repeat, till it does. Now the existing system should work with your new hardware and you can update your CFLAGS and 'emerge -e world' at your leisure. That's the theory at least anyway :-) -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] mtune=k6-2 and a *small* upgrade
On Tue, 2008-04-08 at 15:43 +0100, Anthony Metcalf wrote: Alan McKinnon wrote: On Tuesday 08 April 2008, Anthony Metcalf wrote: � � But what else? Will mtune=k6-2 make executables that will run on an Athlon 64? Anyone tried this? Would I get to a point where I could make -e world and have a nice working system? k6 is 32 bit right? There's no sane upgrade path to amd64, looks like you are in for a reinstall Yes, 32bit, and Athlon 64s ran x86 last I heard :) The 64bit argument is one I will have to consider more deeply, but certainly in the near term, I won't gain anything from it, as I don't do *any* of the things the extended memory range is good for, and don't need more than 4GB RAM... Later when I upgrade to a phenom, and stick 1GB RAM per core in there, then yeah, I will probably recompile into 64bit, but that can be done in a chroot, and migrated fairly easily I would expect, so long as the system is running. It's not just the memory. Using 64bit gives your CPU some more registers thus (possibly) making him faster and it speeds up 64bit calculations (e.g. double precision floating point). I don't think you'll need this for your purposes but I just wanted to say: It's not just the 4 Gig. signature.asc Description: This is a digitally signed message part
Re: [gentoo-user] mtune=k6-2 and a *small* upgrade
Alan McKinnon wrote: OK, so it's 32 bit on an amd64 you'll be doing Initially yes, I'll look into 64bit as need arises. I would reconfigure the kernel and include things that you know ought to be there. Then move the disks over and see if it boots. Rinse, repeat, till it does. Well, more likely, break the mirror, pull a disk, and test on the new machine, if it works, great, take the old machine down, and move the remaining disk across and drop onto the network, and start the process to change the cflags and emerge -e world... If not, then most likely move the disk back, let the mirror rebuild, and do a fresh install on new disks... Now the existing system should work with your new hardware and you can update your CFLAGS and 'emerge -e world' at your leisure. That's the theory at least anyway :-) Well, exactly. That is the theory. I want to know the likelihood of success. I know that using mtune=k6-2 means it won't run on anything before a k6-2, and most likely not on anything Intel, due to the symbols and optimisations used. What I want is some idea of the chance it will run on a *later* AMD processor. Will an Athlon honour the k6-2 optimisations? signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] mtune=k6-2 and a *small* upgrade
On Tue, 08 Apr 2008 16:02:50 +0100, Anthony Metcalf wrote: Well, exactly. That is the theory. I want to know the likelihood of success. I know that using mtune=k6-2 means it won't run on anything before a k6-2, and most likely not on anything Intel, due to the symbols and optimisations used. What I want is some idea of the chance it will run on a *later* AMD processor. Will an Athlon honour the k6-2 optimisations? If you have the time before the transition, you could set CFLAGS to something really generic, like -mcpu=i586 and emerge -e system, as well as recompiling the kernel. Then move the disks over. That way, you'll know that your toolchain and portage will work, which is all you need to get everything else going. -- Neil Bothwick If a book about failures doesn't sell, is it a success? signature.asc Description: PGP signature
Re: [gentoo-user] mtune=k6-2 and a *small* upgrade
Neil Bothwick wrote: On Tue, 08 Apr 2008 16:02:50 +0100, Anthony Metcalf wrote: If you have the time before the transition, you could set CFLAGS to something really generic, like -mcpu=i586 and emerge -e system, as well as recompiling the kernel. Then move the disks over. That way, you'll know that your toolchain and portage will work, which is all you need to get everything else going. May be a good idea... Only problem with that is that his ageing system doesn't like to compile gcc any more. I get segfaults on anything that takes more than about 40 minutes to compile. One of the reasons for moving it. :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] mtune=k6-2 and a *small* upgrade
Anthony Metcalf wrote: Alan McKinnon wrote: Now the existing system should work with your new hardware and you can update your CFLAGS and 'emerge -e world' at your leisure. That's the theory at least anyway :-) Well, exactly. That is the theory. I want to know the likelihood of success. I know that using mtune=k6-2 means it won't run on anything before a k6-2, and most likely not on anything Intel, due to the symbols and optimisations used. What I want is some idea of the chance it will run on a *later* AMD processor. Will an Athlon honour the k6-2 optimisations? There's two points that come to mind. 1) mtune is a request for the compiler to make the code more suited to the given processor, but without breaking compatibility. march is telling the compiler, do everything you can to make this code fastest on this processor. From the GCC docs for 4.2.3: -mtune=cpu-type: Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. -march=cpu-type: Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type. So mtune shouldn't be using any instructions that are in K-6 that weren't in a 386. 2) I believe x86 hardware never goes backwards. That is, if a new feature is added, all future versions of the chip have that feature, just with more added. Of course Intel and AMD both have their separate additions, but since your staying with AMD, moving to a new processor shouldn't break anything (even if you had used march). Disclaimer: I'm not an expert on hardware architectures or compilers, so I might be wrong. Shawn -- gentoo-user@lists.gentoo.org mailing list
