On Sat, May 28, 2011 at 12:37 AM, Yoshiki Ohshima yoshiki@vpri.org wrote:
At Thu, 26 May 2011 16:45:38 -0300,
Martin Dias wrote:
On Thu, May 26, 2011 at 4:41 PM, Mariano Martinez Peck <
marianopeck@gmail.com> wrote:
On Thu, May 26, 2011 at 9:29 PM, Yoshiki Ohshima <yoshiki@vpri.org>
wrote:
BTW, the page (http://rmod.lille.inria.fr/web/pier/software/Fuel
)
says:
Gofer new
squeaksource: 'Fuel';
package: 'ConfigurationOfFuel';
load.
((Smalltalk at: #ConfigurationOfFuel) project =latestVersion)
load: #(Core Tests Benchmarks).
it does not appear to be a valid expression. What is the right
expression?
the =
Hi!
Sorry, now it is fixed.
Thanks! I tried it a bit and I'm officially impressed with its
performancce ^^;
I had a simple serializer/materializer that only handles class
definitions and compiled methods (and initialization of classes). But
Fuel seems faster than that for a factor of two or so for reading
methods.
Thanks Yoshiki. So you said Fuel was 2x faster at reading...did you check in
writing (serializing) ?
we would like to know the difference if possible.
Cheers
Mariano
(Mine was more on simplicity so it has only a few methods
and does some slow way to read sized-strings, as well as generous 4
byte padding. It does make difference when it comes to performance.)
-- Yoshiki
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
--
Mariano
http://marianopeck.wordpress.com
At Sat, 28 May 2011 09:33:27 +0200,
Stéphane Ducasse wrote:
Yoshiki
if you want to help testing, improving fuel you are welcome.
The idea is to make it fast fast fast without vm support.
Yeah. The reason for example I went to pad data to 4 bytes was that
there may be a clever trick I may be able to do to read data into
arrays "directly" and stuff, but did not get around implementing it.
Next time I can try things, I'll give more close attention to Fuel...
-- Yoshiki
At Sat, 28 May 2011 19:26:03 +0200,
Mariano Martinez Peck wrote:
Thanks Yoshiki. So you said Fuel was 2x faster at reading...did you check in writing (serializing) ?
we would like to know the difference if possible.
Well, the serializing part is definitely not tuned for performance.
It is even written in OMeta2! It does not support all bells and
whisles with new kinds of literals and stuff so I cannot really do a
meaningful comparison with Fuel. But if I compare the serializing
time and deserializing time of my thing, writing is about twice slower
than reading.
-- Yoshiki
On Sun, May 29, 2011 at 8:48 PM, Yoshiki Ohshima yoshiki@vpri.org wrote:
At Sat, 28 May 2011 19:26:03 +0200,
Mariano Martinez Peck wrote:
Thanks Yoshiki. So you said Fuel was 2x faster at reading...did you check
in writing (serializing) ?
we would like to know the difference if possible.
Well, the serializing part is definitely not tuned for performance.
It is even written in OMeta2! It does not support all bells and
whisles with new kinds of literals and stuff so I cannot really do a
meaningful comparison with Fuel.
I understand.
But if I compare the serializing
time and deserializing time of my thing, writing is about twice slower
than reading.
Yes, I think that is the normal and more or less the expected difference
right now.
--
Mariano
http://marianopeck.wordpress.com
On Sun, May 29, 2011 at 8:45 PM, Yoshiki Ohshima yoshiki@vpri.org wrote:
At Sat, 28 May 2011 09:33:27 +0200,
Stéphane Ducasse wrote:
Yoshiki
if you want to help testing, improving fuel you are welcome.
The idea is to make it fast fast fast without vm support.
Yeah. The reason for example I went to pad data to 4 bytes
What do you mean by padding data to 4 bytes? I don't understand :(
was that
there may be a clever trick I may be able to do to read data into
arrays "directly" and stuff,
what do you mean by that? like ImageSegment does? I mean, include also
object headers in the stream and then avoid to recreate objects (using
#basicNew) ?
but did not get around implementing it.
Next time I can try things, I'll give more close attention to Fuel...
thanks :)
-- Yoshiki
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
--
Mariano
http://marianopeck.wordpress.com
At Sun, 29 May 2011 20:51:07 +0200,
Mariano Martinez Peck wrote:
But if I compare the serializing
time and deserializing time of my thing, writing is about twice slower
than reading.
Yes, I think that is the normal and more or less the expected difference right now.
Yes, more or less. It, however, seems that if I don't use OMeta2,
it can be quite a lot faster.
-- Yoshiki
At Sun, 29 May 2011 20:52:45 +0200,
Mariano Martinez Peck wrote:
On Sun, May 29, 2011 at 8:45 PM, Yoshiki Ohshima yoshiki@vpri.org wrote:
At Sat, 28 May 2011 09:33:27 +0200,
Stéphane Ducasse wrote:
Yoshiki
if you want to help testing, improving fuel you are welcome.
The idea is to make it fast fast fast without vm support.
Yeah. The reason for example I went to pad data to 4 bytes
What do you mean by padding data to 4 bytes? I don't understand :(
Say a string has length of 5 ('abcde'), the data in file for it
would be "97 98 99 100 101 0 0 0".
was that
there may be a clever trick I may be able to do to read data into
arrays "directly" and stuff,
what do you mean by that? like ImageSegment does? I mean, include also object headers in the stream and then avoid to recreate objects (using #basicNew) ?
Not like ImageSegment, but more like #hackBits: reading from file
into a string object of right size. For pointer arrays and actual
literal fields, I am not sure I can apply this however.
I would not put object headers, as you would agree^^;
-- Yoshiki
On 05/29/2011 08:51 PM, Mariano Martinez Peck wrote:
But if I compare the serializing
time and deserializing time of my thing, writing is about twice slower
than reading.
Yes, I think that is the normal and more or less the expected difference
right now.
Do you want to make some comparisons with the GNU Smalltalk
ObjectDumper? I can help, or I can even make some comparisons myself if
you give me some test Fuel code and an image to test with.
Paolo
On Mon, May 30, 2011 at 8:27 AM, Paolo Bonzini bonzini@gnu.org wrote:
On 05/29/2011 08:51 PM, Mariano Martinez Peck wrote:
But if I compare the serializing
time and deserializing time of my thing, writing is about twice slower
than reading.
Yes, I think that is the normal and more or less the expected difference
right now.
Do you want to make some comparisons with the GNU Smalltalk ObjectDumper?
I can help, or I can even make some comparisons myself if you give me some
test Fuel code and an image to test with.
Hi Paolo. ObjectDumper was one of the serializers that we wanted to analyze
also to get ideas and compare. This is why once I tried to install GNU
Smalltalk in my machine but I couldn't so I give up.
The problem to compare ObjectDumper is that we need to be able to run both
in the same Dialect/VM. Otherwise the difference of the dialect or VM can
change the results a lot.
Sorry for the offtopic but is there an easy way to install GNU Smalltalk in
a Mac OS 10.6.7 ?
Thanks
--
Mariano
http://marianopeck.wordpress.com
On 05/30/2011 10:02 AM, Mariano Martinez Peck wrote:
The problem to compare ObjectDumper is that we need to be able to run
both in the same Dialect/VM. Otherwise the difference of the dialect
or VM can change the results a lot.
That's true.
Sorry for the offtopic but is there an easy way to install GNU
Smalltalk in a Mac OS 10.6.7 ?
With 3.2.4 and MacPorts it should be easy. You need to install the
libsigsegv port first. It may not work right away if your compiler
doesn't look in MacPorts paths. You can preempt the issue with an extra
option to the configure script:
./configure --with-system-libsigsegv=/opt/local/lib --prefix=/opt/local
make
sudo make install
(or /opt/local/lib64, I don't know :)).
ObjectDumper should be easy to port to Pharo. Something like
gst-convert -f gst -F squeak /opt/local/smalltalk/kernel/ObjDumper.st |
tr '\n' '\r' > objdumper.sq
should be a good start. Check out category "private - binary I/O",
that's where changes might be made. The resulting streams should be
portable between dialects, though I've never tried.
Testcases are old so they have not been converted to SUnit, but I'm sure
someone in the GNU Smalltalk community can help. :>
Lastly, it was written entirely by me, so I can relicense parts of it if
required. Contact me off-list if you are interested.
HTH,
Paolo