Re: [dev] Detaolb

On May 23, 2009, at 4:58 PM, Matthias-Christian Ott <ott_AT_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."
>>
>>
>>
>
Received on Sat May 23 2009 - 18:19:01 UTC