🚀 go-pugleaf

Fred Ma <fma@doe.carleton.ca> writes:
> My question is:  is execution speed or optimizability
> (gcc -O) affected by -shared?

PIC might execute slightly slower (less registers might be
available for optimizations and address calculations might
take more steps).

>     -Wl,-M,${MATLAB}/extern/lib/sol2/mexFunction.map

> To get a grip on shared functions, I looked at the ld man
> page for the above -Wl switch.  It talks about mapfiles, and

Regarding speed, map files affect mostly the startup time only.

> I'm using g++ 3.2.1 on solaris 8.

You might want to take a look at gcc2c and use it with the current
(production) Sun C compiler for maximum speed optimization:

http://soldc.sun.com/migration/linux/gcc2c_tool.html
http://access1.sun.com/s1sprod/


Markus

Fred Ma <fma@doe.carleton.ca> writes:

> My question is:  is execution speed or optimizability
> (gcc -O) affected by -shared?  I'm not too sure how to
> compare shared vs. nonshared.  My experience in the
> past has been just to compile without shared.   In that
> case, calling the program is straightforward.  Just type
> the name of the executable.  With matlab, however, I
> compile it using their compiler (which does alot of other
> things beside just invoking gcc).  In particular, they add
> extra  switches:
> 
>      -shared
>      -Wl,-M,${MATLAB}/extern/lib/sol2/mexFunction.map

I've not heard of a case where there is any significant difference
between position independent and non-position independent.  I suspect
most code ends up compiled independent in any case.  Perhaps it could
change something in how registers are allocated, but that would be
something highly architecture specific.  

static vs shared is used to create either a dynamically or statically
linked library.  A static library ends up being an archive of .o files
that are included in a executable when its linked, whereas a
dynamically linked library can be attached to an executable at
runtime.  Optimization is not affected because shared/static is more
of a linker issue than a compiler issue.  Once the code is in memory
and the fixups applied to all the symbols, there isn't any difference.

When you compile an executable, you're not creating a library, so
shared/static are not applicable.


> 
> The -shared is obvious, and the -Wl is for the linker.
> I never used the linker explicitly before, relying on gcc to
> pull it all together.  Now, I'm looking at "man ld", which
> is the sunOS5.8 man page, and I'm not sure if it is the same
> one that gcc uses.  Is there any reason to think otherwise?

A map file is simply a textual representation of some of addresses &
symbols in the output executable.  Perhaps Matlab is reading the map
file to get symbol information or some such.  If you're curious about
looking at compiled code, use objdump -dt against your .o file.

Here, ld is not being invoked separately, the -Wl tells gcc to pass
along the following parameter when it invokes ld.  You definately
don't want to be playing around with ld until you know you need to.

Gregm

>>> Fred Ma wrote:

(Pre-disclaimer to anything I said in this message: I've no experience to deal
with compiling & linking on Sparc, but only on x86 unixes (*BSD, Linuxes).
Something from my words can be non-portable to your system, if it is on Sparc.)

FM> I'm converting a C++ program into a function that can be
FM> called by an external application.  Specifically, I will be
FM> invoking it from a scientific computation package called
FM> Matlab.  It needs my program (main converted into an
FM> actual function) to be compiled with the "gcc -shared"
FM> option, which creates position-indepedent code.

No, -shared doesn't produce position-independent code by itself.
Info gcc specifies this explicitly:

==={{{
`-shared'
     Produce a shared object which can then be linked with other
     objects to form an executable.  Not all systems support this
     option.  You must also specify `-fpic' or `-fPIC' on some systems
     when you specify this option.
===}}}

