On Thu, 9 Dec 2010, Stéphane Ducasse wrote:

It does!
It seems that you did not work in VW2.5 and 3.0 and when parcels arrived 
loading was realllllly a big difference
I do not see why this would not the same with Fuel.

No I didn't, but the version number of VW is around 7.x now, so I guess the CPUs and VMs are now several times faster. Does it really matter if it takes 200ms or 20ms to load a package?


Levente


Stef

The difference is that in Fuel there is no managment for "shared objects".
Fuel is not for swapping (there are no stubs/proxies and becomes), and the
idea is that you write on a file, ALL (not only those objects that are ONLY
accessible by the roots, like in ImageSegment) the objects reachable from
user defined roots.

Fuel is similar to ReferenceStream and subclasses, a XML serializer, or any
serializers, etc...but MOSTLY, to Parcels. It is very similar to VisualWorks
parcel.

Another important thing is that it is binary. The idea is that maybe in a
future we have a Monticello that doesn't need a mcz (code) + Compiler, but
instead, just load binary code (fuel files). This would be muuuch faster
that current Monticello, and even more, for minimal images, we wouldn't need
a Compiler.
Finally, Fuel is designed (like Parcels) to be very fast at loading time :)

Well, I doubt if speed is really important, since you're loading everything at 
most once. And the current tools are really fast IMHO. The following numbers 
are from Squeak:
[ Compiler recompileAll ] timeToRun. 29083.
CompiledMethod allInstances size. 60701.
[ CompiledMethod allInstancesDo: [ :each | each getSource ] ] timeToRun. 1133.
So the compiler is compiling 2087 methods per second on average. You can load 
53575 methods per second from a file on average. If it's zipped, than it may be 
a bit slower, say a factor of 2-3x slowdown. So you can still load and compile 
more than 1800 methods per second. I guess thats fast enough.

Even if Fuel can be 10x faster, it doesn't really make a difference IMHO.


Levente


Cheers

Mariano




It looks exciting!

Alexandre




Alexandre


On 8 Dec 2010, at 13:50, Martin Dias wrote:

Hi all

Last months I and Tristan have been working on Fuel project, an object
binary serialization tool. The idea is that objects are much more
times loaded than stored, therefore it is worth to spend time while
storing in order to have faster loading and user experience. We
present an implementation of a pickle format that is based on
clustering similar objects.

There is a summary of the project below, but more complete information
is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel

The implementation still needs a lot of work to be really useful,
optimizations should be done, but we'll be glad to get feedback of the
community.


= Pickle format =

The pickle format and the serialization algorithm main idea, is
explained in this slides:

http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example


= Current features =

- Class shape changing (when a variable has been added, or removed, or
its index changed)
- Serialize most of the basic objects.
- Serialize (almost) any CompiledMethod
- Detection of global or class variables
- Support for cyclic object graphs
- Tests


= Next steps =

- Improve version checking.
- Optimize performance.
- Serialize more kinds of objects:
-- Class with its complete description.
-- Method contexts
-- Active block closures
-- Continuation
- Some improvements for the user:
-- pre and post actions to be executed.
-- easily say 'this object is singleton'.
- Partial loading of a stored graph.
- Fast statistics/brief info extraction of a stored graph.
- ConfigurationOfFuel.
- Be able to deploy materialization behavior only (independent from
the serialization behavior)


= Download =

In a Pharo 1.1 or 1.1.1 evaluate:

Gofer new
   squeaksource: 'Fuel';
   version: 'Fuel-MartinDias.74';
   version: 'FuelBenchmarks-MartinDias.4';
   load.


= Benchmarks =

You can run benchmarks executing this line (results in Transcript):

FLBenchmarks newBasic run.


Thank you!
Martin Dias


--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.









--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.











Reply via email to