dlt@csun.UUCP (01/29/87)
Because I like the Lightspeed C environment so well, I decided to
purchase Lightspeed Pascal. While the two environments are
similar, I wish they would have done more things the same way. But
what *really* bothers me is the seemingly slow performance of LSP
in comparison with TML (v1.11). I ported some existing trivial appli-
cations like the sieve "benchmark", a towers of hanoi program, and
an eight queens program. The sieve program runs fairly well but
the queens program takes significantly longer to find all (92)
solutions than does TML (TML=11 seconds (with printing) vs LSP 2.5-3
*minutes* (without printing)). The source code in both cases is
identical. The LSP compile options (D, N, V, & R) are turned off.
Why is LSP so slow?
--
Dave Thompson uucp: {ihnp4|hplabs|psivax}!csun!dlt
CSUN Computer Center phone: (818) 885-2790
18111 Nordhoff Street, Northridge, CA 91330othello@batcomputer.UUCP (02/01/87)
In a recent article dlt@csun.UUCP (Dave Thompson) wrote: >the queens program takes significantly longer to find all (92) >solutions than does TML (TML=11 seconds (with printing) vs LSP 2.5-3 >*minutes* (without printing)). The source code in both cases is >identical. The LSP compile options (D, N, V, & R) are turned off. >Why is LSP so slow? > LSP does alot of stuff in its shell -- yes even with all options off... Have you compared the times with the program compiled as an application and all options off? I know that you will find LSP about equal in speed to TML
dlt@csun.UUCP (02/02/87)
In article <2172@batcomputer.tn.cornell.edu>, othello@batcomputer.tn.cornell.edu (Mystery) writes: > In a recent article dlt@csun.UUCP (Dave Thompson) wrote: > >the queens program takes significantly longer to find all (92) > >solutions than does TML (TML=11 seconds (with printing) vs LSP 2.5-3 > >*minutes* (without printing)). The source code in both cases is > >identical. The LSP compile options (D, N, V, & R) are turned off. > >Why is LSP so slow? > > > LSP does alot of stuff in its shell -- yes even with all options off... Have > you compared the times with the program compiled as an application and all > options off? I know that you will find LSP about equal in speed to TML Actually, running the LSP-created application didn't really seem to make much of a difference timewise (it was SO SLOW I didn't bother to time it). The only thing that I can think of that makes this particular program different from others that I've run is that it is recursive. Perhaps LSP doesn't handle that too efficiently. It *does* seem to do other things *quite* well. AS a side note, I've also run the eight queens program on Turbo Pascal. The object code size is quite a bit larger than TML (less than LSP) but seems to run with speed comparable to TML (perhaps a bit slower...). I haven't gotten down to serious benchmarks, yet. Turbo has quite a fast compiler. The only thing I've noticed so far in my brief examination is that you can't back-tab in the editor. If you tab-forward you have to backspace the appropriate number of spaces to get back where you were. -- Dave Thompson uucp: {ihnp4|hplabs|psivax}!csun!dlt CSUN Computer Center phone: (818) 885-2790 18111 Nordhoff Street, Northridge, CA 91330
singer@endor.UUCP (02/04/87)
The generated-code quality of LSP is, on the whole, very similar to that
of TML Pascal. Both are single-pass compilers which are incapable of
performing the kinds of optimizations possible in MPW Pascal (e.g.
assigning local variables to registers).
However, I can think of one area in which LSP would be (significantly)
slower than TML: SET OF integer-subrange operations. One of the design
goals of LSP (and one that I sometimes regret) was the need to retain full
compatibility with the Macintosh Pascal interpreter. In this case, the
interpreter provided for SET OF INTEGER as the largest set type. Operations
on sets which may contain negative elements are cumbersome, since the
requirement of ToolBox compatibility constrains the choice of representation.
Furthermore, because the size of intermediate values can be large
(up to 8K!) they are allocated from the heap (typically a slow operation).
Sets of base-type other than integer or integer subrange are *much* more
efficient.
My guess is that the program that you are benchmarking uses SETs of integer
subranges, and that you have struck one of the few areas in which
compatibility with Macintosh Pascal has cost us some performance
(text I/O is another).
It is unfortunate that Lightspeed Pascal's performance is inferior in this
case, but this is not indicative of its performance on typical programs.
John McEnerney
THINK Technologies, Inc.