Hey,
Oh, indeed it was done after the 1.5.1 release. The diff is here :
https://github.com/viennacl/viennacl-dev/commit/3bfca3c72411907e6d8b6211523170924b72a4da#diff-35,
I'm not entirely satisfied with the family/subfamily architecture, and the
way reductions are handled...
I don't really know what's happening with the norm, then...
Best regards,
Philippe
2014-02-18 17:39 GMT+00:00 Toby St Clere Smithe <[email protected]>:
> Hey Philippe,
>
> Philippe Tillet <[email protected]>
> writes:
> > Concerning the Norm, I have made minor changes in the
> > operator/operator-subfamily for a new version of the generator. Maybe
> your
> > statement parsing relies on the former family? The type
> > (OPERATION_UNARY_NORM_*_TYPE) has not changed, though...
>
> Do you have a link to a diff I can read? Also, I'm still just using
> ViennaCL 1.5.1: did the change happen there? In any case, I might need
> to change things later..
>
> Cheers,
>
> Toby
>
>
>
>
>
>
>
> > Philippe
> >
> >
> > 2014-02-18 17:29 GMT+00:00 Toby St Clere Smithe <[email protected]>:
> >
> >> Hey,
> >>
> >> Karl Rupp <[email protected]> writes:
> >> > Argl, the reason is that I had to do a manual clone of your
> Boost.NumPy
> >> > repo and did not change the branch. I don't think it's good to have a
> >> > patched repo for Boost.NumPy around...
> >>
> >> Ah -- if you do the git submodule update --init command, I think it does
> >> that for you. In any case, I need to ship boost.numpy with pyviennacl,
> >> because it's not a standard part of boost, and I need to ship it as a
> >> static library because it's not included in any public / common
> >> distributions, as far as I can tell.
> >>
> >> > Still searching. The build process is so awfully slow, it's killing
> >> > productivity. It takes me minutes to just get a compiler error if
> >> > something was wrong...
> >>
> >> I know; it's painful. I've wasted so much time over the last couple of
> >> days waiting for compilation runs to terminate.. Hopefully my discovery
> >> of ccache will help in this regard.
> >>
> >> >> I've also remembered that my own code to compute vector norms using
> >> >> scheduler calls doesn't work, and that seems to be because I'm
> building
> >> >> the expression tree in that case as I do for all other expressions at
> >> >> the moment, like this:
> >> >>
> >> >> Assign(Scalar, Norm_2(Vector))
> >> >>
> >> >> but there doesn't seem to be functionality for that kind of scalar
> >> >> expression in the scheduler, so that needs fixing. But I'm not sure
> that
> >> >> the two issues are related.
> >> >
> >> > That might be the cause, because norms are essential in the iterative
> >> > solvers.
> >>
> >> Sure, but why would a problem with the scheduler calls to the norm
> >> functions also interfere with the standard API calls, unless there was
> >> something wrong with the norm computation -- or the norm was in fact 0?
> >> Since the norm doesn't look to be 0, then perhaps something is wrong in
> >> the computation of the norm.. but then why wouldn't it have been
> >> noticed? I'm just using ViennaCL 1.5.1, which works for everyone else!..
> >>
> >> >> Finally, you can improve recompilation speeds using ccache, but alas
> I
> >> >> think it will remain a limitation that standard parallel builds do
> not
> >> >> work, thanks to Python's distutils.
> >> >
> >> > We need to Python's distutils as much as possible and only expose the
> >> > very least amount of targets. libviennacl would certainly be *the*
> >> > solution to this problem.
> >>
> >> Yeah. The trade-off at the moment is between memory usage and
> >> compilation time. Historically, I had fewer targets to build, but that
> >> ate up many gigabytes of RAM, which is less acceptable than using up
> >> more minutes of build time -- because ultimately, a user should only
> >> need to build it once!
> >>
> >> Best,
> >>
> >> Toby
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Managing the Performance of Cloud-Based Applications
> >> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> >> Read the Whitepaper.
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> ViennaCL-devel mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/viennacl-devel
> >>
> >
> ------------------------------------------------------------------------------
> > Managing the Performance of Cloud-Based Applications
> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > Read the Whitepaper.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> > _______________________________________________
> > ViennaCL-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/viennacl-devel
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> ViennaCL-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/viennacl-devel
>
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
