November 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Sven Van Caekenberghe

> On 10 Nov 2016, at 17:35, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > > The speed of GC will always be in linear dependency from the size of governed memory. > > Asymptotic complexity of GC is O(N), where N is heap size - amount of objects, not memory size. Even that is not necessarily true, Generational Garbage collection and other tricks can avoid a full heap GC for a long time, even (or especially) under memory allocation stress. Apart from that, of course we have to write the most resource efficient code that we can ! > I agree, however, that it's not good to create a lot of short living objects. That is why there are many practices how to overcome this problem. For example Object Pool can be nice example. > > Nevertheless I can imagine many usecasses when breaking 4GB limit is useful. For example double buffering during rendering process. 1 pixel takes 32bit of memory => 8k image (near future displays) would take 126Mb of memory. Double buffering would be useful for Roassal (huge zoomed out visualization). > > Storing 126Mb array object takes a lot of memory but does not influence on GC performance since it is just one object on the heap. > > Cheers > Alex > > > On Nov 10, 2016 5:02 PM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: > > > On 10 November 2016 at 11:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Igor, > > I am happy to see you getting active again. The next step is to commit code at the rate you reply emails. Iâd be even happier :). > > To address your point, of course it certainly would be great to have more people work on automated support for swapping data in and out of the image. That was the original idea behind the Fuel work. I have seen a couple of cases on the mailing lists where people are actually using Fuel for caching purposes. I have done this a couple of times, too. But, at this point these are dedicated solutions and would be interesting to see it expand further. > > However, your assumption is that the best design is one that deals with small chunks of data at a time. This made a lot of sense when memory was expensive and small. But, these days the cost is going down very rapidly, and sizes of 128+ GB of RAM is nowadays quite cheap, and there are strong signs of super large non-volatile memories become increasingly accessible. The software design should take advantage of what hardware offers, so it is not unreasonable to want to have a GC that can deal with large size. > > The speed of GC will always be in linear dependency from the size of governed memory. Yes, yes.. super fast and super clever, made by some wizard.. but still same dependency. > So, it will be always in your interest to keep memory footprint as small as possible. PERIOD. > > We should always challenge the assumptions behind our designs, because the world keeps changing and we risk becoming irrelevant, a syndrome that is not foreign to Smalltalk aficionados. > > > What you saying is just: okay, we have a problem here, we hit a wall.. But we don't look for solutions! Instead let us sit and wait till someone else will be so generous to help with it. > WOW, what a brilliant strategy!! > So, you putting fate of your project(s) into hands of 3-rd party, which > a) maybe , only maybe will work to solve your problem in next 10 years > b) may decide it not worth effort right now(never) and focus on something else, because they have own priorities after all > > Are you serious? > "Our furniture don't fits in modern truck(s), so let us wait will industry invent bigger trucks, build larger roads and then we will move" Hilarious! > > In that case, the problem that you arising is not that mission-critical to you, and thus making constant noise about your problem(s) is just what it is: a noise. > Which returns us to my original mail with offensive tone. > > > Cheers, > Doru > > > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be done." > > > > > > -- > Best regards, > Igor Stasenko.

Nov. 10, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Aliaksei Syrel

> The speed of GC will always be in linear dependency from the size of governed memory. Asymptotic complexity of GC is O(N), where N is heap size - amount of objects, not memory size. I agree, however, that it's not good to create a lot of short living objects. That is why there are many practices how to overcome this problem. For example Object Pool can be nice example. Nevertheless I can imagine many usecasses when breaking 4GB limit is useful. For example double buffering during rendering process. 1 pixel takes 32bit of memory => 8k image (near future displays) would take 126Mb of memory. Double buffering would be useful for Roassal (huge zoomed out visualization). Storing 126Mb array object takes a lot of memory but does not influence on GC performance since it is just one object on the heap. Cheers Alex On Nov 10, 2016 5:02 PM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: > > > On 10 November 2016 at 11:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi Igor, >> >> I am happy to see you getting active again. The next step is to commit >> code at the rate you reply emails. Iâd be even happier :). >> > >> To address your point, of course it certainly would be great to have more >> people work on automated support for swapping data in and out of the image. >> That was the original idea behind the Fuel work. I have seen a couple of >> cases on the mailing lists where people are actually using Fuel for caching >> purposes. I have done this a couple of times, too. But, at this point these >> are dedicated solutions and would be interesting to see it expand further. >> >> However, your assumption is that the best design is one that deals with >> small chunks of data at a time. This made a lot of sense when memory was >> expensive and small. But, these days the cost is going down very rapidly, >> and sizes of 128+ GB of RAM is nowadays quite cheap, and there are strong >> signs of super large non-volatile memories become increasingly accessible. >> The software design should take advantage of what hardware offers, so it is >> not unreasonable to want to have a GC that can deal with large size. >> >> The speed of GC will always be in linear dependency from the size of > governed memory. Yes, yes.. super fast and super clever, made by some > wizard.. but still same dependency. > So, it will be always in your interest to keep memory footprint as small > as possible. PERIOD. > > >> We should always challenge the assumptions behind our designs, because >> the world keeps changing and we risk becoming irrelevant, a syndrome that >> is not foreign to Smalltalk aficionados. >> >> > What you saying is just: okay, we have a problem here, we hit a wall.. But > we don't look for solutions! Instead let us sit and wait till someone else > will be so generous to help with it. > WOW, what a brilliant strategy!! > So, you putting fate of your project(s) into hands of 3-rd party, which > a) maybe , only maybe will work to solve your problem in next 10 years > b) may decide it not worth effort right now(never) and focus on something > else, because they have own priorities after all > > Are you serious? > "Our furniture don't fits in modern truck(s), so let us wait will industry > invent bigger trucks, build larger roads and then we will move" Hilarious! > > In that case, the problem that you arising is not that mission-critical to > you, and thus making constant noise about your problem(s) is just what it > is: a noise. > Which returns us to my original mail with offensive tone. > > > Cheers, >> Doru >> >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Not knowing how to do something is not an argument for how it cannot be >> done." >> >> >> > > > -- > Best regards, > Igor Stasenko. >

Nov. 10, 2016

Re: [Pharo-dev] OpalEncoderForV3PlusClosures error

by Thierry Goubier

2016-11-10 17:28 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > Too many statements probably (e.g. a lot of branches). > I suspected that. Many, many loops over arrays of arrays of arrays of float, no branches. Thierry > > Max > > > On 10 Nov 2016, at 17:11, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > I've got a compilation error which is: > > > > genJumpLong: distance index -1504 is out of range -1024 to 1023 > > > > What does it mean? I'm on Pharo6 64 bits. > > > > Thierry > > >

Nov. 10, 2016

Re: [Pharo-dev] OpalEncoderForV3PlusClosures error

by Max Leske

Too many statements probably (e.g. a lot of branches). Max > On 10 Nov 2016, at 17:11, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > I've got a compilation error which is: > > genJumpLong: distance index -1504 is out of range -1024 to 1023 > > What does it mean? I'm on Pharo6 64 bits. > > Thierry

Nov. 10, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Sven Van Caekenberghe

> On 28 Oct 2016, at 11:56, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Image here: http://files.pharo.org/get-files/60/pharo-64.zip In the above image I get the following output on the Transcript while sending #ast to all methods AthensCairoGradientPaint>>initializeRadialBetween:extending:and:extending:withColorRamp:(origin is shadowed) DynamicSpecExample>>openOnString(ui is shadowed) DynamicSpecExample>>openOnInteger(ui is shadowed) ExternalForm>>setExtent:depth:bits:(pointer is shadowed) ExternalForm>>primCreateManualSurfaceWidth:height:rowPitch:depth:isMSB:(width is shadowed) ExternalForm>>primCreateManualSurfaceWidth:height:rowPitch:depth:isMSB:(height is shadowed) ExternalForm>>primCreateManualSurfaceWidth:height:rowPitch:depth:isMSB:(depth is shadowed) ExternalForm>>primManualSurface:setPointer:(pointer is shadowed) ExternalType>>asPointerType:(pointerSize is shadowed) RBRefactoryTestDataApp>>tempVarOverridesInstVar(temporaryVariable is shadowed) RBSmalllintTestObject>>tempVarOverridesInstVar(temporaryVariable is shadowed) TraitDescription>>fileOutLocalMethodsInCategory:on:(localSelectors is shadowed) Just to let you know, Sven

Nov. 10, 2016

Re: [Pharo-dev] Please test new VMs (round one)

by Sven Van Caekenberghe

What is your exact question ? > On 10 Nov 2016, at 16:31, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > Anyone? > > > 2016-11-09 14:17 GMT-03:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > > > 2016-11-09 8:00 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi guys, > > I want to start moving the VM stuff into the new structure. Now I know there are still missing things :) > Can you download a VM from here: https://bintray.com/estebanlm/pharo-vm/build/201611082123#files > > and start using it, and report problems? > > thanks! > Esteban > > ps: Windows users: Iâm still not there, Iâm having problems to build third-party libraries with cygwinâ¦ also if someone can help me here I would thank it :) > > > I can help, let me know how can I reproduce those problems > > HernÃ¡n > >

