Linked by Eugenia Loli on Tue 23rd Nov 2004 01:43 UTC, submitted by Lumbergh
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
More News »
Sponsored Links



@Anonymous: Who cares about overhead in the compiler? The compile stage is hardly a bottleneck to overall system performance. In any case, the ability to hook into the compilation process can be very powerful for performance optimization. If you've built a domain-specific language, chances are that the compiler's built-in optimizer doesn't know anything about optimizations that could be applied to your DSL. If you can control how the code gets compiled, you can add these smarts yourself for your DSL.
@Josh Goldberg: Using higher-level constructs doesn't mean you that you don't know what's going on at the low levels. As long as you are familiar with your compiler, you will have an intuition for what kind of code it'll generate in a given circumstance. In any case, programmer knowledge is always rather undependable. Nothing is as good for tweeking performance as a good profiler, and those work just as well on high-level languages as on low-level ones. Additionally, I must say throwing more hardware at slow software is often a perfectly acceptable solution. Buying a $3000 dual processor server might double or quadruple your software performance. Spending the same $3000 on developer time (1 person, 2 weeks), and you're unlikely to see even a 50% performance improvement.