Progress towards Exupery 0.12

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Progress towards Exupery 0.12

Bryce Kampjes

All that's required is a little more debugging. This release can
compile in the background. The stress test runs again but when Exupery
starts compiling itself using the background compiler after a few
minutes it stops due to a bug. I'd like to be able to run the
background compiler for at least an hour before releasing.

Exupery is probably more reliable now than it's been before. The other
part of this release has been fixing some old stack tracing bugs. That
introduced block finder bugs which have been fixed along with some old
block finder bugs. By the standards of previous releases, it would be
releasable now.

I'm thinking about freeing up the "unused" slot in MethodContext so
that Exupery can be loaded in an image running the closure compiler
without causing crashes. More work would be required to compile
closure compiler code.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

RE: Progress towards Exupery 0.12

Sebastian Sastre-2
Good job Bryce. I know that it's just too soon to say but do you have any
glimpse of the stability of an image running wit exupery? There is any
version that could be stable enough to try it in production or it is too
soon?

Regards,

Sebstian
 

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de [hidden email]
> Enviado el: Domingo, 29 de Abril de 2007 15:55
> Para: [hidden email]
> Asunto: Progress towards Exupery 0.12
>
>
> All that's required is a little more debugging. This release
> can compile in the background. The stress test runs again but
> when Exupery starts compiling itself using the background
> compiler after a few minutes it stops due to a bug. I'd like
> to be able to run the background compiler for at least an
> hour before releasing.
>
> Exupery is probably more reliable now than it's been before.
> The other part of this release has been fixing some old stack
> tracing bugs. That introduced block finder bugs which have
> been fixed along with some old block finder bugs. By the
> standards of previous releases, it would be releasable now.
>
> I'm thinking about freeing up the "unused" slot in
> MethodContext so that Exupery can be loaded in an image
> running the closure compiler without causing crashes. More
> work would be required to compile closure compiler code.
>
> Bryce
> _______________________________________________
> Exupery mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

RE: Progress towards Exupery 0.12

Bryce Kampjes
Sebastian Sastre writes:
 > Good job Bryce. I know that it's just too soon to say but do you have any
 > glimpse of the stability of an image running wit exupery? There is any
 > version that could be stable enough to try it in production or it is too
 > soon?

Ask me closer to to the release.

At the moment it can only compile in the background for a few minutes
then it runs into trouble. Just DNU's that can be fixed by
initializing Exupery.

Are you interested in running it in production soon? I've not yet
decided how quickly to push for stability vs. other things. Closer
to the release it'll be easier to decide but interest does matter
too.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

RE: Progress towards Exupery 0.12

Sebastian Sastre-2
> Are you interested in running it in production soon? I've not
> yet decided how quickly to push for stability vs. other
> things. Closer to the release it'll be easier to decide but
> interest does matter too.
>
> Bryce
> _______________________________________________

Bryce,

I would only put to produce if it proves to has at least the same stability
of a normal squeak image. But I can also get enough courage to experiment it
in a linux test-production to see how it goes.
 
As with many other innovative things one has to "dance at the music's rithm"
between real innovation and real value (to make them sustainable). Think
about when will be appropiate to take Exupery out of the simulator and give
him some real hours of flight ;)

When you have news about stabilizing a version I'll be the first interested.

Thank you,

Sebastian
PD: is not pressure it's interest. Well.. maybe there is a little push also
:)

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

RE: Progress towards Exupery 0.12

Bryce Kampjes
In reply to this post by Bryce Kampjes
[hidden email] writes:
 > Sebastian Sastre writes:
 >  > Good job Bryce. I know that it's just too soon to say but do you have any
 >  > glimpse of the stability of an image running wit exupery? There is any
 >  > version that could be stable enough to try it in production or it is too
 >  > soon?
 >
 > Ask me closer to to the release.
 >
 > At the moment it can only compile in the background for a few minutes
 > then it runs into trouble. Just DNU's that can be fixed by
 > initializing Exupery.
 >
 > Are you interested in running it in production soon? I've not yet
 > decided how quickly to push for stability vs. other things. Closer
 > to the release it'll be easier to decide but interest does matter
 > too.

My goal for the next release is only to be able to run the background
compiler for an hour without crashing. I don't know how reliable that
will be in a production environment.

But it depends on what the constraints of the production environment
are. You can always restrict what Exupery will compile rather than
letting it compile everything. By restricting what it will be able
to compile you could use it now.

Compilation can be slow. There's a few performance bugs in the
register allocator that I mean to fix after the release. Compilation
can always be done in a low priority background thread so that might
not matter.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: Progress towards Exupery 0.12

