3 ms·
I was also there in the 2000's and I remember people saying Java can be just as fast as C And in particular that garbage collection can be faster than malloc/f
by chubot 1y ago
I was also there in the 2000's and I remember people saying Java can be just as fast as C
And in particular that garbage collection can be faster than malloc/free.
This is technically true in the case you have a naive C program. There are tons of C programs out there, and some are slow. (But there are more slow Java programs out there)
But it's 100% clear now that GC has a significant cost, and while you can optimize a bad C program, it can be very hard in many cases to optimize the cost of GC away.
C offers more freedom and thus more footguns, but the freedom also means you don't really have a performance cap.
And I prefer GC -- most programs I write will have GC; I just recognize the performance cap, and design accordingly. (In fact I wrote a GC for a subset of C++ for https://oils.pub https://oils.pub -- I actually think this is a language with nicer performance properties than Java, mainy due to being AOT)
- gf000 1y agoIf you bring parallel processing into the picture (shared memory model), then the achievable performance caps per dev work change significantly though. I will very easily write a faster parallelizable program in Java, before I get the C one even remotely correct and then we haven't even taken into account every future maintenance cost. Also, the way C devs often hide the cost is simply.. less efficient code like copying stuff right and left, etc, which can actually be more "bravely" avoided in managed languages.
- holowoodman 1y agoThen pray tell, how come that the most parallel and most demanding computations like weather simulations, fluid dynamics and stuff like that avoid superior Java like the plague? Shouldn't it have been a blessing with its easier parallelizable code? The reality is that it's quite the opposite. Java boxed types, lack of control over memory layouts leading to page flapping and false sharing, lack of fast synchronisation primitives, lack of a compiler capable of hinted or automatic loop parallelization lead to Java being totally unsuitable here. The crown goes to FORTRAN in that regard, with C and C++ being second and third places. Of course theoretically a magic fairy-tale Java compiler could look at the code, recognize all the aforementioned problems and fix them. Of course the language would allow for this to happen totally without changing semantics. But no Java compiler even comes close...
- carlmr 1y ago>I will very easily write a faster parallelizable program in Java, before I get the C one even remotely correct and then we haven't even taken into account every future maintenance cost. Even better in Rust. You get great memory safety guarantees from the borrow checker helping guide your parallelization, while still being fast and GCless. It's the best of both worlds. >Also, the way C devs often hide the cost is simply.. less efficient code like copying stuff right and left, etc, which can actually be more "bravely" avoided in managed languages. I'd say Rust is again the easiest way to avoid unnecessary copies without sacrificing safety.
- gf000 1y agoFor a subset of algorithms, you are right. For certain other kind of concurrent algorithms, you are in a world of pain and Rust's borrow checker simply refuses to compile a large set of otherwise correct programs.
- carlmr 1y agoI've never had this issue. Use the built-in datastructures that provide that functionality and you're good
- gf000 1y agoJust because you haven't had it doesn't mean it doesn't exist. The built-ins just use unsafe extensively for these kind of algorithms - though that is of course completely fine here and there, since you will only use the safe APIs.