This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]