From: ganesh@mega.cs.umn.edu (M. Ganesh)
Subject: ST in Prod. Env.: Summary of Responses
Organization: University of Minnesota, Minneapolis, CSci dept.
Date: Thu, 3 Sep 1992 22:12:05 GMT

Hi Netters:

Thank you for the answers and references posted in response to my
queries about the use of Smalltalk in a production environment. Before I
post the summary of the responses, I would like to retract my naive reference
to ParcPlace Smalltalk being an interpreted environment. Several people 
pointed out that ParcPlace was a "cache compiled" or "dynamically compiled"
environment. 

Executive summary:
-----------------
1. 3D graphics library:
None reported in the postings - a few opinions for the lack of libraries were
posted.

2. Class libraries for hard copy output
The summary of responses:
utils/Printing.st 
(refer to ParcPlace)

3. Performance in DBMS/Graphic application?
ParcPlace Smalltalk is not interpreted but CACHE COMPILED.
Performance can be improved by using C code.

4. Data sharing with C applications?
Yes, it's possible.

5. Case tools?
1. ENVY by OTI
2. Convergence/Team from Instatiations/Digitalk

Detailed listing of responses
-----------------------------   
 >1. Are there any class libraries that provide 3D graphics capability?

From: Ralph Johnson <johnson@cs.uiuc.edu>
I've had students build some for earlier versions of Smalltalk, but they
aren't compatible.  I guess the bottom line is that 3D is very compute
intensive, and the inefficiencies of Smalltalk hurt a lot.  This is
definitely an area where you will want to write primitives in C or 
FORTRAN and call them from Smalltalk.

>2. Are there class libraries for output to hardcopy for graphics?

 <johnson@cs.uiuc.edu>
Contact ParcPlace for this.

 khaw@parcplace.com
utils/Printing.st includes methods that allow printing instances of
Image to b&w PostScript printers.

>3. There is a concern about the performance of an interpreted environment vs.
>a compiled environment. Can someone share their experience in tuning up 
>smalltalk performance - especially in an application involving interactive 
>graphics and DBMS.

jeff@is.s.u-tokyo.ac.jp
Hard to comment in general.  I have (and seen) Smalltalk in a number
of applications that people would say were impossible for ST.
(Tektronix Digital scope, DREO Realtime AMEP project (see OOPSLA 8x)).
I have noticed a tendency for people to believe or think that ST just
can't go fast.  They are willing to spend days, weeks, months,
optimizing C code to get it fast but they somehow think that they
can't or should have to do that in ST.  The nice thing about ST (and
OOP in general) is that if you do it right, you only have to optimize
a few places to get it faster.

<johnson@cs.uiuc.edu>
I don't have a lot of experience, but those who do universally say that
careful tuning and a little use of C almost always eliminates performance
problems.  Although I build big Smalltalk systems, my performance needs
are not that great, and we have only used a little C.

randy@tigercat.den.mmc.com
First of all, you need to understand that Smalltalk-80 is not interpreted.
It is cache-compiled.  This means that, when you "accept" a method in the
browser, the source code is translated to an intermediate form (called
bytecodes). Then, when the method is invoked for the first time (in each
session within the image), the bytecodes are _translated_ to native machine
code, not interpreted, and the machine code is executed.  The machine code
is then cached in memory and each subsequent invocation of the method
results in the direct execution of the machine code.  Of course in some 
cases the method cache may consume all space available to it, and some
methods that haven't been used for a while may be over-written by more 
recently invoked methods, thereby forcing more than one translation from 
bytecodes per session for some methods.  But in general, cache-compilation
exhibits faster performance than strict interpretation.

As for improving the performance of Smalltalk applications, I suggest you
read an articel in the premier issue of Object magazine by Ken Auer of
Knowledge Systems Corporation called "You Can't Do That in Smalltalk - Or
Can You?".  Ken is also giving a tutorial at this years OOPSLA called,
"Writing Efficient Applications in Smalltalk."

riks@cse.ogi.edu
For graphics, Smalltalk sometimes outperforms straightforward C.
Depending on your platform, and how well the image has been tuned for that
platform, a number of the tricks that the experts use are part of the image.
The an application expert automatically uses the best technique known.
A C environment requires the graphic expert to be on staff.

khaw@parcplace.com (Mike Khaw)
ParcPlace Smalltalk is dynamically compiled, not interpreted. I.e., when
you 'accept' a method, the running image retains it in the form of
Smalltalk bytecodes. While traditionally the bytecodes were interpreted
upon method invocation, for quite some time now, ParcPlace Smalltalk
instead compiles the bytecodes to optimized native machine code and caches
the machine code. Empirical evidence strongly suggests that once a method
is invoked it is likely to be invoked again, so the next time it's invoked,
Smalltalk simply executes the cached code with no translation overhead.

Smalltalk code, however, is unlikely to ever run as fast as compiled C
code or optimized FORTRAN for intensive number crunching operations.

claris!clarisii!jon@ames.arc.nasa.gov
Internet:thatcher@claris.com
There's a large software company near Seattle which does all or most of
its shrink-wrap application programs using significant amounts of p-code.
Supposedly, routines are translated to native code on the fly.  While these 
programs are generally slower than the competition and have horrendous user
interfaces, some of them have gained market acceptance :-).

This translation vs. interpretation trick could also be used in Smalltalk,
and I wouldn't be surprised if one or more vendors used it in some way.

