While we're at it, how about we liberate CPUs and caches from communication between threads and cores?
Many ARM chips have this.
Any useful links? What are the terms I should search for?
For Better Computing, Liberate CPUs from Garbage Collection
371–380 of 460 posts
Re: For Better Computing, Liberate CPUs from Garbage Collection
#372It reminds me of the days I was reading Knuth's quote "97% of the time premature optimisation blabla" every time someone was trying to make something faster. CPUs are not getting faster, yet it seems using tools that makes things run faster are somehow taboo. Wirth's law: Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware becomes faster. Why is java…
> frowns upon writing C because of arrays
Do you mean horrifying security flaws?
Re: For Better Computing, Liberate CPUs from Garbage Collection
#373Earlier quoted context omitted.
Garbage collection is mostly an issue of latency, not overall CPU usage. malloc and free are not O(1) anymore than garbage collection is. [edit] I forgot memory usage as a third resource. The search space of GC algorithms can be considered on a triangle of throughput, latency, and RAM usage. You can make one of these better by making one or both of the other worse.
A Hummer isn’t any more O(n) than a Prius in terms of fuel used per n miles but that constant will still kill you. In practice, no one has ever demonstrated a garbage collected language that was more efficient than Rust/C/C++ other than in very specific cases. https://thenewstack.io/which-programming-languages-use-the-l...
The programming language benchmarks game is not great for finding idiomatic code, since it tends to be highly hand-tuned code.
Dynamic allocation is slow, so both the C and non-C code will avoid it in the benchmarks game (the problems are usually sufficiently fixed-size that it will boil down to a single malloc() at the beginning, which is idiomatic in a lot of embedded C, but not for non-embedded C).
Highly dynamic languages are slower not because the GC is slower, but because the GC encourages (fails to discourage) a lot of allocations. If you were to write Haskell or Ocaml like-code in C you would put a lot of stress on the malloc/free implementations. Those have gotten a lot better in the past 20 years or so (web browsers in particular tend to stress malloc/free a lot as well), but it's still more of a question as to "which malloc best fits my workload" rather than a "one true malloc" which is a factor seen with garbage collectors as well.
Re: For Better Computing, Liberate CPUs from Garbage Collection
#374Earlier quoted context omitted.
> But all of these are much cheaper than developer labour and reputation damage caused by leaky/crashy software. The economics make sense. Of course, with traditional languages, that's the trade-off we're being asked to make. That's my point! We need to develop languages that accurately encapsulate lifetimes statically so that we can express that to the compiler. If we do, the compiler can just make instances disappe…
In Rust, does the standard way of implementing a graph structure still use a vector of nodes and indices for edges? I think I saw a Rust implementation of an arena. Is it working?
>In Rust, does the standard way of implementing a graph structure still use a vector of nodes and indices for edges?
You'd probably want to do this whenever you implement a graph in a performant language, it's faster and safer (depending on the problem). Implementing edges as vectors of pointers is an exercise in memory leaks and data races, imo.
You can see an implementation with adjacency lists here:
https://github.com/bluss/petgraph/blob/master/src/graph_impl...
>I think I saw a Rust implementation of an arena. Is it working?
Re: For Better Computing, Liberate CPUs from Garbage Collection
#375Earlier quoted context omitted.
Cyclic data structures, memory safety, memory management without tracing. Pick 2.
Well, you can use weak pointers appropriately in a safe setting. It's not fun though. Alternately, you can use a layer of indirection, such as throwing all your graph nodes in a big vector and having them use indices to refer to one another. So I would perhaps revise that statement to " easy cyclic data structures, memory safety, memory management without tracing, pick two".
Fair enough. But with the vector approach, now you can have something that looks a lot like a use-after-free error!
Re: For Better Computing, Liberate CPUs from Garbage Collection
#376Earlier quoted context omitted.
This comment is just bad and misinformed all over. (1) Automatic Reference Counting doesn't work; its equivalent in interpreted languages is, well, reference counting , which can be optimized quite a lot (though has some issues with multithreading), but cannot collect cycles. (2) therefore, if you want reference counting, you have to either also have GC (for cycles), or program carefully to avoid creating cycles (whi…
It is weird, I do not feel restricted when I write non-GC code. Btw. you still need to pay attention with GCd languages no to leak references that cannot be GCd. Java has this sort of problems. Rust made it easy and simple to deal with memory in a non-malloc level while not having GC. Erlang on the other hand has a VM that makes GC much faster than in other languages. I can live with that because if you do it right i…
> still need to pay attention with GCd languages no to leak references that cannot be GCd. Java has this sort of problems.
Unless you're doing weird things with class loaders, this is a non-issue.
> Erlang on the other hand has a VM that makes GC much faster than in other languages
What makes Erlang's VM make GC faster than other languages?
Re: For Better Computing, Liberate CPUs from Garbage Collection
#377Objective-C ARC (automatic reference counting) solved the problem neatly for my iOS apps. Is there some overhead? Maybe, but it's neatly spread out through the entire application life time, so there is rarely[1] a UI-freezing stutter associated with GC. To reduce the overhead I turned off thread-safety and simply never access the same objects from more than one thread (object has to be "handed off" first if it comes…
> I do make an occasional slip, which is where I need to rely on Instruments, and I do wish I had better tools than that, something more automatic that would catch me in the act.
Xcode's debug toolbar has a "debug memory graph" button that will visualize the object graph for your entire program. Reference cycles are automatically detected and listed in the issue navigator.
https://developer.apple.com/library/archive/documentation/De...
Re: For Better Computing, Liberate CPUs from Garbage Collection
#378Earlier quoted context omitted.
I don't see your point. Of course sometimes the lifetime of an object is not tied to code scope but actually to something dynamic. Let's say for instance when you close a tab in your browser you expect the resources to be freed (ignoring caching to simplify the argument). Clearly somewhere in your code you have to explicitly handle tab closing and break the references to allow the GC to do its job. Why not free the r…
> Clearly somewhere in your code you have to explicitly handle tab closing and break the references to allow the GC to do its job. Why not free the resources here while you're at it? You are missing the point. The main point behind GC is removing the complexity of writing the software. Writing your own destructors, thinking about when to free your memory or writing lifetime annotations, needing to design your app in…
> The main point behind GC is removing the complexity of writing the software
And more importantly, reading it.
Re: For Better Computing, Liberate CPUs from Garbage Collection
#379Earlier quoted context omitted.
Ridiculous. The problem is not that you don't know when/where the lifetime will end — that can usually be characterized by a terse "English" description. The problem is that this lifetime is dynamic in nature. The end of the lifetime of an object may coincide with some user input, for instance. At this point, either you go back to manual management, with the potential for errors (and for what it's worth, I think manu…
I don't see your point. Of course sometimes the lifetime of an object is not tied to code scope but actually to something dynamic. Let's say for instance when you close a tab in your browser you expect the resources to be freed (ignoring caching to simplify the argument). Clearly somewhere in your code you have to explicitly handle tab closing and break the references to allow the GC to do its job. Why not free the r…
>I find RAII a lot easier to model and think about than "you drop this reference and one day maybe your object is destroyed, but don't really rely on that"
Heh, I just realized this is what we depend on to remove commits from Github. "Uh, just delete any branches that contain it, and, uh, it'll get removed ... like, eventually." (of course you have to assume any secret data is compromised)
Re: For Better Computing, Liberate CPUs from Garbage Collection
#380Earlier quoted context omitted.
C++ code is full of use after free problems. You can avoid those with garbage collection.
If you have a use-after-free it means that you made a wrong assumption in your code about the lifetime of the object. A GC would hide the issue and potentially lessen the gravity of the bug but it doesn't resolve the core issue which is that you probably have a fundamental logical problem in your code. I'm a bit "GC hater" so obviously I'm heavily biased but to me it just means that GC make it easier to write sloppy,…
> A GC would hide the issue and potentially lessen the gravity of the bug but it doesn't resolve the core issue which is that you probably have a fundamental logical problem in your code.
No, it solves the problem because resource lifetime is no longer a concern. A field advances as we decrease the number of irrelevant details we need to attend to.
Turns out, most of the time, memory is one such concern. You can argue that we need better approaches when memory is a concern, but that doesn't discount the value of GC as the right default.