greetings from a C++ b-spline library

[kfjahnke]

Dear collegues!

I'm the author of an extensive C++ library for cardinal b-splines and everything that's needed to create and evaluate them efficiently, using SIMD and multithreading on arbitrarily strided nD arrays of multichannel data (raster processing only, it's entirely grid-based). The code is header-only C++11 template metacode with few dependencies (needs vigra, Vc optional), everything is liberally licensed. Maybe you'd like to take a look - be it for inspiration, as a cross-reference, or to suck it in:

https://bitbucket.org/kfj/vspline

With regards, Kay F. Jahnke

[mkitti]

This is useful thanks. Do you have binary distribution of this code? We could package it via https://binarybuilder.org/ which would make it easier to use from Julia packages.

[kfjahnke]

Am 30.06.21 um 22:23 schrieb Mark Kittisopikul:

This is useful thanks. Do you have binary distribution of this code? We could package it via https://binarybuilder.org/ <https://binarybuilder.org/> which would make it easier to use from Julia packages.

There is no binary as such of this library. It's header-only template metacode. Having binary would require specialization, e.g. to a given set of channels in the *xel data, a fixed number of dimensions for the arrays, etc - which would limit generality, and vspline is 'generic' code. I have 'narrowed it' to a 'reasonable' scope for the python interface, maybe the code there could be used to interface well with julia (sorry, I won't be any help on the julia end, I'm just staring to look at it). The python interface uses precompiled code for 'common' use cases and run-time-instantiates the templates for constellations which aren't covered, thus combining the 'best of both worlds': the 'common' stuff loads near-instantaneously, and the less common needs a while to compile and JIT, using cppyy. For the python interface, instantiation of the 'common' templates is done with this header https://bitbucket.org/kfj/python-vspline/src/master/bspline/vspline_binary.h for the declarations and a c++ file to instantiate: https://bitbucket.org/kfj/python-vspline/src/master/bspline/vspline_binary.cc This should be code you can wrap. The code is to make a shared object which provides the objects and functions declared in the header; there's a makefile to produce the .so (linux only for now) - I think julia can suck in shared libraries, so you wouldn't need an external program. Going down this route would limit the scope to the set of features encompassed by the instantiation code, but that's quite a mouthful already and can be extended easily. Only the run-time instantiation with arbitrary template arguments would be missing. The advantage of using the shared library would be that all dependencies would disappear - the .so can stand by itself. I've made a ZIP file of the four 'common' versions of the .so (single/multithreaded, with and without Vc): https://bitbucket.org/kfj/python-vspline/downloads/vspline_binary.zip And an .so to pull in what's additionally needed for use with Vc: https://bitbucket.org/kfj/python-vspline/downloads/get_vc.so All are for amd64 architecture. I'd be very interested to see (speed) comparisons of my code with your native julia code, where applicable, and if you have any questions, please ask. What I've seen so far of julia is tasty, and I'm tempted to go deeper. I like the native support of nD arrays and slices, and it looks like one might be able to code b-splines with it with the same scope as my c++ library, but without the statically-typed language bother.

[mkitti]

Julia can use ccall to access a C API directly. C++ is a bit more complicated since the names need to be (de)mangled.
https://docs.julialang.org/en/v1/manual/calling-c-and-fortran-code/#C
https://github.com/JuliaInterop/CxxWrap.jl

Do you provide C API or just C++?

[kfjahnke]

Sorry, it's only C++ and python for now, and the shared libraries if you can interface them directly.

[johnnychen94]

It should be sufficient to have BinaryBuilder build the shared library, but for C++ binding we need CxxWrap (which works very similar to pybind), it's a little bit more work to do. Or we can wait for Cxx.jl to revive.

[kfjahnke]

It would suit julia to have a tool like cppyy, which reduces time spent on interface writing significantly. cppyy uses an LLVM-based backend, so it might even be portable to julia - just a wild guess. My python interface to vspline is written that way, and compared to other ways I've used to wrap external code for python (swig, cffi) it was quite painless. The cppyy way is to leave the C++ code more or less untouched (it reads C++ header files) and to do the pythonization in python. cppyy supports the complete C++ language, not just a small subset, and you don't need any annotations in the C++ code. This is more than what CxxWrap or Cxx.jl seem to offer.

This may sound like a strange idea, but why don't you interface to the python module? Even if it's only as an intermediate step to see how vspline gels with julia. The python interface has richer metadata and it's easier to 'talk to'. Browsing a bit, I found PyCall.jl, which seems to be able to handle the complexity of the code. My python interface is already set up to use NumPy ndarrays, and most of vspline's high-level operations are transform/apply-type functions processing such arrays anyway, and these operations are where vspline's speed counts.

Another point to keep in mind is hardware. It's quite possible to run the python interface without any precompiled code, leaving it to cppyy to JIT the C++ header code as needed, but this takes some warm-up time during the first use of a specific instantiation. This method can produce machine instructions native to the processor which the code runs on, and with vspline's heavy use of SIMD, this is a good idea. Having stuff precompiled is a time-saver if the target platform is known, but distributing binary is somewhat contrary to the spirit of vspline.

I established that the python route is viable. With vspline's python module installed (it's simply called 'bspline'), I could do this:

