4 ms·

Oh and does anyone else think the malloc example in comparison to actual garbage collection is incredibly unfair?

• scott_s 15y ago
  "Fairness" is not really relevant. As long as they're comparing typical C idioms to typical Python idioms, it's valid.
  • xd 15y ago
    So why not simply do: #include <stdio.h> #include <stdlib.h> int main() { int i = 0; char *x = malloc(44 * sizeof(char)); for (i = 0; i < 10000000; i++) { sprintf(x, "%d %d", i, i); } free(x); } Their version was intentionally biased, which is a shame.
    • scott_s 15y ago
      Probably because they wanted to simulate calling a function that parsed a string, and such functions will have to allocate and deallocate memory as needed. It's also worth noting that calling malloc and free in a tight loop where you're always requesting the same amount of memory will be pretty fast. Good implementations of malloc - of which glibc certainly is - will consistently return the exact same chunk of memory to you, and you will be on the fast-path of the allocation algorithm.
      • xd 15y ago
        Why would you assume the need to deallocate in the loop? Reuse of an already allocated memory location is C optimisation 101.
        • scott_s 15y ago
          You're looking at this from the wrong angle. You're looking at the C code and thinking, "How can I optimize this?" What you need to do in this case is look at it and say, "How can I optimize this and still retain the essence of what I want to test?" Your optimizations remove that essence - if you're calling a function that is a part of an API, it will have to allocate and free its own memory. That the code is in a loop is an artifact of the experiment.
          • xd 15y ago
            I'm looking at it from the angle of someone that has spent over a decade in and out of C. The code in the loop is in NO way an "artifact", it's absolutely critical to the comparison. My example in no way removes the essence, especially if we are using "idioms".
            • scott_s 15y ago
              I said the loop is an artifact, not the code in the loop. Their experimental design is "Do x N times, then divide the overall runtime of the program by N to estimate the cost of x." If timing a program that did x once lead to good results, they would do that - but it doesn't, so they don't. You're trying to optimize around the loop, but by doing that, you're changing the x that is being measured.
              • xd 15y ago
                If by x you mean performing a string operation and copying the result to memory .. I still fail to see how allocating and deallocating memory on each iteration is a fair comparison, it's not something I'd expect a competent C developer to do ergo how is that a relevant comparison? I know the aim is to show off the string operation in and of itself so why not leave it there, why the need to bring garbage collection into the mix? Edit: it's the way the garbage collection has been thrown into the mix I'm having difficulty understanding the need for.
              • cube13 15y ago
                Two things potentially different between the two implementations: 1. The C code is stack allocating a pointer in every loop iteration. 2. Cleaning up the memory without(potentially) triggering Python's GC. Is the Python GC getting triggered in this scenario? If not, then this is what's actually happening, with the cleanup happening automatically when the process exits: char x[10000000]; int i; for (i = 0; i < 10000000; i++) { x[i] = malloc(44 * sizeof(char)); sprintf(x, "%d %d", i, i); } If GC is thrown into the mix, the C code is really: char x[1000]; int i; int j=0; for (i = 0; i < 10000000; i++) { x[j] = malloc(44 * sizeof(char)); sprintf(x, "%d %d", i, i); j++; if(j == 1000) { for(j = 0; j < 1000; ++j) free(x[j]); } }
    • pizza_ 15y ago
      sizeof(char) is always 1 by definition
    • MostAwesomeDude 15y ago
      If you didn't notice, their version was based off of static allocation for the character array, which is the kind of thing a sharp C programmer will put in as an optimization. Note that the Python version is already pretty optimized, according to general Python idioms. You are arguing that they should have compared against a less efficient C example, which honestly boggles my mind.
• kingkilr 15y ago
  I've long since lost track of what it means for a comparison between languages to be fair. To put that a different way, how should we have compared them? Should we have downloaded some GC library for C to implement it?
  • xd 15y ago
    I guess the real problem is that the example serves no real world purpose and can very easily be biased. See my response to scott_s below.