Difference in code size between x86 and mips

Discussion in 'C++' started by waxinwaxout, Dec 7, 2007.

  1. waxinwaxout

    waxinwaxout Guest

    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, Dec 7, 2007
    #1
    1. Advertising

  2. 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.
    Matthias Buelow, Dec 7, 2007
    #2
    1. Advertising

  3. waxinwaxout

    waxinwaxout Guest

    On Dec 7, 2:08 pm, Matthias Buelow <> 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, Dec 7, 2007
    #3
  4. 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?
    Matthias Buelow, Dec 7, 2007
    #4
  5. waxinwaxout

    waxinwaxout Guest

    On Dec 7, 4:34 pm, Matthias Buelow <> 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
    waxinwaxout, Dec 7, 2007
    #5
  6. waxinwaxout

    waxinwaxout Guest

    On Dec 7, 5:04 pm, waxinwaxout <> wrote:
    > On Dec 7, 4:34 pm, Matthias Buelow <> 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 help 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
    waxinwaxout, Dec 7, 2007
    #6
  7. waxinwaxout

    peter koch Guest

    On 7 Dec., 18:10, waxinwaxout <> wrote:
    > On Dec 7, 5:04 pm, waxinwaxout <> wrote:
    >
    >
    >
    >
    >
    > > On Dec 7, 4:34 pm, Matthias Buelow <> 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 help 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
    peter koch, Dec 7, 2007
    #7
  8. waxinwaxout

    waxinwaxout Guest

    On Dec 7, 6:45 pm, peter koch <> wrote:
    > On 7 Dec., 18:10, waxinwaxout <> wrote:
    >
    >
    >
    > > On Dec 7, 5:04 pm, waxinwaxout <> wrote:

    >
    > > > On Dec 7, 4:34 pm, Matthias Buelow <> 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 help 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
    waxinwaxout, Dec 7, 2007
    #8
  9. waxinwaxout wrote:

    > 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.


    All MIPS instructions are uniformly 32 bits wide (on a 32-bit MIPS) as
    is typical for RISC cpus, while x86 instruction size may vary from 1
    byte to potentially unlimited (I think you can add as many redundant
    prefixes as you like).
    Matthias Buelow, Dec 10, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jakk
    Replies:
    4
    Views:
    11,982
  2. keithb
    Replies:
    1
    Views:
    882
    Bruce Barker
    Mar 29, 2006
  3. Andreas Weichert
    Replies:
    1
    Views:
    747
    Peter van Merkerk
    Nov 25, 2003
  4. c code -> mips code

    , May 14, 2008, in forum: C Programming
    Replies:
    1
    Views:
    1,082
    user923005
    May 14, 2008
  5. cybose
    Replies:
    2
    Views:
    83
    smallpond
    Dec 18, 2007
Loading...

Share This Page