News for hackers. Stuff that matters.
Re:Friendship ended with the garbage collector by jcelerier on Friday August 27, 2021 @04:40AM (#28325584)
> (Way longer than an exp(), for example).

eh, not that much.

use.cpp:

    double rand_double() { return 16.; }
    int rand_int() { return 16; }
    void use(void*) { }
main.cpp:

    #include <iostream>
    #include <chrono>

    void run();
    int main()
    {
      auto t0 = std::chrono::high_resolution_clock::now();
      for(int i = 0; i < 10000000; i++) {
        run();
      }
      auto t1 = std::chrono::high_resolution_clock::now();
      std::cout << std::chrono::duration_cast<std::chrono::milliseconds>(t1 - t0).count() << std::endl;
    }
alloc.cpp:

    #include <cstdlib>

    int rand_int();
    void use(void*);
    void run()
    {
      auto res = malloc(rand_int());
      use(res);
      free(res);
    }
exp.cpp:

    #include <cmath>

    double rand_double();
    void use(void*);
    void run()
    {
      auto res = exp(rand_double());
      use(&res);
    }
I get ~100ms for the exp, ~130ms for the malloc/free at -O3 / -Ofast with both clang and gcc (and checking with perf ensures that the time is indeed spent in these functions). So it's a bit faster, but not exactly fast (or rather, the math functions are really fucking slow)
Re:Friendship ended with the garbage collector by jonv on Friday August 27, 2021 @12:41PM (#28329953)
Excuse me if I have mis-read your sample program but it looks like you are allocating 16 bytes, then immediately freeing it, again and again in a loop. Since you're not allocating anything else, the allocate and free will happen almost immediately. Malloc() has a run time that can vary a lot depending on what has already been allocated & freed in the past, so this test is not meaningful.

Not only that, but the original doug lea's malloc has a bin specifically for 16 byte allocations: http://gee.cs.oswego.edu/dl/html/malloc.html (the smallest size), so you've specifically chosen a very fast example.

In order to properly test malloc() you have to pre-generate some pseudo random numbers for your allocation sizes, and allocate and free unpredictably. But it's more complicated than that, as in the very occasional case when malloc() has to ask the OS for more heap, that system call may not "finish" until your program first writes to that region of memory... (ie malloc() returns but hasn't finished!)

Re:Friendship ended with the garbage collector by jcelerier on Friday August 27, 2021 @01:05PM (#28330305)
I actually tried with up to 256 bytes and got the exact same timings. But sure, that's the absolute possible best case considering glibc thread pool, but it's (allocating and freeing in a loop) still a pretty common case
Re:Friendship ended with the garbage collector by jonv on Friday August 27, 2021 @01:55PM (#28330969)
But when you enter the loop you have no other "objects" in your program allocated at all, so it doesn't have to do a search for a suitably sized block. Near-identical timings for changing the size to 256 is what I would expect.
Re:Friendship ended with the garbage collector by quietbritishjim on Friday August 27, 2021 @08:08AM (#28326763)
That's definitely very interesting. I do wonder if malloc and free would take longer if there would multiple threads in the program, which is more relevant to this discussion; surely exp would not, assuming sufficient free cores. Even more interesting would be if you malloced in one thread and freed in another, given that allocators usually make use of thread-local pools.
Re:Friendship ended with the garbage collector by pjc50 on Friday August 27, 2021 @04:44AM (#28325598)
.. are you sure it's not the rand functions that are slow?
Re:Friendship ended with the garbage collector by arc-in-space on Friday August 27, 2021 @05:00AM (#28325663)
You mean the ones that RET 16? My computer person instincts tell me no, it's not those.
Re:Friendship ended with the garbage collector by jcelerier on Friday August 27, 2021 @04:52AM (#28325636)
the rand functions are

    double rand_double() { return 16.; }
    int rand_int() { return 16; }
here are profiling traces:

https://imgur.com/a/5vkblDr