Hi Ted, I think we might have a misunderstanding. What I am discussing is not the general implementation for a matrix, but the base interface that would be required for input into optimizers. I was saying that there should not be a burden of implementing visitor pattern for users creating a custom class for optimization input, if it is not used internally by the optimizers. It should only consist of the most general and yet basic set of function that are required. While visitor pattern can probably be used to implement all the functionality required for optimization, it would not be the most general formulation, and hence preclude vector based process operations, such as you would find on a GPU. So if the user wanted to speed up the computation using a GPU they would not be able to do it, if we base it on a single element at a time visitor pattern.
Thanks, Konstantin On Dec 29, 2012, at 7:08 PM, Ted Dunning <ted.dunn...@gmail.com> wrote: > Who said force? Linear algebra operations should be available. > > Visitors should be available. > > Your mileage will vary. That was always true. > > On Sat, Dec 29, 2012 at 3:59 PM, Konstantin Berlin <kber...@gmail.com>wrote: > >> Also. If you have GPU implementation of a matrix, or use another type of a >> vector processor, there is no way you can program that in if you force >> vector operations to use a visitor patterns. >> >> On Dec 29, 2012, at 6:43 PM, Konstantin Berlin <kber...@gmail.com> wrote: >> >>> That's a good point about the compiler. I never tested the performance >> of visitors vs. sequential array access. I just don't want the vector >> operations to be tied to any particular implementation detail. >>> >>> On Dec 29, 2012, at 6:30 PM, Ted Dunning <ted.dunn...@gmail.com> wrote: >>> >>>> Actually, the visitor pattern or variants thereof can produce very >>>> performant linear algebra implementations. You can't usually get quite >>>> down to optimized BLAS performance, but you get pretty darned fast code. >>>> >>>> The reason is that the visitor is typically a very simple class which is >>>> immediately inlined by the JIT. Then it is subject to all of the normal >>>> optimizations exactly as if the code were written as a single concrete >>>> loop. For many implementations, the bounds checks will be hoisted out >> of >>>> the loop so you get pretty decent code. >>>> >>>> More importantly in many cases, visitors allow in place algorithms. >>>> Combined with view operators that limit visibility to part of a matrix, >>>> and the inlining phenomenon mentioned above, this can have enormous >>>> implications to performance. >>>> >>>> A great case in point is the Mahout math library. With no special >> efforts >>>> taken and using the visitor style fairly ubiquitously, I can get about >> 2 G >>>> flops from my laptop. Using Atlas as a LINPAK implementation gives me >>>> about 5 G flops. >>>> >>>> I agree with the point that linear algebra operators should be used >> where >>>> possible, but that just isn't feasible for lots of operations in real >>>> applications. Getting solid performance with simple code in those >>>> applications is a real virtue. >>>> >>>> On Sat, Dec 29, 2012 at 3:22 PM, Konstantin Berlin <kber...@gmail.com >>> wrote: >>>> >>>>> While visitor pattern is a good abstraction, I think it would make for >>>>> terrible linear algebra performance. All operations should be based on >>>>> basic vector operations, which internally can take advantage of >> sequential >>>>> memory access. For large problems it makes a difference. The visitor >>>>> pattern is a nice add on, but it should not be the engine driving the >>>>> package under the hood, in my opinion. >>>>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
