March 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Migration from Pharo 1.1 to 2.0

by Mariano Martinez Peck

Fuel works from 1.1.1 to 3.0: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.9/Documentation/… If I remember correctly.... 1.1.1 was just same image but with support for cog right? in such a case, it is likely it should work for 1.1 as well. You can give it a try. Cheers, On Mon, Mar 24, 2014 at 5:37 PM, Laurent Laffont <laurent.laffont(a)gmail.com>wrote: > Hi, > > is there a way to export / fileOut objects from Pharo 1.1 and reload them > into Pharo 2.0 or 3.0 ? > > Cheers, > > Laurent > > -- Mariano http://marianopeck.wordpress.com

March 24, 2014

Migration from Pharo 1.1 to 2.0

by Laurent Laffont

Hi, is there a way to export / fileOut objects from Pharo 1.1 and reload them into Pharo 2.0 or 3.0 ? Cheers, Laurent

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Alexandre Bergel

>> I am working on a memory model for expandable collection in Pharo. Currently, OrderedCollection, Dictionary and other expandable collections use a internal array to store their data. My new collection library recycle these array instead of letting the garbage collector dispose them. I simply insert the arrays in an ordered collection when an array is not necessary anymore. And I remove one when I need one. > > Hm, is that really going to be worth the trouble? This technique reduces the consumption of about 15% of memory. >> At the end, #add: and #remove: are performed on these polls of arrays. I havenât been able to spot any problem regarding concurrency and I made no effort in preventing them. I have a simple global collection and each call site of "OrderedCollection newâ can pick an element of my global collection. >> >> I have the impression that I simply need to guard the access to the global poll, which is basically guarding #add: #remove: and #includes: > > One of the AtomicCollections might be the right things for you? I will have a look at it. >> What is funny, is that I did not care at all about multi-threading and concurrency, and I have not spotted any problem so far. > > There isnât any âmulti-threadingâ like in Java, you got a much more control version: cooperative on the same priority, preemptive between priorities. > So, I am not surprised. And well, these operations are likely not to be problematic when they are racy, except when the underling data structure could get into an inconsistent state itself. The overall operations (adding/removing/searing) are racy on the application level anyway. > > However, much more interesting would be to know what kind of benefit do you see for such reuse? > And especially, with Spur around the corner, will it still pay off then? Or is it an application-specific optimization? I am exploring a new design of the collection library of Pharo. Not all the (academic) ideas will be worth porting into the mainstream of Pharo. But some of them yes. Thanks for all your help guys! Youâre great! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Stefan Marr

Hi Alexandre: On 24 Mar 2014, at 19:57, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > I am working on a memory model for expandable collection in Pharo. Currently, OrderedCollection, Dictionary and other expandable collections use a internal array to store their data. My new collection library recycle these array instead of letting the garbage collector dispose them. I simply insert the arrays in an ordered collection when an array is not necessary anymore. And I remove one when I need one. Hm, is that really going to be worth the trouble? > At the end, #add: and #remove: are performed on these polls of arrays. I havenât been able to spot any problem regarding concurrency and I made no effort in preventing them. I have a simple global collection and each call site of "OrderedCollection newâ can pick an element of my global collection. > > I have the impression that I simply need to guard the access to the global poll, which is basically guarding #add: #remove: and #includes: One of the AtomicCollections might be the right things for you? > What is funny, is that I did not care at all about multi-threading and concurrency, and I have not spotted any problem so far. There isnât any âmulti-threadingâ like in Java, you got a much more control version: cooperative on the same priority, preemptive between priorities. So, I am not surprised. And well, these operations are likely not to be problematic when they are racy, except when the underling data structure could get into an inconsistent state itself. The overall operations (adding/removing/searing) are racy on the application level anyway. However, much more interesting would be to know what kind of benefit do you see for such reuse? And especially, with Spur around the corner, will it still pay off then? Or is it an application-specific optimization? Best regards Stefan > > Alexandre > > >> >> >> Best regards >> Stefan >> >> -- >> Stefan Marr >> INRIA Lille - Nord Europe >> http://stefan-marr.de/research/ >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Alexandre Bergel

> Just out of curiosity, why do you do that? I would say is better throw them away (in most cases) Just for the sake of publishing original ideas :-) Joking :-) The VM is considering expandable collections as simple objects, and this has a cost in terms of memory and CPU consumption. I will be able to say more at esug hopefully. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Jan Vrany

