- Pharo-users - lists.pharo.org

Re: [Pharo-users] parameters of the virtual machine

by stepharo

clement you should add that to a simple blog post :) Stef Le 24/5/16 Ã 19:35, ClÃ©ment Bera a Ã©crit : > Hi, > > Sorry the mail is quite long... I CC'd Nevena for section II, she used > the VM caches for type inference. > * > * > *Section I. VM parameters* > * > * > */46 size of machine code zone, in bytes/* > > Well, the size of the machine code zone :-). To speed-up execution, > the cog uses internally a JIT compiler which translates to machine > code frequently used bytecoded method and run the machine code to > execute them instead of using the interpreter. The machine code zone > is an executable memory zone containing all the machine code versions > of methods. > > The default size should be between 1Mb and 2Mb for standard > applications. If memory is a constraint, it can be lowered down to > 750kb, under that you should use the stack VM else the performance > starts to drastically decrease. > > This setting is useful to tune your application performance. For > example, on compilation-intensive benchs, 750kb is the optimal machine > code zone size. On large benchmarks, 2 Mb, maybe more, is better, but > then one may see machine code garbage collection pauses. On small > benchs all the methods fit into this zone so it doesn't really matter. > > Growing the machine code zone: > - increase the number of methods that can be present there, hence > decreasing machine code zone garbage collection frequency and method > jit compilation. > - decrease the machine code zone to cpu instruction cache mapping > - slow down machine code zone garbage collection > > To set the machine code zone you need to use another parameter (47 I > think) and restart the VM+image. > / > / > /* 59 number of check event calls since startup (read-only)*/ > > If I remember correctly, the number of times the VM has checked for OS > events since start-up. > > /* 60 number of stack page overflows since startup (read-only; > Cog VMs only) > 61 number of stack page divorces since startup (read-only; Cog > VMs only)*/ > > This is related to stack page management. Read the Cog blog to > understand how it's done. See > http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the… > section Stack pages. > > *Section II. Accessing the caches* > > */Is there a way to get access to the cache? How many caches does Cog > has? I guess it has > - a method call cache (associating (object,symbol) -> compiled > method > - a cache for the JIT-compiled methods right?/ > * > /* > */ > /*Are there other cache? How can I access them? In particular to query > about their fill.* > / > > There is indeed a global look-up cache, mapping (receiver type, > symbol) -> (compiled method, primitive function pointer). In the > jitted methods there are per send-sites look-up caches, also known as > inline caches. > > The most useful is the inline cache values, they provide the receiver > types met for each send site and are fairly reliable. There are ways > to access those caches. I personally use those caches values for the > runtime optimizing compiler, but more recently I worked with > Nevena Milojkovic (I CC'd her) and she was able to use those cache > values for type inference, while she is not a VM expert. We wrote an > IWST paper about that, hopefully it'll get accepted and you will be > able to read it. In the IWST paper I sum-up Eliot's implementation of > inline caches and how the VM provides the types. > > In short, to access the caches: > 1) add those primitives: > VirtualMachine>>allMachineCodeMethods > <primitive: 'primitiveAllMethodsCompiledToMachineCode' module:''> > ^#() > CompiledMethod>>sendAndBranchData > <primitive: 'primitiveSistaMethodPICAndCounterData' module:''> > ^#() > 2) add glue code to map caches values from bytecode pc to the AST, > something like that: > CompiledMethod>>astWithCacheAnnotations > | tmp1 | > tmp1 := self sendAndBranchData. > tmp1 > ifEmpty: [ 'No data' logCr. > ^ self ast ]; > do: [ :arg1 | > (self sourceNodeForPC: arg1 first) > propertyAt: #cacheInformation > put: arg1 allButFirst ]. > ^ self ast > 3) Compile the VM with the SistaCogit and SistaVM=true (Slang > compilation settings). > > I guess you could read our IWST paper, that would help. I don't know > if that's possible before the reviewers answer. > > Don't build production tools using those values though, the VM is > evolving and the cache values may vary in the future with the sista > optimizer. > > Regards, > > Clement > > On Tue, May 24, 2016 at 5:39 PM, Alexandre Bergel > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > > Hi, > > The Cog virtual machine expose some very useful parameters. > However, some of them are a bit obscure to me. For example, what > are the following parameters? What do they mean? > > 46 size of machine code zone, in bytes > 59 number of check event calls since startup > (read-only) > 60 number of stack page overflows since > startup (read-only; Cog VMs only) > 61 number of stack page divorces since > startup (read-only; Cog VMs only) > > Is there a way to get access to the cache? How many caches does > Cog has? I guess it has > - a method call cache (associating (object,symbol) -> > compiled method > - a cache for the JIT-compiled methods right? > > Are there other cache? How can I access them? In particular to > query about their fill. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

