Exupery

exupery@lists.squeakfoundation.org

107 discussions

Playing with Exupery
by bryce＠kampjes.demon.co.uk 17 Feb '07

17 Feb '07

Göran Krampe writes: > Hi folks! > > Just stumbled on this little tiny benchmark: > > http://butunclebob.com/ArticleS.UncleBob.SpeedOfJavaCppRuby Interesting, for what it's worth Exupery should be as fast or slightly faster than VW for that benchmark. Though I may have lost a little time recently but there's plenty of room for a little tuning to make it back up. First I had a look at what Exupery's doing with: tail -f Exupery.log | grep -v block Which shows the following: 9:38:21 pm: Initializing the Code Cache 9:38:24 pm: Compiling SmallInteger>>to:by:do: inlining #() 9:38:25 pm: Compiling WBKToys>>runOn: inlining #() 9:38:29 pm: Compiling SmallInteger>>to:by:do: inlining {{61 . ExuperyBlockContext}} 9:38:29 pm: Failed to inline ExuperyBlockContext>>value: 9:38:29 pm: Compiling WBKToys>>runOn: inlining {{33 . Array} . {44 . Array} . {61 . Array}} What's interesting is the #to:by:do. If you look at the bytecodes it's there. If I wrote a compiled version of ExuperyBlockContext>>value then even with the current bytecodes it should improve noticeably. Only compiled primitives can be inlined at the moment. Here's Exupery's benchmark suite: arithmaticLoopBenchmark 1387 compiled 127 ratio: 10.920 bytecodeBenchmark 2139 compiled 484 ratio: 4.419 sendBenchmark 1582 compiled 728 ratio: 2.173 doLoopsBenchmark 1063 compiled 843 ratio: 1.261 pointCreation 1075 compiled 1030 ratio: 1.044 largeExplorers 585 compiled 595 ratio: 0.983 compilerBenchmark 474 compiled 454 ratio: 1.044 Cumulative Time 1058.337 compiled 521.541 ratio 2.028 The bytecode benchmark is a prime number sieve similar to what you were using though coded to avoid sends and real blocks. Bryce

1 0

Image building
by Göran Krampe 16 Feb '07

16 Feb '07