julia> using PyCall; bspline = pyimport("bspline")
PyObject <module 'bspline' from '/home/kfj/.local/lib/python3.8/site-packages/bspline/__init__.py'>

julia> bf3 = bspline.basis_functor()
PyObject <bspline.basis_functor object at 0x7fb223ab5730>

julia> bf3(1.0)
0.16666666666666666

julia> bf7_1 = bspline.basis_functor(7,1)
PyObject <bspline.basis_functor object at 0x7fb2238aa580>

julia> bf7_1(1.0)
-0.3402777777777778

This is just a taster: set up two basis functors, one for the cubic b-spline's basis function, one for a heptic b-spline's first derivative. Both are evaluated at 1.0. It's meant as a proof of viability. What do you think?

[mkitti]

We could interface to the python module. Cxx should do what cppyy does, actually perhaps even lower overhead since it does not use an interpreted approach via Cling. The problem the author of Cxx encountered was that Julia stopped shipping the entire LLVM stack along with Julia after 1.3.x.

The tracking issue for restoring Cxx for current Julia versions is here:
JuliaInterop/Cxx.jl#486 (comment)

I actually think Cxx would be the best match for your code since this would allow for dynamic compilation of C++ code from Julia.

[mkitti]

Also, I think the scope of this package is a bit different than yours. This package is focused on interpolation only.

For more general work with b-splines, there are other packages such as

• https://github.com/sostock/BSplines.jl
• https://github.com/jipolanco/BSplineKit.jl

[kfjahnke]

We could interface to the python module.

Try it out, I think that's a viable option, as demonstrated in my post. If you need help getting the python module running, please ask. It's not (yet) available from PyPI.

I actually think Cxx would be the best match for your code since this would allow for dynamic compilation of C++ code from Julia.

I don't think Cxx has sufficient scope. In the docu it says

The main interface provided by Cxx.jl is the @cxx macro. It supports two main usages:

    Static function call @cxx mynamespace::func(args...)
    Membercall (where m is a CppPtr, CppRef or CppValue) @cxx m->foo(args...)

It looks to me as if cppyy does much more, it can handle the entire C++ language and do stuff like instantiation of templates at run-time.

Also, I think the scope of this package is a bit different than yours. This package is focused on interpolation only.

For more general work with b-splines, there are other packages such as

* https://github.com/sostock/BSplines.jl

* https://github.com/jipolanco/BSplineKit.jl

My library is for interpolation and the focus is on bulk raster data processing - images, volumes, sound files etc. The basics, like access to the basis functions or the spline-specific IIR and FIR filters, might be useful for 'more general' b-spline code. But my code only handles cardinal splines. It is 'backend stuff' processing raster data very efficiently with multithreaded SIMD code. You can see it in action if you like, I use it in my image and panorama viewer for the rendering code.

[kfjahnke]

This exchange has inspired me. It gave me the following idea: since julia can wrap python seamlessly, a julia wrap of cppyy provides instant access to a mighty agent "understanding" all of C++ which julia can simply delegate to. The resulting state in cppyy is immediately available to julia to execute the code. To illustrate what I mean, consider this snippet:

