Just a thought.
Could optional typing be a way to trim Self performance? I spotted the Strong Talk project: http://www.cs.ucsb.edu/projects/strongtalk/pages/
I know that this is somewhat controversial, but it could, without altering what is, also bridge to other typed languages and deliver 'pass by value...' ;-)
Am I Wrong?
best, Jonas
On Friday 09 January 2004 02:41, Jonas Bosson wrote:
Just a thought.
Could optional typing be a way to trim Self performance? I spotted the Strong Talk project: http://www.cs.ucsb.edu/projects/strongtalk/pages/
I think the Strongtalk people found that the typing was just for the programmer (to check contraints at compile time). The performance came from magical compiler technology. Pretty sure that the Strongtalk compiler ignores the declared type of things for producing code.
Steve.
Jonas Bosson wrote:
Just a thought.
Could optional typing be a way to trim Self performance? I spotted the Strong Talk project: http://www.cs.ucsb.edu/projects/strongtalk/pages/
I know that this is somewhat controversial, but it could, without altering what is, also bridge to other typed languages and deliver 'pass by value...' ;-)
Am I Wrong?
I worked on Strongtalk, and in particular on the type system. Strongtalk typing was never intended to be used as a performance boost. It's main value is as documentation and as a design discipline. It has relatively small value for early error detection, and no effect on performance.
The performance of the system came from VM technology, especially adaptive dynamic compilation, which was very close to what Self already does, and indeed inspired by Self. Strongtalk differed from Self in requiring a much smaller footprint - however, Self could be engineered to do the same (at least, Lars Bak, who worked on both Self and Strongtalk, thought so). Another difference that might effect the perceived responsiveness of the system was the absence of a morphic GUI (replaced by a flyweight glyph-based GUI on top of native Windows widgets).
We did experiment with using type information for performance in one area - floating point arithmetic. You can get around 60% of optimized C speed on certain floating point codes, using types as a hint to the JIT, which then verifies the type information and optimizes based on it, stictly intra- (not inter-)procedurally. Check out the Mandelbrot demo in the Strongtalk release to see an example.
Gilad Bracha wrote:
We did experiment with using type information for performance in one area - floating point arithmetic. You can get around 60% of optimized C speed on certain floating point codes, using types as a hint to the JIT, which then verifies the type information and optimizes based on it, stictly intra- (not inter-)procedurally.
Yep, that was my idea, but using the extra typinfo could also do VM optimizations on a interprocedural level, and as such bridge the gap to.. say java classes. I felt that the Strong talk idea is cool because enables optional typing as a special case in a VM, like a seamless bridge to the typed and word-size industry world.
Check out the Mandelbrot demo in the Strong talk release to see an example.
Wine (windows emulator) seems to handle it fine just up until I start the mandel-app: err:local:LOCAL_GetBlock not enough space in GDI heap 0147 for 136 bytes. But I trust your word for it. ;-)
I feel quite restrained in using java, but then have to. I have tried to make it bearable by building a small GUI-Lobby, shared VM (know the limits) and runtime evaluator (using the class loader). This however is far from the practical gains of prototyping and I often find myself starting the ol'Self demo to find comfort in that there might be a revolution rather than just slow evolution out there.
I have long played with the idea to use Self as the development platform for java apps, and combine changing live classes in java by modifying slots. I know this is a ugly round trip in a Self perspective, but in comparison with todays java-IDE-world, it would be a blessing. It would require a well integrated concept for types, at least in the IDE. This method could be used to produce .net, c, etc too, all in the native language but with fragments of the prototype runtime experience.
If one can't sell prototyping directly in industry apps, one could at least make use of it in development. ;-) Any such projects out there perhaps?
/Jonas Bosson
self-interest@lists.selflanguage.org