I'm compiling the same set of c++ sources to both x86 (32 & 64) and to
mips32. For x86 I'm using gcc 4.1.2 and for mips I'm using gcc 3.4.6.

What I don't understand is why the mips binaries are consistently (and
significantly) larger than the x86 binaries.

Compiling to x86 without any selected optimization level results in a
binary of 961600 bytes while compiling to mips32 with -Os results in a
binary of 1414612 bytes. Both binaries have been stripped.

I don't understand why the mips32 binary is so much larger than x86.
They both come from the same sources. They both link against the same
libraries. Only the compiler version (and corresponding lib(c|c++))
are different. The mips32 build even has a more favourable switch (-
Os) than the x86 build, but the x86 build is still more than 30%
smaller than the mips32 binary.

Is there such a significant difference in (size) optimization between
gcc 3.4.6 and gcc 4.1.2, or is this difference between x86 and mips32
binaries 'normal' or is there another explanation?

Thanks,

Miyagi

waxinwaxout wrote:

> Is there such a significant difference in (size) optimization between
> gcc 3.4.6 and gcc 4.1.2, or is this difference between x86 and mips32
> binaries 'normal' or is there another explanation?

RISC (MIPS) vs. CISC (x86), probably (depending on the MIPS model) also
64bit vs. 32bit. You might read up on these topics on Wikipedia.

On Dec 7, 2:08 pm, Matthias Buelow <m...@incubus.de> wrote:
> waxinwaxout wrote:
> > Is there such a significant difference in (size) optimization between
> > gcc 3.4.6 and gcc 4.1.2, or is this difference between x86 and mips32
> > binaries 'normal' or is there another explanation?
>
> RISC (MIPS) vs. CISC (x86), probably (depending on the MIPS model) also
> 64bit vs. 32bit. You might read up on these topics on Wikipedia.

The x86 binary (961600 bytes) is 64 bits.
The mips32 binary (1414612 bytes) is 32bits.

I can understand there's a difference between RISC and CISC code (more
RISC instructions for the equivalent operation on a CISC
architecture). I can't understand that this difference is this large.
I was hoping this was due to compiler differences or I'm missing some
(not so) obvious optimization switch. Or maybe the linker is somewhat
different for MIPS.

Maybe I should be counting assembler instructions.

Thanks,

Miyagi

waxinwaxout wrote:

> I can understand there's a difference between RISC and CISC code (more
> RISC instructions for the equivalent operation on a CISC
> architecture). I can't understand that this difference is this large.
> I was hoping this was due to compiler differences or I'm missing some
> (not so) obvious optimization switch. Or maybe the linker is somewhat
> different for MIPS.

I don't consider it that large. You obviously haven't seen Alpha AXP
code. Does it really matter?

On Dec 7, 4:34 pm, Matthias Buelow <m...@incubus.de> wrote:
> waxinwaxout wrote:
> > I can understand there's a difference between RISC and CISC code (more
> > RISC instructions for the equivalent operation on a CISC
> > architecture). I can't understand that this difference is this large.
> > I was hoping this was due to compiler differences or I'm missing some
> > (not so) obvious optimization switch. Or maybe the linker is somewhat
> > different for MIPS.
>
> I don't consider it that large. You obviously haven't seen Alpha AXP
> code. Does it really matter?

3.5 HD floppy size for a binary matters a lot for embedded devices
with limited storage space.

WRT Alpha AXP, you've made me curious !

I'm currently rebuilding my toolchain without math support. I think
this previously had included emulated floating point code which could
explain the difference as the x86 has hardware floating point support
while the particular mips cpu I'm using doesn't.

Thanks,

Miyagi

On Dec 7, 5:04 pm, waxinwaxout <waxinwax...@hotmail.com> wrote:
> On Dec 7, 4:34 pm, Matthias Buelow <m...@incubus.de> wrote:
>
> > waxinwaxout wrote:
> > > I can understand there's a difference between RISC and CISC code (more
> > > RISC instructions for the equivalent operation on a CISC
> > > architecture). I can't understand that this difference is this large.
> > > I was hoping this was due to compiler differences or I'm missing some
> > > (not so) obvious optimization switch. Or maybe the linker is somewhat
> > > different for MIPS.
>
> > I don't consider it that large. You obviously haven't seen Alpha AXP
> > code. Does it really matter?
>
> 3.5 HD floppy size for a binary matters a lot for embedded devices
> with limited storage space.
>
> WRT Alpha AXP, you've made me curious !
>
> I'm currently rebuilding my toolchain without math support.

Didn't at all. The mips binaries are still large.

objdump -D <binary>

produces 351466 lines for the (-Os) mips binary and 275415 lines for
the (unoptimized) x86 binary. Both binaries were stripped.

