|
But there is still emergence - a phase ordering
problem. Do you run pass "A" first, or pass "B"?? One way produced better
code sometimes; one way the other. You can generate both and see (an
exhaustive search through the solution space), but that assumes you know the
solution space.
At the same time, compilers are better than most
people most of the time. They are not "the best", but rather "the most
pragmatic solution" to the problem. When performance is really an issue,
people will code in assembly - not often at this point in time because hardware
speeds are such that we can be terribly sloppy. That's the same reason you
sometimes see linked lists instead of (pick-your-structure) - it works, and it
was fast enough at the time.
At some point, we will hit the limits again.
If data size doubles at the same rate as processor speed, you are in a losing
battle - we'll end up hand coding more things as we start to realize the
(runtime) cost of using the compiler.
All that said, I haven't coded assembly in years
and years - though I have been bit by years-old "good enough"
implementations that suddenly had to cope with a 10x increase in input data
size.
>
I'd say those optimized compilers were born from emergence, not suffered
> from.
The point is that the compiler itself is not a complex
adaptive system that
exhibits unexpected behavior. Definitely, the human
writer of the compiler does
all sorts of non-linear stuff. But the compiler
manages to automate a part of
software development that used to be done by
human experts and, I think we'll
all agree, generally does it well. So I am
searching for arguments that further
automation is not feasible that
wouldn't have been applicable to the efforts to
write the first compilers.
If the argument applies equally well to compilers,
then the fact that
compilers exist and work well rebuts the argument.
Yahoo! Groups Links
|
