Itkovian 2017-03-08 10:45:16
however, when just running the stack ... ghc -- --make main.hs, it is found
ezyang 2017-03-08 10:45:49
Man, accelerate-llvm really is not easy to build
nilof 2017-03-08 10:47:31
So stupid question: how do I import a module in a file that is in the same directory?
monochrom 2017-03-08 10:47:45
Just do it.
monochrom 2017-03-08 10:47:55
But mind filename cases (upper or lower).
Athas 2017-03-08 10:49:34
ezyang: if you manage to get it work with the LLVM-based GPU backend too, please let me know!
ezyang 2017-03-08 10:49:41
lol
ezyang 2017-03-08 10:49:52
I got to a GHC panic and then gave up
nilof 2017-03-08 10:51:38
ah, my ghci directory was set to the wrong directory, now everything works
kuribas 2017-03-08 10:52:03
monochrom: try this: http://lpaste.net/2846700419663527936
monochrom 2017-03-08 10:52:06
ghci has a ":cd" command
davean 2017-03-08 10:53:05
ezyang: I feel accelerate has never been well maintained, I've never managed to actually use it
kuribas 2017-03-08 10:53:41
monochrom: behaviour is different compiled from in ghci...
kuribas 2017-03-08 10:54:31
monochrom: the second gives 4 times "debug message", the first only once.
monochrom 2017-03-08 10:55:48
kuribas, I am in ghci, version 8.0.2, both give me 4 messages.
kuribas 2017-03-08 10:56:12
monochrom: try compiling it
monochrom 2017-03-08 10:56:25
OK. -O0? -O1? -O2?
kuribas 2017-03-08 10:56:28
-O2
kuribas 2017-03-08 10:56:56
ghc 8.0.1
monochrom 2017-03-08 10:57:48
OK, reproduced.
kuribas 2017-03-08 10:59:07
I would think ghc will inline const, and make the two equivalent.
monochrom 2017-03-08 10:59:45
But there are other moving parts. How do you know, for example, that optimizations didn't do something to traverse_ and affected this experiment too?
monochrom 2017-03-08 10:59:58
Or even [1..4]
monochrom 2017-03-08 11:00:33
Or the way (\i -> trace whatever) is optimzied or not optimized.
kuribas 2017-03-08 11:01:32
@src trace
lambdabot 2017-03-08 11:01:32
trace string expr = unsafePerformIO $ do
lambdabot 2017-03-08 11:01:32
hPutStrLn stderr string
lambdabot 2017-03-08 11:01:32
return expr
monochrom 2017-03-08 11:01:37
I mean, of course, "const" is the most visible difference syntactically, but you probably need to cross this with some other things too for a real difference to be manifested.
monochrom 2017-03-08 11:02:31
I don't think you can trust @src anymore. Look at Debug.Trace actual source code.
kuribas 2017-03-08 11:04:54
well, at least I have my trace messages :)
monochrom 2017-03-08 11:05:32
You will want to look at the Core code.
codedmart 2017-03-08 11:05:41
Anyone familiar with Pool here? I use it with RethinkDB. Which in most cases it works fine, but I have one instance `Changes` where it is a blocking operation. Basically it just sits and waits for an answer https://github.com/AtnNn/haskell-rethinkdb/blob/c7df4f219f1e7251629a9e90280f1ebdfed9ec8c/Database/RethinkDB/Network.hs#L407-L413. The problem is I get
codedmart 2017-03-08 11:05:41
this error `Left thread blocked indefinitely in an MVar operation` over and over. I have a hacky way around this by using `forkFinally` to just restart it, but that is not an optimal solution. Any thoughts/ideas? I am actually not sure if this is even a Pool problem. I assumed it had something to do with reaping
codedmart 2017-03-08 11:05:41
https://github.com/bos/pool/blob/master/Data/Pool.hs#L203, but I haven't used MVar's yet so could be way off base.
monochrom 2017-03-08 11:23:22
kuribas: "const is inlined or not" does not fully explain it, because in the Core code, there is no longer const or mention of i, it is always 'trace "debug message"'.
kuribas 2017-03-08 11:23:52
monochrom: right
kuribas 2017-03-08 11:24:31
monochrom: so ghc is keeping track of the fresh variable i, and makes sure the expression is evaluated every time...
kuribas 2017-03-08 11:25:40
monochrom: or something else to do with unsafePerformIO...
monochrom 2017-03-08 11:26:18
But it is true and I don't know why that in the no-const version, a top level CAF "xxx = trace "debug message" (return ())" is introduced, then reused by the loop. Whereas in the has-const version, the trace is not a CAF, it is re-created every iteration.
kuribas 2017-03-08 11:28:27
Does unsafePerformIO even have clear semantics?
monochrom 2017-03-08 11:28:43
Yes for GHC.
jophish 2017-03-08 11:29:05
Hi folks
monochrom 2017-03-08 11:30:31
I consider it unlikely that unsafePerformIO caused the difference.
jophish 2017-03-08 11:31:41
When do people find it appropriate to curry constraints to functions? i.e. `foo :: Eq a => Num a => a -> a -> a` instead of `foo = (Eq a, Num a) => a -> a -> a`
monochrom 2017-03-08 11:32:06
I consider it far more likely that the order of optimization stages caused the difference. Namely, my hypothesis: First looking for what you can factor out as CAFs, and only after perform simplication and discovering data independence.
jophish 2017-03-08 11:32:22
I have an intuition for where this is a nice thing to do, but am having trouble formalising it
monochrom 2017-03-08 11:33:38
So, for the no-const version: i is not mentioned anywhere syntactically, so factor out trace "dm" (return ()) as its own CAF first, call it xxx, now proceed to compile (\i -> xxx).
monochrom 2017-03-08 11:34:22
And for the has-const version: "Oh nothing to factor out as CAF". Only later to simplify const "dm" i to "dm".
lyxia 2017-03-08 11:34:30
jophish: what's an example where this is useful?
monochrom 2017-03-08 11:34:42
(And so no dependence on i after all, but the factoring ship has sailed.)
jophish 2017-03-08 11:35:52
lyxia: for example I might pass in a bunch of KnownNat constraints to a function after reifying them in a function taking a bunch of Naturals
jophish 2017-03-08 11:36:18
it's nice to highlight the similarities between these two functions by replacing the ->s with =>s
jophish 2017-03-08 11:36:35
admittedly this is a niche case, I'll try and think of a more compelling one
kuribas 2017-03-08 11:36:46
monochrom: this has the same bevaviour: http://lpaste.net/2846700419663527936
jophish 2017-03-08 11:37:29
These kind of signatures most often appear in the parts of our codebase which do a lot of type level computation and term -> type doohickery
monochrom 2017-03-08 11:38:44
Well yeah I'm just referring to the trace expression and whether it syntactically involves i or not.
monochrom 2017-03-08 11:39:23
No one will factor out "trace dm (return ()) >> return i" but the "trace dm (return ())" part can always be factored out.
kuribas 2017-03-08 11:40:01
but the inliner runs in many stages.
monochrom 2017-03-08 11:40:52
Yes, my hypothesis still has a lot of holes.
kuribas 2017-03-08 11:41:02
anyway idk, I am not a ghc expert...
monochrom 2017-03-08 11:41:05
But a lot other hypotheses are clearly worse.
kuribas 2017-03-08 11:41:39
I guess trace, unsafePerformIO, etc... will be always unpredictable.
kuribas 2017-03-08 11:41:51
It's isn't even the same in ghci and compiled.
kuribas 2017-03-08 11:42:37
In my case it's only for debugging, so that's fine.
monochrom 2017-03-08 11:42:46
To some extent, trace is intended to expose compiler mutilations.
monochrom 2017-03-08 11:43:37
It does not advertise itself as "I will show you what happens when faithfully following the vanilla naive lazy evaluation strategy".
monochrom 2017-03-08 11:44:00
It totally intends to show "what did the compiler decide to actually do"
monochrom 2017-03-08 11:44:34
But "compiler" does vary along the axis of ghci -> O0 -> O1 -> O2.
bennofs 2017-03-08 11:44:50
monochrom: doesn't trace inhibit at least some floating out optimization?
