You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mahout.apache.org by Ying Liao <yl...@gmail.com> on 2013/01/23 18:00:01 UTC
QRDecomposition performance
Hi!
The QRDecomposition turns out to be my bottleneck in deploying ALS-WR. It
takes less than a ms to solve X=A^{-1}B when A is 20*20. But it takes 55ms
per solve when A is 60*60. Is there a different approach to solve AX=B?
Thanks,
Ying
Re: QRDecomposition performance
Posted by Ted Dunning <te...@gmail.com>.
Yeah... having to copy the matrix is a pain in the butt.
On Mon, Jan 28, 2013 at 8:13 AM, Ying Liao <yl...@gmail.com> wrote:
> A wrapper is needed then because Commons Math takes in and outputs in
> different data structure.
>
>
> On Mon, Jan 28, 2013 at 3:14 AM, Sean Owen <sr...@gmail.com> wrote:
>
> > Is it worth simply using the Commons Math implementation?
> >
> > On Mon, Jan 28, 2013 at 8:04 AM, Sebastian Schelter <ss...@apache.org>
> > wrote:
> > > This is great news and will automatically boost the performance of all
> > > our ALS-based recommenders which are all using QRDecomposition
> > internally.
> > >
> > > On 28.01.2013 04:02, Ted Dunning wrote:
> > >> Did that.
> > >>
> > >> You are right. The QRD in mahout is abysmally slow. I wrote a new
> > version
> > >> on the airplane that seems to be about 10x faster and still jsut about
> > as
> > >> accurate (and vastly simpler). I will put up some tests and a patch
> in
> > the
> > >> next week or so.
> > >
> >
>
Re: QRDecomposition performance
Posted by Ying Liao <yl...@gmail.com>.
A wrapper is needed then because Commons Math takes in and outputs in
different data structure.
On Mon, Jan 28, 2013 at 3:14 AM, Sean Owen <sr...@gmail.com> wrote:
> Is it worth simply using the Commons Math implementation?
>
> On Mon, Jan 28, 2013 at 8:04 AM, Sebastian Schelter <ss...@apache.org>
> wrote:
> > This is great news and will automatically boost the performance of all
> > our ALS-based recommenders which are all using QRDecomposition
> internally.
> >
> > On 28.01.2013 04:02, Ted Dunning wrote:
> >> Did that.
> >>
> >> You are right. The QRD in mahout is abysmally slow. I wrote a new
> version
> >> on the airplane that seems to be about 10x faster and still jsut about
> as
> >> accurate (and vastly simpler). I will put up some tests and a patch in
> the
> >> next week or so.
> >
>
Re: QRDecomposition performance
Posted by Sean Owen <sr...@gmail.com>.
Is it worth simply using the Commons Math implementation?
On Mon, Jan 28, 2013 at 8:04 AM, Sebastian Schelter <ss...@apache.org> wrote:
> This is great news and will automatically boost the performance of all
> our ALS-based recommenders which are all using QRDecomposition internally.
>
> On 28.01.2013 04:02, Ted Dunning wrote:
>> Did that.
>>
>> You are right. The QRD in mahout is abysmally slow. I wrote a new version
>> on the airplane that seems to be about 10x faster and still jsut about as
>> accurate (and vastly simpler). I will put up some tests and a patch in the
>> next week or so.
>
Re: QRDecomposition performance
Posted by Sebastian Schelter <ss...@apache.org>.
This is great news and will automatically boost the performance of all
our ALS-based recommenders which are all using QRDecomposition internally.
On 28.01.2013 04:02, Ted Dunning wrote:
> Did that.
>
> You are right. The QRD in mahout is abysmally slow. I wrote a new version
> on the airplane that seems to be about 10x faster and still jsut about as
> accurate (and vastly simpler). I will put up some tests and a patch in the
> next week or so.
>
> On Thu, Jan 24, 2013 at 4:55 PM, Ted Dunning <te...@gmail.com> wrote:
>
>> Hmph. That suggests to me that I need to rewrite our QRDecomposition.
>>
>>
>> On Thu, Jan 24, 2013 at 8:27 AM, Ying Liao <yl...@gmail.com> wrote:
>>
>>> Sean suggests "replacing this with a call to the Apache Commons Math
>>> QRDecomposition" and the sloving time is reduced significantly. Thanks.
>>>
>>>
>>> On Wed, Jan 23, 2013 at 5:10 PM, Ted Dunning <te...@gmail.com>
>>> wrote:
>>>
>>>> That is a long time for such a small qr decomposition. I wouldn't think
>>>> that the actually solving would add that much time, either.
>>>>
>>>> On Thu, Jan 24, 2013 at 2:00 AM, Ying Liao <yl...@gmail.com> wrote:
>>>>
>>>>> Hi!
>>>>> The QRDecomposition turns out to be my bottleneck in deploying
>>> ALS-WR. It
>>>>> takes less than a ms to solve X=A^{-1}B when A is 20*20. But it takes
>>>> 55ms
>>>>> per solve when A is 60*60. Is there a different approach to solve
>>> AX=B?
>>>>>
>>>>> Thanks,
>>>>> Ying
>>>>>
>>>>
>>>
>>
>>
>
Re: QRDecomposition performance
Posted by Ted Dunning <te...@gmail.com>.
Did that.
You are right. The QRD in mahout is abysmally slow. I wrote a new version
on the airplane that seems to be about 10x faster and still jsut about as
accurate (and vastly simpler). I will put up some tests and a patch in the
next week or so.
On Thu, Jan 24, 2013 at 4:55 PM, Ted Dunning <te...@gmail.com> wrote:
> Hmph. That suggests to me that I need to rewrite our QRDecomposition.
>
>
> On Thu, Jan 24, 2013 at 8:27 AM, Ying Liao <yl...@gmail.com> wrote:
>
>> Sean suggests "replacing this with a call to the Apache Commons Math
>> QRDecomposition" and the sloving time is reduced significantly. Thanks.
>>
>>
>> On Wed, Jan 23, 2013 at 5:10 PM, Ted Dunning <te...@gmail.com>
>> wrote:
>>
>> > That is a long time for such a small qr decomposition. I wouldn't think
>> > that the actually solving would add that much time, either.
>> >
>> > On Thu, Jan 24, 2013 at 2:00 AM, Ying Liao <yl...@gmail.com> wrote:
>> >
>> > > Hi!
>> > > The QRDecomposition turns out to be my bottleneck in deploying
>> ALS-WR. It
>> > > takes less than a ms to solve X=A^{-1}B when A is 20*20. But it takes
>> > 55ms
>> > > per solve when A is 60*60. Is there a different approach to solve
>> AX=B?
>> > >
>> > > Thanks,
>> > > Ying
>> > >
>> >
>>
>
>
Re: QRDecomposition performance
Posted by Ted Dunning <te...@gmail.com>.
Hmph. That suggests to me that I need to rewrite our QRDecomposition.
On Thu, Jan 24, 2013 at 8:27 AM, Ying Liao <yl...@gmail.com> wrote:
> Sean suggests "replacing this with a call to the Apache Commons Math
> QRDecomposition" and the sloving time is reduced significantly. Thanks.
>
>
> On Wed, Jan 23, 2013 at 5:10 PM, Ted Dunning <te...@gmail.com>
> wrote:
>
> > That is a long time for such a small qr decomposition. I wouldn't think
> > that the actually solving would add that much time, either.
> >
> > On Thu, Jan 24, 2013 at 2:00 AM, Ying Liao <yl...@gmail.com> wrote:
> >
> > > Hi!
> > > The QRDecomposition turns out to be my bottleneck in deploying ALS-WR.
> It
> > > takes less than a ms to solve X=A^{-1}B when A is 20*20. But it takes
> > 55ms
> > > per solve when A is 60*60. Is there a different approach to solve AX=B?
> > >
> > > Thanks,
> > > Ying
> > >
> >
>
Re: QRDecomposition performance
Posted by Ying Liao <yl...@gmail.com>.
Sean suggests "replacing this with a call to the Apache Commons Math
QRDecomposition" and the sloving time is reduced significantly. Thanks.
On Wed, Jan 23, 2013 at 5:10 PM, Ted Dunning <te...@gmail.com> wrote:
> That is a long time for such a small qr decomposition. I wouldn't think
> that the actually solving would add that much time, either.
>
> On Thu, Jan 24, 2013 at 2:00 AM, Ying Liao <yl...@gmail.com> wrote:
>
> > Hi!
> > The QRDecomposition turns out to be my bottleneck in deploying ALS-WR. It
> > takes less than a ms to solve X=A^{-1}B when A is 20*20. But it takes
> 55ms
> > per solve when A is 60*60. Is there a different approach to solve AX=B?
> >
> > Thanks,
> > Ying
> >
>
Re: QRDecomposition performance
Posted by Ted Dunning <te...@gmail.com>.
That is a long time for such a small qr decomposition. I wouldn't think
that the actually solving would add that much time, either.
On Thu, Jan 24, 2013 at 2:00 AM, Ying Liao <yl...@gmail.com> wrote:
> Hi!
> The QRDecomposition turns out to be my bottleneck in deploying ALS-WR. It
> takes less than a ms to solve X=A^{-1}B when A is 20*20. But it takes 55ms
> per solve when A is 60*60. Is there a different approach to solve AX=B?
>
> Thanks,
> Ying
>