The current primops for prefetching do not properly work in pure code; namely, the primops are not 'hoisted' into the correct call sites based on when arguments are evaluated. Instead, they should use a seq-like interface, which will cause it to be evaluated when the needed term is.
See Trac #9353 for the full discussion.
updated tests for pure prefetch in T8256 to reflect the design changes in Trac #9353
| Lint Warnings | Excuse: ignor |
| Severity | Location | Code | Message |
|---|---|---|---|
| Warning | compiler/codeGen/StgCmmPrim.hs:739 | TXT3 | Line Too Long |
| Warning | compiler/codeGen/StgCmmPrim.hs:744 | TXT3 | Line Too Long |
| Warning | compiler/codeGen/StgCmmPrim.hs:749 | TXT3 | Line Too Long |
| Warning | compiler/codeGen/StgCmmPrim.hs:754 | TXT3 | Line Too Long |
| Warning | testsuite/tests/codeGen/should_run/T8256.hs:10 | TXT3 | Line Too Long |
| No Unit Test Coverage |
| Buildable 2229 | |
| Build 2239: GHC Patch Validation (amd64/Linux) |
looks like the only failure in the build is perf/compiler T3064 [stat not good enough] (normal)
Which is not my test! :)
that said, Luite has given me some suggestions / feedback that might require/lead to changing up the design.
Note unsafePerformIO is going to probably eat up any of the performance win for prefetching in the first place.
i'm concerned that the prefetchValue operations dont have the right strictness information on them. The value argument shouldn't be evaluated.
LGTM.
I've wanted a prefetch primop i could use to prefetch a thunk for a long time.
I have some tree processing code that can just drop in the prefetch as it takes things out of the tree and drops it in a bounded processing queue.
i was doing some sanity checking locally, and its pretty clear that the test file wasn't being run by validate somehow (as in, theres no way it compiled, i'm fixing that locally and hopefully things will then be OK)
i seem to have discovered a problem wrt let/app invariant with the api / semantics i have for prefetch value. However, I only seem to get the problem to happen locally on my mac (though I cant even run validate locally for other reasons i can't yet track down).
I *may* have to revert the prefetch value stuff i cant track it down
Davean and I did some benchmarks (mentioned in the thread here )https://www.haskell.org/pipermail/ghc-devs/2014-November/007458.html
when we ran the same codes using a version of GHC that treated the primops as being "pure", there was a teeny (but measurable) change in the resulting application performance (where the resulting performance was worse by ~ 5% of total runtime I think).
LGTM, other than the comments I have now I think.
| compiler/codeGen/StgCmmPrim.hs | ||
|---|---|---|
| 1555–1559 | Change this comment into a regularly-styled Haddock comment and perhaps make it speak more of what the function does, rather than the abstract -- | Translate byte array prefetch operations into proper primcalls. doPrefetchByteArrayOp :: Int ... | |
| 1561–1564 | Haddock comments needed; just add a one-line blurb here. | |
| 1579–1585 | Ditto, haddock comments. | |
| 1587–1594 | Haddock comments. | |
| 1596 | Same here. | |
| testsuite/tests/codeGen/should_run/T8256.hs | ||
| 4–9 | No need for this comment, since this test always existed for the locality primops anyway, so it doesn't need a comment log of when it might be updated. | |