Is the Right Tool a Matter of Preference?

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

User avatar
Sc4Freak
Posts: 673
Joined: Thu Jul 12, 2007 4:50 am UTC
Location: Redmond, Washington

Re: Is the Right Tool a Matter of Preference?

Postby Sc4Freak » Tue Jul 24, 2012 7:05 pm UTC

WarDaft wrote:Of course memory management makes coding faster. Imagine C, exactly as it is, except now it's memory managed. All the time you've ever spent debugging memory leaks and segfaults just basically vanished. How is that not making you more productive?

Because there's no such thing as a free lunch. C is a systems programming language - if a kernel is written in "managed C" which then turns out to be too slow, does the engineering effort to optimize it outweigh the benefit? What about the nondeterminism you've introduced, how many problems is that going to cause? What about your real-time guarantees - do you just throw those out the window?

There has always been the argument that high-level languages often trade performance for programmer time (which then arguably allows for more time spent performing optimizations). But that's always a tradeoff. No doubt managed languages may make you more productive in the short term, but automatic memory management isn't free and can have associated long-term costs.

User avatar
WarDaft
Posts: 1583
Joined: Thu Jul 30, 2009 3:16 pm UTC

Re: Is the Right Tool a Matter of Preference?

Postby WarDaft » Tue Jul 24, 2012 7:47 pm UTC

That is rather dependent on the implementation of the memory management, so I can't give blanket answers to that specific a question. They are all good reasons to have a memory management model the programmer can have input in however, just not free have reign of it. That's actually one thing I feel is really lacking in most functional languages, why can't I tell it that this should be discarded ASAP, offer it a proof that certain things just aren't needed, or that something should stick around for a while longer than it otherwise would have been allowed to? Don't actually allow any errors, only optimization.
All Shadow priest spells that deal Fire damage now appear green.
Big freaky cereal boxes of death.

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Tue Jul 24, 2012 8:53 pm UTC

Sc4Freak wrote:There has always been the argument that high-level languages often trade performance for programmer time (which then arguably allows for more time spent performing optimizations). But that's always a tradeoff. No doubt managed languages may make you more productive in the short term, but automatic memory management isn't free and can have associated long-term costs.

I was just reading a blog yesterday about this... Back in the day (the argument goes) CGI scripts were written in C. This was all very good because the internet was a new and exciting place, and most pages were static HTML anyways. And then the perl hackers came along and starting hacking together CGI scripts in perl. The C programmers railed against the very idea: "You can't write efficient code in perl!" they screamed. But as it turns out, perl is a language designed for text processing, and the internet was built upon text so it worked pretty well. And while the C folks were bitterly resisting perl, the perl (and python, and php) folks were building the internet.

So stick with C if you want, but in the real world, high-level languages are more profitable.

User avatar
Xeio
Friends, Faidites, Countrymen
Posts: 5101
Joined: Wed Jul 25, 2007 11:12 am UTC
Location: C:\Users\Xeio\
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby Xeio » Tue Jul 24, 2012 9:12 pm UTC

sourmìlk wrote:With a garbage collected language, infinite coding time will never achieve the same efficiency as an unmanaged one in cases where memory is scarce.
Doesn't matter, nobody has infinite development time, they do happen to have oodles of memory though (especially given the memory requirements of your average application).

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Tue Jul 24, 2012 9:45 pm UTC

Xeio wrote:
sourmìlk wrote:With a garbage collected language, infinite coding time will never achieve the same efficiency as an unmanaged one in cases where memory is scarce.
Doesn't matter, nobody has infinite development time, they do happen to have oodles of memory though (especially given the memory requirements of your average application).

Okay, that's not fair. There are too many kinds of programming for that kind of blanket to be meaningful.


For everyday applications programming, I agree wholeheartedly: memory and clock cycles aren't scarce, so choose tools to minimize development time.

For game programming (as the OP is primarily interested in for mind-baffling reasons), both matter. Of course, graphics commands will just be sent to the GPU anyways, and there's no need to work with only a single language.

For systems programming, garbage collection isn't an option because it is the GC (in a manner of speaking).

For "enterprise" development, it's a tradeoff. There are really expensive servers, and costly staff. I suspect that most of the time upgrading the servers is more worthwhile than paying for additional programmers.

For "large computations", speed and memory will be everything, as it will be "code once, run on thousands of machines". Extra time optimizing may easily be worthwhile if it means spending a million dollars less on the server farm.


This is why we have so many tools. But functional programming still provides some of the most powerful tools in the box, even for the really constrained scenarios.

User avatar
Xeio
Friends, Faidites, Countrymen
Posts: 5101
Joined: Wed Jul 25, 2007 11:12 am UTC
Location: C:\Users\Xeio\
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby Xeio » Tue Jul 24, 2012 10:55 pm UTC

Ben-oni wrote:For everyday applications programming, I agree wholeheartedly: memory and clock cycles aren't scarce, so choose tools to minimize development time.
Yea, I'll admit I probably overgeneralized the latter part, it will largely depend on what you're doing. It's probably a better argument against pre-optimization though (same thing against optimizing code speed before you know it's a problem).
ahammel wrote:
Sc4freak wrote:Kinda OT, but I'd actually be interested to see where C# lies on the spectrum. It's a shame those benchmarks only have the Mono implementation of C#. Mono is... not known for its performance. The MS implementation running on Windows would do a lot better, but I've yet to see comprehensive benchmarks like those.
They make the source available. You could always compile it yourself and give it a spin.
Fun side thing, I was toying around with the code for the C# mandlebrot one, apparently using Parallel.For is about .1s faster than the solution there (over multiple tests, and this is on a total runtime of 5s). Now if only I weren't lazy and would try it in Mono to see if the same holds...

Quick, somebody less lazy or with mono set up try it. :P
Spoiler:

Code: Select all

//#define PARALLEL

using System;
using System.Threading;
using System.IO;
using System.Threading.Tasks;

public class MandelBrot
{
    private static int n = 200;
    private static byte[][] data;
    private static int lineCount = -1;
    private static double[] xa;

