Re: Bits from the FTPMaster meeting

[Goswin von Brederlow <goswin-v-b@web.de>]

Felipe Sateler <fsateler@gmail.com> writes:

> Luk Claes wrote:
>
>> You apparently fail to see that building the packages on mips uncovers
>> bugs that would otherwise be there, but take a longer time to uncover on
>> the 'mainstream' platforms.
>
> This is not generally true. There are are classes of bugs that appear on
> different platforms _due to being different platforms_, not just because

Unless you talk about hand optimized code the first 3 or 4 debian
archs will already have the bug. They might not all show it directly
but it will be there. The remaining archs then just make it more
likely a bug shows early.

> they were latent bugs waiting to be discovered. I presume that packages
> that require as much efficiency as possible (like Charles is implying in
> his packages) are very likely to implement platform-specific
> hacks/optimizations to run faster. It can be considered bad design, ugly
> and whatnot, but it is irrelevant if nobody ever uses other platforms.
>
> Saludos,
> Felipe Sateler

My take on this is that the code should first be written in a high
level form, e.g. generic C code that runs everywhere, and then only
parts that profiling show being worth it should be optimized.

The generic C code has 3 functions:

1) It is usualy much easier to understand and verify.

2) It can be used to compare results against the optimized code.

3) It can be used on archs where optimized code is too much work or
out of your expertise.


So all supporting all the different archs really costs is keeping the
generic C code current. And you should be using it to verify changes
in the optimized code on a continuing basis. Something that helps keep
the quality of the optimized code strong too.

MfG
        Goswin