kuribas 2017-02-23 09:47:08
monochrom: the disadvantage would be that a user will be required to write a SPECIALIZE pragma if he wants the optimizations.
kuribas 2017-02-23 09:48:12
I am also experimenting with SSE, but it seems SSE support is very limited in ghc.
kuribas 2017-02-23 09:48:34
The easiest is to use the FFI to write SSE code in C.
kuribas 2017-02-23 09:49:15
Ghc doesn't support all SSE instructions, and it only works with a particular version of LLVM.
kuribas 2017-02-23 09:56:42
SSE with rewrite rules and specialize pragmas would be quite powerfull.
kuribas 2017-02-23 09:57:02
It seems most haskell users aren't really concerned with raw speed.
Tuplanolla 2017-02-23 10:05:08
That's because laziness is such a hassle, kuribas.
Tuplanolla 2017-02-23 10:05:34
If I'm already working on a problem I hardly understand, having to reason about thunks is too much.
kuribas 2017-02-23 10:06:09
Tuplanolla: yeah, the first thing when you need performance is to eliminate lazyness...
geekosaur 2017-02-23 10:06:32
not always
kuribas 2017-02-23 10:06:33
Tuplanolla: core can show when ghc makes a function strict.
Tuplanolla 2017-02-23 10:06:34
Not even everywhere, but in strategic places.
geekosaur 2017-02-23 10:06:48
that's the real problem; elimiate laziness in the wrong place and perf can easily get worse
Zemyla 2017-02-23 10:06:57
Okay, so WTF.
geekosaur 2017-02-23 10:07:18
but people always want something where a simpleminded rule like "eliminate laziness" will fix everything
shapr 2017-02-23 10:08:16
geekosaur: that usually does work, stop being lazy and learn more stuff!
davean 2017-02-23 10:08:17
laziness makes a lot of performance a lot easier, like not having to rewrite your algs to have them work together efficiently
kuribas 2017-02-23 10:08:33
For things like numeric code, matrix computations, etc... a sequential style will give better performance
Tuplanolla 2017-02-23 10:09:04
Suddenly CUDA.
maerwald 2017-02-23 10:09:22
davean: ? it's mostly just incredibly hard to reason about in a larger context
kuribas 2017-02-23 10:09:40
Tuplanolla: but you have to be carefull with latency etc...
davean 2017-02-23 10:09:51
maerwald: it allows composittion
maerwald 2017-02-23 10:10:00
I don't need laziness for composition
Tuplanolla 2017-02-23 10:10:00
Fortunately that's not my job.
lpaste_ 2017-02-23 10:10:04
Zemyla pasted "Can't configure containers GitHub fork for tests and benchmarks" at http://lpaste.net/352920
davean 2017-02-23 10:10:36
maerwald: I'd like to see you get alg composition without it or rewriting each alg into one every time! that would be a neat trick
Zemyla 2017-02-23 10:10:43
cabal says they're all there, but that they're missing D:
kuribas 2017-02-23 10:11:37
lazyness is great from a higher-level point of view, but for low level number crunching, sequential is easier...
kuribas 2017-02-23 10:11:53
The extra indirection from lazyness comes with a cost.
SLi 2017-02-23 10:12:27
More than CPU performance, I've always had problems with space. When the input to my program is even somewhat large (example: parsing a few megabytes worth of lispish structure and outputting the same in a different format), I always seem to run into the resulting program eating hundreds of megabytes or gigabytes, and the reason is always hard to find (with the heap profiling tools I'm aware of).
SLi 2017-02-23 10:12:46
I wonder if using -XStrict and using laziness where I want it would help.
Zemyla 2017-02-23 10:13:13
ezyang: Do you know what the problem might be, why it can't find these things I've explicitly installed?
shapr 2017-02-23 10:13:14
SLi: in my experience, strictifying the data in records is the easy fix
kuribas 2017-02-23 10:13:40
SLi: you aren't using String, or lazy IO are you?
SLi 2017-02-23 10:13:48
shapr: That's what I usually do after getting frustrated with profiling, sprinkle ! and deepseq around in the hope that it helps :D
shapr 2017-02-23 10:15:34
SLi: yeah, that's the shotgun debugging fix for me
SLi 2017-02-23 10:15:37
kuribas: Hmm, I think I have been using lazy IO. And in some cases String when I've been too lazy to switch to ByteString. Would that explain? Why does it cause such a huge effect? :) I've thought of String as something that is mostly very slow, but not inherently memory hungry.
SLi 2017-02-23 10:16:43
shapr: But then there's so many possible places for ! and deepseq that it's frustrating... which makes me think I should try -XStrict and explicit laziness annotations.
kuribas 2017-02-23 10:17:25
SLi: I'd try that first in any case. Lazy IO is known to be not very efficient.
shapr 2017-02-23 10:17:38
yeah, but that gets fixed by pipes and that sort of thing, yeah?
thatguy 2017-02-23 10:20:32
is there a way to write the elem function so that it works on infinite lists?
Tuplanolla 2017-02-23 10:21:04
> 42 `elem` [1 ..]
lambdabot 2017-02-23 10:21:08
True
Tuplanolla 2017-02-23 10:21:24
Apparently, thatguy.
thatguy 2017-02-23 10:21:44
> -1 `elem` [1..]
lambdabot 2017-02-23 10:21:50
mueval-core: Time limit exceeded
kuribas 2017-02-23 10:22:12
> isJust $ find (==42) [1..]
lambdabot 2017-02-23 10:22:14
True
glguy 2017-02-23 10:22:15
thatguy: You can decide how much you're willing to search and 'take' that much of the list
thatguy 2017-02-23 10:22:57
What is the best practice way? I think my haskell tutorial said that you should try to avoid functions which can work infinitely long
thatguy 2017-02-23 10:23:04
or is there sometimes just no way around it?
glguy 2017-02-23 10:23:26
thatguy: You can avoid making infinite lists
thatguy 2017-02-23 10:23:41
glguy, are infinite lists considered bad style?
thatguy 2017-02-23 10:23:43
just out of interest
Tuplanolla 2017-02-23 10:23:55
You can't however will undecidable or semidecidable problems out out existence, thatguy.
monochrom 2017-02-23 10:23:58
No, it is good style.
glguy 2017-02-23 10:24:20
thatguy: You can use them, but it's important to know when you are
monochrom 2017-02-23 10:24:26
I disagree with "avoid functions which can work infinitely long".
thatguy 2017-02-23 10:24:47
I think the cis 194 lecture says it right at the beginning but maybe I am remembering wrong
monochrom 2017-02-23 10:25:19
"[1..]" can work infinitely long, yet we use "zip xxx [1..]" all the time.
monochrom 2017-02-23 10:26:10
And infinite lists (and also some functions that "can" work infinitely long) are indispensible for "piecemeal programming" which cis194 advocates.
thatguy 2017-02-23 10:26:32
ok so but it is not bad practice to write functions that cannot work with infinite lists (or would eventually take infinitely long) if I am sure I won't use infinite lists?
thatguy 2017-02-23 10:26:49
shouldn't then the data type somehow declare that this function is thought to be applied only to finite lists?
glguy 2017-02-23 10:27:22
No, Haskell's type system doesn't help you with that question
glguy 2017-02-23 10:28:08
Given even an Int, there's no guarantee that evaluation of it will finish
monochrom 2017-02-23 10:28:11
It is bad practice to cargo-cult, is all I'll say.
thatguy 2017-02-23 10:29:06
glguy, ok thanks
thatguy 2017-02-23 10:29:20
monochrom, I think the only term I've read is wholemeal programming :D
thatguy 2017-02-23 10:29:25
maybe I read it the wrong way
thatguy 2017-02-23 10:29:31
what is cargo-cult?
monochrom 2017-02-23 10:30:30
rules of thumbs.
thatguy 2017-02-23 10:30:44
ah and I also have a another question: a lot of functions just work for positive integers, not you could just let them return a Maybe X which is done in the tutorial, but why not make a new (declerative) type for positive integers
lyxia 2017-02-23 10:31:17
there is already one
lyxia 2017-02-23 10:31:27
nobody uses it
thatguy 2017-02-23 10:31:40
is there a reason?
monochrom 2017-02-23 10:31:42
oh, so it's called "wholemeal" not "piecemeal".
thatguy 2017-02-23 10:32:22
I thought the function types should be as declerative as possible
thatguy 2017-02-23 10:33:06
monochrom, I just mentioned it because I found it funny that it sounds like the exact opposite ;) didn't mean to be rude
lyxia 2017-02-23 10:33:07
It's not well known, and maybe just not worth the effort.
monochrom 2017-02-23 10:33:51
Don't worry, I just had to checked cis194 again.
lyxia 2017-02-23 10:34:31
thatguy: often the context is enough to tell whether it makes sense to call a function with negative numbers.
monochrom 2017-02-23 10:34:31
Do you also want a type for non-negative integers?
xcmw 2017-02-23 10:35:21
Which is better? binary, cereal, or store?
mbrock 2017-02-23 10:35:33
thatguy: such a number type can't implement the subtraction operator, because one positive integer minus another positive integer may not be a positive integer... it's a similar problem to trying to have a type for finite lists -- basically I think you end up needing to do some kind of theorem proving and everything becomes more complicated
thatguy 2017-02-23 10:36:12
I just thought that it somehow fits better into this haskell mindsetting. this "allowing some more inputs and then first checking them if they are ok" is what we are trying to avoid I thought
mbrock 2017-02-23 10:36:19
thatguy: but at some point you will probably look at dependently typed languages like Agda and Idris which allow you to formulate types that have all kinds of interesting membership criteria
Clint 2017-02-23 10:36:30
xcmw: i assume store because i've never tried it
glguy 2017-02-23 10:37:15
In Agda you'll still pay a steep price for trying to encode too much in your types
thatguy 2017-02-23 10:37:19
mbrcknl, I am just starting out in haskell :D I hope I can get into this language first
glguy 2017-02-23 10:37:23
it just gives you the rope to do that
thatguy 2017-02-23 10:37:42
allthough last time when I asked about n-dimensional fields also someone said that I need dependently typed languages I think
mbrock 2017-02-23 10:38:12
Haskell is kind of slowly and carefully adopting features from the dependently typed world
mbrock 2017-02-23 10:39:06
it's pretty interesting what kind of tradeoffs are involved in Haskell language design and evolution
Tuplanolla 2017-02-23 10:40:00
Does reasoning about type erasure become a problem in dependently-typed languages?
thatguy 2017-02-23 10:40:42
mbrock, I hope I stick to haskell long enough s.t. I start reading about the language design and trade offs
thatguy 2017-02-23 10:40:56
but first step is to get productive before I lose motivation and forget everything I learnt
thatguy 2017-02-23 10:40:59
which is my fear
thatguy 2017-02-23 10:41:06
thanks everyone for helping once again
mbrock 2017-02-23 10:43:26
sometimes I wish I could just load my Haskell code into Agda and do some proofs
mbrock 2017-02-23 10:43:44
(that's my digression, not really relevant to your questions thatguy)
thatguy 2017-02-23 10:44:19
mbrock, are you doing automatic theorem proving?
mbrock 2017-02-23 10:45:01
at the moment no, but I'm starting to really want to
