Clang wrappers for base: is this worth pursuing?

[timholy]

The immediate motivation behind this was to provide better support for the cholmod_common struct, which is not currently wrapped (it's big). But of course the scope of this effort could widen (hence the name of the repo).

If you've built julia to support Clang, after cloneing this package you can generate CHOLMOD wrappers like this:

import LinAlgHeaders
LinAlgHeaders.cholmod()

Then look inside your base/sparse/gen folder. To make it easy on those who don't want to do it, here's a gist so you can see what it's like. We could either use raw files (in all their glorious excess), or perhaps more likely copy/paste the useful portions into files that are checked in to julia's repo---basically using this as a starting point for a hand-curated wrapper.

Absolutely nothing has been tested, and one obvious important consideration is mutability and the alignment issues it entails. But I think the first order of business is to decide whether we actually want to use this, or not.

Thoughts? CCing folks who seem to have worked on sparse stuff recently: @andreasnoack, @ViralBShah, @tanmaykm, @tkelman, @jakebolewski, @simonster, @IainNZ (I'm sure I missed some, please add as you see fit). Also @ihnorton, of course.

[timholy]

We should of course migrate this to JuliaLang if it is useful.

[timholy]

Oh, and you need to be running master on Clang.

[tkelman]

Doesn't this struct change significantly between different versions of cholmod? There's already a PR open (not merged yet I think) adding some more run-time version consistency checks here, but IIRC that PR would allow at least a little bit of version flexibility. edit: I misremembered, JuliaLang/julia#10362 will warn unless versions match exactly.

[jakebolewski]

@timholy is the motivation for this to programmatically take advantage of Cholmod's GPU (Cuda) support?

[tkelman]

Can Cuda-SuiteSparse be built as a shared library? JuliaLang/julia#8800

[jakebolewski]

@tkelman even if it could I think then the CUDA support would be all or nothing (controlled through environment variables upon startup).

[timholy]

@jakebolewski there are several motivations, but one of them is simply to get rid of all the Hack! statements in cholmod.jl and make it easier for a user to tweak, e.g., cm.quick_return_if_not_posdef = 1 or cm.nmethods = 9 (for that we'd need mutability). And yes, turning on CUDA support is another one---I think I'm about to encounter a situation where factorization is the rate limiting step.

But I also don't think there's any real rush on this. In particular, Clang.jl will benefit a lot from Jeff's upcoming tuple refactor: we could finally say goodbye to the need for types like Array_32_Uint8. That may be such a nice outcome that it would be worth waiting for.