Exupery October 2006

exupery@lists.squeakfoundation.org

7 participants
7 discussions

Common Smalltalk VM Summit
by David Griswold 20 Nov '06

20 Nov '06

Hi everybody, Dan Ingalls and I have been talking, trying to figure out what to do about the major opportunity offered by the recent release of the Strongtalk virtual machine as open source. Rather than keep this discussion to ourselves, our thinking was that this would be the perfect time to call a kind of summit, with representatives of all the major Smalltalk implementations, both open-source and commercial. The topic: what if we could build a shared high-performance open-source platform suitable for hosting a number of different Smalltalk systems, one that we can all share and work on together? While the details of the type-feedback techniques used in the Strongtalk VM are arcane, the benefits are not: *much* higher performance for general Smalltalk code. Dan, myself, and many others who know about type-feedback and the pioneering Self system, have been dreaming for many years about the possibility that someday this technology might make it into mainstream Smalltalk VMs. It would take Smalltalk performance to a whole new level. That someday is here now, if the different factions within the Smalltalk community can pull together a little bit so that we don't miss this opportunity. There may be debate within the community about some aspects of the Strongtalk project, for example the type system, but we should all be able to agree on the simple idea that a whole lot more performance would be a Good Thing. Now a huge performance gift has suddenly shown up on our doorstep. The last thing Smalltalk needs is another incompatible implementation. The splintering of Smalltalk implementations has dispersed the huge amount of talent and effort needed to build, port, maintain, and extend a really good virtual-machine. Alone, this is a problem for each of us. Together, a really good, super-fast type-feedback VM is for the first time within reach. I would like to invite the smart people out there who know and care most about the various Smalltalk virtual machines, to join Dan and I in a fairly focused discussion about this starting tomorrow (Thursday, PST) on the Strongtalk discussion group, at http://groups.google.com/group/strongtalk-general. I will be out of the country for 6 weeks starting Wed the 11th, so I would like to propose that we try to go back and forth about this a few times by the end of Friday, so we can think about this over the weekend, and maybe come up with a proposed general course of action by the middle of next week, so we all have something to think about until my return. Let's not lose this opportunity. Cheers, Dave

3 2

question
by Chris Muller 25 Oct '06

25 Oct '06

Hi Bryce, great job on your perseverence, sounds like you're getting close! My interest is seething, as I'm sure many in our community, don't quit now, ok? :) I have been thinking in terms of Magma's materialization process, whether Exupery could deal with it. When an object graph is materialized from a ByteArray, the object structure is built in two steps. The first step establishes identity <-> oids by instantiating all of the objects with pointers to Integer oids, potentially Large or Small. For example, aPerson (110) name = 115 address = 130 aName (115) first = 116 last = 117 'Chris' (116) 'Muller' (117) anAddress (130) street = 141 '101 W. Meyer' (141) The second step then replaces those integers with the actual objects (or a proxy). aPerson name = aName address = anAddress anAddress street = '101 W. Meyer' If a particular variable can have an Integer, Proxy or the RealObject at various times, will that disrupt Exupery's ability to optimize the domain code, or am I confusing with Strongtalk?

2 1

Is it worth releasing now?
by bryce＠kampjes.demon.co.uk 24 Oct '06

24 Oct '06

Exupery now produces a noticeable speed improvement for the compiler benchmark. This is the bytecode compiler. I'm now going to work on reliability. It's probably more reliable now than the last release. arithmaticLoopBenchmark 1395 compiled 92 ratio: 15.163 bytecodeBenchmark 2131 compiled 457 ratio: 4.663 sendBenchmark 1588 compiled 697 ratio: 2.278 doLoopsBenchmark 1088 compiled 657 ratio: 1.656 largeExplorers 326 compiled 359 ratio: 0.908 compilerBenchmark 727 compiled 699 ratio: 1.040 ======================================================== Cumulative Time 4140 compiled 1370 ratio 3.022 The two most interesting benchmarks are largeExplorers and the compilerBenchmark. largeExplorers opens a large explorer window, it's an example of slow Morphic behavior. They are the two real world benchmarks, both purely use profiling to drive compilation, and both are real applications. The other benchmarks are micro benchmarks. The gains to compilerBenchmark are obtained by spending only 5% of the time in compiled code and it's support routines. The gains should be able to be improved by both better profiling and tuning. largeExplorers calls #@ frequently to construct points. This is a normal Slang primitive for native code but the interpreter inlines it into a special bytecode. Writing Exupery intermediate versions of #@ and #new would allow Exupery to generate optimal code for object creation that will be inlined by the primitive inlining system. The decision is whether to release as soon as all known testable quality problems are fixed or to implement #new and #@ before releasing. Releasing is quick on my side. The current development code includes Andy's changes to allow Exupery VMs to be built on Windows. Bryce P.S. Tony, the bug we were looking at on Saturday is now fixed. It was caused by an accidental indirect recursion consuming all the C stack. The change to newNativeMethod stopped exuperyBlock:Value: from realizing that it was called from compiled code so it called compiled code directly instead of setting newNativeMethod and returning.

