#becomeUncompact not longer works in Cog/Stack VMs
Locked
12
12
Re: #becomeUncompact not longer works in Cog/Stack VMs
 
|
On Sat, May 7, 2011 at 7:15 AM, Andreas Raab <[hidden email]> wrote:
Thank you Andreas. Exactly. Determining the class of an instance of a compact class is faster than determining the class of an instance of a non-compact class if the compact class index is known. So in asking "is the receiver a LargeInteger" or "is the receiver a Float" in the VM is significantly faster if the compact class index is a constant. If we introduce the in-practice unused facility to allow all classes to become uncompact we lose this performance advantage. I do not see the point of losing performance to support unused or useless functionality.
|
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by stephane ducasse-2
Hi Stephane, On Sat, May 7, 2011 at 1:35 AM, stephane ducasse <[hidden email]> wrote:
You need to understand the technical issue here before you can say that I'm saying "do not fix it". I am /sure/ that there is no bug here to be fixed, and that "fixing" the supposed bug will make things worse for no benefit. I also /do not/ leave bugs unfixed. Recently I have fixed shallow copy for contexts, objects-as-methods, locales on linux and many more. So it is unfair to accuse me of not fixing bugs, and a little intellectually lazy of you in this case not to understand the issue that is behind my saying we should not "fix" this. Pl;ease see Andreas' message and my reply to it.
best, Eliot At least to me the messages is that you are not really interested in that. I can understand that you are busy |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Andreas.Raab
Am 2011-05-07 um 16:15 schrieb Andreas Raab: > 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) Only two versions of object headers. not three. > then use the interpreter. In order to get performance some trade-offs are necessary and this is one of them. > > Cheers, > - Andreas > So Long, -Tobias |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Eliot Miranda-2
Hi Stephane, > > On Sat, May 7, 2011 at 1:35 AM, stephane ducasse <[hidden email]> wrote: > > 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. > > You need to understand the technical issue here before you can say that I'm saying "do not fix it". I am /sure/ that there is no bug here to be fixed, and that "fixing" the supposed bug will make things worse for no benefit. I also /do not/ leave bugs unfixed. Recently I have fixed shallow copy for contexts, objects-as-methods, locales on linux and many more. So it is unfair to accuse me of not fixing bugs, and a little intellectually lazy of you in this case not to understand the issue that is behind my saying we should not "fix" this. Pl;ease see Andreas' message and my reply to it. OK point taken. Now this is my feedback and feeling. I read the explanation on the mail archive and I'm in favor of having a new format. When do you expect that? Then how much speed does it give you? Stef > best, > Eliot > > 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 Tobias Pape
On 5/8/2011 8:38, Tobias Pape wrote: > Am 2011-05-07 um 16:15 schrieb Andreas Raab: >> 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) > Only two versions of object headers. > not three. But why? If your argument is that two object headers make the VM simpler, then my response is: Go use the interpreter. It's *much* simpler than the JIT and if your goal is conceptual simplicity, then the JIT clearly isn't for you. A JIT by its very nature must make some tradeoffs in order to perform better and if you don't like the tradeoffs you'll have difficulties to actually get the performance you're looking for. Cheers, - Andreas >> then use the interpreter. In order to get performance some trade-offs are necessary and this is one of them. >> >> Cheers, >> - Andreas >> > > So Long, > -Tobias |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Igor Stasenko
On 5/7/2011 22:30, Igor Stasenko wrote: > > 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. Then write the code yourself. Why does Eliot have to do that? His metrics is pretty simple, a comparison of the speed of the interpreter with the JIT. The results (as you know) are impressive, but you can't realistically expect Eliot to do the work for something he considers directly detrimental to the goals of Cog. If you suspect that there's no difference, it's up to you to prove that, not up to Eliot to disprove you. And unless you can show differently, his claim stands unabated. >> 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? You don't. But why must Eliot jump every time you have a hunch that something can be done differently? Adding unneeded generality to a JIT just to disprove your hunches is an amazingly pointless waste of time for him. Unless you are intending to pay him for it, of course. Oh, you weren't... Cheers, - Andreas >> 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. > > |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
> 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? > > You don't. But why must Eliot jump every time you have a hunch that something can be done differently? Adding unneeded generality to a JIT just to disprove your hunches is an amazingly pointless waste of time for him. Unless you are intending to pay him for it, of course. Oh, you weren't... Hi andreas your points are totally valid. Now the point is that it does not look like we are building a community around Cog, more a sect and this is sad - even if eliot is doing his best to answer the stupid questions of people like mariano. I organized the school deep into smalltalk and payed eliot for his talks just to spread the knowledge. For me this is important to discuss and that knowledge is spread on pros and cons. So at least the links you sent were good. Now personally I do not use Cog yet just to see how far I need to be bound to something complex and understood by two persons. This is my way to manage my own risks in my business. So making pharo fast on the interpreter is a reasonable approach too. I think that our little community should realize that, else one day it can be hurt. This is sad that we do not succeed to build a set up where the community could pay eliot to work on Cog but this is like that so far. I tried some setup but so far this is not working. Now even if this would be the case, how a set of companies would invest money in something that only one guy or two understand. I think that if we do not minimize the truck factor then we have a high risk profile that investors should be able to understand quite well and run away from us (or they are blind which is better). After we should not cry when "rewrite everything in java" arrives (even if it may be for other less obvious reasons). As an investor of the money for my kids I tend to be much more picky about reality and risks. Having kids is a good way to check reality. Stef |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Eliot Miranda-2
On Sun, May 8, 2011 at 6:54 AM, Eliot Miranda <[hidden email]> wrote:
This is what I don't understand. Even if the compact class index is known, why is it that faster than non-compact? because in non-compact you need to fetch the class pointer from the object header? But... regardless that the compact class index is know, you also have to get the index (those 5 bits) from the OH. So I don't see why there is so much difference in performance.
You mean that to answer "is the receiver a LargeInteger" you don't need to fetch the class of the receiver and then do a speObj: comparison, but instead get the compact class index from the OH and compare to a known value ???
-- Mariano http://marianopeck.wordpress.com |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
On 08.05.2011, at 09:39, Mariano Martinez Peck wrote: > On Sun, May 8, 2011 at 6:54 AM, Eliot Miranda <[hidden email]> wrote: >> Determining the class of an instance of a compact class is faster than determining the class of an instance of a non-compact class if the compact class index is known. > > This is what I don't understand. Even if the compact class index is known, why is it that faster than non-compact? because in non-compact you need to fetch the class pointer from the object header? > But... regardless that the compact class index is know, you also have to get the index (those 5 bits) from the OH. So I don't see why there is so much difference in performance. The difference is that the index can be compared to a *constant*. If the index is 6 (or is it 5?) then this is a Float instance. No matter where in memory the Float class actually is. It's almost like a tag bit for classes, similar to the tag bit to distinguish immediate SmallIntegers. - Bert - |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Mariano Martinez Peck
On 8 May 2011 14:39, Mariano Martinez Peck <[hidden email]> wrote: > > > > On Sun, May 8, 2011 at 6:54 AM, Eliot Miranda <[hidden email]> wrote: >> >> >> >> >> On Sat, May 7, 2011 at 7:15 AM, 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. 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. >> >> Thank you Andreas. Exactly. Determining the class of an instance of a compact class is faster than determining the class of an instance of a non-compact class if the compact class index is known. > > This is what I don't understand. Even if the compact class index is known, why is it that faster than non-compact? because in non-compact you need to fetch the class pointer from the object header? > But... regardless that the compact class index is know, you also have to get the index (those 5 bits) from the OH. So I don't see why there is so much difference in performance. > to prove or disprove that you have to check how fast VM with and without compact classes. > >> >> So in asking "is the receiver a LargeInteger" or "is the receiver a Float" in the VM is significantly faster if the compact class index is a constant. > > You mean that to answer "is the receiver a LargeInteger" you don't need to fetch the class of the receiver and then do a speObj: comparison, but instead get the compact class index from the OH and compare to a known value ??? > yes, it is faster to compare compact class index in OH with constant, instead of fetching the class of object and comparing it to class which held in special objects array at certain index. In fact, i am used the same trick in NativeBoost callout generation. To test if passed argument is instance of float, its just checks the object's header and its compact class index value. This is trivial optimization , which lies on surface. But then, it is dynamically generated code, which i can discard at any moment. And if Float will be non-compact next time, it will generate different code, according to situation. This means, that it is possible to keep flexibility without sacrificing speed. And that's what i trying to argue. >> >> If we introduce the in-practice unused facility to allow all classes to become uncompact we lose this performance advantage. I do not see the point of losing performance to support unused or useless functionality. >> Me neither. > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko AKA sig. |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by stephane ducasse-2
On Sun, May 8, 2011 at 12:21 AM, stephane ducasse <[hidden email]> wrote:
I don't know exactly. It depends on how much time I have to spend on Cog at Cadence. I think there's a good chance of having it done this year.
Then how much speed does it give you? Difficult to say. My estimate is a factor of two, based on the comparison between VisualWorks and Cog since the new object format and GC should be as good as or slightly better than VisualWorks and from the computer language shootout VW looks to be about twice as fast as current Cog.
|
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by stephane ducasse-2
On Sun, May 8, 2011 at 3:24 AM, stephane ducasse <[hidden email]> wrote:
How many people really understand the VisualWorks JIT or any other high-performance VM? In my experience few people have the interest, skills and experience in language design and implementation and low-level computer architecture. There are relatively few really good VM engineers compared to the number of really good high-level object-oriented programmers. That matches perfectly with the far smaller number of VMs than interesting object-oriented programs. A VM, like any other piece of core infrastructure has a very high rate of use. I don't see anything unusual, surprising or worrying about this. How is it that different from Ian, Andreas, John and David as the keepers of the Interpreter before Cog?
Further Nicholas demonstrated this week that with a little intellectual effort someone really good can come to understand Cog and make a contribution quite quickly. Instead of all this FUD about there not being a community around Cog why not try and play with it, as Nicholas has successfully, and we can start building the community. I'm not going to respond well to bullying tactics. I respond well to real collaboration (thanks Marcus, Nicholas, Levente, Andreas, Igor, Mariano and all who have found and reported bugs).
Why express such FUD? I am happily at Cadence again and will have the freedom to spend significant time on Cog (with Newspeak also). And there are a few other potential places I could end up working on Cog. Meanwhile people like Nicholas will gain a better understanding of Cog, people like Mariano will produce ever more comprehensible documentation, people like Marcus will evolve it in really interesting performance directions and people like Igor will evolve its basic architecture away from a monolithic simulated-in-Smalltalk system to a true live bootstrap. Others will work on the FFI and Cog will evolve into a key component of a powerful open-source Smalltalk platform. The community /is/ building. Relax.
best, Eliot
|
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
On 8 May 2011 21:02, Eliot Miranda <[hidden email]> wrote: > > > > On Sun, May 8, 2011 at 3:24 AM, stephane ducasse <[hidden email]> wrote: >> >> > 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? >> > >> > You don't. But why must Eliot jump every time you have a hunch that something can be done differently? Adding unneeded generality to a JIT just to disprove your hunches is an amazingly pointless waste of time for him. Unless you are intending to pay him for it, of course. Oh, you weren't... >> >> Hi andreas >> >> your points are totally valid. Now the point is that it does not look like we are building a community >> around Cog, more a sect and this is sad - even if eliot is doing his best to answer the stupid questions of people like mariano. I organized the school deep into smalltalk and payed eliot for his talks just to spread the knowledge. For me this is important to discuss and that knowledge is spread on pros and cons. So at least the links you sent were good. >> >> Now personally I do not use Cog yet just to see how far I need to be bound to something >> complex and understood by two persons. This is my way to manage my own risks in my business. >> So making pharo fast on the interpreter is a reasonable approach too. I think that our little community >> should realize that, else one day it can be hurt. > > How many people really understand the VisualWorks JIT or any other high-performance VM? In my experience few people have the interest, skills and experience in language design and implementation and low-level computer architecture. There are relatively few really good VM engineers compared to the number of really good high-level object-oriented programmers. That matches perfectly with the far smaller number of VMs than interesting object-oriented programs. A VM, like any other piece of core infrastructure has a very high rate of use. I don't see anything unusual, surprising or worrying about this. How is it that different from Ian, Andreas, John and David as the keepers of the Interpreter before Cog? > Further Nicholas demonstrated this week that with a little intellectual effort someone really good can come to understand Cog and make a contribution quite quickly. Instead of all this FUD about there not being a community around Cog why not try and play with it, as Nicholas has successfully, and we can start building the community. I'm not going to respond well to bullying tactics. I respond well to real collaboration (thanks Marcus, Nicholas, Levente, Andreas, Igor, Mariano and all who have found and reported bugs). >> >> This is sad that we do not succeed to build a set up where the community could pay eliot to work on Cog >> but this is like that so far. I tried some setup but so far this is not working. Now even if this would be the case, how a set of companies would invest money in something that only one guy or two understand. I think that if we do not minimize the truck factor then we have a high risk profile that investors should be able to understand quite well and run away from us (or they are blind which is better). After we should not cry when "rewrite everything in java" arrives (even if it may be for other less obvious reasons). As an investor of the money for my kids I tend to be much more picky about reality and risks. Having kids is a good way to check reality. > > Why express such FUD? I am happily at Cadence again and will have the freedom to spend significant time on Cog (with Newspeak also). And there are a few other potential places I could end up working on Cog. Meanwhile people like Nicholas will gain a better understanding of Cog, people like Mariano will produce ever more comprehensible documentation, people like Marcus will evolve it in really interesting performance directions and people like Igor will evolve its basic architecture away from a monolithic simulated-in-Smalltalk system to a true live bootstrap. Others will work on the FFI and Cog will evolve into a key component of a powerful open-source Smalltalk platform. The community /is/ building. Relax. Be cool, Stephane. JIT is more complex, sure thing. Entry point is high. Sure thing. But the road overcomes a walking one. So little steps at a time. It is just a smalltalk code, after all. Yes, it is slang, and because its a slang, its even more 'stupidified' code than usual smalltalk. Yes, its more tedious to code in 'slang mode' , because you need to make sure it will be translated, but it is still better than writing everything in C. -- Best regards, Igor Stasenko AKA sig. |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
In reply to this post by Andreas.Raab
Hi andreas > 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 I read the second link multiple times but I could not get the following: "- sending a message to an object. The object's class and the message's selector are quertied for their identity hash. If either object does not have one it is assigned. So the class object is identified from context; it is the class of the receiver." I could not understand the last sentence from the second link. "One nice thing I didn't mention is that one can use "class index puns". There is nothing to prevent the VM from entering a class into the class table more than once. So I entered in WeakArray twice into the class table, and used one as a hidden class index for the pages of the class table itself. When one does WeakArray allInstances, therefore, the class table pages are not found. Further, the finalization machinery can easily identify a class table page, because it has a unique class index, and so the maintennance of the first unused class table slot index is very cheap." I could not understand the trick of entering the weakarray twice. Stef |
Re: #becomeUncompact not longer works in Cog/Stack VMs
|
|
On Mon, May 9, 2011 at 1:52 AM, stephane ducasse <[hidden email]> wrote:
This is a mistake on my part. In this scheme it is impossible to have an instance of a class and that class not have an identityHash. I was talking about/getting confused with the standard VisualWorks VM where a class may be assigned an identityHash on send. In the class index scheme classes get assigned identity hashes either in a special version if the identityHash primitive for Behavior (e.g. when one puts a class in an IdentitySet) or when a class is instantiated. So the check for classes having identityHashes (which are also their table indices and hence the class indices of their instances) is on instantiation, not send. Sorry.
"One nice thing I didn't mention is that one can use "class index puns". So we want to use WeakArray for the class table pages since we don't want to hold onto classes strongly through the class table, only through instances. Bt the class table should remain a hidden object, not visible to the image; it is part of the VM implementation, not an official part of the specialObjectsArray. So e.g. these pages shouldn't turn up in WeakArray allInstances. By using a pun for WeakArray (so that there are two entries in the class table that map to the WeakArray class) and using one of these only for the class table pages then WeakArray allInstances won't include them. I'm not sure this is so important, but it is a way of using the heap for the VM to allocate memory without that memory becomming visible to the image.
is this understandable yet? best, Eliot
|
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |