Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Friday April 03, 2009
10:19 PM

On Language Height and Optimization

[ #38751 ]

As I see it, there are two poles on a language criterion to make a given program run fast:

  • Write in a language which gives you as much control as possible over the hardware, which implies fewer opportunities for high-level abstractions (tell me with a straight face that idiomatic Ocaml code regularly worries about memory usage to the byte and CPU register usage, for example).
  • Write in a language with a sufficiently smart runtime optimizer that can remove the penalty for abstractions you don't use (and even some you do).

History suggests that the second option is almost always the right choice over time.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The second option means that optimization is happening outside of your program. So, you don't have to maintain the optimization. But, It also removes a lot of your control over the optimization and takes longer to arrive.

    Can we call that "postmature optimization"?

    • The second option means that optimization is happening outside of your program.

      So does buying faster hardware.

      Can we call that "postmature optimization"?

      Heh. Only when discussing mature programs!

  • Dichotomies can be categorized into exactly two types: true dichotomies and false dichotomies. :-)

    This, my friend, is a false dichotomy.

    Modern haskell believes strongly in the second option. It's all about making and reusing the best abstractions, and hoping the compiler can figure it out. Most don't, ghc often does, but not always.

    The new fad in the haskell community is stream fusion, or writing your code in a pipelined manner that allows a stack of maps and filters to be condensed into a single t

    • If the "sufficiently smart compiler" is True Amber and C is "The Courts of Chaos", GHC approaches Avalon. Now I wonder if Zelazny wrote more about programming than the Kabbalah.

      (For everyone not versed in expert-but-pop SF, I agree that GHC trends toward my second pole, but it certainly hasn't arrived.)