May 25, 2016

Re: [Pharo-users] parameters of the virtual machine

by Alexandre Bergel

Thanks ClÃ©ment for the long description. I will improve the comments of that method. Cheers, Alexandre > On May 24, 2016, at 1:35 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hi, > > Sorry the mail is quite long... I CC'd Nevena for section II, she used the VM caches for type inference. > > Section I. VM parameters > > 46 size of machine code zone, in bytes > > Well, the size of the machine code zone :-). To speed-up execution, the cog uses internally a JIT compiler which translates to machine code frequently used bytecoded method and run the machine code to execute them instead of using the interpreter. The machine code zone is an executable memory zone containing all the machine code versions of methods. > > The default size should be between 1Mb and 2Mb for standard applications. If memory is a constraint, it can be lowered down to 750kb, under that you should use the stack VM else the performance starts to drastically decrease. > > This setting is useful to tune your application performance. For example, on compilation-intensive benchs, 750kb is the optimal machine code zone size. On large benchmarks, 2 Mb, maybe more, is better, but then one may see machine code garbage collection pauses. On small benchs all the methods fit into this zone so it doesn't really matter. > > Growing the machine code zone: > - increase the number of methods that can be present there, hence decreasing machine code zone garbage collection frequency and method jit compilation. > - decrease the machine code zone to cpu instruction cache mapping > - slow down machine code zone garbage collection > > To set the machine code zone you need to use another parameter (47 I think) and restart the VM+image. > > 59 number of check event calls since startup (read-only) > > If I remember correctly, the number of times the VM has checked for OS events since start-up. > > 60 number of stack page overflows since startup (read-only; Cog VMs only) > 61 number of stack page divorces since startup (read-only; Cog VMs only) > > This is related to stack page management. Read the Cog blog to understand how it's done. See http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the… section Stack pages. > > Section II. Accessing the caches > > Is there a way to get access to the cache? How many caches does Cog has? I guess it has > - a method call cache (associating (object,symbol) -> compiled method > - a cache for the JIT-compiled methods right? > > Are there other cache? How can I access them? In particular to query about their fill. > > There is indeed a global look-up cache, mapping (receiver type, symbol) -> (compiled method, primitive function pointer). In the jitted methods there are per send-sites look-up caches, also known as inline caches. > > The most useful is the inline cache values, they provide the receiver types met for each send site and are fairly reliable. There are ways to access those caches. I personally use those caches values for the runtime optimizing compiler, but more recently I worked with Nevena Milojkovic (I CC'd her) and she was able to use those cache values for type inference, while she is not a VM expert. We wrote an IWST paper about that, hopefully it'll get accepted and you will be able to read it. In the IWST paper I sum-up Eliot's implementation of inline caches and how the VM provides the types. > > In short, to access the caches: > 1) add those primitives: > VirtualMachine>>allMachineCodeMethods > <primitive: 'primitiveAllMethodsCompiledToMachineCode' module:''> > ^#() > CompiledMethod>>sendAndBranchData > <primitive: 'primitiveSistaMethodPICAndCounterData' module:''> > ^#() > 2) add glue code to map caches values from bytecode pc to the AST, something like that: > CompiledMethod>>astWithCacheAnnotations > | tmp1 | > tmp1 := self sendAndBranchData. > tmp1 > ifEmpty: [ 'No data' logCr. > ^ self ast ]; > do: [ :arg1 | > (self sourceNodeForPC: arg1 first) > propertyAt: #cacheInformation > put: arg1 allButFirst ]. > ^ self ast > 3) Compile the VM with the SistaCogit and SistaVM=true (Slang compilation settings). > > I guess you could read our IWST paper, that would help. I don't know if that's possible before the reviewers answer. > > Don't build production tools using those values though, the VM is evolving and the cache values may vary in the future with the sista optimizer. > > Regards, > > Clement > > On Tue, May 24, 2016 at 5:39 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi, > > The Cog virtual machine expose some very useful parameters. However, some of them are a bit obscure to me. For example, what are the following parameters? What do they mean? > > 46 size of machine code zone, in bytes > 59 number of check event calls since startup (read-only) > 60 number of stack page overflows since startup (read-only; Cog VMs only) > 61 number of stack page divorces since startup (read-only; Cog VMs only) > > Is there a way to get access to the cache? How many caches does Cog has? I guess it has > - a method call cache (associating (object,symbol) -> compiled method > - a cache for the JIT-compiled methods right? > > Are there other cache? How can I access them? In particular to query about their fill. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 24, 2016

