PDA

View Full Version : 64kb



Pages : [1] 2

AcerN30
04-30-2008, 08:05 AM
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?

Mario F.
04-30-2008, 08:17 AM
:) Those were the days. Getting PCPro or PCPlus magazines with a 3 1/2-inch floppy disk packed with software! Even prior to that, you could fill a 5.25-inch floppy with heaps of software.

So many factors... programs were simpler, programming languages were limited in features and libraries were simpler and smaller, operating systems were less demanding. The fact hardware systems and the media that carried this software at the time was also very limited in storage and processing capacity also forced programmers to squeeze their code to the best of their abilities.

mike_g
04-30-2008, 08:22 AM
Beacuse they were very small people with small brains that could only fit small code inside their head. Seriously tho, your program can be as bloated as you want to make them. Reasons why modern sofware often takes up more space is down to many reasons. Ultimately storage space is not really an issue on computers nowadays so less time is spent worrying about it. Computers and programs are also way more complex now. Theres nothing stopping you from producing tiny programs in C tho.

AcerN30
04-30-2008, 08:27 AM
Oh, I was actually looking at VB. It isn't like some kind of small text file, with your code and stuff.

Gates once said, 300+KB would be enough for anyone...:rolleyes:

Mario F.
04-30-2008, 08:28 AM
There's a resurge of sorts if you look at mobile phone programming. Very small apps, some bursting with functionality.

cboard_member
04-30-2008, 08:46 AM
There's a resurge of sorts if you look at mobile phone programming. Very small apps, some bursting with functionality.

For the most part could we add hand-held console games to that? In theory more complex than most phone apps I'd imagine but still written within... demanding constraints.

EDIT: Actually I may be a little off-topic. Hmm.

matsp
04-30-2008, 08:55 AM
Oh, I was actually looking at VB. It isn't like some kind of small text file, with your code and stuff.

Gates once said, 300+KB would be enough for anyone...:rolleyes:

Yes, and at that time, it would have taken a senior software engineers yearly salary for several years to buy 1GB of RAM. The original IBM PC with 256KB (or was it 64KB) would set you back the best part of $5000. Of course, there was no hard-disk in that type of machine, that only came with the XT machines. My first PC had 8MB of RAM, and that was plenty to run OS/2 with gcc compiler, emacs and a few other apps with no problem.

--
Mats

brewbuck
04-30-2008, 09:00 AM
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?

Code was less abstract and more "to the metal." It was also necessarily less feature-rich, because features take space. Think about what was available: A disk, with a simple file system on it. A text based screen. A keyboard. Maybe a printer, maybe a modem.

A lot of the code size of today's applications is from layer upon layer of abstraction, which is designed to make the programmer's life easier in exchange for being bigger and slower. If you want to use the features (maybe only a small subset) of some library, you just link with it without giving it a second thought. In other times the design goals were opposite. With so little RAM available the emphasis was on small, tight code.

It's not that we couldn't write small programs today, we just don't bother anymore.

AcerN30
04-30-2008, 09:18 AM
It's not that we couldn't write small programs today, we just don't bother anymore.

Depends what it is.:cool:

matsp
04-30-2008, 09:36 AM
Depends what it is.:cool:

Sure. The reason given above explains what and why makes modern apps several hundred kilobytes (or even megabytes) when the corresponding application in olden days would have been a few kilobytes.

Many different flavours of hardware creates a need for a layer of software-to-hardware translation. Modern systems have more memory so there is no need to strip out and link statically to make sure that the application is small. Writing the code to write "Hello, World" inside a Window in MS Window will require something like (at least) 15-20 lines of rather cryptic code, or 50 lines of less cryptic code. Of course, turning that Hello World program into a bigger application that does some simple word processing will add about the same amount of code as it would to the 4-line console version.

Dealing with graphical UI's [in a nice and modern way] requires graphics resources to be compiled into the application, menu handling, dialog boxes, etc, etc. Where a console application could do that in a few lines of C or Pascal, it now requires a few more lines and a "resource" from a resource-file.

C++ also tends to add to the burden by making many layers of things.

