On May 23, 2009, at 4:58 PM, Matthias-Christian Ott <o...@mirix.org>
wrote:
On Sat, May 23, 2009 at 07:01:55AM -0400, Kris Maglione wrote:
On Sat, May 23, 2009 at 12:28:47PM +0200, Matthias-Christian Ott
wrote:
On Sat, May 23, 2009 at 11:17:18AM +0200, pancake wrote:
http://detaolb.sourceforge.net/
Just my first time I see this minimal devel distro :)
uClibc is by no means minimal, even though it's smaller than glibc.
In my opinion a minimal system has all libraries in source code form
and statically links and compiles them with the programme's source
code
(much like templates in C++). You can do a lot of optimisations
using
this approach (constant propagation and dead code elimination,
inlining
etc.), the programmes can be sequentially read from disk and will be
much smaller.
I don't know why I'm getting into this. I can't help but suspect that
this is troll bait, but I don't know what goes on on this list.
What you
just said makes no sense to me. None of that has anything to do with
minimalism. Efficiency, maybe. Disk efficiency, certainly not.
There are
reasons that most embedded systems dynamically link everything: it
saves
disk space. And, as for the read speed, dynamically linked libs are
Even flash disks are pretty cheap these days. Moreover, many
statically
linked programmes are often smaller (see dietlibc).
mmaped (on most systems, anyway) and shared between processes, which
means, of course, that they're read into memory once. Statically
linked
binaries certainly might be read faster. They might not. It depends
on
too many variables to make blanked statements.
Dynamically linked programmes have some relocation overhead. I don't
know
the actual performance decrease but it should be some percent (however
modern processor are optimised for this, so no comparison would be
fair).
It's 1% of overhead on x86-32.
On 64bit x86 or arm I have not tested, but should be less because
those archs have extra regs used as global pointers (like the MIPS GP
register)
The problem of this is the PIC code, which is IMHO a hacky solution
for relicstable code. But it's a more secure than the w32 solution.
Which consists in onmemory patching of relocating code following the
rules of the reloc section.
I have managed to write Pocs of different ways to optimize this at my
work, but the problem is that integrating these things in a compiler
makes the optimisations harder to manage and it's better to optimize
it later.
The problem is that gcc optimizations are not magical. I look forward
projects like diablo or llvm.
Well, at any rate, I've just reread your post, and realized that that
kind of nonsensical tripe (strewn with unconnected buzz words)
can't be
anything but troll bait. Nevertheless, I've gone to all the trouble
of
composing this rant, so I may as well send it.
It was meant serious.
--
Kris Maglione
And the users exclaimed with a laugh and a taunt: "It's just what we
asked for but not what we want."