Word "must" in this citation is too strong: nothing (at least on x86,
but I think it's true for Sparc also) prevents you from building
shared library without PIC. But this isn't recommended way (see below).

FM> My question is:  is execution speed or optimizability
FM> (gcc -O) affected by -shared?  I'm not too sure how to
FM> compare shared vs. nonshared.

`shared' affects execution time in the only way: it requires additional
time for dynamic linker to load library, parse its export and import
list, resolve unresolved links in this list. This time is spent once
on any program startup. It is usually too small, but can be very huge.
E.g., mozilla-1.0 loads on my at-work Linux box (Intel CC820, Celeron 900)
for 8 seconds, and 7.5 seconds of them are dedicated to load dynamic
libraries and resolve cross links. (There are special options in new
binutils which compresses cross-link lists for faster parsing,
`-fcombreloc' for ld; this wasn't applied yet to this mozilla package.)

Position-independent code has one big advantage: it makes code of shared
library minimally touched (usually only a few pages) in any process.
In system with unified virtual memory (as most modern Unixes are), this means
that any process with this library will have most of data of the library
shared in one real instance between all processes which loaded it.
Without PIC, any process which made exec() will have its own modified copy of
most code of the shared library. This is huge memory hog (and fatal for most
popular libraries, such as libc).
So, if you have no strong reason to compile shared library without PIC,
you should compile it with PIC (-fpic, or even -fPIC).
But, if execution speed (except startup) is critical to the application,
and there won't be many programs separately started using exec(),
you can make it non-PIC. If startup speed is also critical, consider
to link statically.
PIC can make library quite slower. For x86, libperl and Linux, it's about 30%
(not my benchmarks).

FM>  My experience in the
FM> past has been just to compile without shared.   In that
FM> case, calling the program is straightforward.  Just type
FM> the name of the executable.  With matlab, however, I
FM> compile it using their compiler (which does alot of other
FM> things beside just invoking gcc).  In particular, they add
FM> extra  switches:

FM>      -shared
FM>      -Wl,-M,${MATLAB}/extern/lib/sol2/mexFunction.map

FM> The -shared is obvious, and the -Wl is for the linker.
FM> I never used the linker explicitly before, relying on gcc to
FM> pull it all together.  Now, I'm looking at "man ld", which
FM> is the sunOS5.8 man page, and I'm not sure if it is the same
FM> one that gcc uses.  Is there any reason to think otherwise?

It isn't subject to make huge thinking, it is trivially testable.
Run gcc of any test example (even "Hello world") with -v.
Its verbose output will contain command line used to call linker, among other
information.
But, as -M for GNU ld means "print the map", I think your gcc uses SunOS ld.

FM> In the end, I'm still left with the question of how to
FM> invoke a shared library function outside of matlab.
FM> This is for the sake of speed comparison with the
FM> nonshared version, as the nonshared version is run
FM> from outside of matlab.

Trivial program will be similar to
main() {
  int (*func)(int);
  lib = dlopen( "yourlib.so", RTLD_LAZY );
  if( !lib ) { fprintf( stderr, "dlopen(): %s\n", dlerror() ); return 1; }
  func = dlsym( lib, "function" );
  if( !func ) { fprintf( stderr, "dlsym(): %s\n", dlerror() ); return 1; }
  printf( "%d\n", func(1) );
}

Rewrite it to your system and your function specifics.

FM> To get a grip on shared functions, I looked at the ld man
FM> page for the above -Wl switch.  It talks about mapfiles, and
FM> refers to "Linker and Libraries Guide" for an explanation,
FM> which I found on the web.  It's one hefty document.  All I
FM> want to know is whether execution speed and optimizability
FM> is affected.  I don't intend to actually dabble with the linker.

Than, mapfile isn't important for you.


-netch-

Markus Gyger wrote:

> Fred Ma <fma@doe.carleton.ca> writes:
> > My question is:  is execution speed or optimizability
> > (gcc -O) affected by -shared?
>
> PIC might execute slightly slower (less registers might be
> available for optimizations and address calculations might
> take more steps).
>
> >     -Wl,-M,${MATLAB}/extern/lib/sol2/mexFunction.map
>
> > To get a grip on shared functions, I looked at the ld man
> > page for the above -Wl switch.  It talks about mapfiles, and
>
> Regarding speed, map files affect mostly the startup time only.
>
> > I'm using g++ 3.2.1 on solaris 8.
>
> You might want to take a look at gcc2c and use it with the current
> (production) Sun C compiler for maximum speed optimization:
>
> http://soldc.sun.com/migration/linux/gcc2c_tool.html
> http://access1.sun.com/s1sprod/
>
> Markus

