64kb

This is a discussion on 64kb within the A Brief History of Cprogramming.com forums, part of the Community Boards category; Originally Posted by Mario F. The issue is not between C and C++ code. Lets not get into that endless ...

  1. #31
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by Mario F. View Post
    The issue is not between C and C++ code. Lets not get into that endless discussion. Is about using STL and not using STL. C doesn't have STL. so, don't use it has a means for comparison.
    The comparison between C and C++ equivalents of the same task is very relevant, because there is a lot of shared runtime between C and C++. In other words:

    code_size(C) = implementation(C) + runtime;
    code_size(C++) = implementation(C++) + runtime;

    In order to figure out how big "runtime" is, you have to try it both ways. Once you have this figure, you have to subtract it out, before making any statements about the code size induced by STL.

    Try linking this statically (it's C, not C++):

    Code:
    int main()
    {
        printf("Hello, world!\n");
        return 0;
    }
    On my system, the resulting binary is over 500k in size. So just because the C++ version is large doesn't necessarily mean anything at all. C can be bloated, too. The problem is not the language itself, but the toolchain.

  2. #32
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,436
    Excellent brewbuck. But only as a means to an end.

    The original argument was about not using the STL to produce smaller code. Which basically means the option to use STL is there.

    As such, C is irrelevant to this discussion in the way it was being presented. Particularly the whole STL-Bloats-Code versus C-Doesn't.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  3. #33
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by Mario F. View Post
    As such, C is irrelevant to this discussion in the way it was being presented. Particularly the whole STL-Bloats-Code versus C-Doesn't.
    I'm using C as a means of discovering the value of a particular variable in the equation. I am not at all trying to compare C vs. C++.

    My point is that you cannot use the size of a statically linked binary as proof that STL produces code bloat, when a simple C program that prints "Hello world" is also linking statically to 500k. By that logic, basic C is bloated, and I hope everybody would agree that that's untrue.

    It indicates something about static linking, and the complexity of modern runtime libraries, it says nothing about the code size of STL.

  4. #34
    Banned
    Join Date
    Nov 2007
    Posts
    678
    do not divert the original discussion!

    Earlier softwares were smaller, simply because they had less features, were less powerful.

  5. #35
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by manav View Post
    do not divert the original discussion!

    Earlier softwares were smaller, simply because they had less features, were less powerful.
    And because they had to support less hardware variants - perhaps you had to do the "if (colourDisplay) base = mkptr(0xA000, 0x0000); else base = mkptr(0xB800, 0x0000)", but that's about it when it came to "support variations of hardware".

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #36
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,436
    Quote Originally Posted by manav View Post
    do not divert the original discussion!

    Earlier softwares were smaller, simply because they had less features, were less powerful.
    The original discussion is still being... discussed. Abachler argument and the discussion that followed was pertinent. Your own answer adds nothing new as what you said is only repetition of what has been said before.

    I'm using C as a means of discovering the value of a particular variable in the equation. I am not at all trying to compare C vs. C++.
    I understood that brewbuck. And I appreciated your thoughts on that. It was what was being said before that made my ears perk; that is, the not so subtle innuendo behind stladdsbloat.exe and cdoesnt.exe
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  7. #37
    Banned
    Join Date
    Nov 2007
    Posts
    678
    Quote Originally Posted by OP
    Can someone tell me why on very old timers computers ha, a programmer could write up some code and it would be so small compared today. 500kb?
    Because old time softwares were having less features and were less powerful!

    That was the correct answer, so, if I repeated or not, matters less.

    Quote Originally Posted by Mario F. View Post
    The original discussion is still being... discussed. Abachler argument and the discussion that followed was pertinent. Your own answer adds nothing new as what you said is only repetition of what has been said before.
    But later discussions try to prove, if new software is pure bloat or not! If C is better or C++? Who is doing more bloat?

    By the way no body is forcing to use boost library just to use a to upper case function, you can build your own. Older days it was done like 'a' ^= 32.
    But now, with all the unicode and other stuff, makes it bigger, yet better and more powerful.

    That's the basic difference between old and new!

  8. #38
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218
    By the way no body is forcing to use boost library just to use a to upper case function, you can build your own. Older days it was done like 'a' ^= 32
    Actually that will switch the case; nt convert to upper case. it will also only work on ASCII encoding, on an encoding that uses the 32 bit to signify the case.

  9. #39
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by manav View Post
    But later discussions try to prove, if new software is pure bloat or not! If C is better or C++? Who is doing more bloat?
    No, that's not what was being discussed. The comparison with C was for the purposes of factoring out "common bloat" inherent to ALL compiled programs, not just C++.

    If you went to a country where every citizen weighed over 500 pounds, it would be weird to point at a particular person and say "That guy's fat!" They're ALL fat.

    A better gauge of code size is the size of the object files, not the final, linked binary. You can't blame the runtime for introducing a ton of code when you choose to link statically -- that's why people don't link statically anymore.

  10. #40
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by Doodle77 View Post
    He means this:
    Code:
    #include <iostream>
     
    int main() {
      std::cout << "STL adds bloat. Lots of it.";
      return 0;
    }
    Attachment 8109
    gcc version 3.4.2 (mingw-special)

    When you strip it, the size is reduced to 260kb.
    I mean when I write 3000 lines of code it compiles to 150kb. I know a lot of my preferences and suggestions cause a lot of eye rolling, but I get the results and the performance. So what if it takes me 3 weeks to impliment something another programmer can do in 2 days, my code runs 10 times faster than hers and makes some projects feasable that otherwise wouldnt be. You use cout, bam code bloat, because the lib just impliments cout using printf. You use string instead of BYTE*, bam code bloat, because the compiler adds all the functions that you dont use. You use MFC, bam code bloat because etc etc etc. Each little thing might only add 20kb here and there, but it adds up.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  11. #41
    Registered User AcerN30's Avatar
    Join Date
    Apr 2008
    Location
    England
    Posts
    32

    Talking

    Any chance of a 10KB program?

  12. #42
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,069
    Quote Originally Posted by AcerN30 View Post
    Any chance of a 10KB program?
    Write something in assembler?

    It's also worth it to mention that 64Kb (kilobit) is smaller than 10KB (kilobyte). Watch your cases.

    This has been mentioned before, but to give you an idea of how small modern programs can get... here is a 98KB 3D FPS that is completely procedural.

    http://www.vgpro.com/file/18896_kkrieger-beta.zip.html

    I mention this also because I love this 2006 quote.
    Needs high end user PC to play. Minimum specs are: 128MB graphics Card with pixel shader 1.3, 512MB ram, and Athlon 1.5Ghz
    Last edited by SlyMaelstrom; 05-02-2008 at 10:43 AM.
    Sent from my iPad®

  13. #43
    Registered User AcerN30's Avatar
    Join Date
    Apr 2008
    Location
    England
    Posts
    32
    This might sound funny, but what exactly is the Assembler?

    I was thinking a very basic game with no levels or something like that.

  14. #44
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by AcerN30 View Post
    Any chance of a 10KB program?
    smallest program I ever wrote was 12 bytes. It changed the file attributes on a file using a dos INT21h call. It even had keyboard input to select the attribute mask.

    Quote Originally Posted by AcerN30 View Post
    This might sound funny, but what exactly is the Assembler?
    I was thinking a very basic game with no levels or something like that.
    Assembly language tool used to write directly in assembly and/or compile assembly. VS includes an inline assembler. Lets you write directly in processor dependant mnemonics. Requires low level knowledge of the processor itself.
    Last edited by abachler; 05-02-2008 at 10:51 AM.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  15. #45
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218
    You dont have to use assembler to create programs < 10k if you dynamically link your libraries like brewbuck said. Theres a load of 4k graphics progs here. Quite a few are done in C. ASM can go really small, some of the 256 byte stuff on there is really impressive. Stuff that drops below that, well, generally cant do much really.

Page 3 of 4 FirstFirst 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. "far"?
    By SgtMuffles in forum C Programming
    Replies: 7
    Last Post: 04-05-2005, 07:08 AM
  2. INI 64kb limit
    By iniguy in forum Windows Programming
    Replies: 1
    Last Post: 02-05-2002, 03:52 PM
  3. Replies: 2
    Last Post: 01-27-2002, 09:40 AM
  4. Memory allocation greater than 64KB in TC 3.0
    By Unregistered in forum C Programming
    Replies: 0
    Last Post: 01-27-2002, 09:28 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21