AccelerateHS / AccelerateHS/accelerate-llvm

Unexpected numerical results with LLVM Native but not with the Interpreter

Đang mở
#40 2 bình luận 0 reaction 0 người được giao Xem trên GitHub
Ngôn ngữ chính
Haskell
Star
171
Fork
65
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Mô tả

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.

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.