Proposals

Steeltoe steeltoe@mail.com
Fri, 30 Jun 2000 07:57:12 -0400 (EDT)


Hi Tunes people!

I have never written to this mailinglist before, neither have I looked at a=
ll the documentation. However, I have read my fair share, even the Arrow Ph=
ilosphy paper which I didn't quite understand I must admit. I have yet to r=
ead on how Slate works, mainly because the webpages on it were not function=
al. I have seen the concepts of Haskell, Forth and Self, and must say those=
 projects look very promising to me. That should be enough "I have"'s ;-)

I see now an unnecessary discussion going on with optimization that may not=
 have much to do with Tunes at all. Let me just say that what is basically =
proposed is called 'inlining functions' is C++. I'm sure most of you know w=
hat this is; a static means of pasting small functions inside the scope of =
the caller in the compilation process. The optimization effects you get fro=
m this is astounding. No jmps, no unnecessary push and pops, the compiler m=
ay use only those registers and operators that the optimizer finds most app=
ropriate, juggling these to a best fit. My experience here is with the exce=
llent Watcom C++ compiler which sadly loses economically to inferior compet=
itors I don't want to name in this forum. The Watcom C++ compiler DO try ou=
t many variations of code to see what "fits" best, just like a chess progra=
m tries to solve a chessgame (heuristic search with branch pruning). The ou=
tput from this compiler is pretty to an assembler programmer who do not wan=
t to program assembler anymore. :-) The Watcom C++ compiler also supports u=
sing registers as arguments in ordinary (non-inlined) functions. However, y=
ou lose the flexibility of arbitrary registers here.

All such optimizations comes at a cost however. The smallest exception here=
 is inlining functions as I see it, where inlining a small functions make f=
or smaller codesize and more efficient code (depending on the platform of c=
ourse). When you make the compiler create optimized code, the OO architectu=
re is being torn apart in the binary output. This has a great impact on dyn=
amic bindings as is case with dynamic libraries and calls from code written=
 in another language. Each function that shall be accessible needs to be at=
omic in the sense of not being nested with other functions having cross-dep=
endencies. They also need a common point of entry. Thankfully an inlined fu=
nction may have its own unique entrypoint too, but what happens to the inli=
ned code if you want to change that function after compilation? If you over=
-optimize your system, you will have to recompile your whole system when so=
mething changes. Especially when you don't know your dependencies.

Also, inlining all functions do NOT generate less code, however it will gen=
erate more efficient code. The benefits of this diminishes with the size of=
 the function to inline however. I believe the tradeoffs of various C++ com=
piler makers are correct. Yes, you will have different results depending on=
 which compiler you choose to compile with. That's the whole point of havin=
g different compilers. We don't have the Perfect Compiler yet. As a program=
mer I can live with that, there's not that much difference anyways.

Some optimizers use more general optimization techniques. Rolling or unroll=
ing loops, inverting loops and "smart" references. These may very well crea=
te more trouble for you than you gain, since the C++ language is not a good=
 language to formalize what constraints and capabilities you've got. There =
is always a limit on how smart the optimizer, and its implementors, can be.

I believe there is no perfect binary output. It depends on values of the ob=
server. If you believe that the most efficient code is the best code, then =
turn on all optimizations. Afterwards, you may want to review the assembly =
output. However, keep in mind that optimizing for Pentium processors is not=
 something humans should do by hand. You may tweak all you like in this are=
a, but I believe we have reached the peak here. There is not much more to a=
chieve in this area (optimizing machine-code) IMHO. And if we're going to t=
alk about optimizing in a broader sense, we should wait until we have somet=
hing more concrete to optimize...


However, I do agree that a specification language is needed and should be d=
iscussed _in concretness_. There's little to correct and build on abstracti=
ons. I'm sorry to say I don't know what kind of a language Slate really is,=
 so pardon my ignorance in this area. However, the meta-language of everyth=
ing that exists can be described as a specification-language. Thus this lan=
guage/system could reside over everything. It doesn't have to be _executing=
_ the language (in this example Slate) that do stuff, it merely has to desc=
ribe it _in relation_ to an execution unit (also described/mirrored in the =
specification language). Such a specification language will in my mind, bin=
d defined concepts with external interfaces to the environment of your syst=
em. In effect, these interfaces acting as "primitives" and "gateways" in yo=
ur system which concepts will try to mirror. I believe the Arrows Philosoph=
y may help to get everything connected in this regard, or view the whole me=
ss from a more analytical view, helping an AI unit (a person if we don't ha=
ve one handy) to regulate the system without breaking things. There will al=
ways be limits to reflection, however, should be torn down wherever we find=
 them.

This is just some thoughts I have on the matter. I know I'm way over my hea=
d here, because everything seem to be interconnected and you need something=
 to start with to get it all going (an LLL or just a C++/whatever program?)=
. If you want this to be discussed further please say so, or I will hold my=
 breath. I do not want to propose things that have already been "solved" fo=
r you, so you may want to point me in the direction where it is all found (=
not just read all IRC-logs, mailinglist-spam, etc, I don't have the time to=
 search everything).

No words are worth silencing in the long run.

Sincerely yours,

- Steeltoe

______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=3Dsignup