headers
Mathieu Suen | 5 Jul 21:15
Picon
Favicon

Papers that inspire Exupery

Hi Bryce,

I would like to know if you can provide us a list a papers on Jit.
Anything that inspire/explain what your doing in Exupery.

And also what do you think of stack base VM vs. register base VM?
I am asking because in smalltalk I am wondering if it worth register base VM.

Thanks

	Mth

	

	
		
___________________________________________________________________________ 
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com
Permalink | Reply | 3 comments |
headers
Bryce Kampjes | 7 Feb 18:12
Picon
Picon

Update on inlining

There's been some progress on Exupery. The current task is inlining
methods that don't create blocks.

The last commit includes the ability to inline methods with arguments.

The remaining tasks are:
 * Accessing the literal frame from an inlined method
 * inlined self references
 * inlined super calls
 * inlined methods with temporaries
 * deoptimising inlined methods
 * updating the profilers to automatically inline methods.

After that it's time to add closure support to Exupery then inline
blocks.

Bryce
Permalink | Reply | 0 comments |
headers
Cameron Sanders | 5 Jul 19:51

iMac support

Bryce & Exupery-minded folks:

I am using Pharo on an iMac for an in-house project that may later  
become a commercial product. My main displeasure with Pharo right now  
is performance; it sounds like Exupery may help greatly.

With that in mind, I am willing to help with Exupery, at least in  
terms of compilation on the iMac. I must be realistic about my time: I  
won't be able to invest a block of time until November or December.  
Still, along the way, I can begin exploring and learning.

My background (which I may already have shamelessly provided on some  
squeak list): I have written a million-plus of lines of code in C,  
always with an eye on performance (we rolled our own Objective-C like  
environment in the 1980's and early 1990's to build a radiation  
treatment planning system -- the product is used widely around the  
globe today... so it works!); also, I have written several byte-code  
interpreters over the years, so I am familiar with the general  
principles. The catch: I haven't compiled a C program in over 12  
years, except for turnkey GNU products. Furthermore, my coding during  
the last 12 years has been part-time in Python (extensively), java,  
gawk, or perl, and smalltalk (during the last year or so); as a  
result, the jargon I use is ... antiquated, if not corrupted, and  
quite simply, derelict. (Add to that the fact that I often type too  
fast and hit send too quickly... )

So... where to begin? I know I recently saw a link, but if you could  
please give me some direction, I would greatly appreciate it.

Thanks,
(Continue reading)

Permalink | Reply | 5 comments |
headers
bryce | 12 Mar 22:45
Picon
Picon

[ANN] Exupery 0.15 released

Exupery 0.15 is released and available via pre-built images, SqueakMap,
and package universes. This release includes some significant bug
fixes and a few performance enhancements.

Instructions are here: 

  http://wiki.squeak.org/squeak/Exupery

The biggest practical benefit is a major bug has been fixed which
makes running with Exupery much more reliable. Crashes are no longer
expected after about an hour or so. 

The two major optimisations were adding more addressing modes and
also compiling calls to the interpreters primitives. This means
that code with many calls to primitives can benefit from Exupery's
PICs. Compiling primitives is responsible for the doLoopsBenchmark
showing a benefit again, Exupery used to perform identically to the
interpreter on a Core 2.

While Exupery can improve the macro benchmarks sometimes it will
slow code down a little as well so practical performance gains
with unrestricted compilation are still a release or two away.

Here's the current benchmarks:

  arithmaticLoopBenchmark 390 compiled 80 ratio: 4.875
  bytecodeBenchmark 724 compiled 250 ratio: 2.895
  sendBenchmark 663 compiled 385 ratio: 1.722
  doLoopsBenchmark 381 compiled 235 ratio: 1.621
  pointCreation 394 compiled 389 ratio: 1.013
(Continue reading)

Permalink | Reply | 0 comments |
headers
bryce | 8 Mar 21:10
Picon
Picon

A design for full method inlining

