Pharo + Exupery VM + Something else than Accuny

Hi,

I'm playing with the Exupery VM on Pharo. If I change the font to
something else than Accuny, the underlined texts are not underlined
anymore. To reproduce:

- download and use http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-linux.tz
- go to preferences->fonts->list fonts
- select Bistream Charter/regular/10, and apply
- open monticello and open the Pharo repository

You will see that the installed packages are not underlined anymore.
Switch back to Accuny to see them underlined.

--
Damien Cassou
http://damiencassou.seasidehosting.st

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

And what about the speed improvment ?



2009/3/7 Damien Cassou <[hidden email]>:
> Hi,
>
> I'm playing with the Exupery VM on Pharo. If I change the font to

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Sat, Mar 7, 2009 at 11:57 AM, Hilaire Fernandes <[hidden email]> wrote:
> And what about the speed improvment ?

Should there be any? I haven't played enough with it. If you are
talking about the closures, I don't think I will see any improvement
until the blocks are converted and I haven't done that.

--
Damien Cassou
http://damiencassou.seasidehosting.st

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I am talking about performance, benchmark, etc.
Is it not Exupery about improving the speed of the VM?


2009/3/7 Damien Cassou <[hidden email]>:


--
http://blog.ofset.org/hilaire

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hilaire Fernandes writes:
 > I am talking about performance, benchmark, etc.
 > Is it not Exupery about improving the speed of the VM?

Exupery is, these VMs include the support Exupery needs but
the compiler is in the image. If you load and start Exupery
you may see some gains. I haven't yet tuned the background
compiler for practical use, it currently will compile every
method it sees which is great for debugging but not good
for providing a practical speed improvement. Compiled code
takes up more cache than bytecode so there can be a loss due
to compiling methods that are hardly ever used.

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
  largeExplorers 269 compiled 210 ratio: 1.280
  compilerBenchmark 273 compiled 250 ratio: 1.092
  Cumulative Time 413.408 compiled 232.706 ratio 1.777

With these VMs you could load Exupery from either SqueakMap
or Universes and start it. Documentation is here:

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

I may add full method inlining next rather than tune for practical
performance. Full method inlining will speed up common sends
extensively.

In summary, there may be a practical performance gain now or there
may not but Exupery is getting close to being seriously useful.

Bryce

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Bryce,

I'll play dumb here - actually, I'm not playing in this case :)
 
The little I know about Exupery comes from FAQs.  In the past at least, you cautioned against enabling dynamic compiling of methods, at least in production.  How does that square with full-inlining?  Are they different concepts, or have thing improved enough that you are now confident enough to throw the switch?  Full-inlining sounds like it could consume a lot of space.  Is that a concern, or does the selection of what it compiles keep it manageable?  How does it decide what to compile, and (more relevant to my dumb questions) how does that differ from the dynamic compilation?

Please don't feel attacked - I'm simply trying to understand what is hopefully just around the corner.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Saturday, March 07, 2009 6:55 AM
To: [hidden email]
Subject: {Spam?} Re: [Pharo-project] Pharo + Exupery VM + Something else than Accuny

Hilaire Fernandes writes:
 > I am talking about performance, benchmark, etc.
 > Is it not Exupery about improving the speed of the VM?

Exupery is, these VMs include the support Exupery needs but
the compiler is in the image. If you load and start Exupery
you may see some gains. I haven't yet tuned the background
compiler for practical use, it currently will compile every
method it sees which is great for debugging but not good
for providing a practical speed improvement. Compiled code
takes up more cache than bytecode so there can be a loss due
to compiling methods that are hardly ever used.

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
  largeExplorers 269 compiled 210 ratio: 1.280
  compilerBenchmark 273 compiled 250 ratio: 1.092
  Cumulative Time 413.408 compiled 232.706 ratio 1.777

With these VMs you could load Exupery from either SqueakMap
or Universes and start it. Documentation is here:

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

I may add full method inlining next rather than tune for practical
performance. Full method inlining will speed up common sends
extensively.

In summary, there may be a practical performance gain now or there
may not but Exupery is getting close to being seriously useful.

Bryce

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/3/7  <[hidden email]>:

> With these VMs you could load Exupery from either SqueakMap
> or Universes and start it. Documentation is here:

I installed exupery code in pharo 203, run the test, got 4 errors on
#testBlockBug3, #testBlockNonLocalReturnRecycledContext,
#testDelayWaitStreeTest, #testStressFailure1

Next I did three benchmarks on 3 different setups with DrGeo
MessageTally spyOn [Carre new].

Carre new instanciate a DrGeo canvas with Smalltalk programmed figure,
it results in a self-repeating sketch (see screenshot)

1. image with exupery runned with exupery VM
2. image without exupery runned with stock 3.9 VM
3. image without exupery runned with exupery VM

I used exupery image Damien pointed to in his email.

Do you want the images ?

Hilaire

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

And the fourth benchmark with compiled methods



2009/3/7 Hilaire Fernandes <[hidden email]>:

--
http://blog.ofset.org/hilaire

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Next I tried the Exupery profiler, but still the benchmark is not as
good as without the compiler.

Hilaire

2009/3/7 Hilaire Fernandes <[hidden email]>:


--
http://blog.ofset.org/hilaire

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hilaire Fernandes writes:
 > 2009/3/7  <[hidden email]>:
 >
 > > With these VMs you could load Exupery from either SqueakMap
 > > or Universes and start it. Documentation is here:
 >
 > I installed exupery code in pharo 203, run the test, got 4 errors on
 > #testBlockBug3, #testBlockNonLocalReturnRecycledContext,
 > #testDelayWaitStreeTest, #testStressFailure1
 >
 > Next I did three benchmarks on 3 different setups with DrGeo
 > MessageTally spyOn [Carre new].
 >
 > Carre new instanciate a DrGeo canvas with Smalltalk programmed figure,
 > it results in a self-repeating sketch (see screenshot)
 >
 > 1. image with exupery runned with exupery VM
 > 2. image without exupery runned with stock 3.9 VM
 > 3. image without exupery runned with exupery VM
 >
 > I used exupery image Damien pointed to in his email.
 >
 > Do you want the images ?

Thanks, I'd like to look at the images later but probably not
until after the next release. The decision to work on full
method inlining is a decision to not do much tuning until
after a critical optimisation is in place.

It is possible that running Exupery can slow down code. Normally this
is because it either didn't compile something it needed to for a given
benchmark. In your case it's suspicious that it's only compiled one of
the leaf methods. It's also possible that I need to optimise something
where Exupery is slower than the interpreter, I'm not aware of any
such cases but further profiling may find some.

Bryce

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Schwab,Wilhelm K writes:
 > Bryce,
 >
 > I'll play dumb here - actually, I'm not playing in this case :)
 >  
 > The little I know about Exupery comes from FAQs.  In the past at least, you cautioned against enabling dynamic compiling of methods, at least in production.  How does that square with full-inlining?  Are they different concepts, or have thing improved enough that you are now confident enough to throw the switch?  Full-inlining sounds like it could consume a lot of space.  Is that a concern, or does the selection of what it compiles keep it manageable?  How does it decide what to compile, and (more relevant to my dumb questions) how does that differ from the dynamic compilation?
 >
 > Please don't feel attacked - I'm simply trying to understand what is hopefully just around the corner.

What's changed is I've fixed a few bugs. It's possible that Exupery
is reliable. I've yet done enough testing to be sure but since the
last fix I haven't yet seen Exupery cause a crash. I'm confident
enough to throw the switch.

By full inlining all I mean is the ability to inline entire methods.
Exupery will already dynamically inline the primitives it compiles to
machine code. Dynamic inlining is the critical optimisation to allow
further optimisations, without it the compiler can only see a method
or a block at a time. It can't see where the loops are as they're
probably in a different method as with #do: loops. This really
limits the optimisations that can be performed later.

Full inlining will be driven by profiling so it's only the hot spots
that should get inlined, at least after I've tuned the
profiler. Inlining can sometimes reduce the amount of code
executed. For small methods it's easy to spend more code on the
message send than is consumed by the method body. Initially it's
likely the profiler will make bad inlining decisions like the current
profiler will compile every method seen eventually which is probably
bad for performance, compiling everything at least doesn't avoid
compiling infrequent methods that may trigger a compiler bug.

Full method inlining is a form of dynamic compilation. It lets the
dynamic compiler inline entire methods when it sees the need.

Bryce.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

It will be great.

Hilaire

2009/3/7  <[hidden email]>:


--
http://blog.ofset.org/hilaire

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project