ertes 2017-02-02 04:45:23
tsahyt: a + (b + (c + d)) -- c and d are quickly accessible in a HashSet, because it's constructed that way
ertes 2017-02-02 04:45:46
with lists the full list needs to be traversed first
tsahyt 2017-02-02 04:46:08
oh, let me try a left fold
ertes 2017-02-02 04:46:16
tsahyt: should give the same result
tsahyt 2017-02-02 04:47:55
with strict left folds, vectors are by far the fastest
ertes 2017-02-02 04:48:13
tsahyt: properly constructed lists should be just as fast, if not faster
tsahyt 2017-02-02 04:48:41
ertes: http://sprunge.us/cgEg
tsahyt 2017-02-02 04:49:02
foldl/list comes out at 593.7µs, and for vectors it's 266.4µs
tsahyt 2017-02-02 04:49:08
definitely a significant difference there
tsahyt 2017-02-02 04:49:59
maybe I just screwed something up in the benchmark construction
ertes 2017-02-02 04:50:36
tsahyt: try this: whhf (foldl' (+) 0 . enumFromTo 1) 100000
ertes 2017-02-02 04:50:40
*whnf
ertes 2017-02-02 04:51:00
tsahyt: try this: whnf (foldl' (+) 0 . enumFromTo 1) (100000 :: Int)
tsahyt 2017-02-02 04:51:05
hmm so this way it would exploit fusion I suppose?
sdx23 2017-02-02 04:51:17
http://termbin.com/s06q what could cause stack to use two different versions of cabal?
ertes 2017-02-02 04:51:20
tsahyt: that, too, but most notably it wouldn't build a list in memory
nitrix 2017-02-02 04:51:27
Tuplanolla: With my limited (and very recent) knowledge of proofs and whatnot, I'd say that possibly it proves that 42 is an inhabitant of the type Int?
ertes 2017-02-02 04:51:40
tsahyt: your 'l' is shared, which ruins everything
tsahyt 2017-02-02 04:51:57
ertes: in my actual use case, I already have data in memory. Right now I'm just trying to eyeball what representation I should go for
sdx23 2017-02-02 04:52:02
nb: I installed gtk2hs-buildtools by stack install ..., because it was not detected as a dependency automatically.
ertes 2017-02-02 04:52:04
it means that your list fold is traversing an actual linked list in memory
Tuplanolla 2017-02-02 04:52:14
It's kind of nice that it proves its own existence, nitrix.
tsahyt 2017-02-02 04:52:22
obviously the folding operation is not a simple (+) either, but I thought I'll use something that is predictable to get a hold of how the actual folding compares
ertes 2017-02-02 04:53:00
tsahyt: whether your data structure is in memory or not is an important piece of information… if you try the benchmark i gave you, i would expect it to outperform all the others
ertes 2017-02-02 04:53:04
including the vector one
nitrix 2017-02-02 04:53:12
Tuplanolla: Yeah it's a little funny looking but I think I get the point.
nitrix 2017-02-02 04:53:36
Tuplanolla: Seems like a nice foundation to begin the reasoning.
merijn 2017-02-02 04:53:57
hmmm, my traceM doesn't seem to get evaluated each time th code runs
tsahyt 2017-02-02 04:54:30
ertes: correct, it's a lot faster.
tsahyt 2017-02-02 04:54:34
about 10x
tsahyt 2017-02-02 04:55:17
right now I'm storing a HashSet because that was just easy to construct, and for reasons that I forgot about I then end up toList-ing that, and foldr over this. That's hardly ideal, but it gets worse because this code is called many million times over the lifetime of the program
tsahyt 2017-02-02 04:55:41
so that's an obvious inefficiency right there. I think I'll use a vector instead, as that performs best with an already in-memory foldl' it seems
ertes 2017-02-02 04:56:03
tsahyt: toList-ing is fine, as long as you use proper traversals… for example you would sum with foldl'
ertes 2017-02-02 04:56:30
tsahyt: i would expect (foldl' (+) 0 . Sh.toList) to be just as fast as (Sh.foldl' (+) 0)
ertes 2017-02-02 04:56:35
where Sh is Data.HashSet
reactormonk 2017-02-02 04:56:56
I've got a lens for a Maybe and a record to write data into - how do I maybe update that field?
ertes 2017-02-02 04:57:14
reactormonk: a lens for a Maybe?
ertes 2017-02-02 04:57:30
that sounds not quite right, unless the lens is 'id'
reactormonk 2017-02-02 04:57:35
ertes, the data comes from a lens via _Just
M0000 2017-02-02 04:57:50
is there any chance that combining InterpreterT and InputT is what is causing my segmentation fault?
ertes 2017-02-02 04:57:57
reactormonk: ah, that's a prism, not a lens, but it works as a setter
nitrix 2017-02-02 04:58:03
I thought _Just was a prism.
reactormonk 2017-02-02 04:58:17
ertes, oops. So I have a prism to get data from, and a record to maybe update.
ertes 2017-02-02 04:58:21
reactormonk: _Just . myField %~ f
ertes 2017-02-02 04:58:28
like this?
ertes 2017-02-02 04:59:25
composing a prism with a lens yields a traversal, so you can use it as a setter and *sometimes* as a getter
jophish 2017-02-02 04:59:35
joeyh: Where's a good place to raise an issue about concurrent-output?
jophish 2017-02-02 04:59:42
(nothing major, just documentation)
tsahyt 2017-02-02 04:59:43
ertes: maybe it's my benchmark again, but it turns out not to be in this case.
reactormonk 2017-02-02 04:59:57
Yeah, sometimes. Somehow (authorityL .> _Just .> authorityPortL .> _Just .> portNumberL) bugs. (via https://hackage.haskell.org/package/uri-bytestring-0.2.2.1/docs/URI-ByteString.html#g:7 )
tsahyt 2017-02-02 05:00:02
ertes: using whnf (L.foldl' (+) 0 . S.toList) s
tsahyt 2017-02-02 05:00:57
it ends up taking the toList time + the foldl' over the list. I happened to have those benchmarked separately too.
reactormonk 2017-02-02 05:01:07
bugs as in, the view complains about "Could not decuce (Monoid Int) arising from a use of "Just""
ertes 2017-02-02 05:01:12
tsahyt: it may be traversing a highly volatile list, which does add some constant cost
reactormonk 2017-02-02 05:01:12
Eh, _Just
tsahyt 2017-02-02 05:01:32
ertes: highly volatile?
M0000 2017-02-02 05:01:33
I'm getting a seg fault, and I'm wondering if it's some combination of the things that I'm less experienced with. The main loop is in InputT, and it calls runInterpret (from the Hint module), and also forks threads
ertes 2017-02-02 05:01:45
tsahyt: you only ever see a single cons in memory
ertes 2017-02-02 05:01:57
no actual in-memory linked list
tsahyt 2017-02-02 05:02:09
hmm interesting.
M0000 2017-02-02 05:02:15
doing an experiment right now to reduce the complexity… I got rid of InputT and so far it's not seg faulting but haven't built up enough functionality yet to really test
ertes 2017-02-02 05:02:38
tsahyt: basically what would happen with something like (foldl' g z (unfoldr f x0)), if they weren't fused
ertes 2017-02-02 05:02:56
it would still run in constant memory, but there would be some extra cost for constructing and then immediately garbage-collecting cons cells
tsahyt 2017-02-02 05:03:29
hmm okay. so this comes down to fusion not triggering then?
ertes 2017-02-02 05:04:56
tsahyt: yeah, most likely
ertes 2017-02-02 05:05:21
tsahyt: i would expect it to trigger, if used like this: foldl' (+) 0 (Sh.toList xs)
ertes 2017-02-02 05:06:24
tsahyt: maybe try this, just to help the fusion rules a bit: whnf (\x -> foldl' (+) 0 (Sh.toList x))
ertes 2017-02-02 05:06:33
i can't imagine that to make a difference, but who knows =)
tsahyt 2017-02-02 05:07:16
hm that still doesn't work.
tsahyt 2017-02-02 05:07:35
In any case, it looks like going for vectors might be the best thing to do
ertes 2017-02-02 05:07:55
depends
tsahyt 2017-02-02 05:08:06
I can still use the HashSet for construction, and build the vector from there. this structure persists through the entire program and never gets changed.
tsahyt 2017-02-02 05:08:37
the more I do this optimization stuff, the more I see why people say that haskell performance can be tricky to reason about
ertes 2017-02-02 05:08:41
indexing and traversal are super-fast for vectors, especially with primitive/storable/unboxed ones, but pretty much everything else is slow
tsahyt 2017-02-02 05:08:59
I only do traversal with this
tsahyt 2017-02-02 05:09:22
thanks for reminding me of unboxed/storable ones though. since I'm basically just storing fancy ints in there, this would be easy to exploit
ertes 2017-02-02 05:09:55
well, since other languages don't give you lazy traversals, there simply is nothing to reason about… it's like saying: "chainsaws are complicated to use… kitchen knifes are way simpler!" =)
merijn 2017-02-02 05:09:59
tsahyt: tbh, performance is tricky in many languages if you want to be really fast :)
tsahyt 2017-02-02 05:10:46
agreed
ertes 2017-02-02 05:11:16
tsahyt: let me point your attention to what is probably my favourite sequence/set data structure: FingerTree v (Vector a)
ertes 2017-02-02 05:11:39
using the 'fingertree' package
tsahyt 2017-02-02 05:12:02
It's been a long time since I last looked at the FingerTree type, but is that roughly a sequence built up from vector chunks?
ertes 2017-02-02 05:12:11
this gives you chunked vectors, so it allows efficient appending, updating, etc.
ertes 2017-02-02 05:12:19
yeah, exactly
tsahyt 2017-02-02 05:12:24
nice. How does this compare to Data.Sequence?
michaelt 2017-02-02 05:12:34
tsahyt: if you are actually using Int, you could substitute Data.Vector.Unboxed
michaelt 2017-02-02 05:12:53
tsahyt: which is 78.45 μs against 280.2 μs for 'regular' vector
ertes 2017-02-02 05:13:12
tsahyt: well, (FingerTree v a) *is* Data.Sequence, if you choose v to measure every individual element as 1
aweinstock 2017-02-02 05:13:17
why doesn't Bool instantiate Data.Bits.Bits?
tsahyt 2017-02-02 05:13:23
78.45? I'm getting 212 here. wait let me check if I messed up somewhere
tsahyt 2017-02-02 05:13:45
hmm, no seems okay
nitrix 2017-02-02 05:14:00
aweinstock: Because packing and unpacking a bit from a data structure would result in more cycles from the CPU.
michaelt 2017-02-02 05:14:13
tsahyt: i'm using this http://sprunge.us/ghJi
michaelt 2017-02-02 05:14:19
tsahyt: oh you tried it.
nitrix 2017-02-02 05:14:22
aweinstock: Almost every languages represents booleans as a Char or an Int.
tsahyt 2017-02-02 05:14:39
michaelt: that is very interesting. I'm doing exactly the same thing.
michaelt 2017-02-02 05:14:42
tsahyt: just making sure you knew U.Vector is better if you happen to have an unbox type
ertes 2017-02-02 05:14:58
aweinstock: the real answer is: because.
tsahyt 2017-02-02 05:15:05
michaelt: how does unboxed and storable compare there?
ertes 2017-02-02 05:15:09
aweinstock: there is no technical reason why Bool is not a Bits
aweinstock 2017-02-02 05:15:09
nitrix: I think that's orthogonal to what I'm asking (about the typeclass Data.Bits.Bits, not representing Bool as an individual bit)
ertes 2017-02-02 05:15:26
aweinstock: "because Bool shouldn't be computed with", i guess
michaelt 2017-02-02 05:15:29
tsahyt: storable is less usable I'm not that familiar really
mbrock 2017-02-02 05:15:37
aweinstock: doesn't it though?
nitrix 2017-02-02 05:15:39
aweinstock: I'm not sure I understand.
nitrix 2017-02-02 05:15:47
aweinstock: There's an instance Bits Bool
mbrock 2017-02-02 05:15:47
aweinstock: https://hackage.haskell.org/package/base-4.9.1.0/docs/src/Data.Bits.html#line-401
aweinstock 2017-02-02 05:15:48
I'd just be convenient to have (xor :: Bool -> Bool -> Bool) in the stdlib for what I'm currently doing
tsahyt 2017-02-02 05:15:50
michaelt: really all I need from it is traverse this set/list/array of ints
ertes 2017-02-02 05:15:57
aweinstock: xor is (==)
ertes 2017-02-02 05:16:03
uhm
ertes 2017-02-02 05:16:05
(/=)
tsahyt 2017-02-02 05:16:09
the accumulator of the fold is where the magic happens, I just need the indices to work on from the vector
aweinstock 2017-02-02 05:16:30
mbrock: thanks (looks like I'm on 7.6.3, so it's a debian stable problem)
michaelt 2017-02-02 05:16:36
tsahyt: unboxed vector is kind of go-to for that in my view, but there may be considerations I didn't hear
aweinstock 2017-02-02 05:16:37
ertes: thanks for the workaround
nitrix 2017-02-02 05:16:58
aweinstock: It exists.
nitrix 2017-02-02 05:17:13
aweinstock: xor :: Bits a => a -> a -> a
nitrix 2017-02-02 05:17:32
aweinstock: Specialize the type variable `a` as Bool (because there is such instance Bits Bool) and off you go.
ertes 2017-02-02 05:17:33
aweinstock: GHC 7.6.3? that's ancient…
tsahyt 2017-02-02 05:17:38
michaelt: did you get the 78µs on foldr or foldl?
michaelt 2017-02-02 05:17:45
tsahyt: foldl'
michaelt 2017-02-02 05:17:57
foldr seemed suprisingly slow
aweinstock 2017-02-02 05:18:10
ertes: maybe I'll learn how to pin newer packages in apt someday, but for now (/=) works
tsahyt 2017-02-02 05:18:28
michaelt: compiler options?
michaelt 2017-02-02 05:18:31
foldl is the natural way of folding the underlying stream type, I think.
michaelt 2017-02-02 05:18:43
tsahyt: -O2
tsahyt 2017-02-02 05:18:47
oh that may make the difference then
aweinstock 2017-02-02 05:18:54
nitrix: I know how typeclass specialization works, it's just that the instance isn't in my (old) version of GHC
michaelt 2017-02-02 05:19:20
tsahyt: I'm a little surprised by the slowness of unboxed foldr not sure what's up
tsahyt 2017-02-02 05:19:20
yes, that's it
nitrix 2017-02-02 05:19:21
> xor <$> [True, False] <*> [True, False] -- aweinstock, here its truth table.
lambdabot 2017-02-02 05:19:24
[False,True,True,False]
tsahyt 2017-02-02 05:19:41
208µs for vector, 55.06µs for unboxed, 45.18µs for storable
tsahyt 2017-02-02 05:19:44
that's quite a speedup
ertes 2017-02-02 05:19:44
michaelt: you would use Storable for communicating with foreign libraries
michaelt 2017-02-02 05:19:48
tsahyt: -O2 is what I always use but I have no good arg for it
ertes 2017-02-02 05:20:05
for example storable vectors are very useful with CUDA, OpenCL, OpenGL, matrix libraries, etc.
michaelt 2017-02-02 05:20:07
ertes: right, which is why as I said I don't have much experience...
tsahyt 2017-02-02 05:20:31
hmm apparently this really *needs* -O2. -O1 doesn't yield the same result either
tsahyt 2017-02-02 05:20:39
fair enough, I can compile my stuff with -O2
merijn 2017-02-02 05:20:42
ertes: Know any companies doing CUDA from Haskell? :p
nitrix 2017-02-02 05:21:02
aweinstock: Using base < 4.7 seems like asking for trouble.
ertes 2017-02-02 05:21:04
merijn: companies? no =)
merijn 2017-02-02 05:21:17
I wouldn't mind getting paid to write some less awful CUDA bindings for Haskell :p
ertes 2017-02-02 05:21:34
merijn: they'd probably just use nvidia's C++ dialect =)
merijn 2017-02-02 05:21:48
ertes: For the kernels, sure
merijn 2017-02-02 05:22:01
ertes: But writing the host code in C++ is annoying
nitrix 2017-02-02 05:22:09
aweinstock: It's two years old ._.
aweinstock 2017-02-02 05:22:10
nitrix: any outright bugs, or just bunches of inconveniences like missing instances?
ertes 2017-02-02 05:22:18
merijn: looks like we need better marketing =)
merijn 2017-02-02 05:23:11
ertes: Well, writing the host code in haskell would require nicer haskell bindings first, but I can't justify the time to develop them atm :p
nitrix 2017-02-02 05:25:42
aweinstock: To me, the question should be presented the other way around. You should be trying your hardest to integrate the updates in your dependencies; especially if you find yourself needing something that got added 2 years ago, it seems like a huge cue.
nitrix 2017-02-02 05:26:36
aweinstock: You remind me of an old coworker that was doing just the strict minimum and didn't want to use Git and he had to use this bridge to connect his SVN repo to our Git repo.
merijn 2017-02-02 05:27:22
nitrix: To be fair, I fully support not using git :)
merijn 2017-02-02 05:27:30
It's using SVN instead that I can't support :p
tsahyt 2017-02-02 05:28:18
I wonder why unboxed/storable vectors require -O2 for the speedup
isBEKaml 2017-02-02 05:28:28
merijn: so what would you use? darcs?
merijn 2017-02-02 05:28:34
isBEKaml: Mercurial
isBEKaml 2017-02-02 05:28:47
merijn: Ah, why not darcs?
merijn 2017-02-02 05:29:16
Because I learned Mercurial first and because it has bidirectional support for git, so I can remain blissfully ignorant while colleagues use git :p
isBEKaml 2017-02-02 05:29:39
merijn: You are the perfect colleague for nitrix :P
michaelt 2017-02-02 05:29:59
tsahyt: dunno which of the extra optimizitions is being used, i see in the cabal file for `vector` that it demands "ghc-options -O2 -Wall" itself
nitrix 2017-02-02 05:30:01
I'd actually enjoy working with merijn.
nitrix 2017-02-02 05:30:17
I'd suck all his knowledge like a sponge c:
michaelt 2017-02-02 05:31:22
tsahyt: cabal defaults to -O1 I think, since -O2 takes longer frequently with no result
merijn 2017-02-02 05:31:25
Most of my knowledge consists of awful abuse of recursive make and bash :p
merijn 2017-02-02 05:31:34
michaelt: Cabal defaults to whatever you configure it to :p
tsahyt 2017-02-02 05:31:50
in any case even without optimizations it's faster than HashSet, so I'll take it
aweinstock 2017-02-02 05:31:50
nitrix: I'm trying to fuzz my crypto protocol before meeting with my advisor today; I'll update ghc this evening
merijn 2017-02-02 05:31:52
michaelt: You can change it in your config file :)
michaelt 2017-02-02 05:31:52
merijn: but i don't configure it
michaelt 2017-02-02 05:32:03
merijn: yes I know that
Tuplanolla 2017-02-02 05:32:24
I recall SPJ talking about improving compiler performance last year. Where are we on that right now?
dcoutts 2017-02-02 05:32:28
merijn, michaelt: yes, but the default default is -O (which means -O1)
michaelt 2017-02-02 05:32:47
dcoutts: yes tats what i said
dcoutts 2017-02-02 05:32:50
Tuplanolla: people are working on it. If you want details lurk in #ghc
dcoutts 2017-02-02 05:32:55
michaelt: yep
Tuplanolla 2017-02-02 05:33:28
I'm already at my lurk quota.
michaelt 2017-02-02 05:33:30
dcoutts: tsahyt was wondering why `vector` programs respond so well to -O2
tsahyt 2017-02-02 05:34:21
dcoutts: talking about cabal, is the foreign libraries support ready?
joeyh 2017-02-02 05:34:33
jophish: can just /msg me
dcoutts 2017-02-02 05:35:02
tsahyt: vector relies on stream fusion for lots of things, and that needs the extra effort of O2
dcoutts 2017-02-02 05:35:14
tsahyt: it's in cabal head
tsahyt 2017-02-02 05:35:41
nice! I've been meaning to play around with FRP to build LV2 audio plugins
tsahyt 2017-02-02 05:36:19
the other usecase I had for it disappeared when I switched to a different solver for my thesis, but it's still a feature I'm looking forward to
dcoutts 2017-02-02 05:37:16
tsahyt: if you can try it out now to make sure it works for you, you it'll be easier to get fixes in :-)
tsahyt 2017-02-02 05:38:04
I'll look into it. Unfortunately this thesis is taking up way too much of my time and I hardly get around to personal projects anymore.
k0001 2017-02-02 05:42:44
Has anyone seen this issue in xmonad? In the initial workspace I'm in when xmonad starts, windows occupy the entire screen even if I don't ask for it (going over xmobar and such). In the rest of the workspaces maximized windows don't cover xmobar and such.
