[petsc-dev] This has officially become too ugly to read

[Barry Smith]

On Jan 20, 2012, at 4:51 PM, Matthew Knepley wrote:

> On Fri, Jan 20, 2012 at 4:45 PM, Paul Mullowney <paulm at txcorp.com> wrote:
> The new code using CUSPARSE gives you triangular solves that are supported by Nvidia. They are as fast as what was in their previously. Advantage is that it's now fully supported by the vendor library. 
> 
> The matrix multiplication is more succinct than what was in petsc-dev. Plus it has options for choosing storage format on the device for optimal performance.
> You now have csr/coo/ell/dia formats ... Plus the SpMV scales across multiple GPUs now.
> 
> I am happy to remove printf's if that helps.
> 
> Although, I care in the abstract about how code looks, I don't have enough time to complain about it. I care in this case,
> because it does not appear to be supportable by us. If this is not true, and someone understands all this, please say so.
> Then I will go back to not caring.

   It may easily be that some refactoring is in order. For example the PETSc style would not have one function that handles conversion to several different matrix formats on the GPU. Rather each conversion would have its own (simple) function which is simplier to understand and maintain and extend.  Paul is new to PETSc development and doesn't understand all our quirks. 

    But Matt does bring up an extremely important point; PETSc code must be clean enough and simple enough to allow any member of the team to maintain it.  If the code requires the author only to make changes to it then the code cannot be allowed.

   Barry

> 
>     Matt
>  
> 
> -Paul
> 
> 
> 
>> On Fri, Jan 20, 2012 at 4:37 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>> 
>> On Jan 20, 2012, at 4:31 PM, Matthew Knepley wrote:
>> 
>> > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/2a4f352daf49
>> >
>> > What is going on here, and why can't it be done more succintly?
>> 
>>   Hell its GPUs, what do you expect?
>> 
>>   What particularly part do you feel is overly complex and could be more succintly?
>> 
>> This checkin of fixes is larger than the entire prior implementation. Why, what is better?
>> 
>> There are a ton of new functions with obscure names (unless Some has a meaning which
>> escapes me).
>> 
>> There seem to be a huge number of cases treated in enormous functions rather than
>> factoring them out.
>> 
>>    Matt
>>  
>> 
>>   Barry
>> 
>> 
>> >
>> >     Matt
>> >
>> > --
>> > What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
>> > -- Norbert Wiener
>> 
>> 
>> 
>> 
>> -- 
>> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
>> -- Norbert Wiener
> 
> 
> 
> 
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener