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.)