Self-interest February 2002

self-interest@lists.selflanguage.org

8 participants
8 discussions

Re: [self-interest] newbie question
by cramakrishnan＠acm.org 05 Jun '02

05 Jun '02

Arjen van Elteren writes: > Unfortunately, I encountered a small glitch. Every time I try to add a slot > to the globals object (by adding or copying a slot) the system simply > crashes. Any hints ??? Yeah, this happens to me in OS X also. I can add a slot without difficulty in OS 9, though. - sekhar -- C. Ramakrishnan cramakrishnan(a)acm.org

4 6

efficient viewpoints in Self
by Jecel Assumpcao Jr 26 Feb '02

26 Feb '02

It is possible to transform the Self virtual machine into an Us one (see "A Simple and Unifying Approach to Subjective Objects", http://citeseer.nj.nec.com/smith96simple.html ) that is acceptably efficient. The solution is simple enough and obvious enough that I feel very silly having taken a whole year to see it. The basic idea is to extend customization from {source method, receiver type} to {source method, receiver type, viewpoint}. For N active viewpoints that would make the code cache N times larger, which is very bad. Unless we do "selective customization" as I described in some previous messages or some comparable scheme. Then only methods that are actually called and are affected by a change in viewpoint will have multiple versions in the cache. There would still be a time cost since whenever a given method is called from a new viewpoint we have to redo all the lookups to see if the code can be shared or must be recompiled, but that shouldn't be too bad. That structure of the objects in memory would have to be slightly changed. The maps would have a list of slots for each layer and lookup would have to visit these "pieces" in the order indicated by the current viewpoint. The objects themselves would be just single sequences of words. Imagine that each layer is stored in a separate snapshot file and that a given object has four data slots and points to a map with pieces from layers 1 to 7. Now we read in two files which will add a layer 8 and a 9 to the map. Layer 8 includes two data slots and these are mapped to words 5 and 6 in the object (which has to be extended, obviously) and layer 9 has one data slot mapped to word 7 in the object. Note that these extensions don't have any effect on code that has already been compiled since none of the previously available viewpoints made any use of layers 8 or 9. The order of the mapping between data slots in the layers and words in the object is not important as long as it doesn't change while there is compiled code that depends on it. Reading in a layer might cause objects that previously shared a map to go their separate ways, but that is not a problem. Note that if we can flush viewpoints and layers from the system, some objects could be left with unused words in the middle of them (we don't compact), but I don't think this is a big deal either. If only one viewpoint and one layer are used, the overhead compared to the current VM will be very small. So the extra stuff doesn't cost you unless you actually need them. I'll have to rewrite my "persistent object store" swiki page to be compatible with this proposal. -- Jecel

1 0

Self/R not started yet - some plans
by Jecel Assumpcao Jr 26 Feb '02

26 Feb '02

2001 was a "hardware year" for me and I haven't written yet the first line of code for Self/R. I did work a little on its design and have posted a Swiki address here with more information. Just a quick review in case someone has no idea what I am talking about: Self/R is supposed to be a reflective implementation of Self. What Self does with a C++ virtual machine, Self/R would do in Self itself with "meta objects". That makes some things easier - if you want to add a new kind of message to Self 4.1.4 you will have to change some source text files, recompile everything and restart Self to see the effect. In Self/R you would get the use all the great tools available in that environment and would be able to see the effect of your changes while the system is running. I think everyone can agree that this is a very good thing to have. But I have been thinking a lot about "the community", as John and Albertina have put it. It would be very desirable for us all to work together around a single code base instead of having two separate implementations (which would be worse than having two lists ;-). So I have been trying to evaluate how far I can go by adding Self/R features to Self 4. There are some things that have nothing to do with reflection and could be written in Self 4 without any changes at all to the virtual machine: 1) the 3D and Zooming graphical user interface 2) the extensible event system 3) multi natural language support 4) simpler graphical syntax The next two would require patching the C++ code, but I don't think they would be too much trouble: 5) primitive objects instead of primitive messages 6) the cache manager The last one might be possible to do in C++, but it would be a really major project: 7) the persistent object store/virtual memory/security/viewpoints The problem with doing things in this order is that 6 and 7 can make possible a different Self programming style that would make 1-4 much simpler. I won't go into details about what each of the projects listed above actually is unless there are people interested in them. Note that having 1-7 would make Self 4 more interesting for my project and do most of what I want reflection for, but it still wouldn't be Self/R. But as the saying goes, "perfect is the enemy of good enough". Until recently I simply had to have a "Self in Self" compiler to get my hardware to work. Self/R would have to be built in any case. But I have now changed my design (it is now less Transmeta-like and more PicoJava-like, though that is a very poor analogy) and a "black box" virtual machine (like Self 4) looks like a reasonable option for running the same software on normal computers as I do on my hardware. So for now "Self/R" will mean "Self 4 running on my hardware". In the hope of helping keep the community together I will put off having it mean "Self in Self" as long as I can. Does this make any sense? Cheers, -- Jecel

