4 ms·
This is not surprising. Parallel GC will almost always be faster than refcounting. If you wrote a C or C++ program to accomplish this task after carefully plann
by voldacar 7y ago
This is not surprising. Parallel GC will almost always be faster than refcounting. If you wrote a C or C++ program to accomplish this task after carefully planning out exactly when stuff needs to get manually malloced/freed, you could outperform any of their approaches
And like another commenter mentioned, if you're writing a program which streams a lot of data sequentially from disk, and where throughput is important (such as in sequencing), you should always be using mmap
- ori_b 7y agoThat's a case where mmap isn't actually all that much faster than read, and due to the inter processor interrupts needed to synchronize the memory mappings across cores, it may end up much slower. You're grabbing large chunks and flushing the TLB a whole lot. If you are seeking randomly and doing small reads, then mmap will help quite a bit: the data will be faulted in, and accessing it a second, third, or hundredth time will not cost much.
- gpderetta 7y agoread mapping are actually not too bad. remote TLBs can be sychronised lazily on a page fault.
- gpderetta 7y agowell, there is careful planning and there is going out of the way to heap allocate everything.
- voldacar 7y agoYeah i hadn't really looked into their c++ code when I wrote my comment. it looks like code written by someone who doesn't even know the stack exists. insane
- yvdriess 7y agoThat makes the assumption that any refcounted object lifetime management can be replaced with manual management, which is not the case. As the paper states: it is not possible to manually determine the object lifetimes due to the nature of the problem, data and openness of the configurable analysis pipeline. Manual alloc/free would in their case mean holding on to much more memory than a GC/refcounting solution would.
- imtringued 7y agoIt doesn't require care. By default you just put stuff on the stack in C++. You have to go out of your way to use things like ref counting.
- voldacar 7y agofor complicated stuff involving multiple threads and shared memory, it's good to plan it out in advance in some way. but you are right that most data can just get stack allocated if you look at their code it's like they have no clue that the stack even exists. seriously. they heap allocate EVERYTHING