This means (poor man's calculation approaching):
961600/275415 = 3.49 bytes per instruction for x86 and
1414612/351466 = 4.02 bytes per instruction for mips, give or take
some garnish produced by objdump. Note this is really weak calculation
as the binary sizes includes non-instructions as well. But the x86
hasn't even eliminated duplicate strings which the mips build is
doing, and still there's this big/huge difference between the two
which I can't ascribe to CISC-RISC differences.

Are the mips instructions larger than the x86 instructions? Seems like
something else is going on. What is it?

Thanks,

Miyagi

On 7 Dec., 18:10, waxinwaxout <waxinwax...@hotmail.com> wrote:
> On Dec 7, 5:04 pm, waxinwaxout <waxinwax...@hotmail.com> wrote:
>
>
>
>
>
> > On Dec 7, 4:34 pm, Matthias Buelow <m...@incubus.de> wrote:
>
> > > waxinwaxout wrote:
> > > > I can understand there's a difference between RISC and CISC code (more
> > > > RISC instructions for the equivalent operation on a CISC
> > > > architecture). I can't understand that this difference is this large.
> > > > I was hoping this was due to compiler differences or I'm missing some
> > > > (not so) obvious optimization switch. Or maybe the linker is somewhat
> > > > different for MIPS.
>
> > > I don't consider it that large. You obviously haven't seen Alpha AXP
> > > code. Does it really matter?
>
> > 3.5 HD floppy size for a binary matters a lot for embedded devices
> > with limited storage space.
>
> > WRT Alpha AXP, you've made me curious !
>
> > I'm currently rebuilding my toolchain without math support.
>
> Didn't at all. The mips binaries are still large.
>
> objdump -D <binary>
>
> produces 351466 lines for the (-Os) mips binary and 275415 lines for
> the (unoptimized) x86 binary. Both binaries were stripped.
>
> This means (poor man's calculation approaching):
> 961600/275415 = 3.49 bytes per instruction for x86 and
> 1414612/351466 = 4.02 bytes per instruction for mips, give or take
> some garnish produced by objdump. Note this is really weak calculation
> as the binary sizes includes non-instructions as well. But the x86
> hasn't even eliminated duplicate strings which the mips build is
> doing, and still there's this big/huge difference between the two
> which I can't ascribe to CISC-RISC differences.
>
> Are the mips instructions larger than the x86 instructions? Seems like
> something else is going on. What is it?
>
> Thanks,
>
> Miyagi

While I can understand your interest in the size of the binary, I
really can't understand why you want to bring it up in this newsgroup:
it is off-topic. ;-)
What I would recommand you to do is to look at the assembly code for
some representative function of yours. See if the result is
implemented in an inefficient way and compare the inefficiency with
that of the other compiler. If the code generated by the mips compiler
is to bad, it is time to read the compilers documentation (if you
haven't done so already!) and perhaps look at other suppliers of
compilers for that platform if you can't live with the overhead and
can't get the compiler to produce higher quality code.

/Peter

On Dec 7, 6:45 pm, peter koch <peter.koch.lar...@gmail.com> wrote:
> On 7 Dec., 18:10, waxinwaxout <waxinwax...@hotmail.com> wrote:
>
>
>
> > On Dec 7, 5:04 pm, waxinwaxout <waxinwax...@hotmail.com> wrote:
>
> > > On Dec 7, 4:34 pm, Matthias Buelow <m...@incubus.de> wrote:
>
> > > > waxinwaxout wrote:
> > > > > I can understand there's a difference between RISC and CISC code (more
> > > > > RISC instructions for the equivalent operation on a CISC
> > > > > architecture). I can't understand that this difference is this large.
> > > > > I was hoping this was due to compiler differences or I'm missing some
> > > > > (not so) obvious optimization switch. Or maybe the linker is somewhat
> > > > > different for MIPS.
>
> > > > I don't consider it that large. You obviously haven't seen Alpha AXP
> > > > code. Does it really matter?
>
> > > 3.5 HD floppy size for a binary matters a lot for embedded devices
> > > with limited storage space.
>
> > > WRT Alpha AXP, you've made me curious !
>
> > > I'm currently rebuilding my toolchain without math support.
>
> > Didn't at all. The mips binaries are still large.
>
> > objdump -D <binary>
>
> > produces 351466 lines for the (-Os) mips binary and 275415 lines for
> > the (unoptimized) x86 binary. Both binaries were stripped.
>
> > This means (poor man's calculation approaching):
> > 961600/275415 = 3.49 bytes per instruction for x86 and
> > 1414612/351466 = 4.02 bytes per instruction for mips, give or take
> > some garnish produced by objdump. Note this is really weak calculation
> > as the binary sizes includes non-instructions as well. But the x86
> > hasn't even eliminated duplicate strings which the mips build is
> > doing, and still there's this big/huge difference between the two
> > which I can't ascribe to CISC-RISC differences.
>
> > Are the mips instructions larger than the x86 instructions? Seems like
> > something else is going on. What is it?
>
> > Thanks,
>
> > Miyagi
>
> While I can understand your interest in the size of the binary, I
> really can't understand why you want to bring it up in this newsgroup:
> it is off-topic. ;-)
> What I would recommand you to do is to look at the assembly code for
> some representative function of yours. See if the result is
> implemented in an inefficient way and compare the inefficiency with
> that of the other compiler. If the code generated by the mips compiler
> is to bad, it is time to read the compilers documentation (if you
> haven't done so already!) and perhaps look at other suppliers of
> compilers for that platform if you can't live with the overhead and
> can't get the compiler to produce higher quality code.

Comparing the assembly code is not straightforward. There's (at least)
two different instruction sets. What's inefficient can really only be
empirically determined if one can generate various forms of assembly
all producing the same output (given equal input). Unless there's some
extremely obvious inefficiency, this is somewhat overkill although I
appreciate the suggestion.

Apparently some people get smaller code when not using -Os while using
other immediate/direct compiler optimization switches, but it differs
per source.

I had hoped that someone would have pointed out some major change
between 3.4.6 and 4.1.2, or some (unobvious) compiler switch.

Looking for a gcc group,

thanks,

Miyagi


>
> /Peter