From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: What is wrong with OO ? Date: 1997/01/10 Message-ID: #1/1 X-Deja-AN: 209088977 references: <5a0niaINNlda@topdog.cs.umbc.edu> <32C43AC8.24E2@sn.no> <32C557F6.532C@rase.com> <5aa0eo$thd@krusty.irvine.com> <5aadbr$ad8@masters0.InterNex.Net> <32D64433.41C6@wi.leidenuniv.nl> organization: New York University newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-10T00:00:00+00:00 List-Id: "> Assembler will ALWAYS be the most efficient language. The more you > abstract the problem, the more you "generalize" the solution to a > given problem, the more you necessarily give up in efficiency. C > takes a minimal 3x hit on integer arithmetic, 10x on more complex > stuff; and OO, because of the overhead interpreting where > to send things, is 10x on top of that." First, it is only true that assembler is most efficient if written by a competent programmer. Since well over 90% of the assembly language that I have seen is highly incompetent, this is an important criterion. In particular, I often see the phenomenon of super ferocious, super tight coding of junk algorithms, and the result can easily be beaten by a decent algorithm written in any language. As for the 3x hit on integer arithmetic, this seems complete nonsense. Almost any decent C compiler these days should be able to handle near optimal code generation for simple integer arithmetic. Finally, writing assembly these days is getting more and more difficult. Doing your own global scheduling as well as a good optimizing compiler can do it is a very big challenge on modern superscalar machines. Yes, it is true that you can often pick up a considerable advantage by choosing clever machine dependent data structures, and taking advantage of processor flags etc, but a modern optimizing compiler will almost certainly be able to do a better job than most assembly language programmers of global register allocation and scheduling. Indeed the most efficient way to write assembly language might well be to use the machine insertions available in many compilers (including GCC and GNAT) that allow you to write register independent code, and then let the optimizer circuits of the compiler do register allocation and instruction scheduling on the instructions you write. I should say that I certainly agree that it is *possible* to achieve remarkable time and space efficiency in assembly. My DASC program is a nice example. It is a complete scanner and syntax recognizer for Ada 83, that gives a pretty nice first error message on syntactically invalid programs. It runs well over a million lines a minute on a 25MHz 386 (I have not run it on more recent machine -- actually let me do it, easy enough in another window here --- OK, a source file of 1.04 million lines of Ada (actually 100 concatenated copies of the GNAT unit sem_ch3.adb) took 14 seconds on my 133 MHs Pentium notebook, so well over four million lines a minute on a machine with a very slow disk). The size is also startling, it is a COM file less than 15K bytes long, and that size INCLUDES 2K bytes of help text, and all the error message text. So this kind of ancedotal evidence does indeed suggest that it is possible some times to get startling performance from hand coded programs, but you have to be VERY careful about extending this kind of data. Whether this approach is practical in other situations depends on all sorts of factors.