But if needs be, almost all applications can be stripped into something smaller, simpler, and less flabby. At one time, working on a driver, I saved some 30KB [although not noticable in the overall size, it's a large amount in itself] by simply putting "static" in front of a bunch of const initialized data in functions - because the compiler will then only generate the data once, rather than storing the data and generating instructions to copy it into the local variable. Just as one example.

As a summary: Applications are bigger now because they can be, in PC's. If you are targetting an embedded system with 32MB of RAM, then having a single application that takes up 400MB won't work!

--
Mats

AcerN30
04-30-2008, 09:42 AM
Well, could you make a small 2D graphics program, like a bunch of squares. or triangles. One move around, and another animated or AI sort of thing and interact with the shape that is controlled by you? A small program.

matsp
04-30-2008, 09:46 AM
Well, could you make a small 2D graphics program, like a bunch of squares. or triangles. One move around, and another animated or AI sort of thing and interact with the shape that is controlled by you? A small program.

Is this not a different thread?

Yes, I could.

--
Mats

AcerN30
04-30-2008, 09:50 AM
Oh, I ment to say me. I am interested in trying to do something along those lines. A possible shooting game of shapes?

I started another thread elsewhere. In Gaming.

matsp
04-30-2008, 09:51 AM
Oh, I ment to say me. I am interested in trying to do something along those lines. A possible shooting game of shapes?

I started another thread elsewhere. In Gaming.

So let's keep that discussion there.

--
Mats

AcerN30
04-30-2008, 09:53 AM
Right, thank you.

So...Um, could someone please direct me to a C compiler thing? Sorry people, I'm not familiar with the terms.

Um, then I can try writing out the traditional er... code thingi.

cboard_member
04-30-2008, 11:33 AM
MinGW is a good (an excellent, actually) compiler / toolchain and I recommend using it with the Code::Blocks IDE (MinGW comes included).

http://www.codeblocks.org/

robwhit
04-30-2008, 12:21 PM
http://www.cprogramming.com/tools.html

abachler
05-01-2008, 05:08 PM
I still write extremely compact code. The secret - don't use MFC or the STL or any 3rd party libraries if you can help it. It also helped that my first computer only had 2.5k of ram and I have spent years programmign microcontrolelrs and PLC's which dont have a lto fo memory to throw at a problem. An additional benefit of course is that sicne my programs are compact they almost alwasy run entirely in the cahce, so they run much faster than teh competition.

brewbuck
05-01-2008, 05:30 PM
The secret - don't use MFC or the STL or any 3rd party libraries if you can help it.

Care to explain why you think STL leads to code bloat? Have you measured this in realistic situations? Under what compilers and STL libraries did you make those observations?

Doodle77
05-01-2008, 05:38 PM
Care to explain why you think STL leads to code bloat? Have you measured this in realistic situations? Under what compilers and STL libraries did you make those observations?

He means this:

#include <iostream>

int main() {
std::cout << "STL adds bloat. Lots of it.";
return 0;
}
8109
gcc version 3.4.2 (mingw-special)

When you strip it, the size is reduced to 260kb.

SlyMaelstrom
05-01-2008, 05:41 PM
He means this:

#include <iostream>

int main() {
std::cout << "STL adds bloat. Lots of it.";
return 0;
}
8109
gcc version 3.4.2 (mingw-special)

When you strip it, the size is reduced to 260kb.Since when is <iostream> part of the Standard Template Library?

brewbuck
05-01-2008, 05:45 PM
Since when is <iostream> part of the Standard Template Library?

Right, iostreams are part of the standard library, not STL. STL, strictly, is not a library but a set of templates stored in header files.

And secondly, look at a linker map of the resulting executable. I bet you'll find that a lot of that size is taken up by standard runtime support.

Try linking the equivalent C program statically, and see how big that is. Then you'll have something approaching a valid comparison (even though it's still not comparing what I'm talking about, which is the effect of STL on code size)

Doodle77
05-01-2008, 05:55 PM
Right, iostreams are part of the standard library, not STL. STL, strictly, is not a library but a set of templates stored in header files.

And secondly, look at a linker map of the resulting executable. I bet you'll find that a lot of that size is taken up by standard runtime support.

Try linking the equivalent C program statically, and see how big that is. Then you'll have something approaching a valid comparison (even though it's still not comparing what I'm talking about, which is the effect of STL on code size)


#include <vector>
#include <string>

int main() {
std::vector<int> v(10);
for (int i=0;i<10;i++) {
v[i] = i*(i+i^3);
}
reverse(v.begin(), v.end());
std::string q = "omgomgom";
return 0;
}
8110

It's less, but still. 58kb stripped.

#include <stdio.h>

int main() {
puts("C doesn't");
return 0;
}
8111
6kb stripped. I don't know how to link to libstdc statically on windows, sorry.

I don't see how anyone would think STL would result in larger source code size, if that's what you're talking about.

Mario F.
05-01-2008, 06:10 PM
uh? Try instead adding vector and string functionality to that C code snippet before you try to compare oranges to apples again.

Doodle77
05-01-2008, 06:19 PM
uh? Try instead adding vector and string functionality to that C code snippet before you try to compare oranges to apples again.

I'm not trying to say that I could magically implement everything in STL in less space, I'm just saying that the mere use a string or vector in your c++ program adds 52kb of STL code.

mike_g
05-01-2008, 06:21 PM
uh? Try instead adding vector and string functionality to that C code snippet before you try to compare oranges to apples again.
I don't see why that should make much of a difference. stdio is small. Its going to be around the same size compiled with g++.

Mario F.
05-01-2008, 06:24 PM
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.

Doodle77
05-01-2008, 06:26 PM
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.

Compile the C code as C++, and you get exactly the same result.

mike_g
05-01-2008, 06:28 PM
Well then doodle77 could always compile this:

#include <stdio.h>

int main() {
puts("C doesn't");
return 0;
}
as c++, and it would come out around the same size. Which would be a valid comparion. And if compiling with C or C++ is around the same as far as file size goes then that means he was originally making a valid comparison too :P

Mario F.
05-01-2008, 06:29 PM
Ok then. You agree it's not an issue of stladdsbloat.exe against cdoesnt.exe. That's a start.

Now, translate that to real-life code and examples.

brewbuck
05-01-2008, 07:17 PM
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++):



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.

Mario F.
05-01-2008, 07:54 PM
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.

brewbuck
05-01-2008, 08:34 PM
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.

manav
05-01-2008, 11:42 PM
do not divert the original discussion!

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

matsp
05-02-2008, 02:01 AM
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

Mario F.
05-02-2008, 04:14 AM
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

manav
05-02-2008, 06:48 AM
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.


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!

mike_g
05-02-2008, 09:27 AM
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.

brewbuck
05-02-2008, 09:33 AM
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.

abachler
05-02-2008, 10:32 AM
He means this:

#include <iostream>

int main() {
std::cout << "STL adds bloat. Lots of it.";
return 0;
}
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.

AcerN30
05-02-2008, 10:37 AM
Any chance of a 10KB program?:D

SlyMaelstrom
05-02-2008, 10:38 AM
Any chance of a 10KB program?:DWrite 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

AcerN30
05-02-2008, 10:41 AM
This might sound funny, but what exactly is the Assembler?

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

abachler
05-02-2008, 10:47 AM
Any chance of a 10KB program?:D

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.


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.

mike_g
05-02-2008, 11:20 AM
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 (http://pouet.net/prodlist.php?type%5B%5D=4k&platform%5B%5D=Windows&order=&x=16&y=12&page=1&order=). 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.

brewbuck
05-02-2008, 11:36 AM
smallest program I ever wrote was 12 bytes.

That must have been a COM file. Most executable format headers are larger than that.

An effort to create the smallest possible binary that Linux will actually load:

http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

abachler
05-02-2008, 01:00 PM
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 (http://pouet.net/prodlist.php?type&#37;5B%5D=4k&platform%5B%5D=Windows&order=&x=16&y=12&page=1&order=). 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.

I sorta count any loaded libraries in the total, otherwise you could just make the exe do nothing but load a dll that has all the code in it.

And yes, the 12 bytes program was a com.

mike_g
05-02-2008, 01:46 PM
Sure, but if you are calling a system library or one thats very common then for practical purposes its going to take up no extra space.

AcerN30
05-02-2008, 02:50 PM
Does the size affect processor speed?

abachler
05-02-2008, 03:01 PM
It effects how much of the program is in the L1 and L2 cache. There is more to system performance than processor speed. A program than runs entirely in the L1 cache will be twice as fast as one that runs entirely in the L2 cache, which willl be 4-8 times faster than one that has to continously pull data from main memory.