09-18-2006, 03:06 AM
It was easier to make programs smaller back in the day because you had fewer programmers working on a project. If you had to do some wierd tricks to reduce the size it wasn't to hard to explain it to everybody on the development team. Now that programs are much larger far more developers are involved and its is highly likely that the many of the developers (if not the entire team in some cases) will change during a projects lifetime. Because the projects are so large individual developers cannot hope to understand all of the code in a project anymore. Therefore companies now focus on creating maintainable and well tested code with well defined APIs rather than using clever tricks etc to reduce the amount of memory taken. Additionally, many programs these days are designed to be portable (even if just between multiple versions of the Windows API) making os/arch specific hacks a bad idea.
Of lot of older programs used to take more memory than was available and did their own form of memory management (such as using link overlays) to swap parts of the program in and out while it was running. These days there is no need to do this since modern operating systems provide paged virtual memory.
It is more difficult with modern operating systems to tell the actual size of a program in memory. Windows and Linux for example both show the memory usage of a process as the total memory being used by both the process and any libraries it is dynamically linked with. A single library (such as libc) may be linked with many processes meaning that it there will only be a single copy in memory, but it appears in the size counts for many programs. It is possible on Windows and Linux for the memory usage (working set) totals to exceed the amount of physical memory you have for this reason.
As for the compiler part (my Masters research is in compiler theory) transfering from C++ to C is likely to do more harm than good. Most of the comercial compilers use the same backend for both C and C++ anyway so you would be getting exactly the same optimisations. Compiler optimisation is a highly reasearched (and very difficult) field. Some of the optimisations done by compilers are pretty insane. One of the major problems with compiler optimisations is that many of the algorithms are either NP complete or have very large theoritical complexities meaning that shortcuts and heuristics need to be found if the compilation process is ever going to finish in a realistic amount of time.
Of lot of older programs used to take more memory than was available and did their own form of memory management (such as using link overlays) to swap parts of the program in and out while it was running. These days there is no need to do this since modern operating systems provide paged virtual memory.
It is more difficult with modern operating systems to tell the actual size of a program in memory. Windows and Linux for example both show the memory usage of a process as the total memory being used by both the process and any libraries it is dynamically linked with. A single library (such as libc) may be linked with many processes meaning that it there will only be a single copy in memory, but it appears in the size counts for many programs. It is possible on Windows and Linux for the memory usage (working set) totals to exceed the amount of physical memory you have for this reason.
As for the compiler part (my Masters research is in compiler theory) transfering from C++ to C is likely to do more harm than good. Most of the comercial compilers use the same backend for both C and C++ anyway so you would be getting exactly the same optimisations. Compiler optimisation is a highly reasearched (and very difficult) field. Some of the optimisations done by compilers are pretty insane. One of the major problems with compiler optimisations is that many of the algorithms are either NP complete or have very large theoritical complexities meaning that shortcuts and heuristics need to be found if the compilation process is ever going to finish in a realistic amount of time.
esus saves.... Passes to Moses, shoots, he scores!