#becomeUncompact not longer works in Cog/Stack VMs
Locked
12
12
#becomeUncompact not longer works in Cog/Stack VMs
 
|
Hi, i tried to do a simple: Smalltalk compactClassesArray do: [:each | each ifNotNil: [each becomeUncompact]] and it crashing the image. I tried to do this for individual classes. CompiledMethod, ByteString, BlockClosure, BlockContext , seems working ok. MethodContext, LargePositiveInteger, LargeNegativeInteger, Float crashes the image. i also tried following: [Smalltalk compactClassesArray do: [:each | each ifNotNil: [each becomeUncompact]] ] forkAt: Processor highestPriority but it didn't helped much. Also, i saved image after couple successfull #becomeUncompact steps.. and now VM cannot open image, most probably because it fails on 'assumptions check' defined in #checkAssumedCompactClasses -- Best regards, Igor Stasenko AKA sig. |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
and your point would be? On Fri, May 6, 2011 at 9:38 AM, Igor Stasenko <[hidden email]> wrote:
|
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
On 6 May 2011 20:04, Eliot Miranda <[hidden email]> wrote: > > and your point would be? > it needs to be fixed. Because if we can't do: Smalltalk compactClassesArray do: [:each | each ifNotNil: [each becomeUncompact]]. then we cant: VM getRidOfCompactClassesNotion :) > On Fri, May 6, 2011 at 9:38 AM, Igor Stasenko <[hidden email]> wrote: >> >> Hi, i tried to do a simple: >> >> Smalltalk compactClassesArray do: [:each | each ifNotNil: [each >> becomeUncompact]] >> >> and it crashing the image. >> I tried to do this for individual classes. >> >> >> CompiledMethod, ByteString, BlockClosure, BlockContext , >> seems working ok. >> >> MethodContext, LargePositiveInteger, LargeNegativeInteger, Float >> crashes the image. >> >> i also tried following: >> >> [Smalltalk compactClassesArray do: [:each | each ifNotNil: [each >> becomeUncompact]] >> ] forkAt: Processor highestPriority >> >> but it didn't helped much. >> >> Also, i saved image after couple successfull #becomeUncompact steps.. >> and now VM cannot open image, most probably >> because it fails on 'assumptions check' defined in #checkAssumedCompactClasses >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > > -- Best regards, Igor Stasenko AKA sig. |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
On Fri, May 6, 2011 at 12:47 PM, Igor Stasenko <[hidden email]> wrote: it needs to be fixed. No. It does /not/ need to be fixed. As I said earlier it is *absurd* to throw away performance for the ability to change certain classes to become uncompact.
That will be done by producing a new GC and a new image format, not by tinkering with compact classes in the current GC. Right?
|
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
On 6 May 2011 21:51, Eliot Miranda <[hidden email]> wrote: > > > > On Fri, May 6, 2011 at 12:47 PM, Igor Stasenko <[hidden email]> wrote: >> >> On 6 May 2011 20:04, Eliot Miranda <[hidden email]> wrote: >> > >> > and your point would be? >> > >> it needs to be fixed. > > No. It does /not/ need to be fixed. As I said earlier it is *absurd* to throw away performance for the ability to change certain classes to become uncompact. No. its nothing to do with performance. It is about getting rid of them as a concept. >> >> Because if we can't do: >> >> Smalltalk compactClassesArray do: [:each | each ifNotNil: [each >> becomeUncompact]]. >> >> then we cant: >> >> VM getRidOfCompactClassesNotion >> >> :) > > > That will be done by producing a new GC and a new image format, not by tinkering with compact classes in the current GC. Right? > yes.. but small steps at a time. Дорогу одолеет идущий. (its hard to me to translate this but if translate it literally, it means): 'road' 'overcome' 'walking one' >> >> > On Fri, May 6, 2011 at 9:38 AM, Igor Stasenko <[hidden email]> wrote: >> >> >> >> Hi, i tried to do a simple: >> >> >> >> Smalltalk compactClassesArray do: [:each | each ifNotNil: [each >> >> becomeUncompact]] >> >> >> >> and it crashing the image. >> >> I tried to do this for individual classes. >> >> >> >> >> >> CompiledMethod, ByteString, BlockClosure, BlockContext , >> >> seems working ok. >> >> >> >> MethodContext, LargePositiveInteger, LargeNegativeInteger, Float >> >> crashes the image. >> >> >> >> i also tried following: >> >> >> >> [Smalltalk compactClassesArray do: [:each | each ifNotNil: [each >> >> becomeUncompact]] >> >> ] forkAt: Processor highestPriority >> >> >> >> but it didn't helped much. >> >> >> >> Also, i saved image after couple successfull #becomeUncompact steps.. >> >> and now VM cannot open image, most probably >> >> because it fails on 'assumptions check' defined in #checkAssumedCompactClasses >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko AKA sig. >> > >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > > -- Best regards, Igor Stasenko AKA sig. |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
On Fri, May 6, 2011 at 5:18 PM, Igor Stasenko <[hidden email]> wrote: > No. its nothing to do with performance. It is about getting rid of > them as a concept. Well, if fixing it makes Cog slower, then it *is* about performance. Just making everything uncompact without changing the image format doesn't really buy us much: it would make Cog slower and the image bigger with no benefit. The benefit comes from having a new image format that is optimized for speed rather than space - getting rid of compact classes would just be a side-effect of the new format. Colin |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Igor Stasenko
On Sat, 7 May 2011, Igor Stasenko wrote: > > On 6 May 2011 21:51, Eliot Miranda <[hidden email]> wrote: >> >> >> >> On Fri, May 6, 2011 at 12:47 PM, Igor Stasenko <[hidden email]> wrote: >>> >>> On 6 May 2011 20:04, Eliot Miranda <[hidden email]> wrote: >>>> >>>> and your point would be? >>>> >>> it needs to be fixed. >> >> No. It does /not/ need to be fixed. As I said earlier it is *absurd* to throw away performance for the ability to change certain classes to become uncompact. > > No. its nothing to do with performance. It is about getting rid of > them as a concept. rid of compact classes? > >>> >>> Because if we can't do: >>> >>> Smalltalk compactClassesArray do: [:each | each ifNotNil: [each >>> becomeUncompact]]. >>> >>> then we cant: >>> >>> VM getRidOfCompactClassesNotion >>> >>> :) >> >> >> That will be done by producing a new GC and a new image format, not by tinkering with compact classes in the current GC. Right? >> > > yes.. but small steps at a time. because once you change your image to not use the compact object representation, you won't be able to use it with current VMs. This kind of change should be avoided or it must bring real benefits that outweight the cost of incompatibility. At the moment I don't see the benefits other than five new free bits in the object header and a bit simpler code for the VM which is not enough IMHO. On the other hand larger objects will probably result in a slower VM (less objects can be cached, more objects will have to be moved around in the memory hierarchy). Levente > > ˙˙˙˙˙˙˙˙˙˙˙˙ ˙˙˙˙˙˙˙˙˙˙˙˙˙˙ ˙˙˙˙˙˙˙˙˙˙˙˙. > > (its hard to me to translate this but if translate it literally, it means): > 'road' 'overcome' 'walking one' > >>> >>>> On Fri, May 6, 2011 at 9:38 AM, Igor Stasenko <[hidden email]> wrote: >>>>> >>>>> Hi, i tried to do a simple: >>>>> >>>>> Smalltalk compactClassesArray do: [:each | each ifNotNil: [each >>>>> becomeUncompact]] >>>>> >>>>> and it crashing the image. >>>>> I tried to do this for individual classes. >>>>> >>>>> >>>>> CompiledMethod, ByteString, BlockClosure, BlockContext , >>>>> seems working ok. >>>>> >>>>> MethodContext, LargePositiveInteger, LargeNegativeInteger, Float >>>>> crashes the image. >>>>> >>>>> i also tried following: >>>>> >>>>> [Smalltalk compactClassesArray do: [:each | each ifNotNil: [each >>>>> becomeUncompact]] >>>>> ] forkAt: Processor highestPriority >>>>> >>>>> but it didn't helped much. >>>>> >>>>> Also, i saved image after couple successfull #becomeUncompact steps.. >>>>> and now VM cannot open image, most probably >>>>> because it fails on 'assumptions check' defined in #checkAssumedCompactClasses >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Eliot Miranda-2
Am 2011-05-06 um 21:51 schrieb Eliot Miranda: > > > On Fri, May 6, 2011 at 12:47 PM, Igor Stasenko <[hidden email]> wrote: > > On 6 May 2011 20:04, Eliot Miranda <[hidden email]> wrote: > > > > and your point would be? > > > it needs to be fixed. > > No. It does /not/ need to be fixed. As I said earlier it is *absurd* to throw away performance for the ability to change certain classes to become uncompact. > When it worked in pre-cog VMs, why should it break in Cog? Just my 2ct So Long, -Tobias |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Eliot Miranda-2
Eliot may be this is because of bad communication medium but each time somebody is mentioning something not really working your main messages over the months is do not fix it. I do not think that this is really the way to build a community around Cog. At least to me the messages is that you are not really interested in that. I can understand that you are busy but there is nothing like little issues: because little issues make hard stupid people to move and since stupid people are the masses then this means that nothing move. This is ok too. but I wanted to let you know the message we receive. I should say that I'm really concerned about the truck factor around Cog. If you go to work on something else what will happen. And imagine that nothing improves except speed for a couple of years and nothing has the knowledge to understand the system and you leave then we would have lost of couple of year making sure that the system is slowly improving and not only from the speed perspective. Now about uncompacting classes - I know that making classes uncompact was working when benjamin was working on hazelnut because he used that to simplify his approach. Now this is not working anymore so instead of working on the bootstrap we will have to understand what is wrong and turn around. - Second if simple stuff do not work or cannot even be changed how can we think about bigger changes. - Third we need a flexible system for making experiments. If we remove that from the system then we should all better go and do ruby or python. May be at the end this what we should do. - Camillo started to work on immutable objects and we check and we have 13 compact classes but 5 bits so it may make sense to keep 4 bits for compact classes and 2 bits for experiments (which are really important to us. it would mean 3 bits since immutability is important and we would like to have it). Then this means that we can live happily waiting for a new object format. Stef > > > > and your point would be? > > > it needs to be fixed. > > No. It does /not/ need to be fixed. As I said earlier it is *absurd* to throw away performance for the ability to change certain classes to become uncompact. > > Because if we can't do: > > Smalltalk compactClassesArray do: [:each | each ifNotNil: [each > becomeUncompact]]. > > then we cant: > > VM getRidOfCompactClassesNotion > > :) > > That will be done by producing a new GC and a new image format, not by tinkering with compact classes in the current GC. Right? > > > On Fri, May 6, 2011 at 9:38 AM, Igor Stasenko <[hidden email]> wrote: > >> > >> Hi, i tried to do a simple: > >> > >> Smalltalk compactClassesArray do: [:each | each ifNotNil: [each > >> becomeUncompact]] > >> > >> and it crashing the image. > >> I tried to do this for individual classes. > >> > >> > >> CompiledMethod, ByteString, BlockClosure, BlockContext , > >> seems working ok. > >> > >> MethodContext, LargePositiveInteger, LargeNegativeInteger, Float > >> crashes the image. > >> > >> i also tried following: > >> > >> [Smalltalk compactClassesArray do: [:each | each ifNotNil: [each > >> becomeUncompact]] > >> ] forkAt: Processor highestPriority > >> > >> but it didn't helped much. > >> > >> Also, i saved image after couple successfull #becomeUncompact steps.. > >> and now VM cannot open image, most probably > >> because it fails on 'assumptions check' defined in #checkAssumedCompactClasses > >> > >> -- > >> Best regards, > >> Igor Stasenko AKA sig. > > > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Colin Putney-3
On 5/7/2011 2:33, Colin Putney wrote: > > On Fri, May 6, 2011 at 5:18 PM, Igor Stasenko<[hidden email]> wrote: > >> No. its nothing to do with performance. It is about getting rid of >> them as a concept. > Well, if fixing it makes Cog slower, then it *is* about performance. > > Just making everything uncompact without changing the image format > doesn't really buy us much: it would make Cog slower and the image > bigger with no benefit. The benefit comes from having a new image > format that is optimized for speed rather than space - getting rid of > compact classes would just be a side-effect of the new format. And interestingly, Eliot's proposal for a new format actually gets rid of the class pointer and makes "everything" a compact class. Cheers, - Andreas |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Tobias Pape
On 5/7/2011 9:25, Tobias Pape wrote: >> No. It does /not/ need to be fixed. As I said earlier it is *absurd* to throw away performance for the ability to change certain classes to become uncompact. > When it worked in pre-cog VMs, why should it break in Cog? Because Cog is all about performance. And there's a big performance difference for some classes when they are changed to be non-compact and Eliot didn't want to add the complexity it would take to support both a fast compact, and a slow non-compact version of the code. Therefore, some classes cannot be made non-compact in Cog, and that is a perfectly good tradeoff. If you really need these classes to be non-compact (please remind me why exactly that would matter to you) then use the interpreter. In order to get performance some trade-offs are necessary and this is one of them. Cheers, - Andreas |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Andreas.Raab
On Sat, May 7, 2011 at 4:09 PM, Andreas Raab <[hidden email]> wrote:
I like this proposal, but wouldn't this have also an overhead? I mean, ok, we don't have to pay for the ifs to check whether a class is compact or not, but we are gonna to pay always the indirection (which right now is only for compact classes). You know much more than me so probably this overhead is smaller that today. cheers -- Mariano http://marianopeck.wordpress.com |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Andreas.Raab
On Sat, May 7, 2011 at 4:15 PM, Andreas Raab <[hidden email]> wrote:
I don't understand that sentence. If I change a class to be non-compact, how it can have worst performance? wouldn't it be faster since you don't pay the indirection? (the if you pay it always). you said "some classes". Could you give an example? Thanks for the clarification. Mariano and Eliot didn't want to add the complexity it would take to support both a fast compact, and a slow non-compact version of the code. Therefore, some classes cannot be made non-compact in Cog, and that is a perfectly good tradeoff. If you really need these classes to be non-compact (please remind me why exactly that would matter to you) then use the interpreter. In order to get performance some trade-offs are necessary and this is one of them. -- Mariano http://marianopeck.wordpress.com |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Andreas.Raab
On Sat, May 7, 2011 at 7:09 AM, Andreas Raab <[hidden email]> wrote: > And interestingly, Eliot's proposal for a new format actually gets rid of > the class pointer and makes "everything" a compact class. Ooh, I'd like to know more. Is that proposal written up anywhere? Colin |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
I don't recall if Eliot has published all the details (we went over it during some lunch break once) but the basic idea is described here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-August/131167.html http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/131206.html (of course, the compact class index is just an index into a class table) Cheers, - Andreas On 5/7/2011 19:20, Colin Putney wrote: > > On Sat, May 7, 2011 at 7:09 AM, Andreas Raab<[hidden email]> wrote: > >> And interestingly, Eliot's proposal for a new format actually gets rid of >> the class pointer and makes "everything" a compact class. > Ooh, I'd like to know more. Is that proposal written up anywhere? > > Colin > |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
On 2011-05-07, at 10:33 AM, Andreas Raab <[hidden email]> wrote: > I don't recall if Eliot has published all the details (we went over it during some lunch break once) but the basic idea is described here: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-August/131167.html > http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/131206.html > > (of course, the compact class index is just an index into a class table) Ok, I remember that now. I guess I was looking for a higher-level description based on the whys and wherefores. It sounds like the advantage here is space-saving, not speed: surely a class pointer is faster to deal with than a multi-level table lookup. I guess it's necessary because 64-bit pointers take a lot of space if you have one for each object? Colin |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Andreas.Raab
Forgive the VM newbie, but it sounds like the trade is actually cognitive load vs. vm performance If Eliot has a plan to introduce "everything is-a compact-class" then it sounds like we get cake and eat cake, we just have to be patient around waiting for cake, or find actually useful ways to help make cake, like getting the baker coffee or something. Compact vs. non-compact confused me too, but I have this crazy idea that everything is going to be okay:)
On Sat, May 7, 2011 at 7:09 AM, Andreas Raab <[hidden email]> wrote:
-- Casey Ransberger |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Andreas.Raab
On 7 May 2011 16:15, Andreas Raab <[hidden email]> wrote: > > On 5/7/2011 9:25, Tobias Pape wrote: >>> >>> No. It does /not/ need to be fixed. As I said earlier it is *absurd* to >>> throw away performance for the ability to change certain classes to become >>> uncompact. >> >> When it worked in pre-cog VMs, why should it break in Cog? > > Because Cog is all about performance. And there's a big performance > difference for some classes when they are changed to be non-compact and > Eliot didn't want to add the complexity it would take to support both a fast > compact, and a slow non-compact version of the code. Where is the metrics? I need to know what we lose if we do it one or another way. And since Cog don't allows me to turn compact class back to be normal class (simply crashing), i cannot measure it. > Therefore, some classes > cannot be made non-compact in Cog, and that is a perfectly good tradeoff. In theory. But you have no proof now. Why i should trust you/Eliot/anyone else, without being able to test it? > If you really need these classes to be non-compact (please remind me why > exactly that would matter to you) then use the interpreter. In order to get > performance some trade-offs are necessary and this is one of them. > It was not necessary to ban uncompaction. I would ban a creation of new compact classes, but not turning compact one to be uncompact again. Also, i don't want to do anything with old Interpreter. It makes no sense to see % slowdown in old interpreter and assume you will have same for Cog. It can be completely different. Comparing Interpreter and Cog is like comparing apples and oranges. I wanted to do a simple experiment: - create an image which has no compact classes - modify cog to not use compact class header so i can measure pro and cons.. Now , it looks like i cannot do it in simple way, because Cog simply cannot run such image(s), because some code in Cog are nailed down presence of concrete compact classes. -- Best regards, Igor Stasenko AKA sig. |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
do you know which are the list of classes that Cog expects to be compact? and are there classes that cog expect to be non-compact? which ones? Thanks in advance, Mariano http://marianopeck.wordpress.com |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
On 7 May 2011 22:38, Mariano Martinez Peck <[hidden email]> wrote: > > >> >> Now , it looks like i cannot do it in simple way, because Cog simply >> cannot run such image(s), >> because some code in Cog are nailed down presence of concrete compact classes. >> > > do you know which are the list of classes that Cog expects to be compact? > and are there classes that cog expect to be non-compact? which ones? > > Thanks in advance, > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Best regards, Igor Stasenko AKA sig. |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |