Smalltalk › Squeak › Squeak - Dev

[squeak-dev] About Collections-ul.137..140

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Levente Uzonyi-2

[squeak-dev] About Collections-ul.137..140

Hi!

Just uploaded four packages to inbox: Collections-ul.137,
Collections-ul.138, Collections-ul.139 and Collections-ul.140. These
packages reimplement #rehash and #grow in Set and its subclasses (except
MethodDictionary). The ideas come are from Ralph Boland's FasterSets
project, but the implementation is different. According to my measurements
they are even faster. The four packages should be loaded in the given
order one-by-one otherwise mc might remove old methods before adding new
ones, etc (couldn't come up with a better mc based load mechanism).

While I was rewriting these methods, I found that KeyedSet and
KeyedIdentitySet are not used (no references, no senders) in the trunk.
Also checked that in a 3.8.1 full image they have no references (just
senders in DecompilerTests >> #decompilerDiscrepancies). I think they
might be removed from the base image and moved to a separate package.

Cheers,
Levente

Ralph Boland

Re: [squeak-dev] About Collections-ul.137..140

2009/9/21 Damien Cassou <[hidden email]>:

> ---------- Forwarded message ----------
> From: Levente Uzonyi <[hidden email]>
> Date: Sun, Sep 20, 2009 at 4:38 PM
> Subject: [squeak-dev] About Collections-ul.137..140
> To: [hidden email]
>
>
> Hi!
>
> Just uploaded four packages to inbox: Collections-ul.137,
> Collections-ul.138, Collections-ul.139 and Collections-ul.140. These
> packages reimplement #rehash and #grow in Set and its subclasses
> (except MethodDictionary). The ideas come are from Ralph Boland's
> FasterSets project, but the implementation is different. According to
> my measurements they are even faster. The four packages should be
> loaded in the given order one-by-one otherwise mc might remove old
> methods before adding new ones, etc (couldn't come up with a better mc
> based load mechanism).
>
> While I was rewriting these methods, I found that KeyedSet and
> KeyedIdentitySet are not used (no references, no senders) in the
> trunk.
> Also checked that in a 3.8.1 full image they have no references (just
> senders in DecompilerTests >> #decompilerDiscrepancies). I think they
> might be removed from the base image and moved to a separate package.
>
> Cheers,
> Levente
>
>
>
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Lambdas are relegated to relative obscurity until Java makes them
> popular by not having them." James Iry
>

It sounds like you are using an older version of fasterSets. The
original version did not make the
modifications for Method dictionary but the new version does. I also
made a number of other improvements.
I suggest you test your version to the version currently in fasterSets
to see which one is actually faster.
Note that fasterSets has code for measuring performance at least in
terms of the number of compares.
Perhaps you can make the comparision and post the results. I would
like to see them.
I suggest that you study the current version of fasterSets and your
version and combine the best
features of both.

If you wanted to make improvements I don't know why you didn't start
from the newer version.
I believe it was Damien Cassou who proposed that I make most of them.
I also asked that any modifications be incorporated into fasterSets
but I assume you have not done this.

Regards,

Ralph Boland

Andreas.Raab

[squeak-dev] Re: About Collections-ul.137..140

Can you please post the benchmarks that you are using to determine what
"faster" sets mean?

Thanks,
- Andreas

Ralph Boland wrote:

> 2009/9/21 Damien Cassou <[hidden email]>:
>> ---------- Forwarded message ----------
>> From: Levente Uzonyi <[hidden email]>
>> Date: Sun, Sep 20, 2009 at 4:38 PM
>> Subject: [squeak-dev] About Collections-ul.137..140
>> To: [hidden email]
>>
>>
>> Hi!
>>
>> Just uploaded four packages to inbox: Collections-ul.137,
>> Collections-ul.138, Collections-ul.139 and Collections-ul.140. These
>> packages reimplement #rehash and #grow in Set and its subclasses
>> (except MethodDictionary). The ideas come are from Ralph Boland's
>> FasterSets project, but the implementation is different. According to
>> my measurements they are even faster. The four packages should be
>> loaded in the given order one-by-one otherwise mc might remove old
>> methods before adding new ones, etc (couldn't come up with a better mc
>> based load mechanism).
>>
>> While I was rewriting these methods, I found that KeyedSet and
>> KeyedIdentitySet are not used (no references, no senders) in the
>> trunk.
>> Also checked that in a 3.8.1 full image they have no references (just
>> senders in DecompilerTests >> #decompilerDiscrepancies). I think they
>> might be removed from the base image and moved to a separate package.
>>
>> Cheers,
>> Levente
>>
>>
>>
>>
>> --
>> Damien Cassou
>> http://damiencassou.seasidehosting.st
>>
>> "Lambdas are relegated to relative obscurity until Java makes them
>> popular by not having them." James Iry
>>
>
>
> It sounds like you are using an older version of fasterSets. The
> original version did not make the
> modifications for Method dictionary but the new version does. I also
> made a number of other improvements.
> I suggest you test your version to the version currently in fasterSets
> to see which one is actually faster.
> Note that fasterSets has code for measuring performance at least in
> terms of the number of compares.
> Perhaps you can make the comparision and post the results. I would
> like to see them.
> I suggest that you study the current version of fasterSets and your
> version and combine the best
> features of both.
>
> If you wanted to make improvements I don't know why you didn't start
> from the newer version.
> I believe it was Damien Cassou who proposed that I make most of them.
> I also asked that any modifications be incorporated into fasterSets
> but I assume you have not done this.
>
>
> Regards,
>
> Ralph Boland
>
>

Ralph Boland

Re: [squeak-dev] About Collections-ul.137..140

In reply to this post by Ralph Boland

Further comments on fasterSets.
My understanding is that the newer version of fasterSets is
scheduled to be incorporated into Pharo1.1.
It would be unfortunate if one version of fasterSets is incorporated
into Squeak and a different version is incorporated into Pharo.
Can we get together and decide on one or better still merge the
best features of both.
I am frustrated by this split so cannot be considered unbiased.
Can someone qualified and unbiased be appointed to coordinate
creating a version of fasterSets that both the Squeak people and
Pharo people are happy with and contains the best features of both.
I am willing to work on the problem.

P.S. My understanding was that there was no interest in having fasterSets
added to Squeak. If/when this changed I would have appreciated being
brought into the loop.

Regards,

Ralph Boland

2009/9/21 Ralph Boland <[hidden email]>:

Levente Uzonyi-2

Re: [squeak-dev] Re: About Collections-ul.137..140

In reply to this post by Andreas.Raab

Hi!

On Mon, 21 Sep 2009, Andreas Raab wrote:

> Can you please post the benchmarks that you are using to determine what
> "faster" sets mean?
>
> Thanks,
> - Andreas
>

Faster means that #grow and #rehash are faster. And because #grow is
faster #add: is slightly faster too.
Here is a quick benchmark:

[
| array1 array2 |
array1 := (1 to: 100000) asArray.
array2 := array1 shuffledBy: (Random seed: 12345).
{ array1. array2 } collect: [ :array |
(1 to: 5) collect: [ :each |
Smalltalk garbageCollect.
[
| s |
s := Set new.
{
[ s addAll: array ] timeToRun.
[ s rehash ] timeToRun } ] value ]
] ] value

And the results (on my notebook):
"trunk (Collections-nice.135)"
#(
#(
#(208 101)
#(217 107)
#(206 91)
#(205 102)
#(206 102))
#(
#(2926 104)
#(2918 101)
#(2926 92)
#(2926 100)
#(2923 103)))
"trunk + FastSetsFileInFirst-rpb.8 FastSets-rpb.9 from squeaksource"
#(
#(
#(154 38)
#(158 37)
#(157 47)
#(150 37)
#(157 47))
#(
#(2848 38)
#(2836 38)
#(2849 37)
#(2849 38)
#(2838 38)))
"trunk + Collections-ul.137..140"
#(
#(
#(143 31)
#(146 31)
#(148 33)
#(151 31)
#(143 31))
#(
#(2826 31)
#(2806 42)
#(2823 31)
#(2843 31)
#(2834 31)))

Cheers,
Levente

Levente Uzonyi-2

Re: [squeak-dev] About Collections-ul.137..140

In reply to this post by Ralph Boland

Hi!

On Mon, 21 Sep 2009, Ralph Boland wrote:

> It sounds like you are using an older version of fasterSets. The
> original version did not make the
> modifications for Method dictionary but the new version does. I also
> made a number of other improvements.
> I suggest you test your version to the version currently in fasterSets
> to see which one is actually faster.
> Note that fasterSets has code for measuring performance at least in
> terms of the number of compares.
> Perhaps you can make the comparision and post the results. I would
> like to see them.
> I suggest that you study the current version of fasterSets and your
> version and combine the best
> features of both.
>
> If you wanted to make improvements I don't know why you didn't start
> from the newer version.
> I believe it was Damien Cassou who proposed that I make most of them.
> I also asked that any modifications be incorporated into fasterSets
> but I assume you have not done this.
>

I didn't use any code from the squeaksource repository, just the idea, and
implemented it differently (IMO better).

Cheers,
Levente

Andreas.Raab

Re: [squeak-dev] About Collections-ul.137..140

In reply to this post by Ralph Boland

Hi Ralph -

I'm not sure that being biased is a problem in this context as long as
the bias is a result of observable behavior (i.e., benchmarks). There is
a lot of stuff that has remained under the radar in the past and I think
these improvements are part of it, and indeed very welcome (in fact, I
don't think there was ever any resistance it was merely that we didn't
have good means to deal with the integration).

If you and Levente could provide a joint proposal, that would be very
welcome. I will say that I am inclined to go with Levente's version, not
because I think it's better or faster (I simply haven't run the
benchmarks) but because I was able to load them and run the tests and
they were green. I am not sure what I would need to load from the
squeaksource project and in which order to do the same level of evaluation.

However, let me repeat that I do recommend you discuss a merged version
with Levente so that we can have the best of both worlds.

Cheers,
- Andreas

Ralph Boland wrote:

> Further comments on fasterSets.
> My understanding is that the newer version of fasterSets is
> scheduled to be incorporated into Pharo1.1.
> It would be unfortunate if one version of fasterSets is incorporated
> into Squeak and a different version is incorporated into Pharo.
> Can we get together and decide on one or better still merge the
> best features of both.
> I am frustrated by this split so cannot be considered unbiased.
> Can someone qualified and unbiased be appointed to coordinate
> creating a version of fasterSets that both the Squeak people and
> Pharo people are happy with and contains the best features of both.
> I am willing to work on the problem.
>
> P.S. My understanding was that there was no interest in having fasterSets
> added to Squeak. If/when this changed I would have appreciated being
> brought into the loop.
>
> Regards,
>
> Ralph Boland
>
>
> 2009/9/21 Ralph Boland <[hidden email]>:
>> 2009/9/21 Damien Cassou <[hidden email]>:
>>> ---------- Forwarded message ----------
>>> From: Levente Uzonyi <[hidden email]>
>>> Date: Sun, Sep 20, 2009 at 4:38 PM
>>> Subject: [squeak-dev] About Collections-ul.137..140
>>> To: [hidden email]
>>>
>>>
>>> Hi!
>>>
>>> Just uploaded four packages to inbox: Collections-ul.137,
>>> Collections-ul.138, Collections-ul.139 and Collections-ul.140. These
>>> packages reimplement #rehash and #grow in Set and its subclasses
>>> (except MethodDictionary). The ideas come are from Ralph Boland's
>>> FasterSets project, but the implementation is different. According to
>>> my measurements they are even faster. The four packages should be
>>> loaded in the given order one-by-one otherwise mc might remove old
>>> methods before adding new ones, etc (couldn't come up with a better mc
>>> based load mechanism).
>>>
>>> While I was rewriting these methods, I found that KeyedSet and
>>> KeyedIdentitySet are not used (no references, no senders) in the
>>> trunk.
>>> Also checked that in a 3.8.1 full image they have no references (just
>>> senders in DecompilerTests >> #decompilerDiscrepancies). I think they
>>> might be removed from the base image and moved to a separate package.
>>>
>>> Cheers,
>>> Levente
>>>
>>>
>>>
>>>
>>> --
>>> Damien Cassou
>>> http://damiencassou.seasidehosting.st
>>>
>>> "Lambdas are relegated to relative obscurity until Java makes them
>>> popular by not having them." James Iry
>>>
>>
>> It sounds like you are using an older version of fasterSets. The
>> original version did not make the
>> modifications for Method dictionary but the new version does. I also
>> made a number of other improvements.
>> I suggest you test your version to the version currently in fasterSets
>> to see which one is actually faster.
>> Note that fasterSets has code for measuring performance at least in
>> terms of the number of compares.
>> Perhaps you can make the comparision and post the results. I would
>> like to see them.
>> I suggest that you study the current version of fasterSets and your
>> version and combine the best
>> features of both.
>>
>> If you wanted to make improvements I don't know why you didn't start
>> from the newer version.
>> I believe it was Damien Cassou who proposed that I make most of them.
>> I also asked that any modifications be incorporated into fasterSets
>> but I assume you have not done this.
>>
>>
>> Regards,
>>
>> Ralph Boland
>>