    public static void Main(String[] args)
    {
        if (args.Length > 0) n = Int32.Parse(args[0]);
        Console.Out.WriteLine("P4\n{0} {0}", n);

        int lineLen = (n - 1) / 8 + 1;
        data = new byte[n][];
        for (int i = 0; i < n; i++) data[i] = new byte[lineLen];

        xa = new double[n];
        for (int x = 0; x < n; x++) xa[x] = x * 2.0 / n - 1.5;

#if PARALLEL
        Parallel.For(0, n, CalculateFor);
#else
        var threads = new Thread[Environment.ProcessorCount];
        for (int i = 0; i < threads.Length; i++)
            (threads[i] = new Thread(MandelBrot.Calculate)).Start();

        foreach (var t in threads) t.Join();
#endif

        var s = Console.OpenStandardOutput();
        for (int y = 0; y < n; y++) s.Write(data[y], 0, lineLen);
    }

#if PARALLEL
    private static void CalculateFor(int y)
    {
        var line = data[y];
        int xbyte = 0, bits = 1;
        double ci = y * 2.0 / n - 1.0;

        for (int x = 0; x < n; x++)
        {
            double cr = xa[x];
            if (bits > 0xff) { line[xbyte++] = (byte)bits; bits = 1; }
            double zr = cr, zi = ci, tr = cr * cr, ti = ci * ci;
            int i = 49;
            do
            {
                zi = zr * zi + zr * zi + ci; zr = tr - ti + cr;
                tr = zr * zr; ti = zi * zi;
            }
            while ((tr + ti <= 4.0) && (--i > 0));
            bits = (bits << 1) | (i == 0 ? 1 : 0);
        }
        while (bits < 0x100) bits = (bits << 1);
        line[xbyte] = (byte)bits;
    }
#else
    private static void Calculate()
    {
        int y;
        while ((y = Interlocked.Increment(ref lineCount)) < n)
        {
            var line = data[y];
            int xbyte = 0, bits = 1;
            double ci = y * 2.0 / n - 1.0;

            for (int x = 0; x < n; x++)
            {
                double cr = xa[x];
                if (bits > 0xff) { line[xbyte++] = (byte)bits; bits = 1; }
                double zr = cr, zi = ci, tr = cr * cr, ti = ci * ci;
                int i = 49;
                do
                {
                    zi = zr * zi + zr * zi + ci; zr = tr - ti + cr;
                    tr = zr * zr; ti = zi * zi;
                }
                while ((tr + ti <= 4.0) && (--i > 0));
                bits = (bits << 1) | (i == 0 ? 1 : 0);
            }
            while (bits < 0x100) bits = (bits << 1);
            line[xbyte] = (byte)bits;
        }
    }
#endif
}

User avatar
Jplus
Posts: 1721
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: Is the Right Tool a Matter of Preference?

Postby Jplus » Wed Jul 25, 2012 12:13 am UTC

Ben-oni wrote:
Jplus wrote:
WarDaft wrote:Functional and garbage collected (which is universally implied by functional AFAIK) languages are known to be more efficient use of programmer's time.

I've heard this claim many times, but I've never seen it backed by actual numbers. It's a dubious claim, [...]. Again it totally neglects that there are many other factors that affect programmer efficiency, such as [...].

[...]
I'm not sure there can be objective studies concerning this, but functional tools at least allow programmers to create things they could not otherwise have thought of.
This is true, but it's equally true of OOP, generic programming, autoiconicity, message passing and any other innovation you can think of. This does nothing to support the claim that functional or GC'd languages are inherently more productive for the programmer.
Ben-oni wrote:It's not all about declarative style and compile time assurances. We wouldn't have things like monads if not for functional programming.
This is not true, the monad is a theoretical construct that was invented before it was introduced in any programming language. For what it's worth, you can also implement monads in C++ and in fact the C# team used continuations as a tool for implementing asynchronous calls.
Ben-oni wrote:As for real-life programming, you've never done OpenGL programming until you've done it in Haskell the way it was meant to be done. Spend just one day on that, and I think you'll be convinced that functional programming increases productivity.
This reminds me of the kind of argument that Jehova's witnesses give when they assure you that you'll be just as convinced as they are after you've read the Bible. Granted, your proposal should be less time-consuming.

Ben-oni wrote:As for your particular concerns, solving problems that have already been solved is easy. Trivially easy. The language doesn't matter anymore. Once the solution is seen, anyone can do it. Work on true research solving problems you've never encountered before, and the existence of a vast array of standard libraries will seem quite inadequate.
Suppose that this is true, and the kind of language you're advocating here is best fit for tackling new, unexplored problems. Then you've still only identified a single type of situation for which it is more fit than other languages. There is no way you're going to infer from that that it is most fit for all situations.

WarDaft wrote:Of course memory management makes coding faster. Imagine C, exactly as it is, except now it's memory managed. All the time you've ever spent debugging memory leaks and segfaults just basically vanished. How is that not making you more productive?
It seems you completely ignored my previous long post. I already said this: C is not representative of "all languages without GC". Your argument doesn't apply to C++, Ada or ATS at all. Here's what I said about C:
Jplus wrote:So to return to my earlier point that there are many ways to manage resources, here's what I think is a more complete overview and fairer comparison of different approaches.
  • Manage everything manually everywhere, like in C. Obviously this is the most error-prone as well as the most labour-intensive strategy. Nonetheless, with enough effort it can produce safe and bug-free software. Zero overhead unless you manage your resources clumsily (which admittedly is likely to happen once in a while).
  • [...]

WarDaft wrote:
I wouldn't be surprised if there are circumstances in which Fortran is a more efficient use of the programmer's time than Haskell. Heck, I can think of one: when you're a physicist and you just need to crunch a lot of numbers in linear algebra.
I sincerely doubt that, Haskell excels at math. I haven't looked into it, but if there aren't libraries to do things like matrix multiplication (which, yes, I know is a primitive operation in FORTRAN) then it's a one-time cost to make one and no one else will need to again because they can just type "cabal install linear-algebra". It will also be vastly more extensible, so sooner or later someone will probably generalize it to algebra over arbitrary kinds of traversable data or some such.
Why write an entire linear algebra library for Haskell if Fortran has BLAS and you just need to run some calculations for your research project? The claim that a similar library for Haskell would be "vastly more extensible" is completely unfounded. Furthermore, in Haskell the calculations would be only half as fast as in Fortran, at best (refer to the language benchmarks game if you think otherwise).

WarDaft wrote:Also, the part about needing more thinking... thinking makes you learn, and so think faster and more effectively in the future. People have time and again demonstrated that the upper bound on this has not been reached.
This is relevant for advanced students, not for people who just need to get work done.
WarDaft wrote:Typing bazillions of lines of code will only make you type so fast however, and once you reach the point where you don't need to take breaks in typing as you're coding up your concepts, then the language is slowing you down.
Firstly, this is irrelevant because you never code without thinking breaks, and secondly, you're grossly exaggerating the difference in amount of typing between functional languages and procedural ones. Refer to the "code used" metric in the language benchmarks game to see what I mean.
WarDaft wrote:Note also that you don't have to use high level concepts that you have to think about more in functional languages, you can easily use very simple things and mimic the operation of any control structures of imperative languages - you just have to use slightly different syntax.
So basically what you're saying is that functional programming is great for productivity, but if it isn't you can always switch back to procedural? Then why not take C++ or Python and switch to functional when you feel like it? How can you even maintain that one is inherently better than the other if you advocate switching between the two?
WarDaft wrote:After this though, you have more control over how things work, and if you notice patterns, you can exploit that much more easily.
Bullshit. Languages differ in the amount of modularity and abstraction that they support, but functional languages do not inherently support such things better than procedural languages. Remember that Turing machines and lambda expressions are two sides of the same coin.

WarDaft wrote:There is also no real upper bound on the level of abstractions you can build effectively in a functional language, which lets you do even more with less.
Apart from this not being entirely true (as there is a practical limit), you can keep on building abstractions in any language. That's why, for example, you can implement Haskell in C.
WarDaft wrote:Imagine if, say Haskell and C/C++, switched places in usage levels throughout history. All of the time spent on making better C/C++ compilers was instead spent on making better Haskell compilers. All the time spend on C/C++ libraries was instead spent on Haskell libraries. We're talking a nearly two order of magnitude increase in time invested. How do you think they would compare then?
The difference would be almost the same. Language implementers borrow techniques from each other and libraries take only a few years to set up. Haskell has pretty good standard libraries, by the way. For your reference: ATS is safe, functional and very young, but it's exactly as fast and at least as efficient as C.
WarDaft wrote:Do you think there would there be as many arguments for using C/C++ in that world as there are for using Haskell in this one? More? Less?
This is turning ridiculously religious. Also, stop conflating C and C++.

Ben-oni wrote:
Sc4Freak wrote:There has always been the argument that high-level languages often trade performance for programmer time (which then arguably allows for more time spent performing optimizations). But that's always a tradeoff. No doubt managed languages may make you more productive in the short term, but automatic memory management isn't free and can have associated long-term costs.

I was just reading a blog yesterday about this... Back in the day (the argument goes) CGI scripts were written in C. This was all very good because the internet was a new and exciting place, and most pages were static HTML anyways. And then the perl hackers came along and starting hacking together CGI scripts in perl. The C programmers railed against the very idea: "You can't write efficient code in perl!" they screamed. But as it turns out, perl is a language designed for text processing, and the internet was built upon text so it worked pretty well. And while the C folks were bitterly resisting perl, the perl (and python, and php) folks were building the internet.

So stick with C if you want, but in the real world, high-level languages are more profitable.
First off, C is a high-level language. Secondly, you're making a false induction: from "Perl is better for hypertext processing than C" to "GC languages are more profitable than non-GC languages in all situations".

Ben-oni wrote:
Xeio wrote:
sourmìlk wrote:With a garbage collected language, infinite coding time will never achieve the same efficiency as an unmanaged one in cases where memory is scarce.
Doesn't matter, nobody has infinite development time, they do happen to have oodles of memory though (especially given the memory requirements of your average application).

Okay, that's not fair. There are too many kinds of programming for that kind of blanket to be meaningful.

For everyday applications programming, I agree wholeheartedly: memory and clock cycles aren't scarce, so choose tools to minimize development time.
I disagree. If it were not for resource hogs like Java and Flash I could run twice as many applications in parallel without things getting swapped (and note that the majority of my applications has nothing to do with Java or Flash). By choosing tools like Java, application developers are needlessly depleting my RAM and I take offense of that. I would mind much less if they took Python, because I don't notice it when my apps take a few milliseconds longer to respond.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Wed Jul 25, 2012 1:14 am UTC

Xeio wrote:
sourmìlk wrote:With a garbage collected language, infinite coding time will never achieve the same efficiency as an unmanaged one in cases where memory is scarce.
Doesn't matter, nobody has infinite development time, they do happen to have oodles of memory though (especially given the memory requirements of your average application).


I'm specifically talking about situations where memory is scarce. In those situations no, they don't have oodles of memory.

I really don't understand what's so controversial about saying that garbage collected languages are inappropriate choices where memory is scarce. They use substantially more memory, and thus are orders of magnitude slower. It turns out that, in many applications, that extra time matters. Whether garbage collected languages are more bug-free (debatable) or easier to program in is beside the point because they don't meet the basic requirements that memory restrictions place on the program.

Jplus wrote:
sourmìlk wrote:Well I suppose I could consider Ada as an alternative for a lot of things then. Mostly I was hoping for a functional language with C-like performance so I could find an excuse to use one, but I rarely ever consider performance an acceptable sacrifice for making the programming job easier. [...]

I forgot to mention this, but ATS is functional.


:D
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Wed Jul 25, 2012 1:57 am UTC

sourmìlk wrote:I really don't understand what's so controversial about saying that garbage collected languages are inappropriate choices where memory is scarce.

Memory is always scarce. Suppose you write your way awesome game that requires every last scrap of memory and every single clock cycle. Will it only run on systems that have sufficient resources? What if it's running on a system that has four times as much RAM, two six core CPUs, and three graphics cards? Are resources suddenly not scarce?

No, you'll design the game to scale to the system it's running on. Now you have only to compare again the performance of your competitor's product: regardless of how they're doing it, if they get better graphics, you've got to work that much harder to catch up. And since there are more important matters than GC performance that go into rendering performance, the advantages of managed memory may be worthwhile. Especially if you end up mutating graphs of objects anyways and need to figure out when nodes are no longer accessible. (This happens more often than you may think.)

And please remember that the benchmark game is, after all, just a game and has no bearing on reality. It's just something to point to when you want to convince your project manager to choose language X.

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Wed Jul 25, 2012 2:02 am UTC

If memory is always scarce then there is never a good reason to use a garbage collected language because it will necessarily run many times slower than a program written in an unmanaged one. But I also contest that memory is always scarce: when I'm writing a small text editor or something, development time matters more than memory because the memory use is trivial.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Wed Jul 25, 2012 3:14 am UTC

sourmìlk wrote:If memory is always scarce then there is never a good reason to use a garbage collected language because it will necessarily run many times slower than a program written in an unmanaged one. But I also contest that memory is always scarce: when I'm writing a small text editor or something, development time matters more than memory because the memory use is trivial.

There are other scarcities: notably, programmer time. You must factor this in. By the same token, there is never a good reason to waste this resource.

The fact that a great many companies use java/php/python or whatever interpreted and/or managed language should suggest there's more to the equation than just computer resources.

Take the case of the coupon clipper. Grocery stores regularly send out coupons to everyone in their neighborhood, encouraging them to buy from them and save money. Given that there will generally be a coupon for at least one thing you want to buy, why doesn't everyone clip coupons? It saves money, after all.

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Wed Jul 25, 2012 3:34 am UTC

Ben-oni wrote:
sourmìlk wrote:If memory is always scarce then there is never a good reason to use a garbage collected language because it will necessarily run many times slower than a program written in an unmanaged one. But I also contest that memory is always scarce: when I'm writing a small text editor or something, development time matters more than memory because the memory use is trivial.

There are other scarcities: notably, programmer time. You must factor this in. By the same token, there is never a good reason to waste this resource.

Taking extra time to make sure your program actually functions reasonably is not "waste". It's a necessity. If you spend less time to make a broken program that's not a reasonable trade-off. So, if my options are using a garbage collected language in a memory-scarce environment to create a non-functional program in less time, or to use an unmanaged language in a memory-scarce environment to make a functional program in more time, only the latter option is ever acceptable. Seriously, I have no idea how you can consider making a program that actually works a sacrifice for anything, at all. If you don't make a program that works, then nothing else matters.

The fact that a great many companies use java/php/python or whatever interpreted and/or managed language should suggest there's more to the equation than just computer resources.

Well yes, but not when resources are scarce. There are perfectly acceptable times to use those languages when you aren't using up all the resources.