Nov. 10, 2016

OpalEncoderForV3PlusClosures error

by Thierry Goubier

I've got a compilation error which is: genJumpLong: distance index -1504 is out of range -1024 to 1023 What does it mean? I'm on Pharo6 64 bits. Thierry

Nov. 10, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Igor Stasenko

On 10 November 2016 at 11:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Igor, > > I am happy to see you getting active again. The next step is to commit > code at the rate you reply emails. Iâd be even happier :). > > To address your point, of course it certainly would be great to have more > people work on automated support for swapping data in and out of the image. > That was the original idea behind the Fuel work. I have seen a couple of > cases on the mailing lists where people are actually using Fuel for caching > purposes. I have done this a couple of times, too. But, at this point these > are dedicated solutions and would be interesting to see it expand further. > > However, your assumption is that the best design is one that deals with > small chunks of data at a time. This made a lot of sense when memory was > expensive and small. But, these days the cost is going down very rapidly, > and sizes of 128+ GB of RAM is nowadays quite cheap, and there are strong > signs of super large non-volatile memories become increasingly accessible. > The software design should take advantage of what hardware offers, so it is > not unreasonable to want to have a GC that can deal with large size. > > The speed of GC will always be in linear dependency from the size of governed memory. Yes, yes.. super fast and super clever, made by some wizard.. but still same dependency. So, it will be always in your interest to keep memory footprint as small as possible. PERIOD. > We should always challenge the assumptions behind our designs, because the > world keeps changing and we risk becoming irrelevant, a syndrome that is > not foreign to Smalltalk aficionados. > > What you saying is just: okay, we have a problem here, we hit a wall.. But we don't look for solutions! Instead let us sit and wait till someone else will be so generous to help with it. WOW, what a brilliant strategy!! So, you putting fate of your project(s) into hands of 3-rd party, which a) maybe , only maybe will work to solve your problem in next 10 years b) may decide it not worth effort right now(never) and focus on something else, because they have own priorities after all Are you serious? "Our furniture don't fits in modern truck(s), so let us wait will industry invent bigger trucks, build larger roads and then we will move" Hilarious! In that case, the problem that you arising is not that mission-critical to you, and thus making constant noise about your problem(s) is just what it is: a noise. Which returns us to my original mail with offensive tone. Cheers, > Doru > > > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be > done." > > > -- Best regards, Igor Stasenko.

Nov. 10, 2016

Re: [Pharo-dev] Please test new VMs (round one)

by HernÃ¡n Morales Durand

Anyone? 2016-11-09 14:17 GMT-03:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > > > 2016-11-09 8:00 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> Hi guys, >> >> I want to start moving the VM stuff into the new structure. Now I know >> there are still missing things :) >> Can you download a VM from here: https://bintray.com/este >> banlm/pharo-vm/build/201611082123#files >> >> and start using it, and report problems? >> >> thanks! >> Esteban >> >> ps: Windows users: Iâm still not there, Iâm having problems to build >> third-party libraries with cygwinâ¦ also if someone can help me here I would >> thank it :) >> > > > I can help, let me know how can I reproduce those problems > > HernÃ¡n > >

Nov. 10, 2016

Re: [Pharo-dev] [ANN] Pharo Association has a new Website!

by Marcus Denker

> On 10 Nov 2016, at 14:44, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > Great! > > What do we do with the current BountySource salt? > (https://salt.bountysource.com/teams/pharo) > Should we move directly to the new Wild Apricot backend? > Salt is just one payment possibiliy. Salt is a bit strange, e.g. we do not get any information about new sponsors there. No email, nothing. So it is a bit hard to keep up, but we will just send mails to all sponsors there telling them to tell us. When they are then in and the bill gets send, the salt sponsorship again is the payment and the bill is accepted as payed. > Accepting Bitcoin payments would be a plus ;-) (https://bitpay.com/tour) > Like everything, we just set up the abolute minimum to get this going. This means for payment we just enabled Paypal. The backing supports â¢ 2Checkout â¢ Authorize.Net â¢ BluePay â beta â¢ Global Payments â beta â¢ iATS Payments â beta â¢ Moneris â¢ PayPal Payflow Pro â beta â¢ PayPal Payments Advanced â beta â¢ PayPal Payments Standard â¢ PayPal Express Checkout â¢ PayPal Payments Pro â¢ Skrill â beta â¢ Stripe â beta and via CRE Secure even more. I have not looked into this at all. There is a lot that one could do, I will collect all suggestions, but we need to see, too, that every tiny one of them takes effort to make real. Marcus

Nov. 10, 2016