|> 4. Can someone share their experience of Smalltalk in mixed development
|> environment that includes C, and Fortran? How is data in memory shared betn.
|> C applications and a language like Smalltalk that does not implement 
|> pointers?


jeff@is.s.u-tokyo.ac.jp
I use C regularly.  You build C structs that "look" like the ST
objects and use copying semantics.  There are some special features of
some VMs that allow for more than this but all will allow this much.

  
riks@cse.ogi.edu
With care, you can write C programs which incidentally obey reasonable
constraints on your data.  You have hit the nail on the head with pointers:
they are very dangerous and error prone.
If you use a modern development/debugging platform for C with all the
constraints turned on, you have a good chance of avoiding disaster, or at
least catching yourself when you mess up.
In a mutli-programmer environment, you just have to trust that no "colleague"
takes a random integer, points it into the middle of your data, and tweaks some bits.
C even has syntax for thwarting the efforts of declaring certain data to be of certain
types: if you can stand to use data in the manner for which it was designed, youwill be better off.
Smalltalk has none of this problem: An OrderedCollection will never be poked as
a String, and an array which contains only Numbers
will never accidentally show up with a Pen or an EmployeeRecord.
Throwing an object out into the C is rather like giving me your wallet
when you owe me a dollar...I might be honest and not also copy down your
VISA number, and I might take only one dollar.  Heh-heh-heh.


khaw@parcplace.com
Actually, every variable in Smalltalk is really a pointer, you just
don't normally worry about it. For example, suppose x and y are variables
and foobar some arbitrary object, then

        x := foobar.
        y := x.

Is more like saying in C

        foobar_type     *x;
 foobar_type     *y;

        *x = foobar;
        y = x;

and less like saying in C

        foobar_type     x;
        foobar_type     y;

        x = foobar;
        y = foobar;

Smalltalk objects exist in Smalltalk object memory, which you should view
as being separate from C's heap and stack space. Though ultimately
Smalltalk object memory is obtained via malloc() or equivalent calls in
the Smalltalk virtual machine, the Smalltalk memory manager is free to
move objects around as part of garbage collection, so it is highly
dangerous to use a C pointer to hang onto something in Smalltalk object
memory, and it fact doing so pretty much guarantees a crash.

If you are using Smalltalk Release 4.1, the optional C Programming
Objectkit allows fairly transparent access to C-callable external code
from Smalltalk, with automatic conversion between many C and Smalltalk
types, and messages provided for copying between Smalltalk object memory
and the C heap. You can also return C pointers that point into the
C heap, with all the attendant shortcomings that go with it (e.g.,
arbitrary C code may free() the chunk of heap that the pointer points
to and reallocate it for other purposes. If your Smalltalk code
subsequently tries to dereference the heap locations pointed to by
the C pointer returned to it, you are likely to get a crash).

thatcher@claris.com
No experience to relate yet, though Smalltalk/V allows primitives to be
written in C, etc. (Fortran, I doubt).  It supposedly provides a way of
mapping objects to C structures, but this seems terribly kludgey.


 > 5. Are there case tools that will support smalltalk development relating to  > configuration management, testing, and source code control?

jeff@is.s.u-tokyo.ac.jp
There are a couple.  Which depends on how serious you are and how big
your problem/budget is.  If you ask me, ENVY/Developer from OTI is the
best.  (Note that I am highly biased as I work for them but I used it
before that and felt the same way then).  Configuration management,
version control, team development, multiplatform development/target,
...  There is one from Instantiations (Convergence/Team?).  I last saw
it at OOPSLA 91.  It had some deficiencies.  That is about all I can
say.  Both are not for you basement hackers in that they relatively
big ticket.  (mail to info@oti.on.ca for ENVY/Developer info)

There are some $200 tools that are great for small things with just a
few people.  I don't remember any of the names but I am sure they are
advertised in JOOP or ST report ...

<johnson@cs.uiuc.edu>
OTI (Object Technologies, Inc?) in Ottawa has a tool called Envy that
supports configuration management and source code control very well.
It costs money, of course, but people speak very highly of it.

OTI also has a lot of experience building high performance systems in
Smalltalk, including real-time embedded systems, so they can answer
your questions much better than I can.

riks@cse.ogi.edu

Yes.  Naked off the shelf, Smalltalk 80 is superior to all but the very best
of environments that support C.  The difference is that C promotes what I call
the BIG-BANG mode of development: you edit a bunch of files, then compile-load-go
which is somewhat akin to trying to fix your car by going back to first principles
of physics, tweaking a constant, and then recreating the universe: it's awfully indirect.
The Smalltalk image instead promotes the notion that most of what you do affectsonly a small part of the universe, and there are browsers to help you see which
parts will be affected.  Your operations happen in context, and you can easily
inspect stuff as you go.
But it gets better with ENVY from OTI, or other tools from Instantiations/Digitalk
or ParcPlace or Coopers/Lybrand.
Fully answering that question would take a lot of effort.  I'll pass, even though
I created a research version of such tools at Sony and maintain a latent interest.

khaw@parcplace.com
Object Technology International, develops and markets a product called
ENVY. OTI: 613-228-3535 (Ottawa).

thatcher@claris.com
Envy/Developer from Object Technology International provides packaging,
profiling, and source control for Smalltalk (V or Parc Place).  I've heard
many good things about it, but have not used it.

---------------------------------------------------------------------------

Newsgroups: comp.lang.smalltalk