3 ms·
You can, anyone can, write all your programs with the mindset that you are given X amount of memory, and you use it as a cache or buffer like they did back when
by vba616 4y ago
You can, anyone can, write all your programs with the mindset that you are given X amount of memory, and you use it as a cache or buffer like they did back when computers had 64K or whatever.
It would solve a lot of what I see as the problems of modern software. For so many years, people have pursued the false vision of a programming environment where resources can be assumed to be infinite.
The problem is, no matter how much memory you have, if you take a data structure that reasonably fits in your vast amount of memory, and then you inadvertently multiply its size, you won't have space.
Or to put it another way, all finite numbers are infinitely smaller than infinity, so the delusion that any finite number is equivalent to infinity will always bring people to grief.
Could someone please write a manifesto along the lines of "malloc considered harmful"? Just. Say. No.
- AtlasBarfed 4y agoJavascript, Java, C#, Golang, Python, Ruby: all garbage collected. Aside from C/C++, those are the languages of modern software dev. Yeah you could arena allocate and do some nonstandard techniques like that, but basically you are at the mercy of a garbage collector, and those LOVE to use memory. So... use C++? use Rust? As you point out, malloc and the heap are kinda the same problem as GC. Personally, some "runs on 1Ghz and 256MB of RAM" would probably be the most real world effective way to advertise some degree of restraint. We can't keep wasting processing power, the "laws" are running out of steam. MHz/Ghz is stalled for a decade, and the die shrinks are going to start running out of steam as well. I can't think the coming AI coding blast will help things either. We also lack stability and sharing in the runtime libraries (and containers are NOT helping this, they just load all their own mini-OSes for each application), and efficient means of extracting only the necessary routines from big libraries in build processes.
- nequo 4y ago> you are at the mercy of a garbage collector, and those LOVE to use memory. It’s not the GC that uses memory, it’s your program. Compare the memory use of Python with that of C++ in these benchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Or OCaml and C++ here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ocaml-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- vba616 4y agoI don't think it's about the amount or the language. I have 16 GB of memory, and I don't expect it to decrease. I don't expect the number of cores and MHz to go down either. I'm just saying that everything should be written to take what you give it and like it. If you do that, it doesn't matter how much memory there is, or if there is a GC or not - you have none of the problems of unpredictable resource usage. I don't think (although I haven't been in school over a decade) most people come out of college with an experience of writing small programs to process everything in chunks. It's so...impure. I didn't have the experience of being taught in Scheme or something, but I can imagine.
- yencabulator 4y ago> write all your programs with the mindset that you are given X amount of memory, and you use it as a cache or buffer like they did back when computers had 64K or whatever Even better, cache-oblivious data structures & algorithms avoid the needing for picking/knowing X, and will essentially auto-adjust to near-optimal regardless of the cache size or pressure.