On 24/03/14 18:57, Alexandre Bergel wrote: >>> Any idea what is the cost of using a semaphore? Inserting the >>> expression "anOrderedCollection add: 42â in a semaphore surely >>> make the expression slower. Any idea how much slower? >> >> Can you elaborate a little on the problem. > > I am working on a memory model for expandable collection in Pharo. > Currently, OrderedCollection, Dictionary and other expandable > collections use a internal array to store their data. My new > collection library recycle these array instead of letting the garbage > collector dispose them. I simply insert the arrays in an ordered > collection when an array is not necessary anymore. And I remove one > when I need one. > Just out of curiosity, why do you do that? I would say is better throw them away (in most cases) Jan

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Alexandre Bergel

>> Any idea what is the cost of using a semaphore? Inserting the expression "anOrderedCollection add: 42â in a semaphore surely make the expression slower. Any idea how much slower? > > Can you elaborate a little on the problem. I am working on a memory model for expandable collection in Pharo. Currently, OrderedCollection, Dictionary and other expandable collections use a internal array to store their data. My new collection library recycle these array instead of letting the garbage collector dispose them. I simply insert the arrays in an ordered collection when an array is not necessary anymore. And I remove one when I need one. At the end, #add: and #remove: are performed on these polls of arrays. I havenât been able to spot any problem regarding concurrency and I made no effort in preventing them. I have a simple global collection and each call site of "OrderedCollection newâ can pick an element of my global collection. I have the impression that I simply need to guard the access to the global poll, which is basically guarding #add: #remove: and #includes: > Your granularity does not seem to be of the right level. > Covering a single #add: operations is most probably rather fine grained, and might not give you the guarantees you would expect. > What exactly do you want to achieve? > How many Smalltalk processes are interacting with that collection? How many consumer/producer do you have? Basically, all the processes may access my global polls by inserting or removing elements. > And well, on the standard priority, you normally got cooperative scheduling anyway. So, it depends on what you are doing whether there is a real issue. > And if you donât want to use a semaphore, there are also other mechanism. I think, there should be something like âexecute uninterruptibleâ for a block. Think that raises the priority of the processes to the highest level for the execution of the block, if I remember correctly. What is funny, is that I did not care at all about multi-threading and concurrency, and I have not spotted any problem so far. Alexandre > > > Best regards > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Jan Vrany

On 24/03/14 18:20, Alexandre Bergel wrote: >>> My current understanding about thread is that there is a scheduling that may occurs each time we enter the VM (e.g., primitive call, instantiating an object, throwing an exception). So, the code "anOrderedCollection add: 42â will _never_ suffer from concurrent call because adding 42 to a collection does not enter the VM. Does this make sense? >> >> I don't think so. AFAIK interrupts are checked on message sends and on >> backward jumps (because of inlined loops just like in your example). >> >> So context switch may happen on each send... > > Ah yes!! I missed this case. > Any idea what is the cost of using a semaphore? Inserting the expression "anOrderedCollection add: 42â in a semaphore surely make the expression slower. Any idea how much slower? > Not really sure, since #signal and #wait are primitives, but simple benchmark should do it :-) However, you may want to use recursion lock (sometimes called monitor - in Pharo class Monitor) which allows for recursion. Otherwise you may get a nice deadlock if your code recurs. Cost of recursion lock could be reduced to couple machine instructions (if there's no contention), if done properly. The implementation of Monitor in Pharo seems to be way, way more costly than few instructions. Jan

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Stefan Marr

Hi Alexandre: On 24 Mar 2014, at 19:20, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Any idea what is the cost of using a semaphore? Inserting the expression "anOrderedCollection add: 42â in a semaphore surely make the expression slower. Any idea how much slower? Can you elaborate a little on the problem. Your granularity does not seem to be of the right level. Covering a single #add: operations is most probably rather fine grained, and might not give you the guarantees you would expect. What exactly do you want to achieve? How many Smalltalk processes are interacting with that collection? How many consumer/producer do you have? And well, on the standard priority, you normally got cooperative scheduling anyway. So, it depends on what you are doing whether there is a real issue. And if you donât want to use a semaphore, there are also other mechanism. I think, there should be something like âexecute uninterruptibleâ for a block. Think that raises the priority of the processes to the highest level for the execution of the block, if I remember correctly. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Alexandre Bergel

>> My current understanding about thread is that there is a scheduling that may occurs each time we enter the VM (e.g., primitive call, instantiating an object, throwing an exception). So, the code "anOrderedCollection add: 42â will _never_ suffer from concurrent call because adding 42 to a collection does not enter the VM. Does this make sense? > > I don't think so. AFAIK interrupts are checked on message sends and on > backward jumps (because of inlined loops just like in your example). > > So context switch may happen on each send... Ah yes!! I missed this case. Any idea what is the cost of using a semaphore? Inserting the expression "anOrderedCollection add: 42â in a semaphore surely make the expression slower. Any idea how much slower? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 24, 2014