Hi Toby,
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...
Philippe
2014-02-18 17:29 GMT+00:00 Toby St Clere Smithe <m...@tsmithe.net>:
> Hey,
>
> Karl Rupp <r...@iue.tuwien.ac.at> 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
> ViennaCL-devel@lists.sourceforge.net
> 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
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