julia> using PyCall; cppyy = pyimport("cppyy")
PyObject <module 'cppyy' from '/home/kfj/.local/lib/python3.8/site-packages/cppyy/__init__.py'>

julia> cppyy.cppdef(
              """#include <iostream>
                 template<typename T>
                 void blah ( const T& arg )
                   { std::cout << "hello " << arg << std::endl ; }""")
true

julia> cppyy.gbl.blah(1.234)
hello 1.234

This may look trivial, but what's happening here is run-time template instantiation, using automatic dispatch via the argument type, which is really quite a tricky issue for a wrapper generator. I always felt cppyy was a bit like magic, and it seems like the magic can simply be 'forwarded' to julia. Using this method might be a near-optimal way to interface between C++ and julia, with no coding effort for the wrap in itself, using a well-established external module, and no need to reinvent the wheel.

[mkitti]

I think that interface looks great. My understanding is that Cxx provided a cxx"" string macro in addition to @cxx that could compile arbitrary C++ code. The difference in approach is the Cxx wraps Clang directly whereas cppyy wraps Cling. This is somewhat moot because at the moment Cxx is not working for the latest Julia. I think it might be best to discuss some of these details with Cxx's author, @Gnimuc .

What you have shown would be a great Julia package and add to the existing interop opportunities.

To reach a wider Julia audience I encourage you to post this content to https://discourse.julialang.org/ . I believe they will be very interested in your ideas and your demonstration.

[wlav]

We could interface to the python module. Cxx should do what cppyy does, actually perhaps even lower overhead since it does not use an interpreted approach via Cling.

Cling JITs, so that's not where the overhead is. :) In fact, the bulk of the overhead of calls in the case of cppyy are in the Python interpreter itself, that's why it achieves native C++ speeds when used with PyPy, where the Python overhead can be elided.

The problem the author of Cxx encountered was that Julia stopped shipping the entire LLVM stack along with Julia after 1.3.x.

This is why in the case of cppyy, Cling, Clang, and LLVM are linked in w/o exposing their internals. Instead, it has a thin bootstrap API (in C for PyPy, in C++ for CPython) and then uses the JIT. There's some effort by the Cling folks for making that approach more friendly to any language and getting it as much as possible accepted into Clang/LLVM directly (see: https://compiler-research.org/); the motivation for upstream being lldb. Right now, we have people for Python (me), for D, and for LISP. It'd be awesome if anyone from the Julia community would be interested to see whether the same would serve their purposes and if not, help shape the work to make it useful for Julia as well.

[Gnimuc]

I think it might be best to discuss some of these details with Cxx's author, @Gnimuc .

I'm not the author, keno is. I just happened to be a maintainer of that package, and I don't know every detail about how it works.

I don't think Cxx has sufficient scope. In the docu it says
It looks to me as if cppyy does much more, it can handle the entire C++ language and do stuff like instantiation of templates at run-time.

@kfjahnke The main interface is cxx/icxx string macros with which you can even interpolate a Julia expression that calls a C++ expression to a C++ expression. I don't think Python can do this because there is no Expr datatype in Python.

As Julia is a language that cares about type, we do const StdVector{T} = cxxt"std::vector<$T>" instead of instantiating templates at run-time.

I don't know why you prefer cppyy(Cxx.jl) over pybind11(CxxWrap.jl). If I have a C++ library and hope it could be accessed in other languages, I'd like to avoid shipping it with a Clang runtime that is only used in a wrapper, but that's only my 50 cent. I completely agree that cppyy(Cxx.jl) is way easier to work with in the development phase.

This is somewhat moot because at the moment Cxx is not working for the latest Julia.

The real reason is that no one would like to invest time in this package, which is probably because we don't have enough Julians who have a good understanding of both LLVM/Clang and Julia internal.

[mkitti]

Thanks for chiming in @Gnimuc . I too am the maintainer and the not the primary author of this package.

It would be great to have Cxx.jl working again against the latest Julia. Perhaps we just need some C++ as a motivation to encourage us to put additional resources into it.

[Gnimuc]

I'm now exploring to reimplement some of the Cxx.jl's features on LLVM.jl+Clang without hacks. Making little progress: