Hi, >> 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.
There's no doubt about shipping Boost.NumPy. It's more a matter of shipping a modified Boost.NumPy or the standard package. I'd prefer to ship a standard package and set LIBRARY_TYPE through CMake as needed rather than let stupid developers like me check out the wrong branch ;-) >>> 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!.. Indeed, within the iterative solvers there's no use of the scheduler right now... >> 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! True. The solution needs to be in the ViennaCL core, which needs to get more lightweight. Best regards, Karli ------------------------------------------------------------------------------ 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
