[PATCH] ipsum_calc_block: Optimize size and speed

Joakim Tjernlund joakim.tjernlund at transmode.se
Fri Apr 23 19:01:48 CEST 2010


Ondrej Filip <feela at network.cz> wrote on 2010/04/23 18:41:57:
>
> On 23.4.2010 18:32, Ondrej Zajicek wrote:
> > On Fri, Apr 23, 2010 at 03:20:55PM +0200, Martin Mares wrote:
> >> Hello!
> >>
> >>> Fairly, I once had the same idea for Quagga but found all those extra tests and
> >>> additions were much slower(I benched it). Just look at the number of extra ops one
> >>> has to do in the current code.
> >>> If you want to do it faster you have to go ASM. It would be easy to
> >>> add support for that too but it can wait.
> >>
> >> My primary reaction was "If something isn't broken, don't fix it." I.e.,
> >> unless you have good reasons for rewriting a piece of code, don't do that.
> >>
> >> Your version is more readable and I would be in favour of accepting it,
> >> but I would still like to see at least a very simple benchmark which shows
> >> that it is not significantly slower.
> >
> > I was curious enough to do some benchmarks and got these results:
> >
> > Intel Atom:   suggested code ~ 1.2* faster
> > AMD Geode:   no diference
> > MIPS ADM5120:   old code ~ 1.2* faster
> >
> > So there isn't really difference in performance of both
> > implementations. Even on slow embedded AMD Geode CPU, it gives
> > ~ 180 MB/s.

No difference? what does 1.2 mean? to me this means 20% which is a lot

>
> Hmm, so there is no major reason for change. I would really support
> dont-fix-whats-not-broken approach. And also we should keep different

So it is smaller, faster and easier to read and you still
want to keep the old code? Very non Open source like I
must say.

> code from Quagga to have heterogeneity.

What kind of argument is that?
Sorry, but this all feels like NIH syndrome.

>
>          Ondrej





More information about the Bird-users mailing list