cc -xarch=native - Solaris
This is a discussion on cc -xarch=native - Solaris ; 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 ...
-
cc -xarch=native
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).
Thanks, Warren.
** Posted from http://www.teranews.com **
-
Re: cc -xarch=native
On Fri, 16 May 2008 13:51:36 -0400, Charmed Snark 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.
A bientot
Paul
--
Paul Floyd http://paulf.free.fr
-
Re: cc -xarch=native
Paul Floyd expounded in news:slrng2rj93.qr.root@tryfan.orange.fr:
> On Fri, 16 May 2008 13:51:36 -0400, Charmed Snark
> 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.
Warren.
** Posted from http://www.teranews.com **
-
Re: cc -xarch=native
Charmed Snark wrote:
> Paul Floyd expounded in news:slrng2rj93.qr.root@tryfan.orange.fr:
>
>> 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?
--
Ian Collins.
-
Re: cc -xarch=native
Ian Collins expounded in news:696d33F30sin2U3@mid.individual.net:
> Charmed Snark wrote:
>> Paul Floyd expounded in news:slrng2rj93.qr.root@tryfan.orange.fr:
>>
>>> 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.
I don't care about this anyway- this digresses
entirely from my OP.
** Posted from http://www.teranews.com **
-
Re: cc -xarch=native
Charmed Snark wrote:
> Ian Collins expounded in news:696d33F30sin2U3@mid.individual.net:
>
>> Charmed Snark wrote:
>>> Paul Floyd expounded in news:slrng2rj93.qr.root@tryfan.orange.fr:
>>>
>>>> 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.
--
Ian Collins.
-
Re: cc -xarch=native
Ian Collins expounded in news:6972acF30sin2U7@mid.individual.net:
> Charmed Snark wrote:
>> Ian Collins expounded in news:696d33F30sin2U3@mid.individual.net:
>>
>>> Charmed Snark wrote:
>>>> Paul Floyd expounded in news:slrng2rj93.qr.root@tryfan.orange.fr:
>>>>
>>>>> 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 ;-)
Warren.
** Posted from http://www.teranews.com **
-
Re: cc -xarch=native
On Fri, 16 May 2008 16:29:02 -0400, Charmed Snark 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.
So, have you done performance analysis?
A bientot
Paul
--
Paul Floyd http://paulf.free.fr
-
Re: cc -xarch=native
Paul Floyd expounded in news:slrng310eg.q3.root@tryfan.orange.fr:
> On Fri, 16 May 2008 16:29:02 -0400, Charmed Snark
> 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.
Warren.
** Posted from http://www.teranews.com **