Take the case of the coupon clipper. Grocery stores regularly send out coupons to everyone in their neighborhood, encouraging them to buy from them and save money. Given that there will generally be a coupon for at least one thing you want to buy, why doesn't everyone clip coupons? It saves money, after all.

Sorry, I'm not getting this analogy.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Wed Jul 25, 2012 5:53 am UTC

sourmìlk wrote:
Ben-oni wrote:
sourmìlk wrote:If memory is always scarce then there is never a good reason to use a garbage collected language because it will necessarily run many times slower than a program written in an unmanaged one. But I also contest that memory is always scarce: when I'm writing a small text editor or something, development time matters more than memory because the memory use is trivial.

There are other scarcities: notably, programmer time. You must factor this in. By the same token, there is never a good reason to waste this resource.

Taking extra time to make sure your program actually functions reasonably is not "waste". It's a necessity. If you spend less time to make a broken program that's not a reasonable trade-off. So, if my options are using a garbage collected language in a memory-scarce environment to create a non-functional program in less time, or to use an unmanaged language in a memory-scarce environment to make a functional program in more time, only the latter option is ever acceptable. Seriously, I have no idea how you can consider making a program that actually works a sacrifice for anything, at all. If you don't make a program that works, then nothing else matters.

I don't know what alternate universe you live in where those are the only options. "non-functional" is hardly ever an outcome unless the code is simply wrong. There's "glitchy", which we try our hardest to avoid, and "slow", which we work to improve. But "non-functioning"? I think I might have heard about such a thing.

The fact that a great many companies use java/php/python or whatever interpreted and/or managed language should suggest there's more to the equation than just computer resources.

Well yes, but not when resources are scarce. There are perfectly acceptable times to use those languages when you aren't using up all the resources.

Let me reiterate: resources are always scarce. This is a simple economic fact. When the servers reach their load limit, the IT department has two choices: spend a lot of time coding the software more efficiently, or add more servers. There's a process to it, but the gist of it is that bottlenecks are identified, and those are the areas the programmers focus on optimization.

Take the case of the coupon clipper. Grocery stores regularly send out coupons to everyone in their neighborhood, encouraging them to buy from them and save money. Given that there will generally be a coupon for at least one thing you want to buy, why doesn't everyone clip coupons? It saves money, after all.

Sorry, I'm not getting this analogy.

That's because you didn't try to answer the question.

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Wed Jul 25, 2012 6:09 am UTC

Ben-oni wrote:I don't know what alternate universe you live in where those are the only options. "non-functional" is hardly ever an outcome unless the code is simply wrong. There's "glitchy", which we try our hardest to avoid, and "slow", which we work to improve. But "non-functioning"? I think I might have heard about such a thing.

