m100-2ai@WEB.berkeley.edu (06/16/90)
Hello world.
There have been a lot of talks lately on the net about PROLOG being
faster than C (and a lot of counter-arguments as well). However, the
basic question which troubles me is that of comparing the speed of
2 programming languages. Is it really "correct" to say that one
programming language is faster than the other? Doesn't that really
depend on the compiler, but not the language itself?
I don't know because I am no expert in the field of programming languages
(even though I know half a dozen of different programming languages). Would
the real experts please give us their opinions on comparing speed of
2 languages?
On a related note.... Even if language A is "faster" than language B by a
minute factor (if the concept of a faster language makes sense), doesn't it
seem unreasonable to pedantically insisting on using A if much less
development time is needed if B is used (for example, B can be OOPL).
An example of this is virtual functions in the C++ language. It takes
longer to invoke a virtual function than a regular function because of
the time required by the selector to resolve dynamic binding. However, we
still prefer virtual functions over regular functions because they make
the code extendible in the future.
__ ___ ___ _/' Conrad Wong (cwong@cory.berkeley.edu)
/ \ __/ \----' \-' c`-o
| | / > __/_ / __/_`, _| Imitation is the sincerest form of
\__/ \_____\`--\____\ ;/' lack of imagination -- Ghondahrlmfinegan@uceng.UC.EDU (michael k finegan) (06/17/90)
m100-2ai@WEB.berkeley.edu writes: >Hello world. >There have been a lot of talks lately on the net about PROLOG being >faster than C (and a lot of counter-arguments as well). However, the >basic question which troubles me is that of comparing the speed of >2 programming languages. Is it really "correct" to say that one >programming language is faster than the other? Doesn't that really >depend on the compiler, but not the language itself? One aspect that is language dependent - array access. Pointer manipulation in C, but recursion or tree traversal in Prolog. Any examples of code where a list gets frequently accessed in the middle, but the Prolog version is 'faster' than the C version ? Probably not (with Clocksin & Mellish syntax). While recursion could be removed by the compiler, would it figure out that a linear sequence of elements was appropriate ? - Michael Finegan mfinegan@uceng.UC.EDU
dankg@headcrash.Berkeley.EDU (Dan KoGai) (06/17/90)
In article <5184@uceng.UC.EDU> mfinegan@uceng.UC.EDU (michael k finegan) writes: >m100-2ai@WEB.berkeley.edu writes: > >>Hello world. > >>There have been a lot of talks lately on the net about PROLOG being >>faster than C (and a lot of counter-arguments as well). However, the >>basic question which troubles me is that of comparing the speed of >>2 programming languages. Is it really "correct" to say that one >>programming language is faster than the other? Doesn't that really >>depend on the compiler, but not the language itself? > >One aspect that is language dependent - array access. Pointer manipulation >in C, but recursion or tree traversal in Prolog. Any examples of code where >a list gets frequently accessed in the middle, but the Prolog version is >'faster' than the C version ? Probably not (with Clocksin & Mellish syntax). >While recursion could be removed by the compiler, would it figure out that >a linear sequence of elements was appropriate ? > But I think recursion is more dependent on machine architecture than programming language. Heavily recursive function like tak() should be a dog for register-window machines like Sparc. And recursion is usually more for programmer's convenience than speed and we usually avoid recursive function when speed is priority. For me a good (compiler) language is the one that meets the following criteria: 1: Simplicity 2: Flexibility 3: Intimatacy to object codes Those 3 looks contradicting each other: Usually simple language is not very flexible: Flexible language is too complicated: Simple and Flexibile language often makes unexpected object code. And IMHO C is the most balanced language I know: It's simple, flexible, and very intimate to object code. C is really computer language: Friendly syntax is second priority. It's never intended to be AI language or language for human's sake: It's a language for computer's sake. ---------------- ____ __ __ + Dan The "Segmentation Fault" Man ||__||__| + E-mail: dankg@ocf.berkeley.edu ____| ______ + Voice: +1 415-549-6111 | |__|__| + USnail: 1730 Laloma Berkeley, CA 94709 U.S.A |___ |__|__| + |____|____ + "Unix is not insecure. It's people who are" \_| | + "Unix doesn't have pain. It's people who do"
hannum@haydn.psu.edu (Charles Hannum) (07/01/90)
In article <2134@polari.UUCP> 6sigma2@polari.UUCP (Brian Matthews) writes:
Of course. I think there would be little argument that for any application,
the optimal speed of that application will be achieved by carefully hand
coding it in assembly language. But how much production software is
written in assembly language these days?
No, definitely not much argument about the point. But to answer your question,
there is a CAD program for the PC called FastCAD that's written in 8086
assembly language, and I'm told (though I don't know positively) that the
entire VM/CMS operating system (which sucks, but that's beside the point) that
IBM uses on their mainframes is written in /370 assembler.
I don't know how much other software is written in assembly language, but
obviously somebody has an interest in speed ...
Anyway, the way /370 assembly language is coded, it's fairly easy to write
modular, working programs, which I can't say for any other assembly language
I've ever written (including 80([123]?8[67]|48|[35]1), 6809, 6502, and VAX,
just in case you're wondering). (BTW: I group the Intel chips in one regular
expression because I feel they're all on the same level ... B-I)
If all assembly language was as clean as /370, you would probably see a lot
more production code written in assembler. (This is not to say that /370 is
perfect and doesn't have problems.)
But to treat your point seriously, yes, I presonally have written production
code in assembly language, mostly for the PC, because compiled C code has a
tremendous amount of extra code (read: library routines) added to it, and is,
as mentioned, slower than the assembly language version.
On Unix machines, I don't worry so much about size, but speed is always a
consideration.
On another note: I've found that, with a good optimizing compiler like gcc,
on the whole the assembly/C speed difference is overall much less than the
difference one gains by finding a better algorithm. I could go into some
horrible details and statistics from my own experience to demonstrate this, but
I'll spare you. It's not worth the effort it would take to dig up all the
information...
--
Virtually,
Charles Martin Hannum "Those who say a thing cannot be done should
Please send mail to: under no circumstances stand in the way of
hannum@schubert.psu.edu he who is doing it." - a misquote