2 2

RE: Porting
by bryce＠kampjes.demon.co.uk 15 Oct '06

15 Oct '06

Hi David, David Griswold writes: > If all that happens is that whenever a typecheck fails you jump > to a single alternate flow of control that does only sends and avoids > all inlining, then that sounds like the equivalent of an uncommon trap, > except that you lose the biggest advantage of deoptimization, which is > that compilation and inlining are completely transparent to the debugger > and all other kinds of context reflection. > > How does Exupery compiled code work with the debugger (especially when you > start doing inlining)? How would the reflection that for example Seaside > does, work with > compiled contexts? Exupery can decompile a context at any time, it's just done in the image by using reflection. Contexts are just normal objects in Squeak and Exupery adds it's own context classes. Exupery's contexts are responsible for converting themselves into interpreted contexts when necessary. (1) If anything is done to an Exupery context that could invalidate the assumptions of compiled code then the context should convert itself to an interpreted context. So if the debugger trys to change a context it should convert itself back to an interpreted context. The profiler however should not cause contexts to convert themselves to interpreted contexts. It's the ExuperyContext's responsibility to convert itself into an interpreted context when Seaside serializes it. Seaside could serializes an ExuperyContext but that could cause a crash if the ExuperyContext converted itself into an interpreted context then Seaside recreated the stack with it in. ExuperyContexts have different instance variables to interpreted contexts so filling an interpreted contexts variables using instVarAt:put: after taking them from an Exupery context with instVarAt: is dangerous. If Seaside calls a context to save itself rather than using instVarAt: to get the state out then making it work with Exupery is easy. An Exupery context could also convert itself if instVarAt: is called on it. ExuperyBlockContext>>convertToInterpretedContext will convert an Exupery block into an interpreted block. It re-arranges the instance variables then calls primitiveChangeClassTo: to change the class. Exupery manages it's code cache purely in the image. It needs to convert all Exupery contexts back to interpreted contexts before flushing the code cache or saving the image. Otherwise it may try to execute compiled code that's not there. Uncommon traps are definitely a very nice optimization for a fast compiling compiler. By removing the need to produce the code they speed up compilation. However uncommon traps do make it harder for a slow compiler that trys to produce very fast code. > Strongtalk doesn't do any of that right now. The normal uncommon trap > mechanism, combined with our use of 0 tags for SmallIntegers, means that > SmallInteger arithmetic is very fast already, since addition for example > doesn't require any tag manipulation at all, so we don't really have to > worry about conversion/deconversion issues. I was thinking about true 32 bit integers not SmallIntegers. True 32 bit integers are needed for a few applications such as cryptology. The Squeak cryptography guys are currently writing a few primitives to speed up their inner loops. > As for double precision floats, they could be done the way you are > suggesting, which would be nice, but right now they are not done that way. > Right now our "fast float" experiment uses special bytecodes that treat them > as a non-OO basic type (with explicit conversion to and from objects). But > that was just a quick experiment that Robert Griesemer did, and it is not > really part of the "language", although they work and are very fast. Sounds interesting, I'd like to talk more about it when I'm ready to start work on floating point. Bryce (1) The description is true for block contexts but not method contexts. Exupery method contexts currently share the same class as interpreted method contexts. I'll create their own class before 1.0. Before blocks the old style Exupery method contexts were executable by a normal VM which was very nice for early bootstrapping. This also meant that the debugger would work for them unless it was single stepped. The decompilation code is present and well tested. What's missing is the hooks to trigger decompilation when a context is manipulated via reflection.

1 0

Re: Cryptographic Primitives
by bryce＠kampjes.demon.co.uk 08 Oct '06

08 Oct '06

