Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!news.luth.se!eru.mt.luth.se!bloom-beacon.mit.edu!news.media.mit.edu!grapevine.lcs.mit.edu!uhog.mit.edu!news.mathworks.com!udel!quadriga.cis.udel.edu!carroll From: carroll@quadriga.cis.udel.edu (Mark C. Chu-Carroll) Newsgroups: comp.lang.beta Subject: Re: BETA questions Date: 20 Apr 1995 21:00:18 GMT Organization: University of Delaware, Newark Lines: 60 Distribution: world Message-ID: <3n6i12$eeq@louie.udel.edu> References: <3n5eht$m2i@fbi-news.informatik.uni-dortmund.de> <3n5foo$m2i@fbi-news.informatik.uni-dortmund.de> <3n6111$4lo@pulm1.accessone.com> NNTP-Posting-Host: quadriga.cis.udel.edu In article <3n6111$4lo@pulm1.accessone.com> Baiss E. Magnusson writes: >> >>I am one of those students who was forced to learn BETA and >>had to cope with severe flaws of BETA resp. the Mjoelnir BETA Compiler : >> >>- BETA-programs are very large (> 250k even for a simple "Hello World" program) >> and REALLY slow (see below) >> >I must admit that your experience with Beta is not encouraging to one who >has followed its progress for fifteen years and been entranced by its >syntax. As a software developer who has authored several large commercial >programs used throughout the world the compiler efficiency certainly >becomes an important factor . Anything more than 50% worse than current >C++ implementations would be unacceptable for a commercial developer. Don't assume that the problems that the earlier Mark posted are due to the language. The Mjolner implementation of Beta really leaves a lot to be desired, but *very* few (if any) of its limitations are actual limitations of the language. A very big problem with Mjolner Beta is that the compiler is extremely weak. I was one of the beta testers of Linux beta, and my impression was that it didn't attempt to do *any* significant optimizations. (It may have done a little bit of peephole optimizations, but I'm not sure.) I can say for certain that it didn't do closure elimination (beta patterns are closures. But the overwhelming majority of the time, they don't need to be treated with the full generality of a closure - they can be treated as simple procedures.)- the speed of programs that did simple pattern calls was significantly slower than it would have been had they used function calls. It didn't do any significant common subexpression elimination. It didn't do loop invariant code motion. It didn't do reduction in strength. (Note that for all of the above, my impression of what it doesn't do is based on performance. I didn't look at generated code, because I don't know intel assembly. What I did was try it out on various things that are textbook examples of things that are simple to optimize. For example, invariant code motion can be tested by putting nothing but a piece of loop invariant code into a loop, and then measuring how execution time changes as the loop index varies. If the compiler does invariant code motion, then the loop becomes empty. Assuming that the compiler does dead code elimination (a *very* simple thing - if it does invariant code motion, it definitely does dead code elimination), the loop will be eliminated. So the execution time shouldn't vary with the loop index. But in Mjolner beta, it does.) In principle, Beta programs should perform *extremely* well: Beta is an extremely easy language to analyze, and it lacks the features of most OO languages that make it hard to optimize (like dynamically bound procedure calls). But Mjolner Beta compiles like a mediocre student project: almost no optimization, poor error messages, terribly verbose, and very slow. -- || Mark Craig Chu-Carroll: || "A libertarian is just a republican || CIS Grad, U of Delaware || who takes drugs" || PGP Key Available, by finger || - Bob Black || carroll@cis.udel.edu ||