Actually, I want to stick with gcc because I want transparency
between solaris8 and Win2K/Cygwin.  Thanks for the suggestions.

Fred

Greg Menke wrote:

> I've not heard of a case where there is any significant difference
> between position independent and non-position independent.

That's reassuring.

> I suspect
> most code ends up compiled independent in any case.  Perhaps it could
> change something in how registers are allocated, but that would be
> something highly architecture specific.
>
> static vs shared is used to create either a dynamically or statically
> linked library.  A static library ends up being an archive of .o files
> that are included in a executable when its linked, whereas a
> dynamically linked library can be attached to an executable at
> runtime.  Optimization is not affected because shared/static is more
> of a linker issue than a compiler issue.  Once the code is in memory
> and the fixups applied to all the symbols, there isn't any difference.

Great.

> When you compile an executable, you're not creating a library, so
> shared/static are not applicable.
>
> >
> > The -shared is obvious, and the -Wl is for the linker.
> > I never used the linker explicitly before, relying on gcc to
> > pull it all together.  Now, I'm looking at "man ld", which
> > is the sunOS5.8 man page, and I'm not sure if it is the same
> > one that gcc uses.  Is there any reason to think otherwise?
>
> A map file is simply a textual representation of some of addresses &
> symbols in the output executable.  Perhaps Matlab is reading the map
> file to get symbol information or some such.  If you're curious about
> looking at compiled code, use objdump -dt against your .o file.
>
> Here, ld is not being invoked separately, the -Wl tells gcc to pass
> along the following parameter when it invokes ld.  You definately
> don't want to be playing around with ld until you know you need to.
>
> Gregm

Well, thanks for the confirmation that I shouldn't be poking around
with ld unnecessarily.  I wasn't looking forward to spending loads
of timing ramping up on a new tool.

Fred

Valentin Nechayev wrote:

> `shared' affects execution time in the only way: it requires additional
> time for dynamic linker to load library, parse its export and import
> list, resolve unresolved links in this list. This time is spent once
> on any program startup. It is usually too small, but can be very huge.
> E.g., mozilla-1.0 loads on my at-work Linux box (Intel CC820, Celeron 900)
> for 8 seconds, and 7.5 seconds of them are dedicated to load dynamic
> libraries and resolve cross links. (There are special options in new
> binutils which compresses cross-link lists for faster parsing,
> `-fcombreloc' for ld; this wasn't applied yet to this mozilla package.)

I can live with long startup time.  The execution time is much longer,
so that's the important thing.

> FM> I never used the linker explicitly before, relying on gcc to
> FM> pull it all together.  Now, I'm looking at "man ld", which
> FM> is the sunOS5.8 man page, and I'm not sure if it is the same
> FM> one that gcc uses.  Is there any reason to think otherwise?
>
> It isn't subject to make huge thinking, it is trivially testable.
> Run gcc of any test example (even "Hello world") with -v.

Well, thanks for the advice.  It wasn't obvious to me how to
obtain the information, but your suggestion to use -v revealed
that it was the solaris linker.

> FM> In the end, I'm still left with the question of how to
> FM> invoke a shared library function outside of matlab.
> FM> This is for the sake of speed comparison with the
> FM> nonshared version, as the nonshared version is run
> FM> from outside of matlab.
>
> Trivial program will be similar to
> main() {
>   int (*func)(int);
>   lib = dlopen( "yourlib.so", RTLD_LAZY );
>   if( !lib ) { fprintf( stderr, "dlopen(): %s\n", dlerror() ); return 1; }
>   func = dlsym( lib, "function" );
>   if( !func ) { fprintf( stderr, "dlsym(): %s\n", dlerror() ); return 1; }
>   printf( "%d\n", func(1) );
> }

