5 ms·

If you take a look at how the GHC Haskell compiler (A "Sufficiently Smart Compiler(tm)" in my opinion) works, for example, it is not naively pushing allocating

by exDM69 12y ago

If you take a look at how the GHC Haskell compiler (A "Sufficiently Smart Compiler(tm)" in my opinion) works, for example, it is not naively pushing allocating objects, creating thunks and emitting trampoline code. Instead, it analyzes the program structures from graphs and emits rather efficient machine code in the end. Not too dissimilar from what your native code emitting C compiler does. If you look at the machine code for something as "stupid" as the Haskell example below, the output object code does not resemble the semantics of the source program at all. (it's not quite as efficient as the same from a C compiler, but still proves a point) foreign export ccall fac :: Int -> Int fac :: Int -> Int fac n = foldl (*) 1 . take n $ [1..] Compiler and programming language research is a very important topic that yields real performance benefits as well as better programmer productivity. That includes using Category theory to reason about program correctness. If you're interested in how the Haskell compiler works, "Implementation of Functional Programming languages" is a good (albeit a bit outdated) starting point. The whole book is freely available here: http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/ http://research.microsoft.com/en-us/um/people/simonpj/papers... I do agree with the title a bit, though. Some of our computer programming environments are just ridiculously slow. Being slow also means "consumes a lot of power" which is important when more and more computers are powered by batteries.

dinglefuk 12y ago
It's amazing the author could be so naive, in my opinion.
cantankerous 12y ago
Seconding on the SPJ book! It's a solid start for learning about the particulars of FP implementation.
cpa 12y ago
The OP (which I totally agree with!) also states: > Such a compiler could properly determine that intermediate steps are unused, merge them (e.g. translate x.map(f).map(g) to x.map(x => g(f(x)))) Ironically, GHC does that already[0], and will also do TCO. [0] http://metagraph.org/papers/stream_fusion.pdf http://metagraph.org/papers/stream_fusion.pdf
gizmo686 12y ago
For anyone curious, here is the dissasembly of the above code: http://pastebin.com/R3QiCBsK http://pastebin.com/R3QiCBsK And the entire resulting object file: http://pastebin.com/a21pqaKW http://pastebin.com/a21pqaKW
- ximeng 12y ago
  What do all the call statements do? They seem a little redundant as they skip forward to the next statement each time.
  - to3m 12y ago
    Note that the operand in each case is 0x00000000. I suspect this is a disassembly of the .o file, or maybe it's some runtime dynamic linking thing? There'll be a fixup table somewhere and this stuff will be sorted out before it's executed.
freyrs3 12y ago
The complaints in the article don't really generalize at all. It seems to just be a rant about why targeting the JVM from a functional language can yield non optimal code without certain program transformations. Haskell and OCaml don't have the problems mentioned here at all. I wish the title actually reflected the content rather than just being kind of antagonistic about functional programming.
0xdeadbeefbabe 12y ago
Correct me if I'm wrong, but teaching a computer to produce good low level code from high level code seems very similar to the machine translation problem (translating English to X). Why are people so hopeful about solving the former problem when the latter problem is so hard? Or are these two problems so different that the failure so far to solve one has no impact on the other?
- comex 12y ago
  I'd say those two things are only superficially similar. One is trying to correctly interpret a syntax which - is tailored to the characteristics of extremely parallel computers which spend years unconsciously learning somewhat pointless statistical micro-rules, and then layer a formal grammar on top of that (both layers need to be correctly maintained); and - sometimes, due to ambiguity, can't be parsed without understanding the nature of what is being referred to (which can be anything one can imagine). The other is trying to transform expressions which are already formally specified (with semantics to a large extent based on computers' whims rather than humans', even in very high-level languages) into a more efficient form. Doing this as well as humans can could require AI-ish "reasoning" about parts of the program, but it's basically a different task. There's no need to understand everything in the world to know what a Haskell program does.
- tmerr 12y ago
  Designing a mapping from a new language to machine code is easier than retroactively trying to map two languages together that were never meant to be. Especially if those languages are complex and ill-defined.
- yayadarsh 12y ago
  Even a high-level programming language has a strict grammar with no ambiguity, albeit maybe with some syntactic sugar and "higher-level" atoms. The same cannot be said about natural languages.
wz1000 12y ago
The Glasgow Haskell Compiler Haskell Compiler? Never heard of that one :P

by exDM69 12y ago

dinglefuk 12y ago

It's amazing the author could be so naive, in my opinion.

cantankerous 12y ago

Seconding on the SPJ book! It's a solid start for learning about the particulars of FP implementation.

cpa 12y ago

The OP (which I totally agree with!) also states: > Such a compiler could properly determine that intermediate steps are unused, merge them (e.g. translate x.map(f).map(g) to x.map(x => g(f(x)))) Ironically, GHC does that already[0], and will also do TCO. [0] http://metagraph.org/papers/stream_fusion.pdf http://metagraph.org/papers/stream_fusion.pdf

gizmo686 12y ago

For anyone curious, here is the dissasembly of the above code: http://pastebin.com/R3QiCBsK http://pastebin.com/R3QiCBsK And the entire resulting object file: http://pastebin.com/a21pqaKW http://pastebin.com/a21pqaKW

ximeng 12y ago
What do all the call statements do? They seem a little redundant as they skip forward to the next statement each time.
- to3m 12y ago
  Note that the operand in each case is 0x00000000. I suspect this is a disassembly of the .o file, or maybe it's some runtime dynamic linking thing? There'll be a fixup table somewhere and this stuff will be sorted out before it's executed.

freyrs3 12y ago

The complaints in the article don't really generalize at all. It seems to just be a rant about why targeting the JVM from a functional language can yield non optimal code without certain program transformations. Haskell and OCaml don't have the problems mentioned here at all. I wish the title actually reflected the content rather than just being kind of antagonistic about functional programming.

0xdeadbeefbabe 12y ago

Correct me if I'm wrong, but teaching a computer to produce good low level code from high level code seems very similar to the machine translation problem (translating English to X). Why are people so hopeful about solving the former problem when the latter problem is so hard? Or are these two problems so different that the failure so far to solve one has no impact on the other?

comex 12y ago
I'd say those two things are only superficially similar. One is trying to correctly interpret a syntax which - is tailored to the characteristics of extremely parallel computers which spend years unconsciously learning somewhat pointless statistical micro-rules, and then layer a formal grammar on top of that (both layers need to be correctly maintained); and - sometimes, due to ambiguity, can't be parsed without understanding the nature of what is being referred to (which can be anything one can imagine). The other is trying to transform expressions which are already formally specified (with semantics to a large extent based on computers' whims rather than humans', even in very high-level languages) into a more efficient form. Doing this as well as humans can could require AI-ish "reasoning" about parts of the program, but it's basically a different task. There's no need to understand everything in the world to know what a Haskell program does.
tmerr 12y ago
Designing a mapping from a new language to machine code is easier than retroactively trying to map two languages together that were never meant to be. Especially if those languages are complex and ill-defined.
yayadarsh 12y ago
Even a high-level programming language has a strict grammar with no ambiguity, albeit maybe with some syntactic sugar and "higher-level" atoms. The same cannot be said about natural languages.

wz1000 12y ago

The Glasgow Haskell Compiler Haskell Compiler? Never heard of that one :P