T.R | Title | User | Personal Name | Date | Lines |
---|
107.1 | Oh, no. Here we go again! | PIXEL::PWONG | Paul H. Wong | Tue Sep 30 1986 09:57 | 0 |
107.2 | | QUARK::LIONEL | Reality is frequently inaccurate | Tue Sep 30 1986 10:13 | 9 |
| It depends on what you're doing. The general impression around
here is that VAX FORTRAN does the overall best job for real programs,
but is missing stuff like inline expansion that can make a real
difference for some programs.
Steve
P.S. If this has been discussed before, I'll be happy to delete
this note.
|
107.3 | Oh, delete me too! | JUNIPR::DMCLURE | Vaxnote your way to ubiquity | Tue Sep 30 1986 11:43 | 26 |
| re: -1,
> P.S. If this has been discussed before, I'll be happy to delete
> this note.
Deleting is really where it's at these days, eh Steve? I know,
why don't we all just delete all of our notes, and then start all over
again! Anyway, if this note is going to get deleted, then I sure as heck
want to get in on it too! :-)
I was going to suggest an addition to the *Life* program which would
have a system call to obtain the current time at the beginning and then
again at precisely the momment that the tenth generation is updated on
the screen. If a set data pattern was used for consistency, it might
prove to be a simple method of testing the speed of all the programming
languages at run time (although alot of them have the advantage of a
more efficient algorithm - but then who said life was fair?).
The following pattern is simple enough, but has some interesting
patterns which develop. I call it the plus sign:
X
XXX
X
-davo
|
107.4 | Say what? | QUARK::LIONEL | Reality is frequently inaccurate | Tue Sep 30 1986 13:15 | 9 |
| Re .3:
Sorry, I don't understand your comment about deleting notes.
I only meant I'd delete MY reply (note) and move it to the other
discussion, if there was one. I am not a moderator of this
conference and have no authority to delete anyone else's notes.
I'd also ask what relevance your further comments on LIFE have
to this subject.
Steve
|
107.5 | Why do I even bother? | JUNIPR::DMCLURE | Vaxnote your way to ubiquity | Tue Sep 30 1986 14:09 | 20 |
|
re: .4,
You missed it, I was just refering to the recent trend of note
deletion (both by authors and by moderators). I was also trying to
inject a little humor into the current state of affairs, but I keep
forgeting that humor isn't in vogue these days.
> I'd also ask what relevance your further comments on LIFE have
> to this subject.
As to whether my mention of the adding a stop-watch feature to the
various Life programs to test the relative speed of code, I guess you're
right: this has nothing to do with the "Fastest Code" topic of this
discussion. In light of this, we should just delete all of our notes
and go home tonight knowing that we are truly relavant to our topics.
-davo
p.s. Oh, I almost forgot... ---> :-)
|
107.6 | A word from our sponsor... | CHOVAX::YOUNG | I think we're all bozos on this BUS. | Tue Sep 30 1986 22:21 | 22 |
| And now back to our regularly scheduled topic...
Let me clarify myself a little. What I am interested in is determining
which Vax language compiler will generate the fastest (least CPU
time) executable code from similar source code logic.
I have found in the past that accurate results require that there
should be as little I/O between timing points as possible. Also
it is important that comparisions between languges be based on the
same algorithims, not just the same functionality. After all even
DCL can eventually quicksort faster than the best macro code can
bubble sort.
By the way, I'm not really interested in Macro, or language examples
that use embedded macro, after all we all know that NOTHING can
be faster than the best macro routines. I want to know which languages
can take simple straightforward source code and produce the fastest
machine instructions.
And SMILE out there! B^)
-- Barry
|
107.7 | | QUARK::LIONEL | Reality is frequently inaccurate | Wed Oct 01 1986 09:49 | 17 |
| If you're asking about choosing the optimal set of instructions,
operands, etc., and aren't as concerned with techniques such
as in-line expansion, inter-procedural optimization, etc. - I'd
say VAX FORTRAN is the best. But, in the Technical Languages world,
we have four major code generators we use - VAX FORTRAN, VAX Pascal,
BLISS and VCG (PL/I, Ada, C). All are very good, but do different
things well.
As I think I've said in this conference before, though (now that
I remember it), "best optimization" is the LAST thing you should
consider when choosing a programming language among all of our
excellent VAX compilers. All are close enough that the language
features and other aspects make far more difference in the
resulting application than does optimization. Also, our compilers
are evolving (except, unfortunately, for BLISS), and keep getting
better each release.
Steve
|
107.8 | Dont worry... | CHOVAX::YOUNG | I think we're all bozos on this BUS. | Wed Oct 01 1986 13:17 | 16 |
| Re .7:
a) Everything counts. Code selection, register allocation,
code motion, expansion, loop unrolling, etc...
b) You say that different languages do different things well.
Could you expand on that some? (This is the kind of thing that I
am looking for).
c) I am not using any of this to choose a programming language.
Its just for personal interest/knowledge. Besides, we software
specialists rarely have the luxury of choosing our own programming
language anyway.
-- Barry B^)}
|
107.9 | | IPG::HAXBY | John Haxby -- Definitively Wrong | Sun Dec 07 1986 09:21 | 19 |
| The best ode generator I have come across to date is the one for
CLU ... it does some incredible things to save time/space. As far
as I am aware, there isn't a version for VMS though. It's worth
pointing out that some of the optimisations can only be made because
the language is sufficiently well-typed to allow the compiler to
make wide-sweeping assumtions. For example, 'string$substr' doesn't
make a copy of the substring because it *knows* that strings cannot
be changed.
I forget who it was that said no compiler produces code as good
as the best macro routines. I disagree. High level languages allow
you to handle abstractions which are just too unwieldy in macro:
huge programs written in a high-level languages (I exclude C and
BLISS et al) are usually smaller and faster than their peers written
in macro. Don't get me wrong: a judicious (very small) sprinkling
of assembler can be a good thing if the language is capable of using,
for example, the 'extv' instruction.
jch
|