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
chromatic (983)
chromatic
(email not shown publicly)
http://wgz.org/chromatic/
(email not shown publicly)
http://wgz.org/chromatic/
Blog Information [technorati.com]
Profile for chr0matic [technorati.com]
Friday April 03, 2009
10:19 PM
On Language Height and Optimization
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
Loading... please wait.
I pour myself a cup of strong coffee. :-)
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
distributed optimization (Score:1)
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"?
Re: (Score:1)
So does buying faster hardware.
Heh. Only when discussing mature programs!
False Dichotomy (Score:2)
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
Re: (Score:1)
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.)