> On 10 Nov 2016, at 17:35, Aliaksei Syrel <[email protected]> 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" <[email protected]> wrote: > > > On 10 November 2016 at 11:42, Tudor Girba <[email protected]> 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.
