AccelerateHS / AccelerateHS/accelerate-llvm

Unexpected numerical results with LLVM Native but not with the Interpreter

オープン
#40 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
Haskell
スター
171
フォーク
65
PR マージ指標
30日以内にマージされた PR はありません

説明

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.

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

評価

この issue はまだ評価されていません。

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。