Hi Gilles,
2013/1/1 Gilles Sadowski <gil...@harfang.homelinux.org> > Hi. > > > > If we stick to > > > > > > 0) algebraic objects are immutable > > > 1) algorithms defined using algebraic concepts should be implemented > > > using algebraic objects > > > > > > ... > > > 0) Start, with Konstantin's help, by fleshing out the InPlace > > > matrix / vector interface > > > 1) Integrate Mahout code as part of a wholesale refactoring of the > > > linear package > > What do you mean by this? > Copy/paste or create a dependency? Something else? > > > > 2) Extend use of the visitor pattern to perform mutations > > > "in-place" (similar to 0) in effect) > > > > > As suggested in a previous post: > > 3) a) Define a new "minimal matrix" interface, and create immutable > implementations. > b) Benchmark critical methods (entry access, iteration, add, multiply, > etc.) > c) Quantify the efficiency gain of in-place operations and only when > this > information is available decide whether the gain is worth the price. > [Even if in-place operations are faster in a single thread context, > it > is not sure that immutability would not change that in a multi-thread > implementation. Trying to outperform multi-threaded code with > in-place > operations is a dead end.] > > Please mention that when I first mentioned in-place operations, I didn't have speed in mind, but really memory. I think we would not gain much speedwise, as Java has become very good at allocating objects (this would be true of large problems, where typically a few big objects would be allocated at each iteration. The conclusion would probably be different with many small objects to be allocated at each iteration). > Before embarking on any of this, please identify the rationale: Is there > _one_ identified problem that would require urgent action? This discussion > about clean-up/improvement/simplification of the CM matrix implementations > has been going on for months, and we should not start a "new" discussion > without referring to what has been recorded by Sébastien on JIRA. > > I agree with you, of course ;-) As for use cases: I'm simulating mechanical experiments on microstructures which are represented as 3D images. The images I'm dealing with are typically 128x128x128, with 6 dofs per voxel, but my aim is 1024x1024x1024, even 2048x2048x2048. For these kind of problems, the main issue is memory (_followed_ by speed). > > Regards, > Gilles > > Best regards, Sébastien > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
