-mtune != -march (>=) - optimizing for a higher architecture

-mtune != -march (>=) - optimizing for a higher architecture

[Tom Alsberg]

Hi there...

Recently I built GCC 3.4.2 for Linux, and read through a bit of its
documentation.  In (gcc.info)i386 and x86-63 Options, it is said under
`-march=CPU-TYPE':  specifying `-march=CPU-TYPE' implies 
`-mtune=CPU-TYPE'.

I wonder, then - how could I compile code that would be optimized for
one x86 CPU family member (say, pentium3), but that would run on all
x86 CPUs since some older one (say, i586), and fully take advantage of
that older (but still newer than i386) one's instruction and register 
set, etc?

For example, how could I compile code to take advantage, of, say,
pentium instructions and registers, but optimize instruction 
scheduling, cache and pipeline usage, etc. for, say, pentium3?

I used to compile code specifying -mcpu=pentiumpro -march=pentium,
believing that this would make it optimized for the i686 but would
run on and take advantage of i586 instructions...

If I understand correctly now, only specifying -mtune will generate
code that will run on i386 (and thus not take advantage of newer 
instructions, etc.), but be optimized for some newer CPU-TYPE...

But I'm not sure how to take the lower limit somewhat higher than the
i386, while still optimizing for something yet newer than that...

I'm sorry if that's a FAQ or some misunderstanding of me...  I couldn't
find any answer, though, and didn't feel like going through the source
of GCC...

  Thanks,
  -- Tom

-- 
  Tom Alsberg - hacker (being the best description fitting this space)
  Web page:	http://www.cs.huji.ac.il/~alsbergt/
DISCLAIMER:  The above message does not even necessarily represent what
my fingers have typed on the keyboard, save anything further.

Re: -mtune != -march (>=) - optimizing for a higher architecture

[Paul Brook]

On Saturday 25 September 2004 10:06, Tom Alsberg wrote:
> Hi there...
>
> Recently I built GCC 3.4.2 for Linux, and read through a bit of its
> documentation.  In (gcc.info)i386 and x86-63 Options, it is said under
> `-march=CPU-TYPE':  specifying `-march=CPU-TYPE' implies
> `-mtune=CPU-TYPE'.
>
> I wonder, then - how could I compile code that would be optimized for
> one x86 CPU family member (say, pentium3), but that would run on all
> x86 CPUs since some older one (say, i586), and fully take advantage of
> that older (but still newer than i386) one's instruction and register
> set, etc?

Specify both -march= and -mtune=

Paul

P.S. This is the wrong place to be asking this sort of question. This list is 
for development *of" gcc, not development *with* gcc. You might try 
gcc-help@gcc.gnu.org for further questions.

Re: -mtune != -march (>=) - optimizing for a higher architecture

[Tom Alsberg]

On Sat, Sep 25, 2004 at 01:50:59PM +0100, Paul Brook wrote:
> On Saturday 25 September 2004 10:06, Tom Alsberg wrote:
> > Hi there...
> >
> > Recently I built GCC 3.4.2 for Linux, and read through a bit of its
> > documentation.  In (gcc.info)i386 and x86-64 Options, it is said under
> > `-march=CPU-TYPE':  specifying `-march=CPU-TYPE' implies
> > `-mtune=CPU-TYPE'.
> >
> > I wonder, then - how could I compile code that would be optimized for
> > one x86 CPU family member (say, pentium3), but that would run on all
> > x86 CPUs since some older one (say, i586), and fully take advantage of
> > that older (but still newer than i386) one's instruction and register
> > set, etc?
> 
> Specify both -march= and -mtune=

OK, so this would work as I asked?  Thanks, then...

I suggest a documentation correction, then, though...  As in the
documentation, it states under `-march=CPU-TYPE' in
(gcc.info)i386 and x86-64 Options: 

Moreover, specifying `-march=CPU-TYPE' implies `-mtune=CPU-TYPE'.

Which I would understand to mean that -march=pentium would imply 
-mtune=pentium, and thus adding -mtune=pentium3 won't apply.

> Paul

  Thanks,
  -- Tom

> P.S. This is the wrong place to be asking this sort of question. 

I'm sorry for that.  Didn't grasp the exact description of this list.
Further usage help requests from me will go to gcc-help...

> This list is for development *of" gcc, not development *with* gcc. 
> You might try gcc-help@gcc.gnu.org for further questions.

-- 
  Tom Alsberg - hacker (being the best description fitting this space)
  Web page:	http://www.cs.huji.ac.il/~alsbergt/
DISCLAIMER:  The above message does not even necessarily represent 
what
my fingers have typed on the keyboard, save anything further.

Reducing the size of the binaries

