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
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: exupery-bounces@lists.squeakfoundation.org [mailto:exupery-bounces@lists.squeakfoundation.org] En nombre de bryce@kampjes.demon.co.uk Enviado el: Domingo, 29 de Abril de 2007 15:55 Para: exupery@lists.squeakfoundation.org 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 Exupery@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
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
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 :)
bryce@kampjes.demon.co.uk 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
Bryce, will Exupery be able to determine what *should* be compiled?
Also, what is the status on LargeInteger support?
Thanks.
On 5/2/07, bryce@kampjes.demon.co.uk bryce@kampjes.demon.co.uk wrote:
bryce@kampjes.demon.co.uk 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 Exupery@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
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
From: bryce@kampjes.demon.co.uk Reply-To: "Discussion about Exupery a native code compiler."exupery@lists.squeakfoundation.org To: ma.chris.m@gmail.com, "Discussion about Exupery a native code compiler."exupery@lists.squeakfoundation.org 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
J J writes:
From: bryce@kampjes.demon.co.uk 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@lists.squeakfoundation.org
-
bryce＠kampjes.demon.co.uk -
Chris Muller -
J J -
Sebastian Sastre