Re: Benchmarking the Explorer vs. the Symbolics

["Robert W. Kerns" <RWK@SCRC-YUKON.ARPA>]

    Date: Wed, 24 Dec 86 11:29 PST
    From: Mabry Tyson <TYSON@SRI-STRIPE.ARPA>

    Re your results in Genera 7.0....

    It is rather obvious that the I/O to dynamic windows is extremely slow.  If you
    want some fun, logout and try to access a file.  When it asks you to login,
    do a Control-Meta-Suspend and then a Control-B.  The backtrace is about a
    screen full, almost entirely due to the accept/presentation system.

I must say that this observation is not very relevant to
anything other than the question "Why did we increase the
default stack size?".  The backtrace is deep in order to
reduce consing and improve performance!  The call tree
could have been much more bushy and less deep, but then
a large amount of temporary storage would have been allocated
in the heap instead of the stack.  The EGC may be fast, but
it's not as fast as stack consing!

    In case you didn't know, PRIN1 in genera 7 is do a pretty-print by default.
    So it makes a lot of difference how the output is being generated.  If indeed
    the routines that are printing out are doing PRINTs or whatever, the added
    overhead of pretty-printing is added in.  Of course, you get something back
    for that extra overhead....more readable output.  (Yes, Guy Steele's book
    describes the initial value of *PRINT-PRETTY* as implementation-dependent.)
This often quite exceeds the cost of dynamic windows.
Try doing 1(setf (sys:standard-value '*print-pretty*) nil)0.
You'll find things get much faster!  But I personally find
the extra time is more than made up by how long it takes me
to read the resulting output!

    By the way, you will find that output is faster if you move the mouse off of
    the screen!  (Thanks to Dynamic Windows, I think.)
Well, it doesn't do mouse sensitivity during output, just input.
I have not been able to reproduce this.  (I would expect a small
slowdown due to turning the mouse-blinker on and off in
1tv:prepare-sheet0, but I can't detect the difference).

    Indirectly, it sounds as though one of your "benchmarks" is loading a compiled
    file.  The reason this is so slow in Genera 7 is that when you load the file
    a set of cross-references are created in the who-calls database.  Benchmark
    a M-X WHO CALLS in both systems and see which runs faster there!  If you don't
    want that feature, you can turn it off.  See page 75 of Volume 0 of the
    documentation.

It doesn't do very much at definition time; it just queues it up for later.

However, the process that does the updates then competes
with what you're doing, so it might as well be doing it
in-line, if you're loading up very much stuff.  However,
if you make it run that process at -1 priority (easily
done by advising 1si:update-who-calls-database0, or modifying
1si:who-calls-gc-every-flip0), you can make it hold off
until you're otherwise idle.  I do this in my init file.

The down side of doing this is that it may hang onto
temporary storage long enough to get it past the EGC.
Personally, I'll pay that price; I do a dynamic GC
every few days anyway.

    It is my hope and expectation that there are many efficiencies that are
    being added by Symbolics that will be coming out in 7.1.  New code
    always has problems and there was a significant change between release 6
    and Genera 7.1.
Indeed.  We've been putting a lot of work into performance, and
will continue to do so.  For instance, have you noticed that
when you have one process running, and you switch windows to
do something else while it's working, that you can actually
interact with almost no degredation over an idle machine?
This is especially noticable when the process is compute-bound
(rather than paging-bound).  Try running 1(loop)0 in a lisp listener,
and then using the editor, in Release 6, and Genera 7.  More
than one of us have managed to forget entirely that we had a
loop running in another window for hours at a time!

Overall, I think more things in Genera 7.0 have gotten faster
than have gotten slower, and those things which got slower
have all gotten much more powerful.  But we're not sitting
still; we want to make the things that got slower fast again.

    Date: Wed, 24 Dec 86 19:41 EST
    From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
    Who-calls is a good example. [That does explain one of the performance flukes,
    by the way - thanks for pointing it out, I had forgotten about it.]
    Personally, I think that for the few times I use it, I would rather build the
    database at THAT time, than on every load. I may use who-calls twice a month,
    and I load files every few minutes. Dynamic windows may be another good
    instance (perhaps the entire new accept/presentation system?). While I have on
    occasion found it nice, it's marginal utility may not be worth the cost in
    significantly lowered performance.  That may be particularly true of the
    presentation system - I don't write user interfaces as often as I just try to
    use the machine - why make me pay all the time to make 1% of my job easier?

    Overall, I think it may be a good thing to keep in mind that different users
    have different levels of expertese and different needs from the system.
    Advanced users should not have to pay the price of making the machine easy to
    use for novices. Novices should not have to have an unlearnable machine to
    make the machine powerful for experts. No one should have to pay a performance
    penalty for features they don't really need or at least rarely use, until they
    START to use them... Obviously this is an idealization...

So, start to use them!  They're designed to be used by everyone,
as soon as you sit down at the machine.

The reason the Lisp Listener, Command Processor, Editor, etc. all
USE the presentation system is not to make it easier to write
user interfaces (1%), it's to make it easier for you, AND your novice
users, to do that 99% of your job that is just "using" the machine.

So much more is available from the mouse now, for both the
experienced user and the novice.  Here are a few of my favorites:

1)  You can monitor when slots of structurs or lists change value,
    just by pointing to it and doing c-m-sh-Left.

2)  Anywhere you see the name of a function or variable, just point
    at it and click m-Left to edit it.  Even in the editor, this
    is easier than doing m-. and clicking!

3)  Supplying arguments to commands by clicking on what you want.
    This can save a LOT of typing!

4)  Control-middle ... everywhere!

5)  Setting and clearing breakpoints by pointing at either the disassembled
    code, or at the source code in the editor (if it's been compiled
    with source-locators).

The novice, of course, has a somewhat different list of benefits,
such as being able to point at the output of Show Directory, click
right, and find out all the things you can do to files.  Also, he
(and you) get a more uniform user-interface, that will get more
uniform as we make more use of this substrate.


			   I simply found it somewhat amusing that the symbolics
    was now doing SO MUCH in system software that it was slower actually executing
    most (of our) applications than the explorer, and it starts off with a
    processor roughly 2x faster! For some people this price will be too high...
    and I was curious as to why it happened and perhaps voicing a hope that
    symbolics might make things a little more efficient....
I don't think the areas you were benchmarking really
address the areas that concern people for whom speed
is of the essence.  I think you'll find their benchmarks
will show the machine got faster!

You really don't give enough information to indicate why
your particular application is slower.  If you'll send
me more information privately, I'll distribute it to
the various people around here who take interest in such
things.