To go back to video games (just because it's an example of software I am intimately familiar with), if you're playing at only a few frames per second, you can't actually play: things happen more quickly than you can react to them. I suppose that means the program still functions, but more as a constant death simulator than a game. So, if your choices are between writing a death simulator in less time or a video game in more time, assuming you want to make software that sells or is even usable in any sort of practical or entertaining way, you have to use an unmanaged language.

Let me reiterate: resources are always scarce. This is a simple economic fact. When the servers reach their load limit, the IT department has two choices: spend a lot of time coding the software more efficiently, or add more servers. There's a process to it, but the gist of it is that bottlenecks are identified, and those are the areas the programmers focus on optimization.

I really don't understand what you're saying here. Most of the time, a given program or even set of programs will not use all the memory and processing power on my computer. Thus, in that case, resources are not scarce. Example: as of typing, my CPU is currently being used at 3% capacity, and my computer is using up 3.19 of my 8 gigabytes of memory.

That's because you didn't try to answer the question.

Okay: laziness. I still don't get the analogy.

Anyways, I think you're dodging the question: why is it ever acceptable to spend time writing a program that, no matter how well written, cannot work?
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Wed Jul 25, 2012 7:08 am UTC

sourmìlk wrote:
Ben-oni wrote:I don't know what alternate universe you live in where those are the only options. "non-functional" is hardly ever an outcome unless the code is simply wrong. There's "glitchy", which we try our hardest to avoid, and "slow", which we work to improve. But "non-functioning"? I think I might have heard about such a thing.

To go back to video games (just because it's an example of software I am intimately familiar with), if you're playing at only a few frames per second, you can't actually play: things happen more quickly than you can react to them. I suppose that means the program still functions, but more as a constant death simulator than a game. So, if your choices are between writing a death simulator in less time or a video game in more time, assuming you want to make software that sells or is even usable in any sort of practical or entertaining way, you have to use an unmanaged language.

How many times do I have to say it?! I've already covered this point. Don't reduce the framerate, reduce the rendering complexity! Maybe google scalability.

Let me reiterate: resources are always scarce. This is a simple economic fact. When the servers reach their load limit, the IT department has two choices: spend a lot of time coding the software more efficiently, or add more servers. There's a process to it, but the gist of it is that bottlenecks are identified, and those are the areas the programmers focus on optimization.

I really don't understand what you're saying here. Most of the time, a given program or even set of programs will not use all the memory and processing power on my computer. Thus, in that case, resources are not scarce. Example: as of typing, my CPU is currently being used at 3% capacity, and my computer is using up 3.19 of my 8 gigabytes of memory.

But you could be running folding@home, or a host of any number of distributed computing tasks. Why aren't you? And there are personal uses for all those resources. I have a friend who likes to run Eve on one monitor while doing who-knows-what on the other. He tends to use his available clock cycles. You could even run a prime-number search as a background task. It's not great odds, but you just might find a new one. (Yes, I know, electricity is a scarce resource as well.)

Anyways, I think you're dodging the question: why is it ever acceptable to spend time writing a program that, no matter how well written, cannot work?

That's not a question, that's an contradiction. You really like those false dichotomies, don't you? Maybe you should run for office.

cannot work?

Garbage collection works. It's a proven technique that's been in use for longer than you've been alive. There are some niche's where it's inappropriate. Microcontroller programming will rarely be managed (except by hobbyists who like putting things like Forth interpreters on their boards). Where performance really matters, every consideration will be taken into account before starting the project. Software development is a high-risk industry where most projects don't get completed. The failures are rarely due to speed or memory issues (well, sometimes), but rather deadlines and budgets that couldn't be met (these are notoriously overshot) and bugs that couldn't be fixed.

--

As a tangential topic, I wonder if Hindley-Milner typing is to theorem-proving-memory-management what dynamic typing is to static typing. Using theorem proving to do compile-time memory management looks fascinating, but also too unwieldy. It looks like things have quite a ways to go before we're ready to seriously move in that direction

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby EvanED » Wed Jul 25, 2012 7:43 am UTC

sourmìlk wrote:To go back to video games (just because it's an example of software I am intimately familiar with), if you're playing at only a few frames per second, you can't actually play: things happen more quickly than you can react to them. I suppose that means the program still functions, but more as a constant death simulator than a game. So, if your choices are between writing a death simulator in less time or a video game in more time, assuming you want to make software that sells or is even usable in any sort of practical or entertaining way, you have to use an unmanaged language.

Why do you assume that someone magically has the right amount of memory that is enough to let the game work at an acceptable rate with good manual memory management, but not GC (so that your argument works)?

I checked memory usage while playing Mass Effect 3, Mirror's Edge, Portal 2, and Starcraft. (I actually went into a level of course, and didn't cop out by deliberately picking some level that I guessed would be small.) With the exception of SC2, the memory use of each of those was about 1 GB. (To be precise, less than 1.1GB. SC2 was ~1.6GB. And that's the total commit size too; resident size is a hundred or two megs smaller.) Quadruple that and you're at 4 GB, which is still in a range that at least I would consider "somewhat acceptable". (For instance, my years-old desktop could run it without thrashing.)

(Edit) And those are AAA games. Defense Grid (just got into that yesterday) took ~650 MB. Limbo (the last indie game I played) takes ~550 MB. Quadruple those and they'll pretty comfortably run on my years-old laptop -- if it even has a good enough video card. Frozen Synapse takes like 200 MB.

Furthermore, there's good reason to believe for a game like that, the situation isn't even nearly that bad. A large portion of that memory use is going to be for models and textures and sounds and other resources like that. To a large extent, those are just going to be loaded from disk, stuck in memory, and left alone. If you tune the sizes of the GC's generations, you should be able to get it so those objects are quickly promoted to the mature generation and then largely left alone. (There may even be a way to hint to the GC to just put an object there either right off the bat or the next time it's "collected", though I'm not sure. Seems like this would be a useful thing to have, anyway.) The younger generations can keep a smaller size, and you shouldn't have to apply the 5x rule or whatever it is to the whole heap, only (memory use - size of static resources).

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Wed Jul 25, 2012 9:00 am UTC

EvanED wrote:tl;dq

Fine, then substitute another situation in which memory is a problem.

Ben-oni wrote:How many times do I have to say it?! I've already covered this point. Don't reduce the framerate, reduce the rendering complexity! Maybe google scalability.

Telling me to write a different program is not offering a solution on how to write a program. If garbage collected languages don't allow me to write a sufficiently complex program, then garbage collected languages are not fit for writing that program. Telling me to write a different program doesn't change that.

But you could be running folding@home, or a host of any number of distributed computing tasks. Why aren't you? And there are personal uses for all those resources. I have a friend who likes to run Eve on one monitor while doing who-knows-what on the other. He tends to use his available clock cycles. You could even run a prime-number search as a background task. It's not great odds, but you just might find a new one. (Yes, I know, electricity is a scarce resource as well.)

Yes, I could be doing those things, but I'm not. Thus memory is currently not scarce. But that's beside the point.

That's not a question, that's an contradiction. You really like those false dichotomies, don't you? Maybe you should run for office.

There is no contradiction or false dichotomy there. I'm asking you to defend your stance and nothing more. Please do so.

Garbage collection works.

Not in memory scarce environments. This was proven a few posts ago.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Wed Jul 25, 2012 11:16 am UTC

sourmìlk wrote:
Garbage collection works.

Not in memory scarce environments. This was proven a few posts ago.

It's like talking to a wall. I repeat it again: all resources are scarce all the time. Just because sometimes you get a ticket to the all-you-can-eat buffet doesn't mean food isn't a scarce commodity. I think you're trying to justify your fear of letting go of manual control. Let me suggest that managed memory is probably the better choice unless you know exactly why it isn't. Do you have some irrational fear that managed memory means an inferior program? This is rarely true. Are you looking for a best-of-all-worlds solution? It's not going to happen. Are you afraid of learning a language because it won't be practical for "real life" use? Nonsense. I've used Scheme for only a handful of toy projects, but I consider the time I spent learning it to be some of the most pivotal of my life.

--

Consider hard memory limits: you have a microcontroller with 4 Mb onboard RAM and 100 Mb flash memory. The flash is slow, so you need to limit accesses to it. Obviously managed memory is out of the question. This kind of "embedded systems programming" is one of the scenarios where C looks like a really attractive language, and even then you'll drop down to assembler every now and then. Furthermore, it's usually electrical engineers who end up working on such problems. I think they have masochistic tendencies. Either that or their egos are so big they don't think "computer scientists" can handle these "real world problems". Sorry, I shouldn't speak ill of EEs, especially as I have some in my immediate family. I find them to be almost as arrogant as people who go to school specifically to learn how to program.

korona
Posts: 495
Joined: Sun Jul 04, 2010 8:40 pm UTC

Re: Is the Right Tool a Matter of Preference?

Postby korona » Wed Jul 25, 2012 12:09 pm UTC

sourmìlk wrote:
Garbage collection works.

Not in memory scarce environments. This was proven a few posts ago.

Where did someone prove that? Java is not "orders of magnitudes slower than C++", even in situations where a large amount of memory is used.
I used to work on a research project that produced gigabytes of data per second (that is, it produced ~40000 small objects per second). Java was about 3 times slower than C++, where the C++ code was using a custom domain specific garbage collector.
If we had to use a malloc call for every object, the C++ code would have been at least 2 times slower.
Even if Oracle's VM uses much memory in their standard configuration, that does not mean java uses much memory in every configuration. Dalvik for example has a very low memory footprint.

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Wed Jul 25, 2012 4:42 pm UTC

korona wrote:Where did someone prove that?

Here you go. Garbage collected languages can be up to 10 times slower if memory is scarce.

Ben-oni wrote:
sourmìlk wrote:
Garbage collection works.

Not in memory scarce environments. This was proven a few posts ago.

It's like talking to a wall. I repeat it again: all resources are scarce all the time. Just because sometimes you get a ticket to the all-you-can-eat buffet doesn't mean food isn't a scarce commodity.

Um... yes it does? If I'm in a position where I'm regularly not using all my memory (as many people I know are), then memory isn't scarce. Just because you can use it doesn't mean you are or will be.

I think you're trying to justify your fear of letting go of manual control. Let me suggest that managed memory is probably the better choice unless you know exactly why it isn't. Do you have some irrational fear that managed memory means an inferior program? This is rarely true. Are you looking for a best-of-all-worlds solution? It's not going to happen. Are you afraid of learning a language because it won't be practical for "real life" use? Nonsense. I've used Scheme for only a handful of toy projects, but I consider the time I spent learning it to be some of the most pivotal of my life.

This is basically all ad-hominem.

Consider hard memory limits: you have a microcontroller with 4 Mb onboard RAM and 100 Mb flash memory. The flash is slow, so you need to limit accesses to it. Obviously managed memory is out of the question. This kind of "embedded systems programming" is one of the scenarios where C looks like a really attractive language, and even then you'll drop down to assembler every now and then.

Right, so why would you suggest using a garbage collected language in this scenario?
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

User avatar
Jplus
Posts: 1721
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: Is the Right Tool a Matter of Preference?

Postby Jplus » Wed Jul 25, 2012 5:00 pm UTC

sourmìlk wrote:
Ben-oni wrote:I don't know what alternate universe you live in where those are the only options. "non-functional" is hardly ever an outcome unless the code is simply wrong. There's "glitchy", which we try our hardest to avoid, and "slow", which we work to improve. But "non-functioning"? I think I might have heard about such a thing.

To go back to video games (just because it's an example of software I am intimately familiar with), if you're playing at only a few frames per second, you can't actually play: things happen more quickly than you can react to them. I suppose that means the program still functions, but more as a constant death simulator than a game. So, if your choices are between writing a death simulator in less time or a video game in more time, assuming you want to make software that sells or is even usable in any sort of practical or entertaining way, you have to use an unmanaged language.

Oh come on sourmìlk. You should know that's not true, as there are several high-end C# games out there with good framerates (on Windows at least).

Ben-oni wrote:Garbage collection works. It's a proven technique that's been in use for longer than you've been alive. There are some niche's where it's inappropriate. Microcontroller programming will rarely be managed (except by hobbyists who like putting things like Forth interpreters on their boards). Where performance really matters, [...]

Since when has Forth automatic memory management?

Ben-oni wrote:As a tangential topic, I wonder if Hindley-Milner typing is to theorem-proving-memory-management what dynamic typing is to static typing. Using theorem proving to do compile-time memory management looks fascinating, but also too unwieldy. It looks like things have quite a ways to go before we're ready to seriously move in that direction

Well Hindley-Milner type inference and theorem proving in ATS are both compile-time operations if I'm right, with different purposes, but other than that, yes I do see why you see a correspondence. The ATS theorem prover doesn't manage your memory though, you still have to do that by hand. It just proves that you're doing it right (or otherwise it won't compile).

I agree that the ATS approach is too cumbersome. To stay in resource terms: it saves very little on memory while costing a lot of programmer time, so safety must be terribly important for you to consider ATS an option for serious production.

korona wrote:
sourmìlk wrote:
Garbage collection works.

Not in memory scarce environments. This was proven a few posts ago.

Where did someone prove that? Java is not "orders of magnitudes slower than C++", even in situations where a large amount of memory is used.
I used to work on a research project that produced gigabytes of data per second (that is, it produced ~40000 small objects per second). Java was about 3 times slower than C++, where the C++ code was using a custom domain specific garbage collector.
If we had to use a malloc call for every object, the C++ code would have been at least 2 times slower.
Comparisons between Java and C++ are nearly always done in unfair ways, funny isn't it? Do note that C++ has the advantage over Java that you have much more freedom to choose how to manage your memory, though.
korona wrote:Even if Oracle's VM uses much memory in their standard configuration, that does not mean java uses much memory in every configuration. Dalvik for example has a very low memory footprint.

Yes Dalvik is interesting. I suspect they were inspired by LuaJIT, because that's also a memory-efficient register-based VM with JIT and tracing GC.

sourmìlk wrote:
Consider hard memory limits: you have a microcontroller with 4 Mb onboard RAM and 100 Mb flash memory. The flash is slow, so you need to limit accesses to it. Obviously managed memory is out of the question. This kind of "embedded systems programming" is one of the scenarios where C looks like a really attractive language, and even then you'll drop down to assembler every now and then.

Right, so why would you suggest using a garbage collected language in this scenario?

Ben-oni didn't mean to suggest such a thing, if I'm right.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

korona
Posts: 495
Joined: Sun Jul 04, 2010 8:40 pm UTC

Re: Is the Right Tool a Matter of Preference?

Postby korona » Wed Jul 25, 2012 5:58 pm UTC

sourmìlk wrote:
korona wrote:Where did someone prove that?

Here you go. Garbage collected languages can be up to 10 times slower if memory is scarce.

In which figure do you see such a slow down? Actually the paper shows that garbage collectors are really competitive when compared against malloc.
EDIT: If you're talking about Figure 7: That figure compares allocators in a situation where memory is constantly swapped out. malloc with a reachability oracle will of course outperform every other allocator in such a situation, even the usual malloc implementations.
EDIT2: Also note that they are comparing garbage collection vs. the best possible malloc/free allocator! They are freeing every object as soon as the program does not use it anymore. They can do that by simulating the program run before doing the actual benchmarks. This is not what a usual C program does. You do not always know exactly when a chunk of memory will not be used again.
Last edited by korona on Wed Jul 25, 2012 6:11 pm UTC, edited 1 time in total.

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Wed Jul 25, 2012 6:10 pm UTC

I'm referring to this bit from the abstract:

Canisius College wrote:With only three times as much memory, the collector runs on average 17% slower than explicit memory management. However, with only twice as much memory, garbage collection degrades performance by nearly 70%. When physical memory is scarce, paging causes garbage collection to run an order of magnitude slower than explicit memory management.


Jplus wrote:Oh come on sourmìlk. You should know that's not true, as there are several high-end C# games out there with good framerates (on Windows at least).

To my knowledge, the rendering code is not written in C#. Honestly, I'm not too familiar with XNA because I hate Microsoft's libraries.

Ben-oni didn't mean to suggest such a thing, if I'm right.

I think his entire point is that you should always use a garbage collected language, even if it means that an equivalent program will run 10 times slower than if written in an unmanaged language.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

korona
Posts: 495
Joined: Sun Jul 04, 2010 8:40 pm UTC

Re: Is the Right Tool a Matter of Preference?

Postby korona » Wed Jul 25, 2012 6:13 pm UTC

If you read the whole paper you will see that the situation they are referring to is when memory is constantly swapped out and there is not enough physical memory to run the desired algorithm.

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Wed Jul 25, 2012 6:14 pm UTC

korona wrote:If you read the whole paper you will see that the situation they are referring to is when memory is constantly swapped out and there is not enough physical memory to run the desired algorithm.

Yeah, that memory-scarce situation is the one I'm talking about. In that situation, it's inappropriate to use a garbage collected language because it creates a program that's so slow as to be unusable.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

korona
Posts: 495
Joined: Sun Jul 04, 2010 8:40 pm UTC

Re: Is the Right Tool a Matter of Preference?

Postby korona » Wed Jul 25, 2012 6:16 pm UTC

I don't know a single application (EDIT: except for embedded hardware) that relies on constant swapping because the program will be unusable anyways. EDIT: If garbage collectors can compete in every other situation, using garbage collectors is fine for me
Of course there are situations in which you need the flexibility and roll your own memory management, but that is in less than 0.1% of all programs that are written.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby EvanED » Wed Jul 25, 2012 6:31 pm UTC

korona wrote:I don't know a single application (EDIT: except for embedded hardware) that relies on constant swapping because the program will be unusable anyways.

You're not getting it. Copying GCs can have comparable performance to manual management, but they are noticeably less efficient with memory use, so it takes rather more memory to achieve that performance. There are three possibilities: if you have too little memory for even the manual case, then both will be constantly swapping, and the program will be unusable as you point out. If you have enough for the GC case, then everything's fine and dandy. But if you have between those cases -- say twice as much as you need for the manual case -- then GC performs poorly.

It's not that the program is relying on constant swapping, it's that the increased GC space usage is causing the GC'd program to swap and become unusable.

User avatar
Xeio
Friends, Faidites, Countrymen
Posts: 5101
Joined: Wed Jul 25, 2007 11:12 am UTC
Location: C:\Users\Xeio\
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby Xeio » Wed Jul 25, 2012 6:56 pm UTC

sourmìlk wrote:
Jplus wrote:Oh come on sourmìlk. You should know that's not true, as there are several high-end C# games out there with good framerates (on Windows at least).
To my knowledge, the rendering code is not written in C#. Honestly, I'm not too familiar with XNA because I hate Microsoft's libraries.
I'm not sure what you're referring to when you say rendering code, but XNA doesn't support native code, it's all managed above the framework layer.

korona
Posts: 495
Joined: Sun Jul 04, 2010 8:40 pm UTC

Re: Is the Right Tool a Matter of Preference?

Postby korona » Wed Jul 25, 2012 6:57 pm UTC

EvanED wrote:But if you have between those cases -- say twice as much as you need for the manual case -- then GC performs poorly.

It's not that the program is relying on constant swapping, it's that the increased GC space usage is causing the GC'd program to swap and become unusable.

That is not the situation that is evaluated in the paper. Figure 7 (the one with the order of magnitude slowdown) just shows that malloc with a reachability orcale has much better locality than collectors have. That is not surprising as the GC has to do a trace and the malloc allocator has an oracle to determine unreachable objects.

That situation that you have to swap because GC needs too much memory does not really exist. You would never extend your garbage collected heap beyond the size of your physical memory. I think Oracle's VM will even prevent you from doing that if you try.
GC does not need twice the memory to work, GC just needs much memory to be efficient and the paper shows that the slowdown is not that bad even if GC has not that much memory available.

User avatar
headprogrammingczar
Posts: 3072
Joined: Mon Oct 22, 2007 5:28 pm UTC
Location: Beaming you up

Re: Is the Right Tool a Matter of Preference?

Postby headprogrammingczar » Wed Jul 25, 2012 8:57 pm UTC

This whole thread would go smoother if sourmilk would just explain what "scarce memory" is supposed to mean.
<quintopia> You're not crazy. you're the goddamn headprogrammingspock!
<Weeks> You're the goddamn headprogrammingspock!
<Cheese> I love you

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Wed Jul 25, 2012 10:05 pm UTC

As in the program uses up >25% of all available memory on a system for which it is designed to run when written in an unmanaged language, or all the memory when written in a managed language, i.e. the same definition used in the paper.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

korona
Posts: 495
Joined: Sun Jul 04, 2010 8:40 pm UTC

Re: Is the Right Tool a Matter of Preference?

Postby korona » Wed Jul 25, 2012 10:28 pm UTC

sourmìlk wrote:As in the program uses up >25% of all available memory on a system for which it is designed to run when written in an unmanaged language, or all the memory when written in a managed language, i.e. the same definition used in the paper.

Where does the paper use such a definition? When they are talking about "scarce memory" in the abstract and conclusion they mean benchmarks that use more than 100% of all available physical memory. They are talking about that in section 5.2. You can see the results in figure 7. That is because the tracing step has very bad locality and almost every page that was swapped out has to be reloaded during the collection on order to determine all live objects.

The results of those benchmarks that do not use 100% of all physical memory in section 5.1 are much better.
They show that even if you run the benchmark with the minimal possible amount of memory, GC increases the runtime by only ~70% (see table 4) when compared to perfect manual allocation (i.e. an object is freed as soon as it will never be used). When the program needs only 33% percent of all available memory (that is the heap size is 3 times larger than the minimal heap size), the GC is as fast as perfect manual allocation. (again see table 4)

User avatar
Jplus
Posts: 1721
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: Is the Right Tool a Matter of Preference?

Postby Jplus » Wed Jul 25, 2012 11:09 pm UTC

Xeio wrote:
sourmìlk wrote:
Jplus wrote:Oh come on sourmìlk. You should know that's not true, as there are several high-end C# games out there with good framerates (on Windows at least).
To my knowledge, the rendering code is not written in C#. Honestly, I'm not too familiar with XNA because I hate Microsoft's libraries.
I'm not sure what you're referring to when you say rendering code, but XNA doesn't support native code, it's all managed above the framework layer.
I think sourmìlk meant to ask what XNA itself is implemented in. I'm wondering about that now, too.

As for the paper: I think EvanED's post and korona's immediate reaction to that summarize everything there is to say about it.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Wed Jul 25, 2012 11:47 pm UTC

korona wrote:Where does the paper use such a definition? When they are talking about "scarce memory" in the abstract and conclusion they mean benchmarks that use more than 100% of all available physical memory.

I know, that's what I said.

The results of those benchmarks that do not use 100% of all physical memory in section 5.1 are much better.

Yes, and in those situations I'm fine using garbage collected languages. But I don't see why I should be with using garbage collected languages when they cause the program to run 10 times slower.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

Ben-oni
Posts: 278
Joined: Mon Sep 26, 2011 4:56 am UTC

Re: Is the Right Tool a Matter of Preference?

Postby Ben-oni » Thu Jul 26, 2012 12:00 am UTC

sourmìlk wrote:
The results of those benchmarks that do not use 100% of all physical memory in section 5.1 are much better.

Yes, and in those situations I'm fine using garbage collected languages. But I don't see why I should be with using garbage collected languages when they cause the program to run 10 times slower.

You're asking that? One possible reason: because such situations are fictional in the world of applications programming. Even the cited situations were contrived.

--

As for using functional GCing languages to write performance critical software (or firmware), there actually are good reasons to do so: Use meta-programming to write code in a highly abstract language to generate code in C or assembler. It's not unlike how a compiler works, and it pays dividends. Just choose a good Meta Language, and you'll find that DSL's are amazingly good tools for generating all sorts of code.

korona
Posts: 495
Joined: Sun Jul 04, 2010 8:40 pm UTC

Re: Is the Right Tool a Matter of Preference?

Postby korona » Thu Jul 26, 2012 12:14 am UTC

sourmìlk wrote:
korona wrote:Where does the paper use such a definition? When they are talking about "scarce memory" in the abstract and conclusion they mean benchmarks that use more than 100% of all available physical memory.

I know, that's what I said.

I do not really understand what you want to say. You said earlier that your definition is that "the program uses up >25% of all available memory". Are you implying that GC requires 4 times as much memory as manual management? That is neither implied by the paper nor true.

sourmìlk wrote:
The results of those benchmarks that do not use 100% of all physical memory in section 5.1 are much better.

Yes, and in those situations I'm fine using garbage collected languages. But I don't see why I should be with using garbage collected languages when they cause the program to run 10 times slower.

You should not use a collector if it causes your program to run 10 times slower but such a large slowdown is only going to happen when memory is constantly swapped out. In this cause your manual managed program will also suck as a single (random) memory access will take >1ms to complete. The situation that an algorithm requires more memory than you physically have will never happen in the real world. Programs are designed to avoid swapping, as swapping will ALWAYS imply an unacceptable slowdown. And by unacceptable I don't mean 10 times slower but 10000 times slower. That situation is of theoretical interest because it shows that the locality of tracing is bad.

I do not think garbage collection is the ultimate answer to all memory allocation needs. Of course there are limits. Sometimes you need more flexibility. When you're writing a game engine in C++ you can have a per-frame allocation buffer that is discarded after each frame. That way you have virtually no malloc/free costs. sometimes you'll have to use this technique in order to get acceptable performance. You cannot do that in java. But the paper you posted certainly shows that GC can compete in almost every situation, even when the heap is very small.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby EvanED » Thu Jul 26, 2012 5:24 am UTC

korona wrote:Are you implying that GC requires 4 times as much memory as manual management? That is neither implied by the paper nor true.

It's right there in the intro (and abstract, and conclusion): "We show that GenMS, an Appel-style generational collector with a mark-sweep mature space, matches or exceeds (by up to 9%) the runtime performance of the best explicit memory manager when given five times as much memory. With three times as much memory, garbage collection slows performance by 17% on average. Garbage collection performance degrades further at smaller heap sizes, ultimately running 70% slower on average." Edit This matches the numbers in table 4 once you squint at them the right way. Edit again First, the 70% measurement is for double the heap size of the explicitly-managed program; the intro doesn't say that, but the other two places do and that can be read off table 4. Second, you also have to interpret "slows performance by 17%" and 70% the right way. What it means is "increases execution time by 17%". I can't figure out what the 70% is really measuring, but if it's consistent with the other numbers, that means the performance is better than halving. In FPS terms, your framerate would be 60% of what it otherwise would be -- not 30%. (That said, I suspect think those numbers wouldn't apply in that setting very well.)

Granted, you can reduce the space overhead by using a non-generational collector, but this is a space-time tradeoff: the generational collectors outperformed the mark-and-sweep collector on most tests and in the average.

korona
Posts: 495
Joined: Sun Jul 04, 2010 8:40 pm UTC

Re: Is the Right Tool a Matter of Preference?

Postby korona » Thu Jul 26, 2012 10:59 am UTC

EvanED wrote:
korona wrote:Are you implying that GC requires 4 times as much memory as manual management? That is neither implied by the paper nor true.

It's right there in the intro (and abstract, and conclusion): "We show that GenMS, an Appel-style generational collector with a mark-sweep mature space, matches or exceeds (by up to 9%) the runtime performance of the best explicit memory manager when given five times as much memory. With three times as much memory, garbage collection slows performance by 17% on average. Garbage collection performance degrades further at smaller heap sizes, ultimately running 70% slower on average." Edit This matches the numbers in table 4 once you squint at them the right way.

Sure but numbers are not about the memory required for the collector but the amount of memory required for good performance. If you do not have enough memory you would not use a maximum heap size greater than the size of your physical memory, you would simply use a lower maximal heap size. That way you will only get up to 70% more execution time and not 1000 times more because swapping kills your performance. My point is that GC will never imply a 10 times slowdown because the situation that your GC'd program uses more than 100% of your physical memory will never happen. And if it does, your manually managed program will also be unusable.

EvanED wrote:Edit again First, the 70% measurement is for double the heap size of the explicitly-managed program; the intro doesn't say that, but the other two places do and that can be read off table 4.

Is for the double average heap size (the second column) but for roughly the same maximum heap size (the first column) i.e. the amount of memory required for GenMS. Since GenMS uses mark and sweep in the mature space I suspect that this is roughly the same amount required for manual allocation. The paper does not talk about the relation of minimal memory required by GenMS to the minimal memory required by manual allocation.

EvanED wrote:Second, you also have to interpret "slows performance by 17%" and 70% the right way. What it means is "increases execution time by 17%". I can't figure out what the 70% is really measuring, but if it's consistent with the other numbers, that means the performance is better than halving. In FPS terms, your framerate would be 60% of what it otherwise would be -- not 30%. (That said, I suspect think those numbers wouldn't apply in that setting very well.)

Granted, you can reduce the space overhead by using a non-generational collector, but this is a space-time tradeoff: the generational collectors outperformed the mark-and-sweep collector on most tests and in the average.

Yes, I think you're interpreting that the correct way. And I think a 70% drop in execution time is pretty good if you take into account that the program runs with minimal maximum heap size.

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby sourmìlk » Thu Jul 26, 2012 3:08 pm UTC

Ben-oni wrote:
sourmìlk wrote:
The results of those benchmarks that do not use 100% of all physical memory in section 5.1 are much better.

Yes, and in those situations I'm fine using garbage collected languages. But I don't see why I should be with using garbage collected languages when they cause the program to run 10 times slower.

You're asking that? One possible reason: because such situations are fictional in the world of applications programming. Even the cited situations were contrived.

The cited situation is just one in which all memory is being used up. You're saying that never happens? I'm going to have to use my own experience as an existence proof.

korona wrote:Sure but numbers are not about the memory required for the collector but the amount of memory required for good performance.

Well, yeah. My point is just that, when a garbage collected language runs ten times slower, it's not appropriate to use that language. I really fail to see that controversy in that statement. I don't think there is one, I think people are miscommunicating.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Is the Right Tool a Matter of Preference?

Postby EvanED » Thu Jul 26, 2012 3:32 pm UTC

korona wrote:
EvanED wrote:Edit again First, the 70% measurement is for double the heap size of the explicitly-managed program; the intro doesn't say that, but the other two places do and that can be read off table 4.

Is for the double average heap size (the second column) but for roughly the same maximum heap size (the first column) i.e. the amount of memory required for GenMS. Since GenMS uses mark and sweep in the mature space I suspect that this is roughly the same amount required for manual allocation. The paper does not talk about the relation of minimal memory required by GenMS to the minimal memory required by manual allocation.

That's not my reading of table 4.

The caption says "The heap sizes are multiples of the minimum amount required to run with GenMS." That means that the first row is the minimum heap size for GenMS. I read the next column as showing the overhead in heap size relative to the manual memory manager -- 210%. That means that GenMS won't even run until you double the heap size relative to the manual allocator. This is consistent with figure 3 as well, which shows table 4 graphically: "Points in the graph represent the heap footprint (the x-axis) and runtime (y-axis) for the garbage collection algorithm relative to the explicit memory manager", and the first data point for GenMS is about x=2. It's also consistent with version of the sentence I quoted before that's in the abstract and conclusion: "with only twice as much memory, garbage collection degrades performance by nearly 70%" -- this matches table 4, where the heap size 1.00 (relative to the minimum that GenMS requires) corresponds to an overhead of 2x vs manual management and a runtime of 169%.

sourmìlk wrote:Well, yeah. My point is just that, when a garbage collected language runs ten times slower, it's not appropriate to use that language. I really fail to see that controversy in that statement. I don't think there is one, I think people are miscommunicating.

I think the point of contention is just of whether a 10x slowdown is likely to happen in practice. I say that such situations are very rare, and it's usually more useful to worry about other things.


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 7 guests