81–90 of 94 posts
Earlier quoted context omitted.
I’m not the best person to answer this question, but AFAIK it’s very very fast (in the rough vicinity of C). But also memory-hungry.
I'm pretty sure highly optimised code won't be elegant Haskell code though.
Hey, since this is likely to attract Haskell programmers: how fast is Haskell these days for a programmer intent on writing optimized code? I am particularly interested in its performance for numerical crunching like matrix operations and other stuff that benefit from SIMD.
If you’re writing idiomatic Haskell. Its performance is terrible. If you’re choosing to fight with Haskell, why? Just use something else. To understand why people claim Haskell is “fast”, you need to understand what they mean. What they mean is “if you opted to write C in such a way as you were performing similar amounts of copious and useless data copying, pointer following and stack blowing madness, Haskell will pe…
Earlier quoted context omitted.
How do you distinguish data shuffling from computation? What’s actual computation from this perspective?
Reading a row from a database and putting it on the screen, and reading some numbers from the keyboard and putting them in the database. These things I would not call computation. I mean sure, displaying needs to compute coordinates for where to light up pixels, but that's all already written. I just call it. Same with updating btrees when writing to the db. I'm guessing if all you do is this kind of db - screen - ke…
If you’re moving a lot of undifferentiated bytes the language you should use is historically C, more recently C++ (which is still the standard), or maybe soon Rust (which looks to become the standard).
If IO is a small part of your problem, performance needs to be good but not insane, and you’re mostly thinking about algorithms and mathematics?
Haskell is a very pragmatic choice there. OCaml is strong here too, and TypeScript is a very cool compromise between “mainstream” and “we do math here”.
Earlier quoted context omitted.
Philosophically speaking there is no difference. What parent commenter probably refers to is that you think in terms of computations and not in terms of data units. And that is just tremendously elegant.
Philosophically speaking there's a great difference. Data shuffling doesn't —in principle— lose information; computation does. ("evaluation is forgetting") In https://news.ycombinator.com/item?id=32498382 "glue code" and "parsley code" are data shuffling, while "crunch code" is computation.
I guess we have to colive in a world where both views are true.
> To make it unambiguous we must make sure that no code word is a prefix of another code word. Technically, this is not quite correct. The class of so-called uniquely decodable codes is unambigous, and a superset of the prefix codes. One simple example of a uniquely decodable code is the reverse of a prefix code. For the example in the article that would be a 1 b 00 c 10 While the code for a is a prefix of the code o…
> It would be interesting to see a [not gratuitously inefficient] uniquely decodable code that is neither a prefix code nor one in reverse. This can be done by composing a prefix code with a suffix code: A 0 B 01 C 11 a A 0 b BA 010 c BB 0101 d BC 0111 e C 11 {a=0,b=010,c=0101,d=0111,e=11} This is trivially uniquely decodable by uniquely decoding 0->A/etc backward, then uniquely decoding A->a/etc foreward. It's equiv…
[flagged]
Earlier quoted context omitted.
Philosophically speaking there's a great difference. Data shuffling doesn't —in principle— lose information; computation does. ("evaluation is forgetting") In https://news.ycombinator.com/item?id=32498382 "glue code" and "parsley code" are data shuffling, while "crunch code" is computation.
Surely someone could find a taxonomy that makes a distinction... I guess we have to colive in a world where both views are true.
Direct link: https://lazamar.github.io/images/data-compressor.svg
Earlier quoted context omitted.
If you’re writing idiomatic Haskell. Its performance is terrible. If you’re choosing to fight with Haskell, why? Just use something else. To understand why people claim Haskell is “fast”, you need to understand what they mean. What they mean is “if you opted to write C in such a way as you were performing similar amounts of copious and useless data copying, pointer following and stack blowing madness, Haskell will pe…
I think if your runtime performance is terrible with Haskell, either the explanation is that you might be doing something a bit crazy, or that your application is memory-constrained.
The explanation is that Haskell has terrible performance idioms like “copying shit for no reason all the time”.
There’s a reason that the prevailing opinion on language performance within the Haskell community is “thinking about performance of a language is a premature optimization”
This, of course, ignores that Haskells poor performance characteristics are actually technical debt, for which all people should be considering off the bat for their project. You cannot simultaneously say “premature” and not also add this to the techdebt column.
There comes a time in *all* scaling applications that Haskell will be such a burden, that it’ll be forced to be rewritten.
Earlier quoted context omitted.
I think if your runtime performance is terrible with Haskell, either the explanation is that you might be doing something a bit crazy, or that your application is memory-constrained.
Uh no. The explanation is that Haskell has terrible performance idioms like “copying shit for no reason all the time”. There’s a reason that the prevailing opinion on language performance within the Haskell community is “thinking about performance of a language is a premature optimization” This, of course, ignores that Haskells poor performance characteristics are actually technical debt, for which all people should…