Chris Muller-3
Bryce, will Exupery be able to determine what *should* be compiled?

Also, what is the status on LargeInteger support?

Thanks.

On 5/2/07, [hidden email] <[hidden email]> wrote:

> [hidden email] writes:
>  > Sebastian Sastre writes:
>  >  > Good job Bryce. I know that it's just too soon to say but do you have any
>  >  > glimpse of the stability of an image running wit exupery? There is any
>  >  > version that could be stable enough to try it in production or it is too
>  >  > soon?
>  >
>  > Ask me closer to to the release.
>  >
>  > At the moment it can only compile in the background for a few minutes
>  > then it runs into trouble. Just DNU's that can be fixed by
>  > initializing Exupery.
>  >
>  > Are you interested in running it in production soon? I've not yet
>  > decided how quickly to push for stability vs. other things. Closer
>  > to the release it'll be easier to decide but interest does matter
>  > too.
>
> My goal for the next release is only to be able to run the background
> compiler for an hour without crashing. I don't know how reliable that
> will be in a production environment.
>
> But it depends on what the constraints of the production environment
> are. You can always restrict what Exupery will compile rather than
> letting it compile everything. By restricting what it will be able
> to compile you could use it now.
>
> Compilation can be slow. There's a few performance bugs in the
> register allocator that I mean to fix after the release. Compilation
> can always be done in a low priority background thread so that might
> not matter.
>
> Bryce
> _______________________________________________
> Exupery mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
>
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: Progress towards Exupery 0.12

Bryce Kampjes
Chris Muller writes:
 > Bryce, will Exupery be able to determine what *should* be compiled?
 
That works now, just enable the background compiler. It's one of
the reasons that I'm debugging. Background compilation requires
reliability as you don't know what will be compiled when.

 > Also, what is the status on LargeInteger support?
 >

I haven't yet done anything for large integers.

The two experimental things I'm thinking about are closure compiler
support and enabling dynamic inlining of arithmetic primitives.

Enabling dynamic inlining of arithmetic primitives would be important
for large integer work. The problem with arithmetic primitives is
they're already manually inlined. The SmallInteger inlining needs to
be moved to use a generic primitive inlining mechanism. This is
especially true if the code mixes arithmetic types which is possible
if you're using large integers.

I plan on playing around with Magma/Seaside with Exupery running
in the background after this release is done.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: Progress towards Exupery 0.12

J J-6
>From: <[hidden email]>
>Reply-To: "Discussion about Exupery a native code
>compiler."<[hidden email]>
>To: [hidden email], "Discussion about Exupery a native code
>compiler."<[hidden email]>
>Subject: Re: Progress towards Exupery 0.12
>Date: Thu, 3 May 2007 20:58:21 +0100
>
>The problem with arithmetic primitives is
>they're already manually inlined. The SmallInteger inlining needs to
>be moved to use a generic primitive inlining mechanism.

Won't the Exupery image disable all Squeak inlining (at least in later
versions)?  I would expect it too, since the profiling code will cause
Exupery to quickly inline anything Squeak would inline itself anyway, no?

_________________________________________________________________
Watch free concerts with Pink, Rod Stewart, Oasis and more.  Visit MSN In
Concert today. http://music.msn.com/presents?icid=ncmsnpresentstagline

_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Reply | Threaded
Open this post in threaded view
|

Re: Progress towards Exupery 0.12

Bryce Kampjes
J J writes:
 > >From: <[hidden email]>
 > >The problem with arithmetic primitives is
 > >they're already manually inlined. The SmallInteger inlining needs to
 > >be moved to use a generic primitive inlining mechanism.
 >
 > Won't the Exupery image disable all Squeak inlining (at least in later
 > versions)?  I would expect it too, since the profiling code will cause
 > Exupery to quickly inline anything Squeak would inline itself anyway, no?

Exupery will not disable Squeak's current inlining. Exupery works
from bytecodes, Squeak inlines when generating bytecodes. Exupery
needs passable interpreted performance to compile the first few
methods. Exupery's story tests clear out Exuperys code cache before
each test to ensure that the test is only testing the intended
compiled code.

That said, I'd expect that with Exupery, many of the inlinings done
now would be removed just not ifTrue: and whileTrue: and friends.
And I'm sure some people will want to remove ifTrue: and whileTrue:
from their images to allow for easier experimentation.

Having decent interpreted performance is nice even with dynamic
inlining. It'll take dynamic inlining some time to figure out what
should be inlined and there are a handful of places where Exupery can
not be used. Even with dynamic inlining interpreted performance will
matter for the first few minutes or on machines without an Exupery
port.

Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery