 |
Newsgroups: comp.lang.c++, comp.lang.ada, comp.lang.cobol
From: f...@munta.cs.mu.OZ.AU (Fergus Henderson)
Date: 1995/05/02
Subject: Re: Language Efficiency
de...@cs.nyu.edu (Robert Dewar) writes: You have misquoted me; perhaps I was not clear in my original post. >Fergus notes the comparison of peformance of Prolog and Mercury, and states >that Mercury is up to 70% faster: >(The feature in question is the ability to write `read(X), call(X)', >which can call any predicate with any arguments depending on the input.) Mercury is "up to" more than 100 times faster than Prolog (if you The reasons why Mercury is better were not stated in my original post, The relevance of the feature `read(X), write(X)' was that >But how can forbidding a feature POSSIBLY mean that you can compile faster. What you would have to do would be to look at every argument to a >If it is possible to compile faster if read(x) and call(x) are avoided, then >surely a prolog compiler can just look at your program, see if you use these >features, and use one of two totally different compilation strategies >depending on the answer. meta-predicate like `call' (Prolog has many of them other than `call' - their use is common in Prolog programs), and see whether the argument could possibly have come from a call to `read'. This is of course undecideable, so you have to approximate. Furthermore, this has to be a genuinely global analysis. Aquarius Prolog's "global" analysis really only works on a module at a time - you must use `cat' to join your entire program into a single really big module if you want genuinely global analysis with Aquarius. Unfortunately Aquarius Prolog is prohibitively slow analysing large programs with genuinely global analysis. I suspect that the analysis required to determine if your program ever invokes a meta-predicate with an argument whose form is not known until runtime would be just a hard as the analysis Aquarius Prolog is doing already, and I would not be surprised if current technology was not sufficient to make this analysis accurate enough in a sufficiently short analysis time to be useful. So in short, if a language provides information that another >Of course I understand that this makes implementation harder, and it is Even if it were theoretically possible, often there is no point >indeed true that you have to work very hard to deal with difficult >problems, but you often can deal with them much better than you might >imagine. optimizing for particular special cases, since they are so rare. Programs that are written in Prolog will be hard to optimize, since they will tend to use all aspects of Prolog, even those that make optimization hard; programs that are written in Mercury are guaranteed to be in the easy-to-optimize basket, since most of those aspects of Prolog that make optimization are aren't present in Mercury. >Another example from SNOBOL-4 I find that unlikely. Is there a space cost? Is that no overhead at >In SNOBOL-4, when you access any variable by name, as in the access to > R = Q >you have to check if Q is input associated (and if so, read from a file), and >Yes, without ANY loss of dynamic flexibility, the 370 SPITBOL compiler all or just no _time_ overhead? Did you consider cache effects? Simply having the code around to handle the uncommon cases will probably slow down the common-case code, even if the uncommon-case code is never executed. At the very least, it will occupy more disk space. -- You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||