OK, that's quite a bit of new material (can't say I recognize
any of it).  I'll have to do some digging and reading before
I make use of it.  Thanks.

Fred

Fred Ma <fma@doe.carleton.ca> writes:
> Markus Gyger wrote:
> > You might want to take a look at gcc2c and use it with the current
> > (production) Sun C compiler for maximum speed optimization:
> >
> > http://soldc.sun.com/migration/linux/gcc2c_tool.html
> > http://access1.sun.com/s1sprod/
> 
> Actually, I want to stick with gcc because I want transparency
> between solaris8 and Win2K/Cygwin.

gcc2c is just a patch for gcc's backend so that it produces
ISO C code that is then fed to another optimizing C compiler.
Kind of like the early C++ compilers/translators worked (cfront).


Markus

Markus Gyger wrote:

> Fred Ma <fma@doe.carleton.ca> writes:
> > Markus Gyger wrote:
> > > You might want to take a look at gcc2c and use it with the current
> > > (production) Sun C compiler for maximum speed optimization:
> > >
> > > http://soldc.sun.com/migration/linux/gcc2c_tool.html
> > > http://access1.sun.com/s1sprod/
> >
> > Actually, I want to stick with gcc because I want transparency
> > between solaris8 and Win2K/Cygwin.
>
> gcc2c is just a patch for gcc's backend so that it produces
> ISO C code that is then fed to another optimizing C compiler.
> Kind of like the early C++ compilers/translators worked (cfront).
>
> Markus

Hi, Markus,

I took a look at the description.  It looks interesting.
Natural question is why not just use sun's CC directly
when compiling on solaris?

There is another factor that I have to consider.  That
is the fact you have to modify the build of gcc.  It took
about a week to learn enough to try (four
times) to build my own gcc (I am nonadministrator).
This included all the facilities required to test it.  It never
passed the tests without many errors, different errors
each time.  Since I couldn't tell which ones were important,
I didn't install it; my concern was that I couldn't tell which
files to remove in order to uninstall everything.  In the end
I asked my sysadmin to install premade binaries for solaris.
So building gcc is a bit of a problem.

As soon as I finish recoding for matlab, I can do a speed
comparison to confirm that compiling with PIC and as shared
does not adversely affect executio speed.  30% speed
increase from using gcc2c is somewhat significant, and
I'll see if in the future, time permits me to ramp up on what's
necessary to make it work.  Thanks for the suggestion.

Fred

On Fri, 14 Mar 2003 04:49:41 -0500, fma@doe.carleton.ca wrote:
>Markus Gyger wrote:
>> You might want to take a look at gcc2c and use it with the current
>> (production) Sun C compiler for maximum speed optimization:
>>...
>
>Actually, I want to stick with gcc because I want transparency
>between solaris8 and Win2K/Cygwin.


you should have no problems using forte for solaris 8 and gcc on cygwin.

It's easy taking source code developed under forte CC, and recompiling with
g++. Usually, (almost always) there's nothing extra to do.
The problem is when you try to go the other way.



-- 
  http://www.blastwave.org/ for solaris pre-packaged binaries with pkg-get
    Organized by the author of pkg-get
[Trim the no-bots from my address to reply to me by email!]
         S.1618 http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:@@@D
                            http://www.spamlaws.com/state/ca1.html

Philip Brown wrote:

