naikrovek
Why doesn't this software handle nested quotes? What year is this?

This software is still in beta and not officially launched yet, even though this early community is active. From the home page:

handmade.network/home">handmade.network/home
"Some features are missing, other things are a bit janky. We're working diligently to resolve all of this. If you come across something not mentioned in either of those threads, kindly open a new topic in the feedback forum."

'Nested quotes' is listed on the feedback forum. No need to excuse a grumpy mood, and you weren't violating our guidelines.

naikrovek
outside of games, which I neither author nor contribute to, garbage collection is just fine. In my world (the plebian business applications and middleware) GC is more than sufficient in 99% of cases, and in the remaining 1%, throwing more hardware at the problem fixes any performance problems I've ever encountered.

Well, maybe for specifically what you do that could be true (I have no idea). But I do find that none of the non-game software I use on a daily basis performs adequately (with a few exceptions - perhaps Reaper). Most software seems to be very slow and quite laggy compared to what a well-optimized version might be expected to accomplish. So while I don't know how much of this has to do with memory policy, I do think there is a tendency to say "well, games are this special case" as a convenient way of ignoring a problem that really should be getting addressed! If games can be responsive, so should all my applications, in my opinion. I don't think games are unique in the world as things which are better at 60fps. _Everything_ is better at 60fps :)

naikrovek
I am curious about the hinted third option after manual memory management and garbage collection (which I have always considered automatic memory management.) Is there a third or are the current GC methods insufficient? I am asking honestly.

I'm not suggesting I magically know the answer, I'm more saying that I don't think it's impossible, so I am optimistic that the two options will not forever be "write all memory management code yourself and perform optimally or use a garbage collector and take a performance hit."

- Casey

cmuratori
I'm not suggesting I magically know the answer, I'm more saying that I don't think it's impossible, so I am optimistic that the two options will not forever be "write all memory management code yourself and perform optimally or use a garbage collector and take a performance hit."

- Casey

I hope you're right. I don't want to see this discussion repeated again and again for the rest of my life.

Well, I am at least pretty sure that we will look back on garbage collection as a silly idea, like medicinal bloodletting. The only thing I'm not sure about is whether the argument will just on to manual memory management vs. some other thing that's not garbage collection, but still has some problems.

Hopefully it becomes more like register allocation, where it's not super clear we ever need to do it by hand ever again. Like most people don't think there's a lot to be gained by hand-allocating registers these days, at least not anyone I regular hear from.

- Casey

cmuratori
Well, I am at least pretty sure that we will look back on garbage collection as a silly idea, like medicinal bloodletting. The only thing I'm not sure about is whether the argument will just on to manual memory management vs. some other thing that's not garbage collection, but still has some problems.

Hopefully it becomes more like register allocation, where it's not super clear we ever need to do it by hand ever again. Like most people don't think there's a lot to be gained by hand-allocating registers these days, at least not anyone I regular hear from.

- Casey

The most obvious next step in memory management is letting static analysis find out how to manage memory in a "optimal" way.

Though that will quickly reach the obstacle that is the halting problem in the general case and have to revert back to run-time management of which blocks of memory are touched by the program (aka garbage collection).

I am curious about the hinted third option after manual memory management and garbage collection (which I have always considered automatic memory management.) Is there a third or are the current GC methods insufficient? I am asking honestly.

Rust does this by only allowing you to do memory operations about which it is possible to reason at compile time. This means the compiler has to understand who owns what memory at all times.

http://pcwalton.github.io/blog/20...iew-of-memory-management-in-rust/

Note that, at this link, when he says "smart pointer" he doesn't necessarily mean the equivalent of a C++ smart pointer with a bunch of weird code wrapped into it. Very often these are just the same as regular raw pointers, it's just that the compiler understands them more.

Most software seems to be very slow and quite laggy compared to what a well-optimized version might be expected to accomplish.

It is probably not a surprise that I agree with this. We are today using supercomputers compared to what I used to program 3D games on when I started my professional career ... and we can't even draw 2D web pages without lagging. Earlier this year I gave a whole speech about this:

https://www.youtube.com/watch?v=k56wra39lwA

_Everything_ is better at 60fps

And actually, 60fps is kind of a low bar at this point. We should be aiming for 120fps or higher for simple 2D applications, because, come on.

almost every time you use a garbage collected application you are also using a JITted/runtime language. So you take the fixed memory overhead of the runtime, compilation has to be fast so may not be optimal, there is startup cost doing the JIT compilation. As well there is a general attitude problem in those ecosystems (just throw hardware at it) instead of keeping allocations to a minimum (important whether you gc or not). Java is sort of a worst case scenario because the language encourages you to allocate constantly since it completely adheres to OOP idioms. Contrast to say, c# which has value semantics on its structs so you can at least more easily escape the OOP universe when needed, or ocaml/f# with records and no idiomatic OOP at all (though they are functional-first which can have it's own issues)

Anyway TLDNR; - ecosystems where you have GC but do native compilation and don't encourage tons of OOP Objects seem to get good performance (ocaml, d, for instance)

I don't know that gc in isolation is the first order problem, but the confluence of virtual machines, plus oop idioms which encourage heap allocation, plus a culture of "who cares" with gc on top of all that is definitely a problem.

jon


http://pcwalton.github.io/blog/20...iew-of-memory-management-in-rust/

Note that, at this link, when he says "smart pointer" he doesn't necessarily mean the equivalent of a C++ smart pointer with a bunch of weird code wrapped into it. Very often these are just the same as regular raw pointers, it's just that the compiler understands them more.

Or in other words the "smartness" of the smart pointers in rust is in the compiler and not in the assignment operator/constructor and destructor of a "smart pointer" struct.

jon
Note that, at this link, when he says "smart pointer" he doesn't necessarily mean the equivalent of a C++ smart pointer with a bunch of weird code wrapped into it. Very often these are just the same as regular raw pointers, it's just that the compiler understands them more.

Smart pointers were removed from Rust, now there are only "raw pointers", and "references". IIRC, they removed smart pointers because they could not reason about correctness of usage of smart pointers.
References are pointers, but the usage is checked for correctness at compile-time.

I wonder if it's possible to do "reference" annotation for C code to run borrow checking.
This will probably fail for most C code out there.

So what's the deal? It seems my professors are just straight up wrong. Do pointers become a problem with large projects? Maybe programming casey-style resolves common points of pointer errors?

Here is the question. What are the true pros / cons of pointers?

I'm going to say some cons of using pointers/pointer arithmetics.

If you make a mistake when you work with pointers, the results are likely to be disastrous, see: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow, https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pointer
There are very few things in programming that cause arbitrary code execution all the time, and simple mistakes in pointer arithmetics is one of them.
You have to be perfect not to make such mistakes.
It's really hard to be perfect all the time, and vast majority of programmers are not perfect.

Some C interfaces force you to cast your pointers to "void*", which makes you lose any type safety you had. It's the same with Java, with their generics implementation.

There are compiler optimizations that may be unavailable to you if you choose to use pointer arithmetics. The less constraints you give to compiler, the more space it has for optimizations. Using pointer arithmetics directly is a big constraint.
For example, if you chose to store an int with 1-byte offset off your pointer, the alignment will be wrong, which will slow down your code on some architectures, and the compiler can't help you.
Of course, there are cases when compiler is stupid and it will be better for you to do some bit fiddling, but this does not happen most of the time.