Re: [Pharo-users] An Idea for a minimal self documented begineer friendly pharo image

by Offray Vladimir Luna CÃ¡rdenas

Hi, Nice to see this efforts. I will try to help with my interactive notebook documentation project for reproducible/open research and by making visualization for more diverse fields, mainly data activism: Panama Papers[1], Political discourses[2](should be updated), but also medicines [3]. Also I'm making some builders to make more easy specific domain visualizations and re-reading, this time deeply, the Agile Visualization book and making some comments (i.e [4][5]) [1] http://mutabit.com/offray/blog/en/entry/panama-papers-1 [2] http://mutabit.com/offray/static/blog/output/posts/visualizing-politiciansp… [3] http://mutabit.com/offray/blog/en/entry/sdv-infomed [4] https://hyp.is/8hHnlCHzEeaIfiOOWSL11w/dl.dropboxusercontent.com/u/31543901/… [5] https://hyp.is/44eZbiHxEeaykduI7FzoXQ/dl.dropboxusercontent.com/u/31543901/… I just tell this because at some point could be an intersection/complementarity from the documentation point and helps to have this overview of where people is focused and trying to contribute. I don't know if there is a place where interested can find where other people is doing that is not properly software (or is not integrated yet into software)... kind of related project/interest in Pharo. Cheers, Offray On 24/05/16 15:55, Dimitris Chloupis wrote: > WOW I did not expect so many replies > > Its amazing you guys work on a minimal image, since that is the case I > will wait for you experts to deliver and instead as you advise me > Esteban I will focus my effort on documentation, it looks like I have > come to a decision to contribute to pharo in 3 ways > > 1) Make a theme for pharo which is very modern flexible and super easy > to customise to whatever one wants, a theme to rule them all -> Nireas > (its there but needs a lot of improvement) > 2) Make an API for Blender that will allow pharo developers to take > advantage of Blender awesome graphics capabilities -> Ephestos (same > as above) > 3) Contribute to documentation both via pillar and class and method > comments. -> Prometheas (same as above) > > I am sure the minimal image that you will provide will be perfect for > my needs. I dont mind size per se, just system complexity. > > I agree again with you Esteban that it would be better to let the > maintaince of a minimal image to pharo devs since I think we are all > in the same page and instead tackle areas of my expertise like > graphics, theme and documentation. > > I was just thinking how I could help Pharo the best way and I think > these 3 projects are more than enough to keep me occupied. > > The linked image you posted does not open after I download it and > unzip it. Does it require a special VM or is it something else ? > > On Tue, May 24, 2016 at 5:28 PM Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > 2016-05-24 16:18 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>>: > > >> On 24 May 2016, at 16:11, Thierry Goubier >> <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>> wrote: >> >> >> >> 2016-05-24 15:18 GMT+02:00 Dimitris Chloupis >> <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>>: >> >> Well technically the python part works fine, BUT I also >> always wanted it to be friendly to begineers . So nope , >> its same project. And you are correct its still focused >> in coding 3d graphics but I came to realisation that if I >> want some people to use it, obviously i dont expect the >> massive majority to give up the comforts of python but >> for those that are curious I have to provide an >> enviroment thats is even easier to code in than python is >> currently for Blender. >> >> My goal is to provide a development enviroment for >> Blender addons that is simple, and easy to use and learn. >> >> So providing a minimal pharo image that is self >> documented has always being a dream for Ephestos. >> >> By the way whats the news on the matter of modular pharo >> image ? Is there any work done to provide a minimal pharo >> image ? >> >> >> There is a minimal image, which is I think usable as-is, >> except that what you want is something in between the minimal >> image (no gui, no tools) and a full image, and that is a bit >> complex to set-up. >> >> I started some work on doing that with Pharo4 (put a place >> with baselines I could use to load the HEAD of the Pharo main >> repository and load the right packages), but Pharo5 changed >> the way external projects are included, and my approach >> wasn't good anymore. >> >> I think the overall Pharo organisation could benefit from >> such an effort; it would exercise all the planned mechanisms >> for the modular image, in maybe an easier way than a modular >> full image, and with someone motivated to debug and maintain >> the process: you! > > honestly, I wouldnât. > working in a parallel image is too much work (believe me, I > know something about keeping an image going). > > > Well, I am technically working in a parallel image for the past > ... 3 years ? So, no, as long as you handle a changing minimal > image and a well mastered set of slow changing packages over it, > it is doable. > > The base Pharo isn't changing much. As long as you don't use what > is changing a lot, then this is doable. Maintaining changes all > over all the fast moving packages that are in the full Pharo, then > I agree with you, Esteban. > > Pavel and Christophe are working on the bootstrap process who > should be working in one-two months, with that, building > custom images will be finally a realityâ¦from there you might > want to give it a try. > > > This, given the timeframe, is both an excellent suggestion and > good to know :) > > But I would better invest on document (something that you have > been doing very well and Iâm very thankful for that) than in > keeping alive what is, in fact, a fork. > > > Racing to document all the fast moving packages in Pharo can > really be a challenge, still. > > Thierry > > cheers, > Esteban > >> >> Thierry >> >> >> >> I would hate to replicate what is already done. >> >> On Tue, May 24, 2016 at 3:59 PM Ben Coman >> <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> >> On Tue, May 24, 2016 at 7:01 PM, Dimitris Chloupis >> <kilon.alios(a)gmail.com >> <mailto:kilon.alios@gmail.com>> wrote: >> > So I was reading the complains from Sven and got >> Inspiration from Torsten >> > Pharo image and CUIs and made me wonder what if we >> had an image which has >> > the least amount of libraries and every library >> inside it is full commented >> > in class, package and method and even has tutorial >> using inside help tool. >> > >> > So I think I will give this project a try. I know >> there is a plan to make >> > pharo image more modular, but modularity does not >> equal minimalism , >> > simplicity and ease of use. >> > >> > I think I will follow the CUIs example and do the >> development via Github. >> > >> > But I am open to ideas and suggestions. >> > >> > My intention is to remove the excess fat, to make >> Pharo prettier (improve >> > theme support and make available several themes ) >> and to have everything >> > commented and self documented. >> > >> > Obviously this will be a long term project and in >> no way a walk in the park >> > but I was looking for a nice project to name >> "Ephestos" :D seem as good as >> > any >> >> Did this project not pane out?... >> https://pharoweekly.wordpress.com/2014/07/16/ephestos-using-and-coding-blen… >> >> Seems you're quite attached to that name :) >> but is there a minor chance of confusion? >> >> cheers -ben >> >> >

May 24, 2016

Re: [Pharo-users] An Idea for a minimal self documented begineer friendly pharo image

by Dimitris Chloupis

WOW I did not expect so many replies Its amazing you guys work on a minimal image, since that is the case I will wait for you experts to deliver and instead as you advise me Esteban I will focus my effort on documentation, it looks like I have come to a decision to contribute to pharo in 3 ways 1) Make a theme for pharo which is very modern flexible and super easy to customise to whatever one wants, a theme to rule them all -> Nireas (its there but needs a lot of improvement) 2) Make an API for Blender that will allow pharo developers to take advantage of Blender awesome graphics capabilities -> Ephestos (same as above) 3) Contribute to documentation both via pillar and class and method comments. -> Prometheas (same as above) I am sure the minimal image that you will provide will be perfect for my needs. I dont mind size per se, just system complexity. I agree again with you Esteban that it would be better to let the maintaince of a minimal image to pharo devs since I think we are all in the same page and instead tackle areas of my expertise like graphics, theme and documentation. I was just thinking how I could help Pharo the best way and I think these 3 projects are more than enough to keep me occupied. The linked image you posted does not open after I download it and unzip it. Does it require a special VM or is it something else ? On Tue, May 24, 2016 at 5:28 PM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > 2016-05-24 16:18 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> >> On 24 May 2016, at 16:11, Thierry Goubier <thierry.goubier(a)gmail.com> >> wrote: >> >> >> >> 2016-05-24 15:18 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >> >>> Well technically the python part works fine, BUT I also always wanted it >>> to be friendly to begineers . So nope , its same project. And you are >>> correct its still focused in coding 3d graphics but I came to realisation >>> that if I want some people to use it, obviously i dont expect the massive >>> majority to give up the comforts of python but for those that are curious I >>> have to provide an enviroment thats is even easier to code in than python >>> is currently for Blender. >>> >>> My goal is to provide a development enviroment for Blender addons that >>> is simple, and easy to use and learn. >>> >>> So providing a minimal pharo image that is self documented has always >>> being a dream for Ephestos. >>> >>> By the way whats the news on the matter of modular pharo image ? Is >>> there any work done to provide a minimal pharo image ? >>> >> >> There is a minimal image, which is I think usable as-is, except that what >> you want is something in between the minimal image (no gui, no tools) and a >> full image, and that is a bit complex to set-up. >> >> I started some work on doing that with Pharo4 (put a place with baselines >> I could use to load the HEAD of the Pharo main repository and load the >> right packages), but Pharo5 changed the way external projects are included, >> and my approach wasn't good anymore. >> >> I think the overall Pharo organisation could benefit from such an effort; >> it would exercise all the planned mechanisms for the modular image, in >> maybe an easier way than a modular full image, and with someone motivated >> to debug and maintain the process: you! >> >> >> honestly, I wouldnât. >> working in a parallel image is too much work (believe me, I know >> something about keeping an image going). >> > > Well, I am technically working in a parallel image for the past ... 3 > years ? So, no, as long as you handle a changing minimal image and a well > mastered set of slow changing packages over it, it is doable. > > The base Pharo isn't changing much. As long as you don't use what is > changing a lot, then this is doable. Maintaining changes all over all the > fast moving packages that are in the full Pharo, then I agree with you, > Esteban. > > >> Pavel and Christophe are working on the bootstrap process who should be >> working in one-two months, with that, building custom images will be >> finally a realityâ¦from there you might want to give it a try. >> > > This, given the timeframe, is both an excellent suggestion and good to > know :) > > >> But I would better invest on document (something that you have been doing >> very well and Iâm very thankful for that) than in keeping alive what is, in >> fact, a fork. >> > > Racing to document all the fast moving packages in Pharo can really be a > challenge, still. > > Thierry > > >> >> cheers, >> Esteban >> >> >> Thierry >> >> >> >> >>> >>> I would hate to replicate what is already done. >>> >>> On Tue, May 24, 2016 at 3:59 PM Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> On Tue, May 24, 2016 at 7:01 PM, Dimitris Chloupis >>>> <kilon.alios(a)gmail.com> wrote: >>>> > So I was reading the complains from Sven and got Inspiration from >>>> Torsten >>>> > Pharo image and CUIs and made me wonder what if we had an image which >>>> has >>>> > the least amount of libraries and every library inside it is full >>>> commented >>>> > in class, package and method and even has tutorial using inside help >>>> tool. >>>> > >>>> > So I think I will give this project a try. I know there is a plan to >>>> make >>>> > pharo image more modular, but modularity does not equal minimalism , >>>> > simplicity and ease of use. >>>> > >>>> > I think I will follow the CUIs example and do the development via >>>> Github. >>>> > >>>> > But I am open to ideas and suggestions. >>>> > >>>> > My intention is to remove the excess fat, to make Pharo prettier >>>> (improve >>>> > theme support and make available several themes ) and to have >>>> everything >>>> > commented and self documented. >>>> > >>>> > Obviously this will be a long term project and in no way a walk in >>>> the park >>>> > but I was looking for a nice project to name "Ephestos" :D seem as >>>> good as >>>> > any >>>> >>>> Did this project not pane out?... >>>> >>>> https://pharoweekly.wordpress.com/2014/07/16/ephestos-using-and-coding-blen… >>>> >>>> Seems you're quite attached to that name :) >>>> but is there a minor chance of confusion? >>>> >>>> cheers -ben >>>> >>>> >> >>

May 24, 2016

Re: [Pharo-users] Retina support in Pharo

by Yuriy Tymchuk

You can also open an info window about the Pharo.app and check the âOpen in low resolutionâ box. Then you will have a real pixelated graphics and now blurry (which can be annoying). Cheers. Uko > On 17 May 2016, at 22:21, Damien Pollet <damien.pollet+pharo(a)gmail.com> wrote: > > On 17 May 2016 at 22:14, Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > My email was _not_ about judging the community effort, but more on whether pharo work on a Retina laptop. > What happens if Pharo is launched on a retina computer? > > You get the same thing as on a non-retina display, except instead of each fuzzy pixel you get a visibly sharper square made of 2Ã2 retina pixels. From sufficiently far away there's no difference, but when you're right in front of it you can see the pixelation, especially for text and compared to HiDPI-enabled apps in nearby windows.

May 24, 2016

Re: [Pharo-users] parameters of the virtual machine

by ClÃ©ment Bera

Hi, Sorry the mail is quite long... I CC'd Nevena for section II, she used the VM caches for type inference. *Section I. VM parameters* * 46 size of machine code zone, in bytes* Well, the size of the machine code zone :-). To speed-up execution, the cog uses internally a JIT compiler which translates to machine code frequently used bytecoded method and run the machine code to execute them instead of using the interpreter. The machine code zone is an executable memory zone containing all the machine code versions of methods. The default size should be between 1Mb and 2Mb for standard applications. If memory is a constraint, it can be lowered down to 750kb, under that you should use the stack VM else the performance starts to drastically decrease. This setting is useful to tune your application performance. For example, on compilation-intensive benchs, 750kb is the optimal machine code zone size. On large benchmarks, 2 Mb, maybe more, is better, but then one may see machine code garbage collection pauses. On small benchs all the methods fit into this zone so it doesn't really matter. Growing the machine code zone: - increase the number of methods that can be present there, hence decreasing machine code zone garbage collection frequency and method jit compilation. - decrease the machine code zone to cpu instruction cache mapping - slow down machine code zone garbage collection To set the machine code zone you need to use another parameter (47 I think) and restart the VM+image. * 59 number of check event calls since startup (read-only)* If I remember correctly, the number of times the VM has checked for OS events since start-up. * 60 number of stack page overflows since startup (read-only; Cog VMs only) 61 number of stack page divorces since startup (read-only; Cog VMs only)* This is related to stack page management. Read the Cog blog to understand how it's done. See http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the… section Stack pages. *Section II. Accessing the caches* *Is there a way to get access to the cache? How many caches does Cog has? I guess it has - a method call cache (associating (object,symbol) -> compiled method - a cache for the JIT-compiled methods right?* *Are there other cache? How can I access them? In particular to query about their fill.* There is indeed a global look-up cache, mapping (receiver type, symbol) -> (compiled method, primitive function pointer). In the jitted methods there are per send-sites look-up caches, also known as inline caches. The most useful is the inline cache values, they provide the receiver types met for each send site and are fairly reliable. There are ways to access those caches. I personally use those caches values for the runtime optimizing compiler, but more recently I worked with Nevena Milojkovic (I CC'd her) and she was able to use those cache values for type inference, while she is not a VM expert. We wrote an IWST paper about that, hopefully it'll get accepted and you will be able to read it. In the IWST paper I sum-up Eliot's implementation of inline caches and how the VM provides the types. In short, to access the caches: 1) add those primitives: VirtualMachine>>allMachineCodeMethods <primitive: 'primitiveAllMethodsCompiledToMachineCode' module:''> ^#() CompiledMethod>>sendAndBranchData <primitive: 'primitiveSistaMethodPICAndCounterData' module:''> ^#() 2) add glue code to map caches values from bytecode pc to the AST, something like that: CompiledMethod>>astWithCacheAnnotations | tmp1 | tmp1 := self sendAndBranchData. tmp1 ifEmpty: [ 'No data' logCr. ^ self ast ]; do: [ :arg1 | (self sourceNodeForPC: arg1 first) propertyAt: #cacheInformation put: arg1 allButFirst ]. ^ self ast 3) Compile the VM with the SistaCogit and SistaVM=true (Slang compilation settings). I guess you could read our IWST paper, that would help. I don't know if that's possible before the reviewers answer. Don't build production tools using those values though, the VM is evolving and the cache values may vary in the future with the sista optimizer. Regards, Clement On Tue, May 24, 2016 at 5:39 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi, > > The Cog virtual machine expose some very useful parameters. However, some > of them are a bit obscure to me. For example, what are the following > parameters? What do they mean? > > 46 size of machine code zone, in bytes > 59 number of check event calls since startup > (read-only) > 60 number of stack page overflows since startup > (read-only; Cog VMs only) > 61 number of stack page divorces since startup > (read-only; Cog VMs only) > > Is there a way to get access to the cache? How many caches does Cog has? I > guess it has > - a method call cache (associating (object,symbol) -> compiled > method > - a cache for the JIT-compiled methods right? > > Are there other cache? How can I access them? In particular to query about > their fill. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

