[BUG] Compilation ghc 8.10 Segmentation fault 1.3.0.0 #546
Comments
|
Running A segmentation fault in the compiler while compiling accelerate sounds highly suspect. Are you sure it is a segmentation fault, and not, for example, an OOM kill? Also: the release on Hackage is fairly old, for various reasons. The |
|
Given |
BTW is there anything we can do to improve the situation? It would be great to have a new release of |
|
(Disclaimer: I've never been an active developer of accelerate, just contributed on the sidelines and happen to work in the same office as those who do.) Warning: braindump incoming. There's a few reasons that I can see; I'll ask around if I'm missing things.
There are further quality-of-life improvements that would be good, but that's what patch releases are for, I guess. Regarding work / priorities / help (regardless of from whom):
Sorry for the braindump. Thoughts? (Also, nothing here has anything to do with the segfault in OP here, which I'm still suspicious about.) |
|
Regarding the original issue, GHC-8.10 is very old at this point, how long does Nix need (us) to maintain backwards compatibility? I don't think I have tested with 8.* in quite a while, even when I was more actively working on accelerate... Regarding the rest, warning: brain dump incoming...
That's a great question. I have a lot of half-finished work that I wanted to complete before cutting a new release, but that has kind of stalled due to lack of spare time & motivation. Also a lot of ideas for how the language should evolve. But, again... ¯\_(ツ)_/¯
These all came about as an example of the classic chicken-and-egg problem: people are interested in Accelerate but don't know how to use it, or it is missing some feature that the would need but they don't (yet!) have the time/skill to write it themselves. Basically, I needed a standard library of stuff, both for others to use, as well as myself to write demo programs to show others to get them interested and so (hopefully) entice them to write something in Accelerate, etc. etc., and build momentum that way. That was the idea anyway, I don't know if it every worked out... Other than the FFI packages they should all be pretty easy to update. But to your question, which parts of this are actually useful is unknown...
This sounds like adding technical debt, without a clear path to when it would be cleaned up. I'd also be hesitant to take on An alternative I tried was to make As with most open source work, Windows support is often a second or third class citizen. Accelerate has occasionally worked on Windows, or so I am told...
The larger question I have with this is whether on not to continue in the same direction with this package. The surface area of the CUDA API keeps increasing, and a lot of the bindings I have made here are just completely untested. The README started tracking what functions were not covered from each CUDA version, but that is only from the driver API; the runtime API is in even worse shape. So, maybe we shouldn't try to provide bindings to all functions, but rather just the types (so that they can be shared across different packages) and let users declare their own FFI declarations at the point where they need it. All this package really needs to do is find the relevant libraries and tell the linker how to include them, and all clients really need is to tell the compiler to assume that a particular symbol exists. All this automatic marshalling with c2hs is, I now think, more hassle than it's worth... But I'm old and jaded, so take that all with a grain of salt. Thoughts? |
|
@tmcdonell Thanks for sharing your thoughts! You naturally have more perspective here, practical and historical :)
I think point releases exist for a reason. If the code works and is not worse than before, but is improved in some respect, that could be worth releasing. Backwards-incompatble changes are trickier, but new features or better optimisations / compilation strategies etc. shouldn't block a release, I think.
I'm also not a fan of a half- But re dependencies, in the ideal world where the GPU backend is also refactored to use (a forked) llvm-pretty, I do think things are better: llvm-hs and llvm-hs-pure get scrapped from the dep list, and llvm-pretty comes in place. (In the patched version of -native this is already the case.)
I think this is quite possible, and even Stack seems to have support for this now (e.g. this, can't find the proper issue at the moment). However, while vendoring-in llvm-hs does free us from their release process, or indeed from binding anything from LLVM that we don't need in accelerate, it does not change the fact that users need to version-match LLVM against a haskell library version (right? Actually how would that even work as a sublibrary?).
As I alluded to, the Concurrency students this year are (hopefully! 🙏) going to use Accelerate on CPU (! not gpu!) on Windows native, no WSL, with the llvm-pretty approach. That should be a decent test. :)
I dunno, this is very much your area. |
|
My personal priority is that readers of Marlow's book have an opportunity to run Accelerate on modern GHC versions. New features can be added later on, but it would be nice if https://hackage.haskell.org/package/accelerate works out of the box. With regards to |
|
Haven't seen it, but I just had a look. It seems it does essentially what llvm-pretty does, with a different API, and adds a few basic bindings to the LLVM C API by linking to LLVM. The C API bindings are not for actual code generation but only got getting type size information, which we don't really care about because we just generate explicitly sized types anyway. So it would be a replacement for llvm-pretty for us, not a replacement for llvm-hs. And while I didn't check the whole instruction list, it doesn't seem to support address spaces on pointers, so it isn't (yet) capable of supporting the GPU backend. Of course the same holds for llvm-pretty, as written above, but this means it's not really an improvement over llvm-pretty either — and we already have a patch for the CPU backend for llvm-pretty so sunk cost. :) |
The LLVM AST internal to accelerate-llvm is already fully featured for what we need, it just lacks a pretty printer. I started working on this already a while ago, but, again, that's one of those things I have not yet finished... Using llvm-pretty as an intermediate solution was a good choice, but it sounds like moving forward it will be more pain than it is worth.
Correct, but this is also true in the current setup because in practice only one version of llvm-hs on hackage has ever worked at a time, so the fact that accelerate-llvm itself supports multiple versions is somewhat irrelevant (for end users). Having a particular version of llvm available on your system would just become part of the installation prerequisites. Saying that, we should at least pay attention to what versions of llvm are supported for the versions of ghc that we support (and potentially that nix offers, but someone from that crowd would need to be in charge of that). Related to this:
That isn't an accident. I submitted the patches to homebrew to make this happen, and also maintained my own homebrew tap during the period they only provided the latest llvm release while llvm-hs/llvm-general lagged behind. So the situation on macOS is easy now, but it would be even easier if they could just use the system clang they have already (Xcode default toolchain is going to be built on an older version of llvm than what you could get directly from llvm.org, but for the most part that shouldn't matter).
Good luck! It's great to have so many (un)willing guinea pigs 😂
That would be great. In the far distant past I started working on the necessary errata so that people knew what to change in order to use the newer versions of the library with his book; here and mostly the Mandelbrot example here. Maybe also in the hackage docs, I can't remember. That should also be kept up-to-date (the whole website needs attention, really...) |
|
I think it would be most beneficial to get at least something working released and available from Hackage. What is the minimal amount of work required for it to happen? Shall we start with a release of |
Description
Failed to compile the last version of the accelerate with Nix + GHC 8.10. The compilation fails with segmentation fault:
Compilation log
Steps to reproduce
Steps to reproduce the behaviour:
nix-buildExpected behaviour
Success build of accelerate and dependencies
Your environment
The exact environment is pinned in the demo repo (by pinning accelerate version and nixpkgs).
The text was updated successfully, but these errors were encountered: