Self-interest September 1990

self-interest@lists.selflanguage.org

7 participants
11 discussions

mailing list
by thomas＠loria.crin.fr 25 Sep '90

25 Sep '90

Could you please add me to the mailing list? Thank you. laurent Thomas - CRIN EMAIL : thomas(a)loria.crin.fr - POST : BP 239, 54506 VANDOEUVRE CEDEX, France

1 0

re: self compiler questions
by craig 24 Sep '90

24 Sep '90

vme131!lsi4!jecel(a)uunet.UU.NET writes: >Why is the Self compiler always compared with optimizing C? Since >it does many run-time checks I would think that Self would be >more fairly compared to Pascal. When comparing the performance of our Self compiler to other systems, we try to be as honest and fair as possible, in the sense of comparing against the best commonly available system. Comparing against a Pascal compiler that generates slower code with extra run-time checks might make our compiler look better, but wouldn't be as honest. Comparing against the best traditional compiler available (e.g. an optimizing C compiler) will give the results the most validity, and (hopefully) convince the largest number of people that they should switch to a nicer language like Self, now that the run-time performance is close. Some might argue that we should compare against an optimizing Fortran compiler, since they tend to be better than C compilers. This might be more honest, in the sense of giving us the worst possible comparison. But I would claim that Fortran really isn't a general purpose programming language, and is only used in numerical applications where the limited functionality of the language is adequate. Also, we don't really want to find an optimizer that does a significant number of optimizations, since our Self compiler only includes common subexpression elimination and global register allocation. Presumably we'd have to implement every optimization implemented in a competitor's compiler in order to reach comparable code quality. C seems to be a good thing to compare against, since the language is general purpose, commonly used, and the optimizing compilers produce good code, but without extreme amounts of optimization. reed.bitnet writes: >And, in the interests of completeness, which C compiler are you >comparing against. I don't know about the Sparcstation, but on a >Sun 3 you can get a factor-of-two performance improvement simply by >using gcc instead of Sun cc. We use the standard Sun optimizing C compiler. On the SPARC, this compiler is about the same quality as the GCC compiler, a least the last time we compared them (a couple of years ago). vme131!lsi4!jecel(a)uunet.UU.NET writes: >I don't like C++ very much - couldn't the Self compiler be written >in Self ( which, I hope you will agree, is much nicer ) and compile >itself using a tiny bootstrap interpreter? We've been asked that question many times. When we first designed the language, we didn't know whether we'd be able to reach Smalltalk performance, let alone C performance, so bootstrapping was never considered. However, even if we were to reimplement our compiler in Self, there are still some tricky issues left. One is the fact that the compiler's compiled code would be in the code cache, and so might get flushed, in which case the system would have to fall back to the interpreter to interpret the Self compiler to compile some application code. This could make compiler pauses very distracting. Also, bugs in the Self compiler could be very difficult to find, especially if it compiles itself. Finally, there would be a large dependency between the Self code and the virtual machine. The Self compiler would have to communicate a lot of information to the virtual machine, and vice versa, in order to generate the same high quality code. Designing the interface between the virtual machine and the Self compiler is a hard problem. vme131!lsi4!jecel(a)uunet.UU.NET writes: >Are there any statistics on Self like those on Smalltalk in >"Smalltalk-80: Bits of History, Words of Advice"? I'm designing a >Self multiprocessor machine and knowing such things as average >object size and so on would be helpful. No real statistics yet. I'd imagine that Self objects look a lot like Smalltalk objects. Perhaps a bit smaller because of differences in coding styles. The major differences would have to do with statistics related to the execution engine and method lookup, which could be wildly different with our optimizing compiler. -- Craig Chambers

1 0

Re: self compiler questinos
by trost%reed.BITNET＠Forsythe.Stanford.EDU 24 Sep '90

24 Sep '90

vme131!lsi4!jecel(a)uunet.UU.NET writes: >Why is the Self compiler always compared with optimizing C? Since >it does many run-time checks I would think that Self would be >more fairly compared to Pascal. And, in the interests of completeness, which C compiler are you comparing against. I don't know about the Sparcstation, but on a Sun 3 you can get a factor-of-two performance improvement simply by using gcc instead of Sun cc.

1 0

mailing list
by thomas＠loria.crin.fr 24 Sep '90

24 Sep '90

Could you please add me to the mailing list ? Thank you. Laurent Thomas - CRIN EMAIL : thomas(a)loria.crin.fr - POST : BP 239, 54506 VANDOEUVRE CEDEX, France

1 0

Put me on the mailing list: bogaart@serc.nl
by Eugene Bogaart 24 Sep '90

24 Sep '90

1 0

we're back
by craig 22 Sep '90

22 Sep '90

We've been down for a few days, upgrading operating systems. Mail to self-interest(a)self.stanford.edu should work again now. If you've sent mail recently to this list, then you might like to resend it. -- Craig Chambers (Apologies to those who already received this message.)

1 0

we're back
by craig 22 Sep '90

22 Sep '90

1 0

self compiler questions
by vme131!lsi4!jecel＠uunet.UU.NET 14 Sep '90

14 Sep '90

I haven't been able to use Self yet, but I've read the manual and papers and have *lots* of questions. Why is the Self compiler always compared with optimizing C? Since it does many run-time checks I would think that Self would be more fairly compared to Pascal. I don't like C++ very much - couldn't the Self compiler be written in Self ( which, I hope you will agree, is much nicer ) and compile itself using a tiny bootstrap interpreter? Are there any statistics on Self like those on Smalltalk in "Smalltalk-80: Bits of History, Words of Advice"? I'm designing a Self multiprocessor machine and knowing such things as average object size and so on would be helpful. - Jecel - Universidade de Sao Paulo, Brazil

1 0

Re: SELF and X
by ungar 13 Sep '90

13 Sep '90

From dsmythe(a)portia.stanford.edu Tue Sep 4 11:06:57 1990 Return-Path: <dsmythe(a)portia.stanford.edu> Received: from portia.stanford.edu by thoreau.Stanford.EDU (4.1/inc-1.0) id AA16555; Tue, 4 Sep 90 11:06:56 PDT Received: by portia.stanford.edu (5.59/25-eef) id AA24838; Tue, 4 Sep 90 11:06:56 PDT Date: Tue, 4 Sep 90 11:06:56 PDT From: Dave Smythe <dsmythe(a)portia.stanford.edu> Message-Id: <9009041806.AA24838(a)portia.stanford.edu> To: ungar(a)thoreau.stanford.edu Subject: SELF and X Status: RO Is there any plan to build-in X window system support as was done for Sunview? This might make it accessible to a larger community of users. Perhaps Interviews or Xt support... Dave Smythe dsmythe@portia We originally used X, a year or two ago, and found it was much too slow. We plan to experiment with XGL, a Sun libarary that promises good performance when used with OpenWindows and a local GX. David

1 0

My impression on Self
by boissier＠ccettix.UUCP 11 Sep '90

11 Sep '90

I have tried to use Self on both sun3 sun4 color and mono displays. The whole thing looks pretty nice and seem to have powerfull ideas to dig in. >From my experience you cannot make a snapshot on a sun4 and run it later Status: O on a sun3, this was disappointing as I am addicted to Smalltalk-80. This may be an area for future work, although it may be quite q bit of work. More problematic is that I'd like to start the graphic stuff (UI at least) in monochrome even if I am on a color fb. This saves a looooootttttttt of memory when it's a scarce ressource and when you swap over the net. One more bad thing is that when you've loaded the ui stuff started it, then back to the command mode, making a snapshot sometimes produces bad files which cannot be run later. I'll compile more info on it if possible. That's it for the bad points, for the good ones I feel that theconcept of dynamic inheritance may be a very powerful tool for prototyping applications I will soon investigate some more thouroughly the possibilities I just have to find an application to play with. Keep on the fast lane Franck. +----------------------------+---------------------------------------------+ |Franck BOISSIERE | Tel: Int'l access + 33 99 02 46 81 | | | FAX: Int'l access + 33 99 02 40 98 | | | TELEX: 740 284 F | |C.C.E.T.T. |E-Mail: ...!mcvax!inria!irisa!boissier | |B.P. 59 | boissier(a)irisa.irisa.fr | |35512 CESSON SEVIGNE CEDEX | boissier(a)ccettix.UUCP | | FRANCE | | +----------------------------+---------------------------------------------+

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest September 1990