AccelerateHS / AccelerateHS/accelerate-llvm
Unexpected numerical results with LLVM Native but not with the Interpreter
- Lingua principale
- Haskell
- Stelle
- 171
- Fork
- 65
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Descrizione
I am submitting a...
- [x] bug report
- [ ] feature request
- [ ] support request => you might also like to ask your question on the [mailing list](mailto:accelerate-haskell@googlegroups.com) or [gitter chat](https://gitter.im/AccelerateHS/Lobby).
## Description
Using LLVM as backend gives different results than using the Interpreter.
From a high-level view, ignoring everything thought irrelevant, I have a simulator executing an iterated function `x' = f(x)`, where `f` adds or subtracts at most 1 from a subset of elements of `x`. Domain rules dictate that no element will ever leave the inclusive integer bound `[0, 70]`, which holds true when running with the interpreter. When using LLVM, this does not hold true.
I am inclined to believe that this might be a bug outside of my program for the following reasons:
- The simulator checks every iteration (given run-time flags below) if [any element of `x` exceeds 70](https://github.com/tsoernes/haskelldca/blob/070ee164250fe1668392d18075de864107f3fde5/src/SimRunner.hs#L156), and if so,
prints out previous `x` (where no element should exceed the bounds, lest the simulator would have quit). `x` here refers to the slice of elements with depth 70 (which is maximum depth) for any spatial position in the 3D array `freps`, that is, in numpy notation, `freps[:, :, -1]`.
- Elements of `x` are only ever changed by `f` in [increments or decrements of 1](https://github.com/tsoernes/haskelldca/blob/070ee164250fe1668392d18075de864107f3fde5/src/Gridfuncs.hs#L222)
- Example observed value 283480585120
## Steps to reproduce (for bugs)
1. Clone
https://github.com/tsoernes/haskelldca/tree/070ee164250fe1668392d18075de864107f3fde5
2. Build
`stack build`
3.
Compare
`stack exec dca-exe -- --backend interp --log_iter 1`
against
`stack exec dca-exe -- --backend cpu --log_iter 1`
The interpreter runs without error and yields expected results.
The second, which uses LLVM, always quits due to previously mentioned check on "out of bounds" values, *at a non-deterministic time* (usually 200-1000 iterations which takes a minute or 2 on a laptop) despite there being no inherent randomness in the program (random seed is fixed). On exit, it will print (amongst other things), `x` and `x'`, named `Prev frep` and `Current frep` respectively. "Prev" will be the last input without out-of-bounds values, while "Current" will have large values.
## Your environment
- Version used:
- Backend(s) used and version:
- accelerate-1.2.0.0
- accelerate-llvm-1.2.0.0
- accelerate-llvm-native-1.2.0.0
- accelerate-blas-0.2.0.0
- llvm-hs-6.0.0
- llvm-hs-pure-6.0.0
- GHC version: 8.4.3
- Operating system and version: Linux Fedora 28
- Link to your project: https://github.com/tsoernes/haskelldca/tree/overflow
Tell me if you need more information about or explanation of the code.
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Valutazione
Questa issue non è ancora stata valutata.