Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer
Yes if you do not use the same vm , the problem is that you will compare apple and orange.
Stef
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
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
On Sun, May 29, 2011 at 9:07 PM, Yoshiki Ohshima yoshiki@vpri.org wrote:
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".
Sorry but I don't understand then how that is related to "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."
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.
I am not sure if I understand. For some kind of objects (those that are
variable) we store first its size and then at materialization time we
directly create an object of that size using #basicNew:
but I guess you are talking about something else.
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
--
Mariano
http://marianopeck.wordpress.com
At Tue, 31 May 2011 23:16:12 +0200,
Mariano Martinez Peck wrote:
On Sun, May 29, 2011 at 9:07 PM, Yoshiki Ohshima yoshiki@vpri.org wrote:
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".
Sorry but I don't understand then how that is related to "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."
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.
I am not sure if I understand. For some kind of objects (those that are variable) we store first its size and then at materialization time we directly create an object
of that size using #basicNew:
but I guess you are talking about something else.
Hmm, I'm also confused. You know that ByteStrings are
padded in the image, right? And you see a user of #hackBits:,
#nextWordsInto:, right? We can eliminate some buffer copying there.
For example, when I run Fuel materializer, I see
PositionableStream>>nextString is used which does not do basicNew: of
(Byte)String but actually does extra copy (which can be easily
eliminated and would make it faster).
-- Yoshiki