commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [math] [linear] immutability
Date Tue, 01 Jan 2013 19:17:30 GMT
Hi Gilles,


2013/1/1 Gilles Sadowski <gilles@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message