Hi! Since the question on image building came up I just thought I could share a script we use with Gjallar - it is very KISS. For more advanced stuff - Keith Hodges has done lots of work on image building recently. Below is my script, slightly edited. It basically does these things: 1. Update SqueakMap. 2. Install a bunch of packages, either "newest for this Squeak version" or specific versions. 3. Set up some MC repositories. 4. Install newest MC version given matching patterns. 5. Install a changeset with "loose patches". regards, Göran ------------- | gjallarRepo seasideRepo magmaRepo graphvizRepo mcRepo block | SMSqueakMap default loadUpdates; installPackageNamed: 'Shout'; "this is used by the LocalizationTools" installPackageNamed: 'DynamicBindings'; installPackageNamed: 'KomServices'; installPackageNamed: 'KomHttpServer'; installPackageNamed: 'HTMLBuilder'; installPackageNamed: 'HttpView2'; installPackageNamed: 'YAXO'; installPackageNamed: 'ODBC for Squeak'; installPackageNamed: 'ODBCEnh' autoVersion: '7': installPackageNamed: 'SoapCore' autoVersion: '6'; installPackageNamed: 'OperaORB' autoVersion: '1'. (Smalltalk at: #MCRepositoryGroup) default initialize addRepository: (magmaRepo _ (Smalltalk at: #MCHttpRepository) location: 'http://www.squeaksource.com/MagmaTester' user: '' password: ''); addRepository: (mcRepo _ MCHttpRepository location: 'http://www.squeaksource.com/Monticello' user: '' password: ''); addRepository: (graphvizRepo _ (Smalltalk at: #MCHttpRepository) location: 'http://squeak.saltypickle.com/GraphViz/' user: '' password: ''); addRepository: (seasideRepo _ (Smalltalk at: #MCHttpRepository) location: 'http://www.squeaksource.com/Seaside' user: '' password: ''); addRepository: (gjallarRepo _ (Smalltalk at: #MCHttpRepository) location: 'http://gjallar.krampe.se' user: '' password: ''). block _ [:repo :base | | coll name | coll _ SortedCollection new. (repo readableFileNames select: [:e | base, '*' match: e]) do: [ :each | name _ (each copyUpToLast: $.) copyUpTo: $(. name last isDigit ifTrue: [ coll add: (((name copyAfterLast: $-) copyAfter: $.) asInteger) -> each]]. coll last value]. (mcRepo versionFromFileNamed: ( block value: mcRepo value: 'Monticello-avi.')) load. (magmaRepo versionFromFileNamed: ( block value: magmaRepo value: 'MagmaServerLoader-cmm.')) load. (gjallarRepo versionFromFileNamed: ( block value: gjallarRepo value: 'GraphViz-gk.')) load. " (graphvizRepo versionFromFileNamed: ( block value: graphvizRepo value: 'GraphViz-jrp.')) load." "Prerequisites for the localization tool" (gjallarRepo versionFromFileNamed: ( block value: gjallarRepo value: 'AST')) load. (gjallarRepo versionFromFileNamed: ( block value: gjallarRepo value: 'Shout')) load. (gjallarRepo versionFromFileNamed: ( block value: gjallarRepo value: 'INIFile-gk.')) load. (gjallarRepo versionFromFileNamed: ( block value: gjallarRepo value: 'Seaside2.7a1-gk.')) load. (seasideRepo versionFromFileNamed: ( block value: seasideRepo value: 'Scriptaculous-lr.141')) load. (gjallarRepo versionFromFileNamed: ( block value: gjallarRepo value: 'LocalizationTools-kb.')) load. (gjallarRepo versionFromFileNamed: ( block value: gjallarRepo value: 'InstallerBuilder-gk.')) load. (gjallarRepo versionFromFileNamed: ( block value: gjallarRepo value: 'LDAP-gk.')) load. (gjallarRepo versionFromFileNamed: ( block value: gjallarRepo value: 'Q2v0.3-gk')) load. (gjallarRepo versionFromFileNamed: ( block value: gjallarRepo value: 'Q2-Morphic-hk')) load. SARInstaller fileIntoChangeSetNamed: 'basepatches' fromStream: (FileDirectory default readOnlyFileNamed: 'basepatches.1.cs'). Q2Gjallar prepareDevImage.

1 0

Building a VM for Exupery on Linux/x86
by Andrew Gaylard 12 Jan '07

12 Jan '07

Hi, I've just started poking around with Exupery, and thought I'd try building the whole lot from scratch. This turned out to be harder than I expected. When I finally got something that worked, I thought I'd turn the process into a script to make it easier for anyone else who's come up against this. If you'd like to try this, you need a Linux PC, with X and the necessary development tools installed (gcc, etc.). You don't need a working squeak installation. The script first downloads the necessary bits, before building a plain 3.9 VM. It then runs VMMaker in this VM to generate the new bits, before finally building the Exupery VM. Some notes: * After the script completes, you'll be left with two functional VMs. By default, they're installed in /opt/squeak-3.9-8 and /opt/squeak-3.9-8-exupery. You just need to alter your PATH to pick the one you want. * You'll have to make your /opt writable by the user who runs the script (or choose other locations). * During the VMMaker process, squeak requests your initials. I haven't figured out how to get the Squeak installer to respond automatically, so you'll have to respond manually for now. * For some reason, the UUIDPlugin and B3DAcceleratorPlugin had problems compiling. So I've left them out. The new VM and image run most of the tests correctly. However, I'm seeing these 16 errors from the Programmer-tests: AssemblerTests>>#testDoublePicEntry AssemblerTests>>#testPic AssemblerTests>>#testPicEntry AssemblerTests>>#testPicEntry2 ByteCodeReaderTests>>#testStackHeightWithJumps InstructionSelectionTests>>#testPic InterferenceGraphGenerationTests>>#testPic IntermediateSimplifierTests>>#testBytecodePrimNewWithArg IntermediateSimplifierTests>>#testSendMessage IntermediateSimplifierTests>>#testSendMessageCheckingPicEntry IntermediateSimplifierTests>>#testSendWithStack IntermediateSimplifierTests>>#testSendWithStack2 LivenessAnalysisTests>>#testPic LowLevelOptimiserTests>>#testPic TestEndToEnd>>#testBenchFib TestEndToEnd>>#testStringConcatenate I'm also seeing these errors from the Customer-tests: ExuperyStoryTests>>#testBlockBug3 ExuperyStoryTests>>#testBlockNonLocalReturnsRecycleContexts ExuperyStoryTests>>#testBlocksAndProcesssesBug ExuperyStoryTests>>#testDelayWaitStressTest Should these work? If so, what have I missed? Thanks, Andrew. PS: Sory for the long mail, but I tried adding this info to the "Building Exupery on Unix" wiki page (http://wiki.squeak.org:8080/squeak/5672), but my login was rejected. PPS: I'm completely unable to use the wiki on port 80. Apparently, this is due to the site rejecting proxied connections. However, Internet connections without transparent proxying are _extremely_ rare in my neck of the woods. Are there any plans to sort this out?

3 3

Progress towards Exupery 0.11
by bryce＠kampjes.demon.co.uk 30 Dec '06

30 Dec '06

There is now a working new primitive and an ExuperyMethodContext class. The stress test also is mostly working, there's a bug that may not be due to Exupery but should probably be investigated further. I've started work on interrupt support. Hopefully 0.11 should have all the VM level support required for reasonable background compilation. The new primitive only works for fixed size pointer objects that don't need a large header. This covers many cases as a small object can have up to 64 instance variables. Adding variable sized objects, larger objects, and byte storage objects should be relatively easy but can wait. ExuperyMethodContext is there to deal with the differences between Exupery's method contexts and the interpreters. When I added block support I moved the compiled program counter into the interpreters program counter slot which meant that the debugger stopped working with Exupery's method contexts as the PC was no longer pointing to bytecodes. Before blocks, the compiled PC was stored in an unused slot in the MethodContext and compiled code would save the bytecode PC so the debugger would work if the method wasn't changed by the debugger. The new ExuperyMethodContext class provides both a place to translate a compiled PC to a bytecode PC and also a place to put deoptimisation code if the context is modified. There is now some basic support for deoptimisation in the debugger. With both the new primitive and ExuperyMethodContext working and the stress test mostly working, I've started work on interrupt support. Squeak has it's own interrupts that are used for processes, Alt-., and profiling. On backwards jumps and sends Squeak checks if any events have happened that require a context switch. Until now Exupery hasn't done this. Interrupts are important for background compilation so infinite loops inside compiled code are interruptible with Alt-. and so that Squeak's profiler will see compiled code. After 0.11, the next step will be the image side support required for background compilation. Background compilation itself should be fairly easy. It would be nice to have better ways to decide what should be compiled. The current profiler doesn't track what's already been compiled. Also methods should be deoptimised if they are changed. Bryce

1 0

HOWTO: Building Exupery on Windows
by Jakub Kozisek 16 Dec '06

16 Dec '06

Hello, you can read this new howto on http://wiki.squeak.org/5904 . Hope you will find it useful! Big 'thank you' goes to Bryce and Andrew Tween for support! Jakub Kozisek

1 0

Thinking about the next release.
by bryce＠kampjes.demon.co.uk 26 Nov '06

26 Nov '06

At the moment I'd like to get the following into the next release of Exupery: * A new primitive. * A new context class for Exupery's method contexts. * Return true and false primitives. * Get the stress test running in 3.9 The new primitive should mean that compiling the large explorers benchmark will always be beneficial. At the moment if it tries to inline point creation then there's a 5-10% speed loss. New is also a useful building block because it's used in many other primitives. The new context class is to interact with the debugger and other tools. It will also provide an easy place to put decompilation hooks if a context is being manipulated via reflection. The goal is to have the debugger and profilers work nicely with Exupery's compiled methods again. Creating a new context class to do this should make it easier to add full method inlining in 2.0. Return true and false primitives are to enable these simple primitives to be compiled and inlined as they do almost nothing. At the moment compiled code does a full primitive lookup to execute these primitives while the interpreter inlines them into commonSend. The stress test crashes again. This looks like it's because there are more tests in 3.9 and some of those tests cause Exupery problems. I also think there may be a bug or two due to upgrading VMMaker to 3.8b6. That just leaves implementing interrupt checking in compiled code before Exupery is ready to begin running in the background. I suspect that the register allocator will need a bit of tuning to speed up compile times and more bugs will need to be fixed before background compilation is practical. Bryce

1 0

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

exupery vm
by Chris Muller 17 Nov '06

17 Nov '06

One more question. How safe is it to stick with the exupery vm for my non-exupery-loaded images?

4 4

testing with new 0.1
by Chris Muller 17 Nov '06

17 Nov '06

Hi Bryce, thanks for the new release. I have been playing around with it and have some questions. First, I was surprised to see the suggestion to compile Array>>at: and Array>>at:put:. These methods are already inlined, right? They inherit the implementation in Object which are already both primitives. Primitives are already "compiled" right? So how does Exupery speed them up? Overall, does it ever make sense to compile a method with just a single send in it? Does Exupery dive into the called method and compile that too? If not, I don't see how it could help unless some inlining was done.. This allso led to my other question. These Swiki instructions tell Exupery to compile an inherited method, not an actual method that exists on Array. Since we don't pass the actual CompiledMethod object to Exupery (e.g., Exupery compile: Array>>#at:), instead a selector and a class, what interpretations about these does Exupery make with respect to inheritance. Forging onward, I decided to piggyback on your easy approach provided by ExuperyBenchmarks to experiment so I can easily see results of compiling some of my own methods. I have these two methods which set or get an unsigned integer into a ByteArray. Because of the lesser results I get, I want to post their implementation right in the email so you may have an idea.. ByteArray>>maUint: bits at: anInteger | answer bytes | bits == 64 ifTrue: [ ^ self maUnsigned64At: anInteger + 1 ]. bits == 56 ifTrue: [ ^ self maUnsigned56At: anInteger + 1 ]. bits == 48 ifTrue: [ ^ self maUnsigned48At: anInteger + 1 ]. bits == 40 ifTrue: [ ^ self maUnsigned40At: anInteger + 1 ]. bits == 32 ifTrue: [ ^self unsignedLongAt: anInteger + 1 bigEndian: false ]. bits == 16 ifTrue: [ ^self unsignedShortAt: anInteger + 1 bigEndian: false ]. bits == 8 ifTrue: [ ^self byteAt: anInteger + 1 ]. bytes _ bits // 8. answer _ LargePositiveInteger new: bytes. 1 to: bytes do: [ :digitPosition | answer digitAt: digitPosition put: (self at: digitPosition + anInteger) ]. ^answer normalize and ByteArray>>#maUint: bits at: position put: anInteger position + 1 to: position + (bits // 8) do: [ :pos | self at: pos put: (anInteger digitAt: pos-position) ]. ^anInteger Now, when I just compiled these two methods alone, I get: maUintAtPutBenchmark 5625 compiled 7912 ratio: 0.711 maUintAtBenchmark 2610 compiled 3474 ratio: 0.751 Cumulative Time 27.124 compiled 30.748 ratio 0.882 So, this tells me that compiling *can* actually make things worse. Is there any way for Exupery to detect and prevent this or is this strictly the user/developers responsibility to profile everything for comparison? Next I tried adding compilation of some of the lower-level methods called by these methods. I first just added Exupery compileMethod: #at: class: ByteArray Normally I wouldn't do this but since the Swiki suggested compiling Array>>#at: I thought it worth a try. But it caused the stack-trace at the end of this e-mail. I tried just a few more experiments such as SmallInteger>>#digitAt: and Integer>>#bitShift: but generally couldn't get results above 1.0. BTW, on a completely separate experiment, one method I tried to compile it said "Unknow bytecode" (it was bytecode 136). Ok, so obviously I'm a novice at this! This project is exciting and I'm at least I know Exupery is doing something (compared to my last attempt where I didn't even know to compile methods), but hope that I can figure out how to actually make it go *faster*. :) Can you help me with any advice / guidelines for *what* to compile? Thanks, Chris 15 November 2006 10:53:18 pm VM: Win32 - a SmalltalkImage Image: Squeak3.8 [latest update: #6665] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir C:\Development\Chris\Development\Squeak Trusted Dir C:\Development\Chris\Development\Squeak\Chris Untrusted Dir C:\My Squeak\Chris IntermediateSimplifier>>primitiveAt: Receiver: an IntermediateSimplifier Arguments and temporary variables: aMedPrimitive: #(#primitive 60 'block6' #(#mem #(#add #(#mem #activeContext) #(...etc... methodBytecodes: nil index: nil resultAddress: nil receiver: nil Receiver's instance variables: source: a MedMethod result: a MedMethod emitter: an IntermediateEmitter currentBlock: (block1 (primitiveReturn #(#primitive 60 'block6' #(#mem #(#add ...etc... stack: an OrderedCollection() simplifier: an IntermediateSimplifier stacksForBlocks: a Dictionary() IntermediateSimplifier>>visitPrimitive: Receiver: an IntermediateSimplifier Arguments and temporary variables: aMedPrimitive: #(#primitive 60 'block6' #(#mem #(#add #(#mem #activeContext) #(...etc... Receiver's instance variables: source: a MedMethod result: a MedMethod emitter: an IntermediateEmitter currentBlock: (block1 (primitiveReturn #(#primitive 60 'block6' #(#mem #(#add ...etc... stack: an OrderedCollection() simplifier: an IntermediateSimplifier stacksForBlocks: a Dictionary() MedPrimitive>>visitWith: Receiver: #(#primitive 60 'block6' #(#mem #(#add #(#mem #activeContext) #(#add #(#sal #(#mem #(#add ...etc... Arguments and temporary variables: aTreeOptimiser: an IntermediateSimplifier Receiver's instance variables: in: nil out: nil primitiveName: primitive 60 arguments: #(#(#mem #(#add #(#mem #activeContext) #(#add #(#sal #(#mem #(#add #...etc... failureBlock: (block6 (createContext) (deconvertBoolean falseObj #(#send #(#m...etc... receiver: ByteArray IntermediateSimplifier>>visitPrimitiveReturn: Receiver: an IntermediateSimplifier Arguments and temporary variables: aMedPrimitiveReturn: #(#primitiveReturn 2 #(#primitive 60 'block6' #(#mem #(#ad...etc... Receiver's instance variables: source: a MedMethod result: a MedMethod emitter: an IntermediateEmitter currentBlock: (block1 (primitiveReturn #(#primitive 60 'block6' #(#mem #(#add ...etc... stack: an OrderedCollection() simplifier: an IntermediateSimplifier stacksForBlocks: a Dictionary() --- The full stack --- IntermediateSimplifier>>primitiveAt: IntermediateSimplifier>>visitPrimitive: MedPrimitive>>visitWith: IntermediateSimplifier>>visitPrimitiveReturn: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MedPrimitiveReturn>>visitWith: [] in IntermediateSimplifier(IntermediateCopier)>>simplifyBlock: {[:each | emitter addExpression: (each visitWith: self)]} OrderedCollection>>do: MedBlock>>instructionsDo: IntermediateSimplifier(IntermediateCopier)>>simplifyBlock: IntermediateSimplifier>>simplifyBlock: [] in IntermediateSimplifier>>visitMethod: {[:each | self prepareBlockFrom: each. self simplifyBlock: each]} OrderedCollection>>do: IntermediateSimplifier>>visitMethod: MedMethod>>visitWith: IntermediateSimplifier(IntermediateCopier)>>run Exupery>>convertIntermediate Exupery>>run Exupery class>>compileMethod:inlining:receiver: Exupery class>>compileMethod:into:forClass:inlining: Exupery class>>compileMethod:class:inlining: Exupery class>>compileMethod:class: ExuperyBenchmarks>>compilemaUintAt ExuperyBenchmarks>>runBenchmark:compilingWith: [] in ExuperyBenchmarks>>run {[:each | self runBenchmark: (each at: 1) compilingWith: (each at: 2)]} Array(SequenceableCollection)>>do: ExuperyBenchmarks>>run UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: [] in TextMorphEditor(ParagraphEditor)>>evaluateSelection {[rcvr class evaluatorClass new evaluate: self selectionAsStream in: ctxt...]} BlockContext>>on:do: TextMorphEditor(ParagraphEditor)>>evaluateSelection TextMorphEditor(ParagraphEditor)>>doIt [] in TextMorphEditor(ParagraphEditor)>>doIt: {[self doIt]} TextMorphEditor(Controller)>>terminateAndInitializeAround: TextMorphEditor(ParagraphEditor)>>doIt: TextMorphEditor(ParagraphEditor)>>dispatchOnCharacter:with: TextMorphEditor>>dispatchOnCharacter:with: TextMorphEditor(ParagraphEditor)>>readKeyboard ...etc...

2 1

[ANN] Exupery 0.10 released, now on Windows and Linux
by bryce＠kampjes.demon.co.uk 16 Nov '06

16 Nov '06

Exupery 0.10 is now released. There are prebuilt VM's available for both Windows and Linux. This release now provides a measurable speed improvement for the compilerBenchmark macro benchmark due to work on dynamic primitive inlining. Instructions for installation and a link to a pre-built image is here: http://minnow.cc.gatech.edu/squeak/3945 Benchmarks on my Athlon 64 3500+ ========================================================= arithmaticLoopBenchmark 1398 compiled 92 ratio: 15.196 bytecodeBenchmark 2134 compiled 469 ratio: 4.550 sendBenchmark 1580 compiled 697 ratio: 2.267 doLoopsBenchmark 1090 compiled 840 ratio: 1.298 largeExplorers 334 compiled 358 ratio: 0.933 compilerBenchmark 733 compiled 705 ratio: 1.040 Cumulative Time 4167 compiled 1448 ratio 2.878 1,067,222,511 bytecodes/sec; 16,716,421 sends/sec Benchmarks on Andy's Mobile Pentium 3 ========================================================= arithmaticLoopBenchmark 2487 compiled 285 ratio: 8.726 bytecodeBenchmark 4271 compiled 1255 ratio: 3.403 sendBenchmark 3482 compiled 1772 ratio: 1.965 doLoopsBenchmark 2078 compiled 1663 ratio: 1.250 largeExplorers 2224 compiled 1683 ratio: 1.321 compilerBenchmark 2093 compiled 1712 ratio: 1.223 Cumulative Time 12903 compiled 4971 ratio 2.596 Benchmarks from my Pentium-M laptop ========================================================= arithmaticLoopBenchmark 1003 compiled 191 ratio: 5.251 bytecodeBenchmark 1773 compiled 683 ratio: 2.596 sendBenchmark 1446 compiled 922 ratio: 1.568 doLoopsBenchmark 991 compiled 918 ratio: 1.080 largeExplorers 418 compiled 441 ratio: 0.948 compilerBenchmark 718 compiled 683 ratio: 1.051 Cumulative Time 3773 compiled 2015 ratio 1.872 It's interesting that on Andy's machine Exupery is providing a nice performance improvement for largeExplorers while on my machine there is a 7% performance loss. The loss is due to the interpreter inlining Point>>@ into the main interpreter loop while Exupery executes it as a normal primitive. Andy's benchmarks are promising enough for a 1.0, pity relative performance isn't so high on the other two machines. There is a mailing list for those interested in the project here: http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery Many thanks to Andy Tween for doing the Windows port and building the official Windows VM. Thanks also to Patrick Mauritz for doing a Solaris x86 port which was the first OS port. Bryce

2 2

← Newer
1
...
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Exupery