May 24, 2016

Re: [Pharo-users] Developer and guide needed for Pharo+Seaside business application

by Esteban A. Maringolo

Hi Sanjay, I sent an email to the referenced address. Regards. -- Esteban -- View this message in context: http://forum.world.st/Developer-and-guide-needed-for-Pharo-Seaside-business… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 24, 2016

parameters of the virtual machine

by Alexandre Bergel

Hi, The Cog virtual machine expose some very useful parameters. However, some of them are a bit obscure to me. For example, what are the following parameters? What do they mean? 46 size of machine code zone, in bytes 59 number of check event calls since startup (read-only) 60 number of stack page overflows since startup (read-only; Cog VMs only) 61 number of stack page divorces since startup (read-only; Cog VMs only) Is there a way to get access to the cache? How many caches does Cog has? I guess it has - a method call cache (associating (object,symbol) -> compiled method - a cache for the JIT-compiled methods right? Are there other cache? How can I access them? In particular to query about their fill. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 24, 2016

Re: [Pharo-users] [Article] Speeding up factorial computation by changing the order of multiplications

by Henrik Johansen

For the specially interested, there's also this fun thread from some years ago: http://forum.world.st/Challenge-Tuning-the-large-factorial-td3588660.html <http://forum.world.st/Challenge-Tuning-the-large-factorial-td3588660.html> Cheers, Henry > On 24 May 2016, at 9:57 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I just published a short, introduction level article, > > Speeding up factorial computation by changing the order of multiplications. > > This is a story about a small, seemingly innocent code change that speeds up a very simple computation. It is pretty magical and serves as an example of how things are not always what they seem. > > https://medium.com/concerning-pharo/speeding-up-factorial-computation-by-ch… > > Enjoy, > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > >

May 24, 2016

Re: [Pharo-users] An Idea for a minimal self documented begineer friendly pharo image

by Thierry Goubier

2016-05-24 16:18 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 24 May 2016, at 16:11, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > 2016-05-24 15:18 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > >> Well technically the python part works fine, BUT I also always wanted it >> to be friendly to begineers . So nope , its same project. And you are >> correct its still focused in coding 3d graphics but I came to realisation >> that if I want some people to use it, obviously i dont expect the massive >> majority to give up the comforts of python but for those that are curious I >> have to provide an enviroment thats is even easier to code in than python >> is currently for Blender. >> >> My goal is to provide a development enviroment for Blender addons that is >> simple, and easy to use and learn. >> >> So providing a minimal pharo image that is self documented has always >> being a dream for Ephestos. >> >> By the way whats the news on the matter of modular pharo image ? Is there >> any work done to provide a minimal pharo image ? >> > > There is a minimal image, which is I think usable as-is, except that what > you want is something in between the minimal image (no gui, no tools) and a > full image, and that is a bit complex to set-up. > > I started some work on doing that with Pharo4 (put a place with baselines > I could use to load the HEAD of the Pharo main repository and load the > right packages), but Pharo5 changed the way external projects are included, > and my approach wasn't good anymore. > > I think the overall Pharo organisation could benefit from such an effort; > it would exercise all the planned mechanisms for the modular image, in > maybe an easier way than a modular full image, and with someone motivated > to debug and maintain the process: you! > > > honestly, I wouldnât. > working in a parallel image is too much work (believe me, I know something > about keeping an image going). > Well, I am technically working in a parallel image for the past ... 3 years ? So, no, as long as you handle a changing minimal image and a well mastered set of slow changing packages over it, it is doable. The base Pharo isn't changing much. As long as you don't use what is changing a lot, then this is doable. Maintaining changes all over all the fast moving packages that are in the full Pharo, then I agree with you, Esteban. > Pavel and Christophe are working on the bootstrap process who should be > working in one-two months, with that, building custom images will be > finally a realityâ¦from there you might want to give it a try. > This, given the timeframe, is both an excellent suggestion and good to know :) > But I would better invest on document (something that you have been doing > very well and Iâm very thankful for that) than in keeping alive what is, in > fact, a fork. > Racing to document all the fast moving packages in Pharo can really be a challenge, still. Thierry > > cheers, > Esteban > > > Thierry > > > > >> >> I would hate to replicate what is already done. >> >> On Tue, May 24, 2016 at 3:59 PM Ben Coman <btc(a)openinworld.com> wrote: >> >>> On Tue, May 24, 2016 at 7:01 PM, Dimitris Chloupis >>> <kilon.alios(a)gmail.com> wrote: >>> > So I was reading the complains from Sven and got Inspiration from >>> Torsten >>> > Pharo image and CUIs and made me wonder what if we had an image which >>> has >>> > the least amount of libraries and every library inside it is full >>> commented >>> > in class, package and method and even has tutorial using inside help >>> tool. >>> > >>> > So I think I will give this project a try. I know there is a plan to >>> make >>> > pharo image more modular, but modularity does not equal minimalism , >>> > simplicity and ease of use. >>> > >>> > I think I will follow the CUIs example and do the development via >>> Github. >>> > >>> > But I am open to ideas and suggestions. >>> > >>> > My intention is to remove the excess fat, to make Pharo prettier >>> (improve >>> > theme support and make available several themes ) and to have >>> everything >>> > commented and self documented. >>> > >>> > Obviously this will be a long term project and in no way a walk in the >>> park >>> > but I was looking for a nice project to name "Ephestos" :D seem as >>> good as >>> > any >>> >>> Did this project not pane out?... >>> >>> https://pharoweekly.wordpress.com/2014/07/16/ephestos-using-and-coding-blen… >>> >>> Seems you're quite attached to that name :) >>> but is there a minor chance of confusion? >>> >>> cheers -ben >>> >>> > >

May 24, 2016