This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Change to search_n
- From: Dimitris Xochellis <jimxoch at yahoo dot gr>
- To: Paolo Carlini <pcarlini at suse dot de>
- Cc: Chris Jefferson <caj at cs dot york dot ac dot uk>, libstdc++ at gcc dot gnu dot org
- Date: Tue, 22 Feb 2005 20:44:39 +0000 (GMT)
- Subject: Re: Change to search_n
Hi Paolo, hi list,
> >I would recommend to first concentrate on improving
> >the "generic" performance of your core algorithm
> and
> >test it intensively. Then test it again with a
> variety
> >of iterators, a variety data types and a variety of
> >data distributions. Compare it a lot with my
> >implementation. You can download my performance
> tests
> >from CodeProject and use them to compare the two
> >algorithms.
> >
> >After ensuring that your core algorithm is at least
> as
> >fast as mine (there is no sense in re-implementing
> a
> >slower version of a piece of free code that already
> >exists!) then (and only then) is the time to worry
> >about backward prefetchers in "exotic" targets and
> do
> >specializations for N=2, N=3, N=4 etc. In my
> opinion,
> >it is essential that you first work a lot more with
> >your generic/core algorithm.
> >
> >
> Thanks Dimitri for your interesting feedback.
>
> I feel compelled to point out two things:
> 1- Personally, as a maintainer of libstdc++-v3, I
> have nothing against you and Chris merging and
> submitting your work together. Nobody decided
> that Chris implementation was better than yours, or
> something like that. Simply, you did *not* show up
on
> the list, whereas Chris did! Is this clear?
It's clear and fair. No problem :) You misunderstood
me here I am afraid! Of course, there is nothing wrong
with Chris (or anyone) committing his search_n
implementation in your library. Furthermore there is
nothing wrong with Cris (or anyone) committing my
search_n implementation (or part of it) in any
library. My code is free for anyone to use it as he
like.
The fact that I am comparing a lot your implementation
with mine was (IMHO) the sensible thing to do. In most
IT articles/papers the authors frequently compare
their implementations to prior ones. The only prior
implementation of search_n that makes sense to compare
it with yours is mine. All other implementations I am
aware of are too slow! Personally I believe that
studying other implementations (including mine) and
making performance comparisons is the right way to go,
if you want to improve the runtime performance.
I am only trying to help here! And my comments is the
only way I can help. (As long as you thing that my
comments are helpful.) Commiting my implementation was
out of the question anyway, since I have only recently
started using gcc and I am still learning the basics
:) Besides, I am already in the process of committing
my own search_n implementation in the STLPort library.
> Why don't you file a Copyright Assignment and
> start contributing first person to the project, I
> wonder?!?
I don't understand that, my code is already free for
you or anyone to use it. It's license is the same to
the license that HP-STL and SGI-STL are using. What is
that Copyright Assignment?
> 2- About "backward prefetchers" and all that, those
> are concerns which
> are generally valid - that is, both for your and
> Chris implementations,
> of course - and *in principle* are critical
> concerns, that *in
> principle* can fundamentally undermine the relevance
> of this entire
> class of algorithms for a portable implementation.
I have read again my last sentence and I have to admit
that it is not written properly. I am realy sorry, its
my fault.
Yes I agree that backward prefetchers can be critical
concerns. I am only trying to say that it could be
beneficial to first concentrate on solving generic
performance problems and then deal with more
specialized ones. It is just the way I work.
Furthermore, in case you find that my implementation
has better "generic" performance it makes more sense
to use it as a starting point and then add your
specializations or any other improvements you like. If
I discover that your implementation has better
"generic" performance than mine I will use it for
sure. It's rational enough I believe :)
Best Regards,
Jim Xochellis
____________________________________________________________
Do You Yahoo!?
Αποκτήστε τη δωρεάν @yahoo.gr διεύθυνση σας στο http://www.otenet.gr