| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 181.1 | Some ramblings about a Pascal-like language. | PANGLS::BAILEY | | Tue Aug 02 1988 16:57 | 35 |
| I don't know about Pascal, but I can share my experience with Modula-2
(TDI) versus C. (Do you have a disassembler for your Pascal, or
some way to generate machine language output from the compiler?)
The Modula-2 code is really bad. It never seems to do any variable
``caching'' at all. That is, variables are operated upon in main
memory at all times. Expression calculation occurs in registers
(I should hope so!) but all the register values seem to be discarded
across expressions.
It also doesn't do any peephole optimization at the end. I have
seen the following ridiculous code:
MOVE.L D5,D5
MOVE.L D5,xxx
Actually this is only a beef with the code generated for the statement:
xxx := REGISTER(5); (* Save D5 in xxx *)
In C you can at force register based variable allocation, so they
compiler doesn't have to feel obliged to perform register caching
optimizations.
MWC does seem to produce quite good code, but I like Modula enough
to stick with it. My programs almost always work if they compile
and I knew what I was doing when I coded them.
Some day soon, I'm going to get fed up and figure out how to make
Modula-2 link in MWC object modules. I really the services of a
decent assembler.
Steph
|
| 181.2 | | STAR::HEERMANCE | Mars needs RMS developers! | Tue Aug 02 1988 20:17 | 5 |
| Re: .1
Nope, I don't have a disassembler.
Martin
|
| 181.3 | Let's do a benchmark! | MILRAT::WALLACE | | Wed Aug 03 1988 12:30 | 4 |
| If you want to define some relevant benchmarks and code them in Pascal,
I will volunteer to code them in C (MWC).
Ray
|
| 181.4 | | STAR::HEERMANCE | Mars needs RMS developers! | Wed Aug 03 1988 14:49 | 13 |
| Re: .3
My application is a forward and backward chainer. XLISP is just
to slow for this. The relevant operations are loading the rule
base and fact base from disk (disk i/o and memory allocation).
Requesting a query from the user, and performing the search (string
compares)
A file sort program would probably have all the same characteristics.
A reasonable benchmark would be load 1000 80 byte records into memory,
bubble sort them, and write them back to disk.
Martin H.
|
| 181.5 | File I/O metrics in judging compilers | PRNSYS::LOMICKAJ | Jeff Lomicka | Fri Aug 05 1988 12:38 | 9 |
| Be careful about doing file I/O metrics.
There's orders of magnitude of differences in performance in the
different ways you can do I/O on the Atari. If, for example, you wish
to read a file into a buffer, doing a Fsetdta(), looking up the file size,
and read the file with a single Fread(), will read the file much, much
faster than if you were to read it with a lot of getc() calls, or even
with fread()s.
|
| 181.6 | size, speed, or both? | MILRAT::WALLACE | | Fri Aug 05 1988 13:19 | 5 |
| Good point Jeff! Martin since your original note stated you were
concerned about code generation specificaly in string handling and
loops what about just coding the buble sort and comparing code size?
Ray
|
| 181.7 | | STAR::HEERMANCE | Return of the Crash Dumps from Hell | Mon Aug 08 1988 09:56 | 21 |
| Re: .5
Hmm, your quite right, another problem would be the relative
fragmentation of our hard disks and Turbodos vs. FATSPEED vs.
TOS alone.
Re: .6
Code size does not always equal quality. I'm interested in
speed of execution so I really wouldn't mind if compactness
was sacrificed to gain speed (explicitly iterating loops is
one example).
As a modification to the original benchmark I'm going to have
Pascal randomly generate 1000 records, sort them, and then
print them to the screen.
Another thing I'm currious about is which compiler can build
call frames quicker. A recursive benchmark would help here.
Martin H.
|