6 ms·

Wasn't that what the author was getting at? The DSL for including rewrite/optimization rules in the compiler is actually accessible to the "mere mortal".

by rw 17y ago

three14 17y ago
Yes and no. It's great that it's available. I'm just not seeing that it implies a workable routine for Joe Programmer. Write code. Run. Runs out of memory after 3 hours of protein folding. Check the GHC processed code. Discover that you need to rewrite 5 functions. The premise is that your mental model wasn't good enough to predict this without the GHC processing, so rewrite, run through GHC, stare at code, rewrite again. If that whole cycle is necessary, then this does not sound workable. But I'd be thrilled to learn that I'm missing something.
- chancho 17y ago
  To be fair, no language lets you just "write code" and have it run anywhere near optimally. The programmer always has to be aware of what the compiler is going to do and work with it. I've written a fair amount of Haskell, and done a lot of this type of optimization, looking at the core (intermediate representation) and fiddling with pragmas, unboxing, strictness, etc. I've put Haskell on the back burner and gone back to C++ because I spent SO MUCH time doing this. Maybe I'm not being fair, and in another 5 years I'd be able to predict what GHC is going to do as well as I can predict what a C++ compiler will do. But for now, I can't justify the expenditure in time it takes to get a large piece of Haskell code (more than a microbenchmark) to perform at the C/C++ level. If you write idiomatic Haskell you're tracking down stack overflows (the Haskell kind, not the C kind) and misfired optimizations, and if you're writing C-in-Haskell you're better off just writing C. In the end, I think Haskell just isn't (yet) the best language for what I was doing (image processing, graphics, 3d modeling, etc.) (The short reply to your comment is: yes, you the application writer have to be very aware of what GHC is doing if you want C-level performance.)
  - three14 17y ago
    Thank you. That was the impression I got. I'm still curious to hear if anyone else had a different experience. I'm not so much looking for what it takes to get code running optimally, as much as having idiomatic code run with "reasonable" performance.

Wasn't that what the author was getting at? The DSL for including rewrite/optimization rules in the compiler is actually accessible to the "mere mortal".

by rw 17y ago

Wasn't that what the author was getting at? The DSL for including rewrite/optimization rules in the compiler is actually accessible to the "mere mortal".

three14 17y ago

Yes and no. It's great that it's available. I'm just not seeing that it implies a workable routine for Joe Programmer. Write code. Run. Runs out of memory after 3 hours of protein folding. Check the GHC processed code. Discover that you need to rewrite 5 functions. The premise is that your mental model wasn't good enough to predict this without the GHC processing, so rewrite, run through GHC, stare at code, rewrite again. If that whole cycle is necessary, then this does not sound workable. But I'd be thrilled to learn that I'm missing something.

chancho 17y ago
To be fair, no language lets you just "write code" and have it run anywhere near optimally. The programmer always has to be aware of what the compiler is going to do and work with it. I've written a fair amount of Haskell, and done a lot of this type of optimization, looking at the core (intermediate representation) and fiddling with pragmas, unboxing, strictness, etc. I've put Haskell on the back burner and gone back to C++ because I spent SO MUCH time doing this. Maybe I'm not being fair, and in another 5 years I'd be able to predict what GHC is going to do as well as I can predict what a C++ compiler will do. But for now, I can't justify the expenditure in time it takes to get a large piece of Haskell code (more than a microbenchmark) to perform at the C/C++ level. If you write idiomatic Haskell you're tracking down stack overflows (the Haskell kind, not the C kind) and misfired optimizations, and if you're writing C-in-Haskell you're better off just writing C. In the end, I think Haskell just isn't (yet) the best language for what I was doing (image processing, graphics, 3d modeling, etc.) (The short reply to your comment is: yes, you the application writer have to be very aware of what GHC is doing if you want C-level performance.)
- three14 17y ago
  Thank you. That was the impression I got. I'm still curious to hear if anyone else had a different experience. I'm not so much looking for what it takes to get code running optimally, as much as having idiomatic code run with "reasonable" performance.