On Sat, 17 Dec 2011, Mariano Martinez Peck wrote:
Can't you debug it ?
Of course I could do it when I have some time. It already took me 1 hour to isolate the bug from Fuel and make a reproducible test. I hope that at least you find that useful. I found the bug and I thought I could send my progress and see if someone could continue it. Otherwise, I was going to debug it as soon as I have some free time (which I don't have much this year).
It took 2 minutes to find this sentence at line 19 of LargeDictionary>>at:put:
But you are so smart and a Collection hacker. Me, I am newbie, and just the method at:put: scares me, but I understand if it has to be that way in order to be fast. And so far it seems to be fast, so I am happy with it.
(values at: hash) at: newIndex put: key
Can you replace key with value and retry the tests ?
Yes, that works. Thanks!
Now I noticed that SmallIntegers storing is really slow
This is not entirely true. Every hash table can be made slow if you know how it's hash function works. Since in your example all numbers are congruent to 1 modulo 4096 and the size of the array is also 4096, therefore they will be mapped to the same slot (1). Try using random (or at least more realistic) numbers in your test. If this is a real problem, then it may be necessary to implement a new hash method, which uses the primitive for general objects and does something else with SmallIntegers and that method shoul be used from these large collections. Levente
numbers := OrderedCollection new. numbers add: 1. numbers addAll: (1 to: 1 << 29 by: 1 << 14) asArray. numbers addAll: ((1 to: 1 << 29 by: 1 << 14) asArray collect: [:each | each negated] ).
dict := LargeIdentityDictionary new. [numbers do: [:each | dict at: each put: dict size + 1. ]. ] timeToRun -> 12657
whereas with IdentityDictionary it is 37. I guess it could be related to #identityHash or #basicIdentityHash. I tried in Squeak 4.3 and it is also also there. I will try to take a look into it during the next week.
Thanks in advance
Nicolas
Thanks for any idea.
On Sat, Dec 17, 2011 at 1:50 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 16, 2011, at 3:28 PM, Levente Uzonyi wrote:
Cool. One more thing: in Squeak the method using primitive 132
directly
was renamed to #instVarsInclude:, so now #pointsTo: works as expected. If this was also added to Pharo, then the #pointsTo: sends should be changed to #instVarsInclude:, otherwise Array can be reported as included even if it wasn't added. I'll upload my LargeIdentityDictionary implementation to the same place this evening, since it's still 2-3 factor faster than other solutionts and there seem to be demand for it.
Levente
"in Squeak the method using primitive 132 directly was renamed to #instVarsInclude:, so now #pointsTo: works as expected." I do not get the following. Indeed pointTo: looks like instVarsInclude: now I do not understand the rest of your paragraph.
Stef
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com