eliot@cs.qmw.ac.uk (Eliot Miranda) (01/28/91)
In article <2961.279ffcba@iccgcc.decnet.ab.com> klimas@iccgcc.decnet.ab.com writes: >In article <22574@well.sf.ca.us>, jjacobs@well.sf.ca.us (Jeffrey Jacobs) writes: >> Performance is generally on the slow side. This really isn't a compiler > > If performance in modern Smalltalk's is a problem then it > will be a problem in C also. We have seen Smalltalk programs > actually run faster than the C programs they were replacing. Can you post more details? kind of program simple metrics (k lines, k bytes of code) % speed increase? I also remember vaguely hearing from ParcPlace about Smalltalk to C++ rewrites that didn't produce the expected speedups. Can anyone comment on this too? -- Eliot Miranda email: eliot@cs.qmw.ac.uk Dept of Computer Science Tel: 071 975 5229 (+44 71 975 5229) Queen Mary Westfield College ARPA: eliot%cs.qmw.ac.uk@nsf.ac.uk Mile End Road UUCP: eliot@qmw-cs.uucp LONDON E1 4NS
martino@logitek.co.uk (Martin O'Nions) (01/29/91)
eliot@cs.qmw.ac.uk (Eliot Miranda) writes: >> If performance in modern Smalltalk's is a problem then it >> will be a problem in C also. We have seen Smalltalk programs >> actually run faster than the C programs they were replacing. I missed the beginning of this discussion, but I would have thought that it was the traditional 'Horses for Courses' argument. I like object orientated systems, and feel that for most simulation tasks, and similar 'real world' applications that an object orientated approach is applicable. In the absence of OO architectures though (apart from Rekursiv - Linn take a bow (even if it has taken three years to start seeing them out there in numbers)), there are always going to be situations where smalltalk is inappropriate - I wouldn't want to see a traditional operating system (YES THERE IS STILL A REQUIREMENT) written in it for example. C++ encourages reasonable design whilst still allowing the performance of C where appropriate - the one to one C to assembler operation coding does give better performance than most lang's. Use each as necessary - there is no universally applicable language for current architectures, so pick a tool for the job in hand - better still, use many tools intelligently..... Martin -- DISCLAIMER: All My Own Work (Unless stated otherwise) -------------------------------------------------------------------------- Martin O'Nions Logitek Group Support martino@logitek.co.uk -------------------------------------------------------------------------- Auntie did you feel no pain / Falling from that willow tree? Could you do it, please again / 'Cos my friend here didn't see. (Harry Graham - Ruthless Rhymes for Heartless Homes)
klimas@iccgcc.decnet.ab.com (01/30/91)
In article <3282@sequent.cs.qmw.ac.uk>, eliot@cs.qmw.ac.uk (Eliot Miranda) writes: > In article <2961.279ffcba@iccgcc.decnet.ab.com> klimas@iccgcc.decnet.ab.com writes: >>In article <22574@well.sf.ca.us>, jjacobs@well.sf.ca.us (Jeffrey Jacobs) writes: >>> Performance is generally on the slow side. This really isn't a compiler >> >> If performance in modern Smalltalk's is a problem then it >> will be a problem in C also. We have seen Smalltalk programs >> actually run faster than the C programs they were replacing. > > Can you post more details? > kind of program > simple metrics (k lines, k bytes of code) > % speed increase? > > I also remember vaguely hearing from ParcPlace about Smalltalk to C++ > rewrites that didn't produce the expected speedups. Can anyone comment > on this too? One tidbit I can share with you, was a case history that was reviewed at the Workshop on Real Time OOP at OOPSLA90 in Ottawa. One of the participants from a French firm told of an attempt to rewrite a large military discrete event simulation from Smalltalk-80 to C++. When all was said and done, the C++ incarnation ran only 10% faster (i.e. the more object oriented your program the more its performance will be like Smalltalk).
tom@ssd.csd.harris.com (Tom Horsley) (01/30/91)
I have seen several references to performance problems in Smalltalk related
to the way it references objects -- object "pointers" are just indexes into
a table, and you always have to indirect through the table to get to the
real "object". Is this still true of ``modern'' Smalltalk implementations?
If so, it seems like an extra level of indirection would always remain a
performance problem. (I apoligize to Smalltalk hackers for not remembering
the Official Smalltalk Jargon for the data structures I am talking about).
P.S. I *know* there are advantages to be had from the extra level of
indirection, I don't need them described to me. I am just saying that it
seems like you have to pay a fairly high price for them.
--
======================================================================
domain: tahorsley@csd.harris.com USMail: Tom Horsley
uucp: ...!uunet!hcx1!tahorsley 511 Kingbird Circle
Delray Beach, FL 33444
+==== Censorship is the only form of Obscenity ======================+
| (Wait, I forgot government tobacco subsidies...) |
+====================================================================+moss@cs.umass.edu (Eliot Moss) (01/31/91)
Many more modern Smalltalk implementations, following Ungar's lead, have eliminated the object table and its consequent level of indirection. I would say that there are two primary sources of slowdown compared with C: the examination and manipulation of tags on everything, including small integers, and the overhead of interpretation (which the translation scheme of PARC Place Smalltalk largely avoids). Smalltalk also always error checks -- overflow, array subscripts, types of things in primitives, etc., and these checks have a noticeable run-time impact (Ralph Johnson at Univ of Ill., among others, has research projects that aim to optimize a lot of that away; see also the work done by Ungar and Chambers at Stanford for the Self language). A well designed garbage collector adds less than 10% overhead to what is there, so that is more of a secondary factor, but will become a large fraction as other things get tuned or optimized away. Hope this helps folks understand why Smalltalk "costs" -- a lot of it is safety and flexibility features. -- J. Eliot B. Moss, Assistant Professor Department of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
G.Joly@cs.ucl.ac.uk (02/05/91)
>> If performance in modern Smalltalk's is a problem then it >> will be a problem in C also. We have seen Smalltalk programs >> actually run faster than the C programs they were replacing. And awk is faster than C code equivalents. Therefore... Gordon Joly +44 71 387 7050 ext 3716 Internet: G.Joly@cs.ucl.ac.uk UUCP: ...!{uunet,ukc}!ucl-cs!G.Joly Computer Science, University College London, Gower Street, LONDON WC1E 6BT
roger@xanadu.com (Roger Gregory) (02/09/91)
Unfortunately I don't have any good numbers at this point. We currently have about 60K lines of smalltalk and a translator that turns it into about 200K lines of c++. I have posted about the translator to the c++ groups, and can forward that message, or post it here. Currently the c++ has all kinds of inefficient stuff in it, as we havn't started with performance tuneing yet, I expect to use 2 major kinds of heuristics to speed things up: casheing and inlines. Cashes will speed up the smalltalk equivalently, inlines will only affect the C++, right now the C++ and smalltalk run at about the same speed, but the C++ has -> overloaded (for gc) and thus does 3 (3 !) function calls per -> , this will of course be inlined away with some improvement in speed. I'll post some numbers after we reach that phase. The interesting thing about our code is that the exact same code can be profiled in both enviornments, thus speed improvments can be added to the source and not cause the versions in C++ & Smalltalk to diverge. This can be a major impediment to comparison, even with a translator, certain implementation decesions that may cause a differential between performance in the two languages. In most cases we are able to hide the implementation details low enough that we can do the right thing in each language. We have deliberately refrained from doing any implementation tuneing and confined ourselves to algormithmic speedups believing that "premature optimization is the root of all evil" (Knuth?) Our code is currently optimized to be eaisy to understand and change, which should make it eaisy to change to run faster. What little speedup has been attempted is mostly to make the smalltalk tests run faster, to speed the development and debugging phases. -- Roger Gregory Xanadu Operating Company (415) 856-4112 x113 roger@xanadu.com