> On Fri, 14 Mar 2003 04:49:41 -0500, fma@doe.carleton.ca wrote:
> >Markus Gyger wrote:
> >> You might want to take a look at gcc2c and use it with the current
> >> (production) Sun C compiler for maximum speed optimization:
> >>...
> >
> >Actually, I want to stick with gcc because I want transparency
> >between solaris8 and Win2K/Cygwin.
>
> you should have no problems using forte for solaris 8 and gcc on cygwin.
>
> It's easy taking source code developed under forte CC, and recompiling with
> g++. Usually, (almost always) there's nothing extra to do.
> The problem is when you try to go the other way.
>
> --
>   http://www.blastwave.org/ for solaris pre-packaged binaries with pkg-get
>     Organized by the author of pkg-get
> [Trim the no-bots from my address to reply to me by email!]
>          S.1618 http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:@@@D
>                             http://www.spamlaws.com/state/ca1.html

I do recall years ago when I last used C++, I was in fact making
minor mods to enable compiling with gcc on the suns and HP's CC.
That was on HPUX.  For now, I just want to understand what
coding practices affect speed, in principle, and worry about tweaking
based on compilers/platform later.  I may decide to forgo some of
those for cross-platform portablility e.g. if it involves time to tweak
stuff everytime I migrate from cygwin gcc to solaris forte, I may decide
just to stick with gcc because of its ubiquity.

By the way, gcc has a handy --version switch, but cc on the sun
doesn't.  Is there a way to check beyond any doubt what compiler
it is?

Fred

On Sat, 15 Mar 2003 17:27:43 -0500
Fred Ma <fma@doe.carleton.ca> wrote:

> 
> By the way, gcc has a handy --version switch, but cc on the sun
> doesn't.  Is there a way to check beyond any doubt what compiler
> it is?
> 

cc -V


-- 
Barbie - Prayers are like junkmail for Jesus

I have seen things you lusers would not believe.
I've seen Sun monitors on fire off the side of the multimedia lab.
I've seen NTU lights glitter in the dark near the Mail Gate.
All these things will be lost in time, like the root partition last week.
Time to die.

Fred Ma <fma@doe.carleton.ca> writes:

>By the way, gcc has a handy --version switch, but cc on the sun
>doesn't.  Is there a way to check beyond any doubt what compiler
>it is?

"cc -V" or "CC -V"

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

"Casper H.S. Dik" wrote:

> Fred Ma <fma@doe.carleton.ca> writes:
>
> >By the way, gcc has a handy --version switch, but cc on the sun
> >doesn't.  Is there a way to check beyond any doubt what compiler
> >it is?
>
> "cc -V" or "CC -V"
>
> Casper
> --
> Expressed in this posting are my opinions.  They are in no way related
> to opinions held by my employer, Sun Microsystems.
> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.

Thanks, Barbie and Casper.  Our department's sun cc is
WorkShop Compilers 5.0 98/12/15 C++ 5.0.  It isn't Forte
(which has changed names to Sun ONE Studio 7, according
to a web search), the one mentioned by Philip Brown.  Unless
it goes by more than one name.

Fred

In article <3E73B68E.7C001CEF@doe.carleton.ca>,
Fred Ma  <fma@doe.carleton.ca> wrote:
>
>Thanks, Barbie and Casper.  Our department's sun cc is
>WorkShop Compilers 5.0 98/12/15 C++ 5.0.  It isn't Forte
>(which has changed names to Sun ONE Studio 7, according
>to a web search), the one mentioned by Philip Brown.  Unless
>it goes by more than one name.

Your time may be better served if you take the time to browse Sun's 
extensive online documentation (docs.sun.com) and get a better feel 
for what you have and what you need. For more information on Sun
Forte/ONE Studio tools, go to http://www.sun.com/workshop/. 

The C++ compiler in Workshop 5.x is so ancient that it's useless in 
today's world. Sun ONE Studio 7 does have a good C++ compiler; Forte 
6 update 2 is the oldest you want to use at this point, at least for 
any new code (make sure you apply all the patches available from the
workshop site). If you're using it on a University machine, Forte/ONE
Studio are available from Sun at a *very* reasonable price.

Do please watch the all the cross-posting! Followup set to comp.unix.solaris
only.

Regards,
Mumit