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
