←back to thread

271 points mithcs | 9 comments | | HN request time: 0s | source | bottom
Show context
cachius ◴[] No.45953162[source]
A recent superpower was added by Fil aka the pizlonator who made C more Fil-C with FUGC, a garbage collector with minimal adjustments to existing code, turning it into a memory safe implementation of the C and C++ programming languages you already know and love.

https://news.ycombinator.com/item?id=45133938

https://fil-c.org/

replies(3): >>45953284 #>>45953390 #>>45954377 #
762236 ◴[] No.45953390[source]
Why would I want to run a garbage collector and deal with it's performance penalties?
replies(4): >>45953453 #>>45953598 #>>45953991 #>>45961132 #
1. sesm ◴[] No.45953991[source]
IDK about Fil-C, but in Java garbage collector actually speeds up memory management compared to C++ if you measure the throughput. The cost of this is increased worst-case latency.

A CLI tool (which most POSIX tools are) would pick throughput over latency any time.

replies(5): >>45954231 #>>45954275 #>>45954762 #>>45954883 #>>45958686 #
2. zozbot234 ◴[] No.45954231[source]
You also pay for the increased throughput with significant memory overhead, in addition to worst-case latency.
replies(1): >>45954698 #
3. dataflow ◴[] No.45954275[source]
> in Java garbage collector actually speeds up memory management compared to C++ if you measure the throughput

If I had a dollar for every time somebody repeated this without real-world benchmarks to back it up...

replies(1): >>45959456 #
4. KerrAvon ◴[] No.45954698[source]
This. The memory overhead kills you in large systems/OS-level GC. Reducing the working set size really matters in a complex system to keep things performant, and GC vastly expands the working set.

In the best cases, you’re losing a huge amount of performance vs. an equivalent non-GC system. In the worst, it affects interactive UI performance with multi-second stalls (a suitably modern GC shouldn’t do this, though).

5. CyberDildonics ◴[] No.45954762[source]
I see this claim all the time without evidence, but it's also apples and oranges. In C++ you can avoid heap allocations so they are rare and large. In java you end up with non stop small heap allocations which is exactly what you try to avoid when you want a program to be fast.

Basically java gc is a solution to a problem that shouldn't exist.

6. wavemode ◴[] No.45954883[source]
Java (w/ the JIT warmed up) could possibly be faster than C++, if the C++ program were to allocate every single value on the heap.

But you're never going to encounter a C++ program that does that, since it makes no sense.

replies(1): >>45959449 #
7. milch ◴[] No.45958686[source]
Depending on the CLI tool you could even forego memory management completely and just rely on the OS to clean up. If your program completely reads arbitrary files into memory it's probably not the best idea, but otherwise it can be a valid option. This is likely at least partly what happens when you run a benchmark like this - the C++ one cleans everything up nicely if you use smart pointers or manual memory management, while the Java tool doesn't even get to run GC at all, or if it does it only cleans up a percentage of the objects instead of all of them.
8. jesse__ ◴[] No.45959449[source]
Entertaining anecdote:

I once worked on a python program that was transpiled to C++, and literally every variable was heap allocated (because that's what python does). It was still on the order of 200x faster than python IIRC.

9. jesse__ ◴[] No.45959456[source]
I wish I could upvote this 100 times