1 1

New Version of Cel - Ver. 0.8.5
by Dru Nelson 25 Feb '02

25 Feb '02

Hi, I'm still having fun with this side project. The release notes say it all. Feb. 24, 2002 - Release 0.8.5 MAJOR FEATURES Added a Mark-Sweep Garbage Collector Added Win32 support (under Mingw/Msys GCC) Added support for Mac OS X Changed the whole build process. See readme. No longer using shared-libraries (in order to support multiple OS's) KITS Made kits OS independent (or dropped functionality - Win32/fork) Dru Nelson San Mateo, California

1 0

newbie question
by Arjen van Elteren 24 Feb '02

24 Feb '02

Hi I've been lurking on the self mailing list for a while but so far was unable to try it out. With my new iBook I could finally download it and give it a spin on OSX 10.1 (it is great!). Although I notice small hick-ups, the systems runs smoothly. Unfortunately, I encountered a small glitch. Every time I try to add a slot to the globals object (by adding or copying a slot) the system simply crashes. Any hints ??? Greetings, Arjen van Elteren.

2 2

Re: [self-interest] Digest Number 219
by Mario Wolczko 13 Feb '02

13 Feb '02

Jecel wrote: > Here is an idea that I just had to filter out useless customization (it > probably has lots of flaws...): > > When the NIC first generates code for a given source method, all the > call sites are initialized with inline caches instead of PICs. When first generated, all call sites call the inline-cache-miss code; a transition to a PIC takes place only when after this code has been replaced with an inline cache, and then _that_ has missed. > What if > the second time the NIC had to generate code for the same source method > (different receiver "type") we just made a link to the same code? This > code would be shared until any one of the ICs misses. Then we copy the > code, set its IC to the new value and let each customized version go on > its own path from now on. > > The SIC could check this sharing as a hint that it might not want to > customize a given method. Obviously, any method that has aquired one or > more PICs must be customized. > > This still generates some identical copies, but at least it doesn't > need more checking than we already have. That sounds quite plausible to me. It's an alternative to the implementation I was pursuing, which never customizes NIC code, but uses PICs within NIC methods. -Mario

2 1

Re: compressing the code cache
by Mario Wolczko 03 Feb '02

03 Feb '02