[Juan Ignacio Garzón]

Hi i'm compiling a very simple program that consists
in 3 files:
-a .h file (20 lines of code), which declares a class
and includes iostream
-a .cpp file (33 lines of code), including only the .h
file.
-main.cpp (11 lines), which includes only the .h.

So, as you can see, its a very very simple program
with 1 class and a main. I'm just beginning a proyect.
When I compiled this using the following command line:
g++.exe -c ... -o ... -I ... -DDEBUG -Wall -pedantic
-g -ansi -fno-inline

the result was:
a .o file for the main.cpp (803 KB)
a .o file for the .cpp (class definition) ( 810 KB)
the .exe file (1251 KB)

I'm using gcc 3.2 (mingw32)
I cannot understand why are they so big in size... I
think im doing something bad, but I don't know what...

If I include stdlib.h in any file, it results in a 2
MB exe.
I have a lot of programs made with C++ and their
binaries are smaller than mine, and mi program has
less than 100 lines. What's wrong?

Thanks in advance...



	
	
		
___________________________________________________________
100mb gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar

Re: Reducing the size of the binaries

[Kevin Puetz]

Juan Ignacio Garzón wrote:

> Hi i'm compiling a very simple program that consists
> in 3 files:
> -a .h file (20 lines of code), which declares a class
> and includes iostream
> -a .cpp file (33 lines of code), including only the .h
> file.
> -main.cpp (11 lines), which includes only the .h.
> 
> So, as you can see, its a very very simple program
> with 1 class and a main. I'm just beginning a proyect.
> When I compiled this using the following command line:
> g++.exe -c ... -o ... -I ... -DDEBUG -Wall -pedantic
> -g -ansi -fno-inline

-g is a request for debug symbols. These are huge, because you when you
#include iostream, debug symbols for your application involves the debug
symbols for a pretty fair chunk of the templates in libstdc++ :-)

> the result was:
> a .o file for the main.cpp (803 KB)
> a .o file for the .cpp (class definition) ( 810 KB)
> the .exe file (1251 KB)
> 
> I'm using gcc 3.2 (mingw32)
> I cannot understand why are they so big in size... I
> think im doing something bad, but I don't know what...
> 
> If I include stdlib.h in any file, it results in a 2
> MB exe.
> I have a lot of programs made with C++ and their
> binaries are smaller than mine, and mi program has
> less than 100 lines. What's wrong?

They don't have debug symbols turned on (in fact, if you're looking at
release stuff, they probably have been run through 'strip' and don't have
any symbols at all except those needed to resolve linkage to DLLs).

Also note that at -O0 (the default, no optimization) binaries are likely to
be larger and slower than at -O1 (quick optimizations, don't slow the build
down too much), -Os (specifically optimize for size), or -O2 (optimize for
speed, most often used). -O0 mode is rather naive in it's code generation,
and is usually either to make the compile go fast or to make the code easy
for a debugger to follow.

> Thanks in advance...
> 
> 
> 
> 
> 
> 
> ___________________________________________________________
> 100mb gratis, Antivirus y Antispam
> Correo Yahoo!, el mejor correo web del mundo
> http://correo.yahoo.com.ar

Re: Reducing the size of the binaries

[Oscar Fuentes]

Juan Ignacio Garzón <jigarzon82-chan@yahoo.com.ar> writes:

[snip]

> the result was:
> a .o file for the main.cpp (803 KB)
> a .o file for the .cpp (class definition) ( 810 KB)
> the .exe file (1251 KB)
>
> I'm using gcc 3.2 (mingw32)
> I cannot understand why are they so big in size... I
> think im doing something bad, but I don't know what...

First: use strip -s yourexecutablename.exe and see if that reduces
size.

Second: MinGW's libstdc++ is statically linked. This means that there
is a fixed size overhead for all executables that uses iostreams, for
instance.

> If I include stdlib.h in any file, it results in a 2
> MB exe.

I doubt that by merely #include'ing <stdlib.h> you obtain a 2 MB
exe. Does this program produces a 2 MB exe?

#include <stdlib.h>

int main() { return 0; }

> I have a lot of programs made with C++ and their
> binaries are smaller than mine, and mi program has
> less than 100 lines. What's wrong?

Those programs compiled with [Visual] C++ uses a dynamically linked
C++ Standard Library. My experience shows that, for medium to large
projects, MinGW and VC++ 6.x executable size tends to converge. VC++
7.x uses some clever tricks that can produce considerably smaller
executables under some common circumstances.

BTW, the correct place for discussing this topic is the MinGW users
mailing list, or other MinGW-related forum. This mailing list is for
discussing the development *of* GCC, not *with* GCC.

-- 
Oscar