Inlining contexts requires care to ensure that it's possible to
de-optimise them safely and that the semantics are never changed
even when code is changed or when reflection is used.

Things to consider:
 * De-optimisation
 * Blocks returning from the method and accessing state.
 * Changing code
 * debuggers and profilers (stack walking)
 * become: and changeClassTo: and #primitiveChangeClassTo:
 * other reflection including #instVarAt:put:
 * Seaside

At the moment it's possible to de-optimise any context individually
which is very convenient but means that the VM must not need to be
aware of whether a context is native or interpreted except when it's
executing it. The VM will refer to the home context of a block, so
everything it accesses must be in the same locations whether
interpreted or compiled. Being able to de-optimise a context without
needing to worry if there are block contexts is a great simplification
when ensuring Exupery doesn't cause crashes on de-optimisation.

De-optimisation can be triggered by various things like saving the
image, modifying a context, saving it in Seaside. Native contexts
can not be in the image when it's saved as the machine code they
depend on will not be there, and even if it is it's unlikely to
be at the same location. Seaside, and the profiler have opposite
problems for de-optimisation with Seaside we want to de-optimise
the context to make it safe to persist while with the profiler we
want to leave the context optimised so profiling doesn't change
(Continue reading)

Permalink | Reply | 1 comment |
headers
bryce | 8 Mar 10:28
Picon
Picon

0.16 possible tasks.


Here's a list if things that could be considered for 0.16 in rough
priority order:
 1) Full method inlining
 2) Support for proper closures
 3) Tuning to make the current compiler more useful
 4) Saving the image without removing all native code
 5) Saving native code with the image

I've fairly much settled on 1) as the main part of the
next release. It'll change the overall behaviour of Exupery
so it's worth doing before focusing on tuning the profiler
to pick the correct hot-spots. It's also hard to judge the
value of other send optimisations until I can see how well
dynamic inlining works.

2) would be nice and isn't that large. It'll involve freeing up the
"unused" slot in MethodContext, Exupery uses it as a flag to indicate
what methods are compiled and what methods are interpreted. That's a
legacy from back when it was the native PC. After freeing up the
"unused" slot closure support is just implementing a few more
bytecodes.

3) was the original plan. As reliability has jumped up enough to
tackle full method inlining and relative send performance is so much
worse on Core 2 than it was on Athlon 1) looks more appealing.

4) and 5) will both make testing a little easier. Given Exupery
is a slow compiler it shouldn't really throw native code away
as readily as it does now. Being able to use native code for longer
(Continue reading)

Permalink | Reply | 0 comments |
headers
bryce | 6 Mar 22:47
Picon
Picon

PIC details

Jecel Assumpcao Jr writes:
 > I am interested in the various efforts to add Polymorphic Inline Caches
 > to Squeak, like in
 > 
 > > slides - http://www.iam.unibe.ch/~denker/talks/07ICOOLPS/07PICsICOOOLPS.pdf
 > 
 > > paper - http://www.hirschfeld.org/misc/media/HauptHirschfeldDenker_2007_TypeFeedbackForBytecodeInterpreters.pdf
 > 
 > For this design they just replace the pointer to the symbol in the
 > method's literal frame with a pointer to an object which then points to
 > that symbol and which also adds the needed information (class / compiled
 > method pairs).
 > 
 > I plan to browse the Exupery sources to see what its PICs are like, but
 > for now I just took a quick look at the various presentations that are
 > available and saw a thread on this list from October 2008. My impression
 > so far is that PICs are short code fragments with pointers to classes
 > and which are treated mostly like native methods.
 > 
 > If there are more details anywhere, it would be very helpful.
 > -- Jecel

Exupery's PICs are still very simple. They are a short sequence of
null instructions that are replaced with cmp reg class, je newMethod
sequences. The PICs are made of two parts a control block with a
little data describing the PIC and a single slot to record any
interpreted classes. The profiler doesn't see primitives so the
PIC records interpreted receivers so primitives from interpreted
methods can be inlined.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Igor Stasenko | 6 Mar 00:34
Picon

