Dylan TR timings and their implications 
Author Message
 Dylan TR timings and their implications

On the off chance that someone still reads this group:

Well, I finally happened to have a Quadra 800 to work with here in our
new lab, with a decent-sized hard disk and 40 megs of RAM. I suspect
that the Quadra 800 is what the Apple Dylan development environment
was built on - it's a great workhorse development machine.

I took my old Fractal Workbench code (now on the TR, but in a non-
functional state). I tried to find out why it wasn't working under
the TR. The problem was a menu resource failing to load. I never
did determine exactly why it was happening, but the fix was to make
a new project from scratch and add all my old code. Then it worked
fine. During all this, I was quite surprised to find out just how
well the Dylan TR runs on a Quadra 800. It is sluggish, but really
quite bearable. On my 8500, however, it is horrid. Redrawing the
browser is agonizingly slow. It's making me want to run out and
get a used Quadra 800 for my home.

Time to launch Dylan, open my project, and run it on my PowerMac
8500/120 with 64 megs of RAM running a new 7.5.3 install: about
six{*filter*} minutes.

Time to launch Dylan, open my project, and run it on the Quadra 800:
about two minutes.

I was stunned. I haven't had a decent 680x0 machine to use Apple
Dylan on besides my Duo, which didn't have enough memory. Trying
to run it on our PowerBook 190 was a disaster, for reasons that
likely had nothing to do with the TR's code (haven't tried it
with the latest system yet).

Could it really be that the TR runs _eight times_ faster on a
Quadra 800? Apparently so. I recall some discussions with people
from the Cambridge lab on just why the emulated Dylan ran so
slowly. Some thoughts were that it does a lot of QuickDraw calls
to redraw the browser, but QuickDraw is native now, and that it
does a very large amount of file access (doing a lot of object-
database stuff with the project files). This explanation makes
a lot of sense.

It is very disheartening, though, to consider that if Digitool
does get a native build working, that since the file system is
still emulated, we may not see much in the way of performance
improvement. One would imagine that an all-native TR would run
much faster than the Quadra 800 version. But the theory that most
of the time is spent in the emulated file manager would indicate
that it won't even be as fast.

Would Digitool or anyone from the original team care to comment?

-Paul-

--
Paul R. Potts - Technical Lead - Health Media Research Lab
University of Michigan - Comprehensive Cancer Center



Sun, 20 Dec 1998 03:00:00 GMT  
 Dylan TR timings and their implications



Quote:
>Would Digitool or anyone from the original team care to comment?

Sure, I'll take a shot at it.

Quote:
>Well, I finally happened to have a Quadra 800 to work with here in our
>new lab, with a decent-sized hard disk and 40 megs of RAM. I suspect
>that the Quadra 800 is what the Apple Dylan development environment
>was built on - it's a great workhorse development machine.

Yes, I did all my work on the Dylan framework on a Quadra 800.  In the
early days of the Cambridge lab, I think they all used IIfxs.  But while
I was there most people had Quadra 800s or 840avs.

Quote:
>Time to launch Dylan, open my project, and run it on my PowerMac
>8500/120 with 64 megs of RAM running a new 7.5.3 install: about
>six{*filter*} minutes.

>Time to launch Dylan, open my project, and run it on the Quadra 800:
>about two minutes.

>Could it really be that the TR runs _eight times_ faster on a
>Quadra 800? Apparently so. I recall some discussions with people
>from the Cambridge lab on just why the emulated Dylan ran so
>slowly. Some thoughts were that it does a lot of QuickDraw calls
>to redraw the browser, but QuickDraw is native now, and that it
>does a very large amount of file access (doing a lot of object-
>database stuff with the project files). This explanation makes
>a lot of sense.

I think the problem is that lisp code (which the Dylan environment is
implemented in) interacts terribly with the dynamic recompiling emulator
on the newer PowerMacs.  It must be that something in the lisp code is
causing the DR emulator to flush its cache too much.  Running Apple Dylan
on the first generation PowerMacs (before the DR emulator) wasn't nearly
as bad.  It wasn't very fast, but not nearly as slow as on the newer
PowerMacs.

BTW - there is a control panel you can get off of the Digitool ftp site
that turns of the DR emulator.  Try that out - it should make Dylan run a
lot faster on your 8500.