Andreas Raab writes: > J J wrote: > >> No. First, Exupery is not a JIT. > > > > I had been told it was. In this list actually. > > Yeah, it's quite confusing actually. I found the statement that > "[Exupery is] a "JIT" for Squeak that doesn't compile just in time" > which (to me) makes no sense as "JIT" stands for "just in time" so how > could a JIT not compile just in time? ;-) When Exupery is running in a background thread a user shouldn't notice that it's not a "real" JIT. So calling it a JIT is fair. It does not stop execution to compile like the VisualWorks VM does. This means it must fall back to the interpreter if compiled code doesn't exist. It can't compile "just" in time. It can compile just afterwards though. I'll write an up to date overview of what Exupery is, what it plans to be, and what it does now soon. Either before or just after the next release. All that's left to do before releasing is implement the two primitives #new and #@ then fix some bugs. The two primitives are required for the largeExplorers benchmark. Here's the current benchmarks. arithmaticLoopBenchmark 1395 compiled 91 ratio: 15.330 bytecodeBenchmark 2132 compiled 456 ratio: 4.675 sendBenchmark 1588 compiled 684 ratio: 2.322 doLoopsBenchmark 1086 compiled 649 ratio: 1.673 largeExplorers 337 compiled 366 ratio: 0.921 compilerBenchmark 794 compiled 767 ratio: 1.035 Cumulative Time 4241 compiled 1389 ratio 3.053 The most interesting benchmarks now are largeExplores (opening a very large explorer) and compilerBenchmark (compiling a large method into bytecodes). Both are real uses. Both use a profiler to choose methods to compile then PIC based type feedback to inline primitives. largeExplorers needs a faster #@. The interpreter inlines this into a bytecode while Exupery is currently doing a full message send. Once it's implemented as a compiled primitive it will then get inlined automatically. compilerBenchmark is spending 5% of it's time in compiled code and support routines. That provides a 3.5% gain. Better profiling may help by compiling more methods. I haven't looked at the profiler since the last optimisation. So would a little tuning, 1% of the time (out of 5% in compiled code) is spent building the new context during a message send, most of that time could be saved. It is however producing a performance gain. Which is enough to make bug fixing the priority again. The list of things to do before a 1.0 is here: http://minnow.cc.gatech.edu/squeak/5793 Nothing on it is hard or risks destabilising things. Bryce

2 3

Exupery is not JIT (was Re: Cryptographic Primitives)
by bryce＠kampjes.demon.co.uk 07 Oct '06

07 Oct '06

tim Rowledge writes: > Actually I don't think JIT is a sensible description at all; it isn't > accurate and it doesn't really indicate the advantages that Exupery > could have. For example, no extra startup costs, easier extension/ > maintenance/optimising because it is written in a sensible language, > access to all of the reflexive capabilities of the system, trivial > fallback if the system is run on an unsupported platform (it just > doesn't do the compiles and leaves everything to the interpreter), > potential for using a spoon-like inter-image communication system to > allow the compiles to run in a different image/machine, and... well I > could probably go on. Well, most people only really understand the static compilation model of C/C++, and the dynamic compilation model of VisualWorks and Java. They call any form of dynamic compilation a JIT. Many so called JITs compile in the background. I think IBM's Jalapino does background thread compilation. Exupery is in some ways closer to a Lisp compiler written in Lisp than a Deutsch-Schiffman influenced JIT. So, you could say it's drawing on a tradition that goes back to at least the '70s. Help is always appreciated. Exupery is a test heavy project, this should help people get up to speed. Tests are required for everything. If anyone would like to help please join the Exupery mailing list and ask. http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery There's a list of things to do before 1.0 here: http://minnow.cc.gatech.edu/squeak/5793 If you're thinking of writing hundreds of primitives for speed then helping out with Exupery is probably the best use of your time. If you're thinking about writing tens of primitives then it's debatable. If you're only thinking of writing a handful of primitives the just write the primitive unless working on a compiler is it's own reward. Going back to crypto. From what I understand about SSL writing the streaming cyphers as primitives should make sense for the next few years. Writing public key primitives would require some serious profiling first as they're only used once per session. But we all vote with our time. Just don't get upset if in 5 years time you're rewriting cyphers into Smalltalk from primitives for speed. Bryce

1 0

trying to see Exupery in action
by Chris Muller 06 Oct '06

06 Oct '06

Hi, I would like to see some indication of Squeak going faster with Exupery under Windows. I folllowed the instructions at http://minnow.cc.gatech.edu/squeak/3945. - downloaded the Windows VM and replaced my squeak.exe. F2 | Version Information reports "Squeak 3.7.1 (release) from Sep 18 2006". Is this right? - I then installed Exupery-wbk.206 from SqueakMap. Then ran the ExuperyStoryTests. All but two passed. - Still, I was eager so I did "0 tinyBenchmarks". Unfortunately I got the same #'s I got with another image without Exupery. I tried it a couple of times. - I then loaded the Exupery from SqueakMap and reran the tests. Same two failed. Ah, I need CommandShell and GraphViz loaded! - So I loaded CommandShell to try making those other tests pass. (When it reached that test it gave a bunch of errors saying it was going to stdout (looked like a mixed Unix/Windows filename), oh well). I didn't install GraphViz, I just don't think this is the problem; I am sure I am doing something else wrong. Any suggestions are appreciated.. - Chris

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Exupery October 2006