Welkin 2017-02-11 06:45:25
Bish: why do you want to have jit?
Bish 2017-02-11 06:45:27
hm.. well, i really like the concept of functional programming, after read myself into the theory of it
Bish 2017-02-11 06:45:39
Welkin: because vm always means bad performance.. without jit
nitrix 2017-02-11 06:45:40
Bish: Typically, people that never try FP will never like it. I'm sure there are statistical evidences.
Bish 2017-02-11 06:45:54
to my understanding a perfect jit would make a bytecodevm as fast as native code ( which doesn't exist, ofc )
nitrix 2017-02-11 06:46:11
Bish: So the best recommendation would be for you to try it and see if it's for you.
Lokathor 2017-02-11 06:46:20
Bish, erlang has reasonable performance if you use it for what it's intended for :P
Bish 2017-02-11 06:46:32
what is is intended to do?
Bish 2017-02-11 06:46:51
http://b.z19r.com/upload/did-you-just-tell-me-to-go-fuck-myself.jpg
Bish 2017-02-11 06:46:59
that?
Lokathor 2017-02-11 06:47:25
no
Lokathor 2017-02-11 06:47:33
Erlang is good for highly concurrent programs
Bish 2017-02-11 06:47:43
that sounds like something i like
Lokathor 2017-02-11 06:47:53
because it's designed around having lots and lots of little processes passing around messages
Lokathor 2017-02-11 06:48:19
it has worse straight line performance than just writing whatever in another language, if you're only going to be doing straight line computations
nitrix 2017-02-11 06:50:03
It has an overhead cost but that same overhead is what allows you to distribute the work to multiple threads/machines, making it cost-worthy again past some treshold.
Lokathor 2017-02-11 06:51:04
yes, and of course all the normal concurrency limits apply, "running on N cores won't get you a Nx speedup if your program isn't actually that concurrent", and so on
Bish 2017-02-11 06:51:34
actually i don't have a use case, i am in search of the holy grail.. meaning i want to do all with it
Bish 2017-02-11 06:51:55
right now this was ruby to me, which is like the opposite of functional
Bish 2017-02-11 06:52:03
(meaning it has state all over the place)
Bish 2017-02-11 06:52:16
i am aware of the fact that this holy grail might not exist
Lokathor 2017-02-11 06:52:52
the holy grail is either Haskell, Rust, or Erlang. probably, depending on use case
nitrix 2017-02-11 06:52:53
C.S. is going to be a perpetual tradeoff between space and speed. So no.
nitrix 2017-02-11 06:54:23
(Because we're working with finite machines)
Bish 2017-02-11 06:54:42
why rust?
Bish 2017-02-11 06:55:09
nitrix: i know all that :D i just like to dream
Lokathor 2017-02-11 06:55:10
Rust wins the "no overhead" category, Erlang wins the "never stops" category, Haskell wins the rest because look at the channel name
Bish 2017-02-11 06:55:27
but rust is not functional is it?
nitrix 2017-02-11 06:55:39
It's general purpose.
nitrix 2017-02-11 06:55:56
Multi paragdim :)
Bish 2017-02-11 06:56:17
haskell isn't ?
Lokathor 2017-02-11 06:56:30
You could do things functionally-oriented in rust if you wanted to, but that's probably going to be worse for your performance, BUT, it'd be pretty obvious the whole time what the performance hits were going to be
nitrix 2017-02-11 06:57:01
Bish: Of course haskell is functional.
Bish 2017-02-11 06:57:20
doesn't mean it's not general purpose
Bish 2017-02-11 06:57:24
or does it?
Lokathor 2017-02-11 06:57:50
haskell is a general purpose language that is also a functional language, correct
nitrix 2017-02-11 06:58:09
Bish: I haven't said otherwise. I think you're getting tangled in your own questions.
sandonfuge 2017-02-11 06:58:11
Bish: You can do anything with Haskell, but sometimes Haskell might not be the best choice.
nitrix 2017-02-11 06:58:30
Bish: The argument made for Rust was the "no overhead" part.
Bish 2017-02-11 06:59:55
whats haskells overhead?
Bish 2017-02-11 06:59:58
i mean it compiles to native
nitrix 2017-02-11 07:00:57
Sure and that native code can still contain overheads in respect to how other languages are translated natively.
Lokathor 2017-02-11 07:01:03
Haskell has a garbage collector, and lazyness is also a lot of overhead, and also the way it treats numbers can be a lot of overhead too, and List is a linked list which is a pretty bulky data type so if you use it for all of your sequences instead of switching to Vector as needed you'll be losing some there too for example
nitrix 2017-02-11 07:01:26
For one, Haskell programs have a very important runtime system that they all depend on.
Bish 2017-02-11 07:01:40
oh sure forgot about gc
Bish 2017-02-11 07:01:53
lists are real lists :o?
Bish 2017-02-11 07:01:54
dafuq
Bish 2017-02-11 07:02:05
thought they will be arrays in mem
nitrix 2017-02-11 07:02:11
Bish: It's not just GC. There are thunks and everything.
nshepperd 2017-02-11 07:02:20
[] is a cons list
Lokathor 2017-02-11 07:02:31
a haskell "List" is a linked list
nitrix 2017-02-11 07:02:32
Bish: We have boxed values and quite a lot of pointer indirection for various things.
nitrix 2017-02-11 07:02:46
Heck, strings are linked lists.
exio4 2017-02-11 07:03:08
note that in Haskell, what you see isn't what you get in terms of assembly, with optimizations, a list might be removed from the final code
Lokathor 2017-02-11 07:03:12
plays murder on your cache. that's why switching to Vector and Text and ByteString and such get such performance benefits
Lokathor 2017-02-11 07:03:20
they're not magic, they're just cache friendly
nshepperd 2017-02-11 07:03:23
for many cases, haskell overhead is not very terrible though. because things can be inlined and erased
nitrix 2017-02-11 07:03:55
The overheads are made up elsewhere by the variety of optimizations the language abstractions offer.
Lokathor 2017-02-11 07:04:18
there's that too. When you tell the compiler what things should be what other things, and not the specific memory operations it should do, then it's free to sometimes make things faster than you would have
nshepperd 2017-02-11 07:04:33
if you produce a list and immediately consume it, you usually get a loop in asm instead of building and destroying a linked list
exio4 2017-02-11 07:07:35
even so, GHC's GC is heavily optimized for that kind of situation
Lokathor 2017-02-11 07:09:26
i wonder how different "data StrictHeadList a = Nil | Cons !a (StrictHeadList a)" would be performance wise
Lokathor 2017-02-11 07:09:41
probably "crazily different in some way you don't expect"
Bish 2017-02-11 07:23:02
Lokathor: plays murder on your cache
Bish 2017-02-11 07:23:14
lists or arrays
Lokathor 2017-02-11 07:23:34
linked lists are bad for cache, arrays are good for cache
Bish 2017-02-11 07:23:46
yeah i guessed so, but your statement confused me
tsahyt 2017-02-11 07:23:56
with the caveat that you can implement cache efficient lists too, although I'm not sure what that would look like in haskell
Bish 2017-02-11 07:24:14
but why do lists really have to be lists?
Bish 2017-02-11 07:24:28
i really thought they gonna be abstracted away ( is that even a word in english )
monochrom 2017-02-11 07:24:38
Lokathor: scanl for StrictHeadList will use a lot less space
tsahyt 2017-02-11 07:25:04
having lists behave like lists sometimes and like arrays at other times when the optimizer happens to trigger would be even worse. predictability is important
Lokathor 2017-02-11 07:25:26
Bish, when you load memory address X, the CPU will often load X+1, X+2, X+3, and so on, since loads are so long relative to the instrucitons that act on the memory once it's in cache. With an array, this is a helpful optimization, with a linked list it's not helpful since you're just jumping some other place anyway
Bish 2017-02-11 07:25:35
yeah i get that, but why does it really have to be list, why could you not construc them as arrays
Bish 2017-02-11 07:26:01
Lokathor: i know all that i studied cs.. but it doesn't help me understand why they're not just virtually lists
exio4 2017-02-11 07:26:07
because of the way it is constructed
Bish 2017-02-11 07:26:27
wow, that's some sherlock statement there
Lokathor 2017-02-11 07:26:30
A lazy haskell list has very different properties from an array. Particularly, a lazy list can be infinite and generated on the fly, but an array must be a fixed size that you pick when you allocate it
Bish 2017-02-11 07:26:32
it is because it has been made this way
monochrom 2017-02-11 07:27:05
Bish, I think you're pitching it at the wrong level of programming. You need to go higher level and go declarative, in which you describe problems (and the computer solves it the best way) not solutions.
Bish 2017-02-11 07:27:19
monochrom: isn't that opinion?
monochrom 2017-02-11 07:27:29
No.
monochrom 2017-02-11 07:27:54
The Haskell language is still a language for writing solutions, not writing problems.
Bish 2017-02-11 07:28:13
i don't know what you're trying to say :D
monochrom 2017-02-11 07:28:24
It wants to respect the programmer's will of sticking to list, if the programmer says "list".
tsahyt 2017-02-11 07:28:45
if you want an array, there's Array
tsahyt 2017-02-11 07:28:48
and Vector for that matter
tsahyt 2017-02-11 07:28:54
it's nice to know what's actually going on
Bish 2017-02-11 07:28:58
that's like saying you don't want cache, because if programmer says memory he wants memory
Lokathor 2017-02-11 07:29:01
Bish, here's an example. To have a list of all the postive Int values, you just write [0..], and that'll take up just a few bytes of memory until you start to evaluate it. If you wanted an array of all the positive Int value you'd use up 2^63 * 8 bytes of memory all at once
Bish 2017-02-11 07:29:33
Lokathor: yeah i understand, but i don't get why non-infinite lists will not be saved as arrays
Bish 2017-02-11 07:29:49
i mean.. infinite arrays will also not be in ram, since there is not quite enough memory for it
tsahyt 2017-02-11 07:29:52
I don't think that's even possible to optimize in all cases
monochrom 2017-02-11 07:29:56
Yes, I would say that too. The programmer wants memory.
exio4 2017-02-11 07:29:56
Bish: how do you know if a list isn't infinite?
tsahyt 2017-02-11 07:30:21
deciding whether a list will be infinite from its construction is surely equivalent to the halting problem in the general case, isn't it?
monochrom 2017-02-11 07:30:48
Did you notice how the cache implementers took so much pain to make sure that the programmer can't tell the difference between memory and cache? (Except by looking at the clock.)
Lokathor 2017-02-11 07:31:04
i admit that most list literals would possibly be convertable to arrays, but then you wouldn't be able to mix those list literals with other list operiaotns because the internal reprisentation of a list and an array are quite different
Bish 2017-02-11 07:31:09
monochrom: yeah that's all im saying... want a list? you get a list, but it doesn't have to be implemented as list
exio4 2017-02-11 07:31:51
Bish: quite often - it doesn't even exist in memory, or only a few cells exist at an specific point of time.
Bish 2017-02-11 07:32:23
i get that, was just wondering
exio4 2017-02-11 07:32:35
Bish: (:) provides fast cons, too. that operation is expensive on arrays :)
monochrom 2017-02-11 07:34:09
Bish: Go to grad school, do your PhD on writing a compiler that does what you said.
monochrom 2017-02-11 07:34:29
It has not happened because you haven't done it.
tsahyt 2017-02-11 07:35:14
you can also build a structure that's inbetween right now in Haskell, say [Vector a], with a corresponding list-like interface to it
exio4 2017-02-11 07:37:01
tsahyt: so, a generic Data.ByteString.Lazy? :P
tsahyt 2017-02-11 07:37:08
basically, yeah
tsahyt 2017-02-11 07:37:19
lazy list of chunks
Bish 2017-02-11 07:37:22
monochrom: geez, take a chill pill
monochrom 2017-02-11 07:37:35
No, you take a chill pill.
Tuplanolla 2017-02-11 07:37:36
Don't we already have that somewhere, tsahyt?
nshepperd 2017-02-11 07:37:38
also you could add extra constructors to the list, like 'Cons4 a a a a [a]' and have the compiler automatically use them 'when appropriate'. but that would 1. be complicated 2. have overhead 3. probably mess with other optimizations
tsahyt 2017-02-11 07:37:44
Tuplanolla: I'd be surprised if we didn't
Tuplanolla 2017-02-11 07:37:54
Likewise.
Lokathor 2017-02-11 07:38:20
Bish, basically, the benefits of an array are great if you're willing to pre-allocate, but the things you'd use Lits for aren't things you want to pre-allocate
Lokathor 2017-02-11 07:38:37
in Haskell, the List type is more often for loop control than for holding all your data
Lokathor 2017-02-11 07:39:02
we've got other types for holding data that are each specialized to how you're using the data (Set, Sequence, Vector, etc)
Tuplanolla 2017-02-11 07:40:09
You're unlikely to come across the C idiom `char buf[BUFSIZ]` in Haskell, Bish.
nshepperd 2017-02-11 07:40:13
tsahyt: actually I use [Vector a] sometimes, as a cheap way of holding some arrays that are waiting to be concatenated
makrusak 2017-02-11 07:40:39
Hello, Sarkin :)
tsahyt 2017-02-11 07:40:58
nshepperd: what are the performance characteristics of that then, since every concatenation would take O(m+n) time, wouldn't it?
sarkin 2017-02-11 07:41:12
makrusak hey
Lokathor 2017-02-11 07:41:31
tsahyt, you'd walk the whole list and compute the final size once I think :P
Bish 2017-02-11 07:41:42
not saying it has to be this way, im asking questions to understand
Bish 2017-02-11 07:41:49
if you dont want to be part of that, don't be
Bish 2017-02-11 07:42:03
Lokathor: thanks, that helps
Lokathor 2017-02-11 07:42:37
Bish, for better or worse, Haskell has more types that are each a little more specialized than you would have in other languages. It's our version of being performance aware
nshepperd 2017-02-11 07:42:38
tsahyt: well, when I concatenate two of those it takes O(length of list) instead of O(length of arrays). And then yeah at the end I concatenate all the arrays at once in O(final array length)
tsahyt 2017-02-11 07:42:56
using mconcat I suppose
nshepperd 2017-02-11 07:43:25
maybe I should really be using DList or Data.Sequence for that use case, but [] works well enough for 1-10 elements. the important thing is the constant factors are much lower
nshepperd 2017-02-11 07:43:33
yep
tsahyt 2017-02-11 07:43:36
nice
tsahyt 2017-02-11 07:43:52
some digging in vector suggests that this all happens due to fusion magic that I don't understand