Quote:
>It is very disheartening, though, to consider that if Digitool
>does get a native build working, that since the file system is
>still emulated, we may not see much in the way of performance
>improvement. One would imagine that an all-native TR would run
>much faster than the Quadra 800 version. But the theory that most
>of the time is spent in the emulated file manager would indicate
>that it won't even be as fast.

I believe the native version of the Dylan TR will run much faster once it
is native - especially on the newer PowerMacs.  MCL 3.0 was UNBEARABLY
slow on my PowerBook 5300c, but the native MCL 3.9 is remarkably fast.
So porting the Dylan TR to the native MCL should make a nice improvement.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike Lockwood (former Dylan framework person)



Mon, 21 Dec 1998 03:00:00 GMT  
 Dylan TR timings and their implications


If I have any money left in a couple of months I think I am going to
see about getting myself a used Quadra 800 : )

You're right about the older PowerMacs vs. newer ones: I remember it
being quite a lot faster on my 6100/60, although I don't have exact
timings at hand. (Slower than the Q 800, but considerably faster than
my 8500, even using some VM on my 6100).

Quote:
> I think the problem is that lisp code (which the Dylan environment is
> implemented in) interacts terribly with the dynamic recompiling emulator
> on the newer PowerMacs.  It must be that something in the lisp code is
> causing the DR emulator to flush its cache too much.  Running Apple Dylan
> on the first generation PowerMacs (before the DR emulator) wasn't nearly
> as bad.  It wasn't very fast, but not nearly as slow as on the newer
> PowerMacs.

> BTW - there is a control panel you can get off of the Digitool ftp site
> that turns of the DR emulator.  Try that out - it should make Dylan run a
> lot faster on your 8500.

Will try it. This sounds like a reasonable explanation.

Quote:
> I believe the native version of the Dylan TR will run much faster once it
> is native - especially on the newer PowerMacs.  MCL 3.0 was UNBEARABLY
> slow on my PowerBook 5300c, but the native MCL 3.9 is remarkably fast.
> So porting the Dylan TR to the native MCL should make a nice improvement.

Looking forward to trying it!

p.s.: I kind of like the title you gave me a the WWDC:
"are you the flame of Dylan?" I guess the answer is: at least a spark.
I'm going to try to do some real work with the TR later this summer.

Anyone else patiently waiting for the world to catch up to dynamic
languages?

p.p.s.: It also seems very encouraging to me that Object Magazine
has been doing a series on CLOS, and had this to say in their latest
issue:

"Whatever the case, the attempt to establish C++ as the standard object
language has failed. Smalltalk, which looked to be the biggest loser in
the battle of object languages, has come back with a vengeance... but the
struggle for {*filter*} among the object languages is not just between
Smalltalk and C++. More and more, the battle lines are breaking down and
organized warfare is degenerating into a great free-for-all."

And in another article: "I like CLOS and I feel that the industry is
now ready for it. Some of the dynamic aspects of CLOS make it prime
for today's technological demands. Also, the 'big machine' stigma is
now gone. Remember when it was appalling that we needed 16 megs of
real memory for CLOS?"

This seems like a good sign to me. Two years ago, it was virtually
unthinkable for magazines like Object Magazine and JOOP to slam C++.
Now even the C++ report devotes a good chunk of every issue to
serious articles on pitfalls, caveats, and things that are very
difficult to do correctly and safely in C++.

-Paul-

--
Paul R. Potts - Technical Lead - Health Media Research Lab
University of Michigan - Comprehensive Cancer Center



Mon, 21 Dec 1998 03:00:00 GMT  
 Dylan TR timings and their implications



Yow! Using the Emulator control panel to turn off code translation
resulted in an open-project and run of about 4.5 minutes on my 8500/120
vs. 2 minutes on the Quadra 800 and about 16 minutes with the DR
caching! That's a big difference! Now it starts to make more sense.

-Paul-

--
Paul R. Potts - Technical Lead - Health Media Research Lab
University of Michigan - Comprehensive Cancer Center



Mon, 21 Dec 1998 03:00:00 GMT  
 Dylan TR timings and their implications