Re: PIC details

I'm also interested.
Especially, what statistical information need to be collected at call
site to effectively switch between mono/poly/megamorphic cache.

2009/3/6 Jecel Assumpcao Jr <jecel <at> merlintec.com>:
> I am interested in the various efforts to add Polymorphic Inline Caches
> to Squeak, like in
>
>> slides - http://www.iam.unibe.ch/~denker/talks/07ICOOLPS/07PICsICOOOLPS.pdf
>
>> paper - http://www.hirschfeld.org/misc/media/HauptHirschfeldDenker_2007_TypeFeedbackForBytecodeInterpreters.pdf
>
> For this design they just replace the pointer to the symbol in the
> method's literal frame with a pointer to an object which then points to
> that symbol and which also adds the needed information (class / compiled
> method pairs).
>
> I plan to browse the Exupery sources to see what its PICs are like, but
> for now I just took a quick look at the various presentations that are
> available and saw a thread on this list from October 2008. My impression
> so far is that PICs are short code fragments with pointers to classes
> and which are treated mostly like native methods.
>
> If there are more details anywhere, it would be very helpful.
> -- Jecel
>
> _______________________________________________
> Exupery mailing list
> Exupery <at> lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
(Continue reading)

Permalink | Reply | 0 comments |
headers
bryce | 1 Mar 21:46
Picon
Picon

Preparing for 0.15 and planning 0.16


I'm doing the final preparation for the 0.15 release. There's a Linux
VM and a Windows VM built so far. The Windows VM lacks freetype but
should otherwise be OK, a proper Windows VM with Freetype would be
nice especially as these VMs have Eliot's closure bytecodes in
them.. I'll build an image in the next few days. The code on
SqueakSource should be very close to the actual release code.

There's no Mac VM. It would be nice if someone built one. 

I may add full method inlining in the next release, or at least an
initial implementation. Inlining is a fairly simple feature except for
blocks and de-optimisation. The problem with blocks is they can be
accessed from external contexts so need to exist and can be returned
to which complicates inlining them. The problem with de-optimisation
is almost another blocks problem as de-optimisation needs to
be thought about a little more carefully when de-optimising a method
context may impact the execution of the block.

The solution is probably to create contexts for both blocks and
methods that create blocks. It'll make the inlined block situation a
little slower but will make it possible to de-optimise one context at
a time without risking crashes. Block contexts can always be removed
if they're inlined from creation to execution, i.e. for the entire
loop. The exact block inlining design doesn't need to be decided yet,
it can wait until after the simple case of inlining a method into
another method is implemented and debugged.

Starting on full method inlining is a departure from plan. 0.15 looks
solid enough to enable easy debugging of blocks. The original plan was
(Continue reading)

Permalink | Reply | 0 comments |
headers
bryce | 10 Nov 00:06
Picon
Picon

Debugging Exupery


I've just found one of the old bugs that's causing crashes every hour
or so. I'm not sure if it's the causes of all the crashes I can
reproduce with the current slow reproduction or just one of the
crashes. Here's a quick walk through debugging real crashes in
Exupery.

First try running the background compiler to see if it crashes:

      Exupery initialiseExupery.
      Exupery startBackgroundCompilation.

Now just use Squeak as normal until it crashes. It takes about
ten minutes on my machine for it to finish compiling itself.

Load the logs using "explore it":

     ExuperyLogReader new readFile: 'Exupery.log'.

Exupery is a dynamic compiler, it chooses what to compile
based on profiling, so it can be very hard to reproduce
bugs as there's some luck in what's compiled.

Then replay the logs to reproduce the code cache as it
was when it crashed. Execute the following in the explorer
on the logs:

     self compile

Then try to make the crash reproducible by running the
(Continue reading)

Permalink | Reply | 2 comments |

Gmane