3 ms·

It's not clear what he's referring to. It could be garbage collection, libraries, frameworks, optimizing compilers... - Garbage collection make performance u

by jkabrg 8y ago

It's not clear what he's referring to. It could be garbage collection, libraries, frameworks, optimizing compilers... - Garbage collection make performance unpredictable because of collection spikes. - If you use a big library, you now have to load the library, which is an extra time-sink. - Likewise for frameworks. - Optimizing compilers optimize the 80% of our programs that don't need optimizing, and under-optimize the 20% that do. (This is DJB's argument.) That might be what he's saying. He didn't say anything about dynamic vs. static typing. Also, there's a counter-argument to this, that writing non-garbage-collected code might result in security bugs (to do with memory management). And security is a non-functional requirement that some might say is more important than speed. It's hard to judge though; there are loads of requiremenets in software dev, and it's hard to balance them.

ghaff 8y ago
All those things could be the case. I'm not advocating any specific approach. I'm just saying that, if you make performance/efficiency job #1 and make all other language, tools, hiring, and project timeline decisions in service of that goal, you probably make some decisions that are different from today's norm.
- gameswithgo 8y ago
  Right, and I think there are lot of decisions we could make that would improve efficiency without downsides, if we could somehow change what are the popular ecosystems from things like Python/Ruby to other ones that are more efficient with similar ergonomics.
Elv13 8y ago
> Also, there's a counter-argument to this, that writing non-garbage-collected code might result in security bugs (to do with memory management). That's falacy. Don't mix "fully manual memory management" with "I have no GC". Those are 2 totally unrelated topics. GC is one of the way to manage memory automatically. There is hundreds with their own plus-sides and downsides. Here's the least unpopular: * Stop the world and incremental GC: Makes it easy to write simple code. Doesn't really make the lifecycle explicit so when the codebase grow larger you start to have boilerplate code to manage/close connections/files/transactions. (all toys languages, also Java and Go). * Reference counting: Can be made fast enough by using some of the pointer 64bits to store its state. A giant problem is that all your libraries have to support compatible "smart pointer" formats or the whole thing become unmanageable. (Modern C++) * Contacts/Lending: Does it's job, is safe but makes the code more complex by making a lot of implicit things explicit (Rust, Modern C++) * Explicit ownership + message passing: works well enough for GUI because just like HTML everything is less or more a tree. Also consuming messages allow "higher level" objects not to have to care about pointers. For backend code it's not very good. (Qt-C++) * Pure functional: Everything is a copy, they get freed when out of scope. Works well for some domain, but gets in your way for more stateful constructs. * Copy-on-Write: Pass everything by reference (and count them). Copy when they are modified, otherwise point to the real memory. Only solves half of the problem. Assuming most allocations are containers it works well enough. It doesn't attempt to solve objects management. * Pipelining: Get input, process them, pass them on or free them. The processing should not have to dynamically allocate at all (Bash, Erlang). * Pre-allocation: Allocate everything at compile time and use buffers big enough for your use case. (C) * State machines: Encode the object lifecycle as a series of state changes. Release when it reaches end-of-life. Great for protocols, parsing, transactions. You usually can use code generators to generate proven safe C from an higher level format or proof. However it doesn't scale and only matches a subset of programming projects. It's also hard to learn for non EE programmers because it doesn't map perfectly on the iterative Von Neumann CPU. Easy to read but hard to write. No-GC != security-bugs because of memory management. If a C program uses pre-allocated buffers, then the security issues is because the language is unsafe, not because it has no GC.

by jkabrg 8y ago

ghaff 8y ago

All those things could be the case. I'm not advocating any specific approach. I'm just saying that, if you make performance/efficiency job #1 and make all other language, tools, hiring, and project timeline decisions in service of that goal, you probably make some decisions that are different from today's norm.

gameswithgo 8y ago
Right, and I think there are lot of decisions we could make that would improve efficiency without downsides, if we could somehow change what are the popular ecosystems from things like Python/Ruby to other ones that are more efficient with similar ergonomics.

Elv13 8y ago

> Also, there's a counter-argument to this, that writing non-garbage-collected code might result in security bugs (to do with memory management). That's falacy. Don't mix "fully manual memory management" with "I have no GC". Those are 2 totally unrelated topics. GC is one of the way to manage memory automatically. There is hundreds with their own plus-sides and downsides. Here's the least unpopular: * Stop the world and incremental GC: Makes it easy to write simple code. Doesn't really make the lifecycle explicit so when the codebase grow larger you start to have boilerplate code to manage/close connections/files/transactions. (all toys languages, also Java and Go). * Reference counting: Can be made fast enough by using some of the pointer 64bits to store its state. A giant problem is that all your libraries have to support compatible "smart pointer" formats or the whole thing become unmanageable. (Modern C++) * Contacts/Lending: Does it's job, is safe but makes the code more complex by making a lot of implicit things explicit (Rust, Modern C++) * Explicit ownership + message passing: works well enough for GUI because just like HTML everything is less or more a tree. Also consuming messages allow "higher level" objects not to have to care about pointers. For backend code it's not very good. (Qt-C++) * Pure functional: Everything is a copy, they get freed when out of scope. Works well for some domain, but gets in your way for more stateful constructs. * Copy-on-Write: Pass everything by reference (and count them). Copy when they are modified, otherwise point to the real memory. Only solves half of the problem. Assuming most allocations are containers it works well enough. It doesn't attempt to solve objects management. * Pipelining: Get input, process them, pass them on or free them. The processing should not have to dynamically allocate at all (Bash, Erlang). * Pre-allocation: Allocate everything at compile time and use buffers big enough for your use case. (C) * State machines: Encode the object lifecycle as a series of state changes. Release when it reaches end-of-life. Great for protocols, parsing, transactions. You usually can use code generators to generate proven safe C from an higher level format or proof. However it doesn't scale and only matches a subset of programming projects. It's also hard to learn for non EE programmers because it doesn't map perfectly on the iterative Von Neumann CPU. Easy to read but hard to write. No-GC != security-bugs because of memory management. If a C program uses pre-allocated buffers, then the security issues is because the language is unsafe, not because it has no GC.