Quote:
> This seems like a good sign to me. Two years ago, it was virtually
> unthinkable for magazines like Object Magazine and JOOP to slam C++.
> Now even the C++ report devotes a good chunk of every issue to
> serious articles on pitfalls, caveats, and things that are very
> difficult to do correctly and safely in C++.

I've said it before, and I'll say it again: The more I use C++, the more I
like Dylan. If I had time, I'd write Dylan plugins for Metrowerks
CodeWarrior. Too bad compilers aren't weekend projects.

....................................................................
Chris Page

Claris Corporation                 http:www.best.com/~page/home.html
....................................................................



Tue, 22 Dec 1998 03:00:00 GMT  
 Dylan TR timings and their implications

Quote:

>BTW - there is a control panel you can get off of the Digitool ftp site
>that turns of the DR emulator.  Try that out - it should make Dylan run a
>lot faster on your 8500.

Mike, can you post the URL of that control panel, please.

Tim



Tue, 22 Dec 1998 03:00:00 GMT  
 Dylan TR timings and their implications

Quote:

>>BTW - there is a control panel you can get off of the Digitool ftp site
>>that turns of the DR emulator.  Try that out - it should make Dylan run a
>>lot faster on your 8500.

The Digitool Home Page is <http://www.digitool.com/>
The MCL FTP Site is <http://www.digitool.com/MCL-ftp-site.html>
The folder you want is <ftp://ftp.digitool.com/pub/mcl/patches/>
The files are
   Emulator.bin 23K
   Emulator.hqx 31K
   Emulator.txt 3K


Tue, 22 Dec 1998 03:00:00 GMT  
 Dylan TR timings and their implications



Quote:

>p.p.s.: It also seems very encouraging to me that Object Magazine
>has been doing a series on CLOS, and had this to say in their latest
>issue:

>"Whatever the case, the attempt to establish C++ as the standard object
>language has failed. Smalltalk, which looked to be the biggest loser in
>the battle of object languages, has come back with a vengeance... but the
>struggle for {*filter*} among the object languages is not just between
>Smalltalk and C++. More and more, the battle lines are breaking down and
>organized warfare is degenerating into a great free-for-all."

>And in another article: "I like CLOS and I feel that the industry is
>now ready for it. Some of the dynamic aspects of CLOS make it prime
>for today's technological demands. Also, the 'big machine' stigma is
>now gone. Remember when it was appalling that we needed 16 megs of
>real memory for CLOS?"

>This seems like a good sign to me. Two years ago, it was virtually
>unthinkable for magazines like Object Magazine and JOOP to slam C++.
>Now even the C++ report devotes a good chunk of every issue to
>serious articles on pitfalls, caveats, and things that are very
>difficult to do correctly and safely in C++.

Yes, that is a good sign.  A few years ago when we were promoting Dylan,
it seemed that most professional programmers realized that C++ was not
the best language in the world, but stuck with it because it was the
standard.  Now that Java is suddenly so popular, that perception is gone
and people are no longer afraid to look beyond C++.  Perhaps that will
open things up for some more innovative languages.

Java seems like a nice language, but it is not nearly as powerful as
Dylan or CLOS.  But atleast Java is moving the public closer in that
direction.  Perhaps some people will abandon C++ for Java and get used to
having GC and (almost) everything being an object.  After awhile, they
may want to try a language with a more powerful object model and more
expressiveness, and look toward the dynamic languages.

Oh well, now I have to go back to my C++ programming.  Sure, I would love
to do all my work in Dylan or CLOS, but atleast with C++ I can write code
that runs preemptively on MacOS 8 and I can open my project in 5 seconds
:-)

Mike
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike Lockwood



Wed, 23 Dec 1998 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Apple Dylan TR

2. Newbie problem? (Dylan TR)

3. CGIs in Apple Dylan TR???

4. apple dylan tr no format-out

5. Doing MCL with Dylan TR?

6. PPC Dylan TR Run With RAM Doubler?

7. Apple Dylan TR PPC Buggy?

8. HELP! Apple Dylan TR problem

9. Dylan TR speed

10. Upgrade to PPC Dylan TR?

11. How to get Apple-Dylan-TR in Europe?

12. Learning the Apple Dylan TR Framework.

 

 
Powered by phpBB® Forum Software