Hmm.. what causing such huge computation cost? Half an hour to bootstrap 600k.. sounds like unrealistically high. All you need to do is to build a graph in memory and then serialize it.. so what it does extra to make it so slow?
On 28 February 2017 at 15:03, Guillermo Polito <[email protected]> wrote: > Hi, > > yes this is cool :) > > There is also a new smart student that will work on this infrastructure a > bit to make it "normal developer friendly", you know, hiding some > implementation details, making maybe a UI for the process and so on. > > Now, about the questions: > > - And how much smaller could the image get if the class builder was > removed? > > Well, as Pavel says, you can get for example 10K. You can get even less > if you tweak it manually. Around 10k is the minimal required by the VM to > run a full featured image (at least in cog 32 bits, I did not measure it in > Spur). Imagine that the VM requires at least: > * one process scheduler > * one process in that scheduler > * one context on that process > * one method on that context > > Then, the VM requires some information to interact with the runtime, > e.g., > * what is the selector used for doesNotUnderstand: (yes, we can > change it!) > * what are the first 256 character objects in the Character flyweight > * what is the class of SmallInteger immediate instances > * some special/optimized selectors > > My automatic process generated a somewhat 10k of objects required for > this VM/image interaction. > > Of course this list changes a bit with Spur, and could be reduced (for > example, if you don't use characters, you wouldn't need the character > flyweight and so on...) > > - Is it future approach for bootstrap? (with respect to the 10k image) > > Well, if you read my thesis, what I'm doing there is to lazily pick what > classes and methods will go inside an image. While this is nice to > experiment, I do not think It's a good approach for bootstrapping: > * you need to exercise/execute all possible cases your image needs to > support > * and that means you need to know all those cases in advance > * and that you have to be careful with side effects > > Otherwise, code not executed is not taken in the resulting image. > > Also take the fact that changing a little line of code may result in > bootstrapping an image a couple of times bigger because of a wrong > dependency. > > All these points make this approach less reproducible and a bit more > complicated. I prefer an explicit list of packages to bootstrap, that we > can control and really test the output :) > > Also, as Igor says, we could be able to generate an image without a class > builder, as we are able to generate an image without a compiler. But we do > not want to. Because that is an image that we cannot almost interact with. > We cannot load code inside. So the more interesting question is where is > the balance between space and functionality. > > BTW Pavel, this approach may need to be updated but I think we could make > it run on top of the simulator also ;). > > - How faster or slower bootstrap process with it? > > They are not really comparable. They do not use the same infrastructure, > nor the same process, and they do not generate the same results. > The 10k image is of course generated in a matter of seconds, but a 600k > image containing the seaside counter may take half an hour. > > In our current approach, the speed of bootstrap is directly related to > the number of classes and methods inside the result. There are two ways to > speed up the process: > - by speeding up the ast interpreter (or replacing it by a compiled > version of it) > - and by cleaning the kernel > > > > Guille > > On Fri, Feb 24, 2017 at 9:15 PM, Igor Stasenko <[email protected]> wrote: > >> >> >> On 24 February 2017 at 21:01, Pavel Krivanek <[email protected]> >> wrote: >> >>> >>> 2017-02-24 17:17 GMT+01:00 Denis Kudriashov <[email protected]>: >>> >>>> >>>> 2017-02-24 16:36 GMT+01:00 Pavel Krivanek <[email protected]>: >>>> >>>>> The "guest" object memory runs in a special virtual machine simulator >>>>> during the bootstrapping. That simulator uses AST Interpreter to execute >>>>> the code inside the guest environment before it is installed for real. It >>>>> uses own special kind of proxies and tricks to do it. The current >>>>> bootstrap >>>>> cannot run without class builder in the guest environment, but... >>>>> >>>>> >>>>>> And how much smaller could the image get if the class builder was >>>>>> removed. >>>>>> >>>>> >>>>> ...Guille in his thesis tried different approaches and he was able to >>>>> produce extremely small images (~10 KiB) that did for example only a sum >>>>> of two numbers. >>>>> >>>> >>>> Is it future approach for bootstrap? >>>> How faster or slower bootstrap process with it? >>>> >>> >>> That's more question for Guille, but I do not think we will adopt this >>> approach of bootstrapping in near future because it needs to be updated for >>> the Spur format and it needs a special VM modifications. And the question >>> is how much is it really needed because if you want to do something with >>> the image, you will anyway need most of methods needed for the class >>> builder like basic strings and collections support. >>> >>> >> I think, you can shrink image even more, by running something after >> booting it to remove ClassBuilder & co, if you don't need to create classes >> etc. >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.
