Building a data compression utility in Haskell using Huffman codes • Hacker News Board

Re: Building a data compression utility in Haskell using Huffman codes

#91

Post by wredue » Fri, Jul 05, 2024, 6:18 PM UTC

epgui wrote: post #90

wredue wrote: post #89

Earlier quoted context omitted.

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…

It seems we’re in complete polar disagreement. None of the observations you make match mine.

Yeah. And one of us is objectively, measurably correct, while the other is speaking in terms of “performance is a premature optimization” Haskell community brainwashing tomfoolery.

I mean. Fundamentally, reducing cache invalidation, reducing pointer following, and branch prediction are like 80% of your performance gains today. Haskell, being bad at all of these, fundamentally will never perform from a language standpoint.

You can make all the “I believe!!!” Arguments you like. Belief is not fact. Fact is that Haskell measurably performs badly, and Haskell idioms will never perform well.

If your organization is okay with accepting that huge performance tech debt, that’s a choice for your org.

Re: Building a data compression utility in Haskell using Huffman codes

#92

Post by iso8859-1 » Fri, Jul 05, 2024, 11:22 PM UTC

lo_zamoyski wrote: post #88

Btw, what is that on the girl's shirt in the image? Direct link: https://lazamar.github.io/images/data-compressor.svg

She has made Jesus illegal.

Re: Building a data compression utility in Haskell using Huffman codes

#93

Post by nequo » Sat, Jul 06, 2024, 2:01 AM UTC

wredue wrote: post #91

epgui wrote: post #90

Earlier quoted context omitted.

It seems we’re in complete polar disagreement. None of the observations you make match mine.

Yeah. And one of us is objectively, measurably correct, while the other is speaking in terms of “performance is a premature optimization” Haskell community brainwashing tomfoolery. I mean. Fundamentally, reducing cache invalidation, reducing pointer following, and branch prediction are like 80% of your performance gains today. Haskell, being bad at all of these, fundamentally will never perform from a language standp…

> one of us is objectively, measurably correct

In concrete terms, what are these Haskell idioms, what are their measured performance characteristics, and what are alternative idioms for each that perform better? Is there a write up that you could share about this?

I think it would be truly educational. Without that though, your statements appear equally as anecdotal.

Re: Building a data compression utility in Haskell using Huffman codes

#94

Post by epgui » Sat, Jul 06, 2024, 5:42 PM UTC

wredue wrote: post #91

epgui wrote: post #90

Earlier quoted context omitted.

It seems we’re in complete polar disagreement. None of the observations you make match mine.

Yeah. And one of us is objectively, measurably correct, while the other is speaking in terms of “performance is a premature optimization” Haskell community brainwashing tomfoolery. I mean. Fundamentally, reducing cache invalidation, reducing pointer following, and branch prediction are like 80% of your performance gains today. Haskell, being bad at all of these, fundamentally will never perform from a language standp…

> the other is speaking in terms of “performance is a premature optimization”

While I do think this is often and perhaps even usually true, it’s irrelevant to anything I’ve said in this thread, and I wasn’t even thinking in these terms.

You’re hearing things.