On Tue, May 31, 2016 at 3:31 AM, Gilles <gil...@harfang.homelinux.org> wrote:
> On Tue, 31 May 2016 03:10:20 +0300, Artem Barger wrote: > >> >>> >>>>> Yes, you can parallelize it, though it will cancel several >>>>> optimizations >>>>> >>>> I've added. >>>> In fact you can partition the input according to number of threads you'd >>>> like to use >>>> and make each thread to take care of relevant data chunk. >>>> >>>> I guess it will increase performance, not sure why current >>>> implementation >>>> wasn't >>>> parallelized. >>>> >>>> >>>> You are most welcome to enhance it. ;-) >>> >>> >> Well, already did it ;-) >> And if you mean to parallelize my current implementation for Elkan >> algorithm, >> I think that it should be handled as a separate task. >> >> > What I mean is that algorithms that can perform their computation > on multiple threads should be implemented in such a way that the > feature can be used. > > Of course, that means a more complex code, to ensure thread-safety. > So, for sure, your code could be added now (modulo the remarks) > if you don't want to handle that now.v And as you pointed out the > other implementations are not multi-thread either. > > But it's a direction worth exploring I think. I totally agree w/ you, simply suggesting to go incremental, first to have work done on all comments provided, then having it committed and accepted I can multi-threaded support either. Also I think that multi-threading support might impose some API changes and should be added carefully :)))
