10 Jun
2013
10 Jun
'13
11:34 a.m.
On Jun 10, 2013, at 1:18 PM, Tothwolf <tothwolf at concentric.net> wrote:
As for disk space, a lot of that is due to the
distribution maintainers. Software packages today are not compiled to be space/memory/CPU
efficient, but rather to work on the largest subset of what the package maintainers
/personally/ consider to be "modern" CPUs (which right now, are multi-core AMD
and Intel CPUs). Those packages eat up a lot more disk space (and often memory) and it is
now the norm for most distributions to build everything with debugging symbols. The
thinking is that debug symbols somehow help debug large programs that crash, however it
really hurts the performance of most software, and is very very silly for basic UNIX-like
command line utilities.
In what sense does it hurt performance? I didn't think the symbols got
loaded into RAM unless you were actually opening something up under GDB
or something that needed to read the symbol table. Or are you talking
about startup performance when the symbol table is used to bind the
dynamic libs?
I'm slowing coming to the opinion that a first
year C developer should be /forced/ to develop on a CPU and memory constrained platform,
such as a 386 with 4-8MB of memory vs a modern multi-core CPU with multiple gigabytes of
memory, so that they will learn first hand how to write more efficient C code. I wonder
how many of the current userspace developers and package maintainers have ever even
touched a 386 based machine, let alone something even more resource limited?
Or a reasonably-sized embedded ARM SBC, which are a little easier to
come by these days. I'm specifically talking about something like an
ARM7/9 that can run Linux, but an example with an MMU-less embedded OS
would work as well, provided that it's self-hosting; there are also
plenty of developers who would do well to slim down their compile times
as well, so being required to compile on the same machine you run your
code on is a decent requirement as well (if not always reflective of
reality).
That, and small 8-bits, especially the PIC (which, as much as I dislike
it as a CPU, is a great example because of its rather parsimonious
instruction set and resource allotment). It REALLY emphasizes the
difference between C and assembly for embedded work that so many just
don't get (one of our customers asked us to do an AES engine on a PIC
in BASIC, no joke).
- Dave