It's so rare that Jecel makes a factual error that I feel obliged to correct this message: Ian wrote: > > Still, it would be interesting to know if there are any clues > > that the compiler could write to disk that would help it next > > time around; that would also improve performance. Can the code > > cache be compressed in any way? I implemented the snapshot code in 4.0. There is an option to pipe the snapshot through compress. Jecel replied: > One source of bloat used to be that every "type"/source method > combination that was called got its own native code version, yet often > the code was identical for different types. I think this was eliminated > from the NIC (I read somewhere that it no longer does "customization") > but would guess that it might still be a problem for the SIC. Just > passing the code cache through gzip when saving to disk should take > care of this, however. I tried to make the NIC not customize, and got most of the way there, however, it was still too unreliable to turn on by default. The option is called _ReuseNICMethods. The only benefit of customization in the current NIC is that accessess to slots in self are inlined. Surprisingly this doesn't buy very much performance (most of the time is spent running SIC code), but customization costs a great deal of memory, especially when running the ui. If you look at the SIC code, you really do want it to customize, because this enables a whole bunch of optimization opportunities that otherwise wouldn't be present (inlnining all sends to self). > One interesting solution would be to throw out all the code but keep > the PICs. They typically take up only 2% of the space of the compiled > code. I have no idea what the impact of this "warm compilation" would > have on start up performance, but it might be enough to be worth the > trouble. Yes, that's not a bad idea. Another is to throw out NIC code but keep SIC code. Unfortunately the different kinds of code are not segregated, so this would require a pass through the code cache. Mario

2 1

Re: Self ported to Linux
by Jecel Assumpcao Jr 02 Feb '02

02 Feb '02

On Monday 28 January 2002 02:48, alban read wrote: > Despite all the hype about the self compiler it actually runs like > a total dog (Self 4.1 on the Mac anyway). > It has to be ten times slower than Squeak and is too slow to be > useful. (Which is a shame) There is a lot of confusion about this. Since this is getting off topic for Squeak, I am sending a copy to the Self list so any discussion can continue over there. On the other hand, the subject might be of interest to jittery Squeakers ;-) The famous Self compiler that ran numerical benchmarks at 50% the speed of optimized C was introduced in Self 2.0 and was created by Craig Chambers. The result is simply amazing when you consider that C does no index or overflow checking and had a far better code generator. Craig's compiler was a huge leap forward in type analysis and he has continued this work in his Vortex Compiler project (for the Modula 3 and Cecil languages). The problem was that compilation was slow and so interactive use of Self 2 wasn't very nice. The compiler didn't do such a great job in highly polymorphic (very OO styled) benchmarks. In Self 3 and 4 an entirely different direction was taken by Urs H�lzle. Two simple compilers replaced the complex one used previously, and type analysis was replaced with type feedback. The first compiler (NIC, the Non Inlining Compiler) did a quick and dirty job that allowed code to start running. Data structures called PICs (Polymorphic Inline Caches) improved the performance of message sending and, as a side effect, collected information about the types of objects actually used in the various call sites in the code. When a given method was identified as being critical to system performance (a "hot spot", hence the name of the technology given at Animorphics and included in Java 2) the second compiler (SIC, the Simple Inlining Compiler) was called to generate much better code. Though the type information available in the PICs was just a subset of what could be obtained with type analysis, it was good enough for the SIC to do a good job very quickly. This new system did a better job on real applications and is far better for interactive use, but it doesn't get the fantastic benchmark results that Self 2 did. When porting Self to a new system, you can get it running by just implementing the NIC. Performance will be terrible since no inlining or type feedback will be used and these two are the key technologies in Self. For example, a simple "[...] whileTrue: [...]" will involve many message sends and block context creations *per loop*. Contrast that with Squeak where the compiler will generate optimized jump bytecodes instead. Unfortunately, neither the Power Mac nor the Linux PC ports implement the SIC, yet. David Ungar says performance is good enough on his PowerBook and a previous version (4.1.2) seemed almost reasonable on a 233 MHz iMac. The current version (4.1.4) is supposed to improve performance, but it seemed very slow on the 600 MHz iBook I tried it on (it wouldn't run on the iMac's OS 8.6). So I am afraid you haven't had a chance to see Self either as it was (Self 2) or how it is meant to be (NIC+SIC). At least for now, I am keeping my UltraSparc :-) -- Jecel

5 10

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 February 2002