I am working on an open sourced project, where I must allow the user to ./configure and make. What I understand from Solaris documentation for cc, is that -xarch=native causes cc to compile to the best architecture for the current platform.
In the note, it also mentioned that you should make sure to pass the "matching option to the linker" to make certain that the correct startup routine is used. I assume this only applies to using the cc command as the front end to the linking process, but I saw no ld options that would apply. So if you used ld directly, you would probably manually select the correct startup object by pathname. I'll be using cc, so this question is purely academic.
I also assume for Solaris, that if the user decides to use gcc to build the project, that I'll need to determine the architecture for him, in order to get a more optimal build. I've worked out a C program that should be in the ballpark, using Sun's /dev/cpu/self/cpuid or some such.
But I have to ask if there is any Solaris provided utility for this purpose (on Intel)?
Or has someone else provided a fully functional CPL version of such a program to produce gcc -march=* values?
I believe there are tools for this on the SPARC side, which I'll have to re-investigate (its been a while).
On Fri, 16 May 2008 13:51:36 -0400, Charmed Snark <sn...@cogeco.ca> wrote: > I am working on an open sourced project, where I must allow the user to > ./configure and make. What I understand from Solaris documentation for > cc, is that -xarch=native causes cc to compile to the best architecture > for the current platform.
> In the note, it also mentioned that you should make sure to pass the > "matching option to the linker" to make certain that the correct startup > routine is used. I assume this only applies to using the cc command as > the front end to the linking process, but I saw no ld options that would > apply. So if you used ld directly, you would probably manually select the > correct startup object by pathname. I'll be using cc, so this question is > purely academic.
> I also assume for Solaris, that if the user decides to use gcc to build > the project, that I'll need to determine the architecture for him, in > order to get a more optimal build. I've worked out a C program that > should be in the ballpark, using Sun's /dev/cpu/self/cpuid or some such.
> But I have to ask if there is any Solaris provided utility for this > purpose (on Intel)?
> Or has someone else provided a fully functional CPL version of such a > program to produce gcc -march=* values?
> I believe there are tools for this on the SPARC side, which I'll have to > re-investigate (its been a while).
Don't bother dicking about with a ton of options. Here are some very simple rules to get you started.
1. Compile with cc (-O if you want it optimised) 2. If it includes C++ code, compile it with CC, and also use CC to link, otherwise use cc to link. Never use ld directly to link.
When you've got it to build, _then_ consider profiling and dicking with optimization flags. However, for a lot of software, just plain -O is good enough. Remember, a program that works slowly is infinitely more useful than one that doesn't work and is fast.
> On Fri, 16 May 2008 13:51:36 -0400, Charmed Snark <sn...@cogeco.ca> > wrote: >> In the note, it also mentioned that you should make sure to pass the >> "matching option to the linker" to make certain that the correct >> startup routine is used. I assume this only applies to using the cc >> command as the front end to the linking process, but I saw no ld >> options that would apply. So if you used ld directly, you would >> probably manually select the correct startup object by pathname. I'll >> be using cc, so this question is purely academic.
> Don't bother dicking about with a ton of options.
I'm only concerned with ONE option here: -xarch=* for cc, and -march=* for gcc. Not "tons" of options.
I also recognize that there are additional options that influence performance, but further comments below..
> Never use ld directly to link.
Agreed that it is best to avoid it, and I can in this case (as I said, this is an academic question). But it is bad advice to say "never" use ld. There are times when it is required.
> Here are some very > simple rules to get you started. .. > When you've got it to build, _then_ consider > profiling and dicking
I am very well aquainted with the process.
> ... However, for a lot of software, just plain -O > is good enough.
What is "good enough" depends very much on the application involved and how it is used. In this case, it is for an interpreter (BASIC) where performance can make a big difference to the end user.
Further to this, I am not looking for the perfect solution. CFLAGS is available for any saavy end user to undo or perfect the optimization for his build.
But I suspect many end users won't go there, so it makes perfect sense to get a "reasonable" optimization in place by default.
> Agreed that it is best to avoid it, and I can > in this case (as I said, this is an academic > question). But it is bad advice to say "never" > use ld. There are times when it is required.
>> Agreed that it is best to avoid it, and I can >> in this case (as I said, this is an academic >> question). But it is bad advice to say "never" >> use ld. There are times when it is required.
> Care to name one?
I recall one project on HP where this was done in many places. I wasn't the one who initially set it up, but I do remember unsucessfully trying to eliminate using ld. So I don't recall the precise nature of it but there were definitely reasons.
I don't care about this anyway- this digresses entirely from my OP. ** Posted from http://www.teranews.com **
>>>> Never use ld directly to link. >>> Agreed that it is best to avoid it, and I can >>> in this case (as I said, this is an academic >>> question). But it is bad advice to say "never" >>> use ld. There are times when it is required.
>> Care to name one?
> I recall one project on HP where this was done > in many places. I wasn't the one who initially > set it up, but I do remember unsucessfully trying > to eliminate using ld. So I don't recall the > precise nature of it but there were > definitely reasons.
OK, but I don't think you will find one on Solaris.
> I don't care about this anyway- this digresses > entirely from my OP.
Oh well, you started it!
Regarding your OP, I don't think there is a suitable wrapper for cpuid, so your little C program is probably the best way to go.
>>>>> Never use ld directly to link. .. >> I recall one project on HP where this was done >> in many places. I wasn't the one who initially >> set it up, but I do remember unsucessfully trying >> to eliminate using ld. So I don't recall the >> precise nature of it but there were >> definitely reasons.
> OK, but I don't think you will find one on Solaris.
That is fine, but I was responding to the _general_ statement "never use ld". Life is complicated, and so the old adage "never say never" becomes quite applicable.
>> I don't care about this anyway- this digresses >> entirely from my OP.
> Oh well, you started it!
Heh, heh, not exactly- I simply responded to a general statement which is, at least in my own experience, flawed. YMMV.
> Regarding your OP, I don't think there is a suitable wrapper for cpuid, > so your little C program is probably the best way to go.
Yes, that was pretty much what I concluded a few days ago before I got the idea of asking here. Wishful thinking sometimes get rewarded if you ask in the right places ;-)
On Fri, 16 May 2008 16:29:02 -0400, Charmed Snark <sn...@cogeco.ca> wrote:
> I'm only concerned with ONE option here: -xarch=* for cc, > and -march=* for gcc. Not "tons" of options.
> I also recognize that there are additional options > that influence performance, but further comments below..
What I've seen of a lot of GNUish projects (the libtool corner of autohell springs to mind) is an excessive use of options.
>> ... However, for a lot of software, just plain -O >> is good enough.
> What is "good enough" depends very much on the application > involved and how it is used. In this case, it is for > an interpreter (BASIC) where performance can make a big > difference to the end user.
> On Fri, 16 May 2008 16:29:02 -0400, Charmed Snark <sn...@cogeco.ca> > wrote:
>> I'm only concerned with ONE option here: -xarch=* for cc, >> and -march=* for gcc. Not "tons" of options.
>> I also recognize that there are additional options >> that influence performance, but further comments below..
> What I've seen of a lot of GNUish projects (the libtool corner of > autohell springs to mind) is an excessive use of options.
I'm not a fan of libtool per se, but may have to get into that later on as this project matures.
>>> ... However, for a lot of software, just plain -O >>> is good enough.
>> What is "good enough" depends very much on the application >> involved and how it is used. In this case, it is for >> an interpreter (BASIC) where performance can make a big >> difference to the end user.
> So, have you done performance analysis?
Yes, but the project is still Alpha. So there isn't a big push in this direction yet.
