191–200 of 207 posts
Earlier quoted context omitted.
Or you could just use a language whose implementation doesn't blow.
And suffer from 5x slower development time. Yeah your deadline now has to be extended from 2012 to 2015 but at least the language is FAST and is technically excellent, right?
Reference counting is GC; a poor form if it's the only thing you rely on, but it is automatic memory management all the same. Generational GC will frequently use the (L2/L3) cache size itself as its smallest generation, meaning it shouldn't suffer from the pathologies talked about by Linus here. What GC really gives you, though, is the freedom to write code in a functional and referentially transparent way. Writing f…
GC code runs differently depending on the code running around it. It causes the code to be non deterministic, and introduces a side effect. I've written code in a reference counted language(python) which processes about a gigabyte of data per second from the network, with hard real time requirements - all on one machine with multiple cpus/cores. The code is fully unit tested, doc tested, and functionally tested. It's…
We should really encourage eachother to put the date in the title when submitting old articles to HN. It's a total brainf*k to read through the entire article, and not realize the context it was in.. or to just glance at the title and assume the topic is a current one. Just saying. [Edit] Not that I have a problem with older posts, btw.. I actually really like them most of the time. But the date would give everyone a…
Is it just me, or does the title say (2002) to give you context?
Earlier quoted context omitted.
I like simplicity. Simplicity tends to perform well, and being simple also means it has little space for problems. Amen. I saw an old interview with Chuck Moore a while ago in which he said: I like simplicity and efficiency. That struck me. How often do people put those two things together? We're conditioned to think of them as a tradeoff. But if you can have both, shouldn't we be trying hard for that? Which raises a…
In my experience, it takes an incredible amount of effort and experience to solve a complex problem with simplicity and efficiency. It's well worth it, but there's definitely a cost, and not everyone is capable of it.
That's one thing that's so intriguing about Moore. He's a living specimen of an alternate computing history. I sometimes wonder what would have happened if he had been in, say, Backus's position at the dawn of high-level languages.
Earlier quoted context omitted.
cpp avoids reprocessing: http://gcc.gnu.org/onlinedocs/cpp/Once_002dOnly-Headers.html Processing header files in the first place is certainly a problem affecting C, but I believe optimizations take more time. Parsing is a much larger problem for C++.
I meant reprocessing the same set of header files for every single cpp file including them. Precompiled headers suppose to speed it up. But they still need to be read in and re-created in memory for each cpp file. Why not just compile all the cpp files in one process rather than spawning off a compiler process for every file? That can ensure reusing all the header files processed and are still in memory. My point is:…
This is just mmap for Clang. For GCC it... isn't. The other one you mentioned is called a compile server and nobody seems to have cared enough to implement it.
> If they ran the profiler and L1/L2 cache misses are really the problem, then I have nothing else to say.
Earlier quoted context omitted.
Python doesn't do code analysis to determine when it's effectively doing obj.refs++; obj.refs-- repeatedly. This sort of analysis is useful, and if the interpreter had been designed to do any optimization along with jitting, would probably come nearly for free. Reference counting could be far far cheaper than it is in python. (How much cheaper? I don't know - it'd need work to figure it out)
This sort of analysis does not come easily. Say you have: def bar(): return some_constructor() def foo(): b = bar() Here the decrement is in bar() and the increment is in foo(). You have no way to elide the operation without doing inter-procedural analysis, which is hard.
Earlier quoted context omitted.
That's rarely a realistic option if you use any Cocoa library code. autorelease is a pretty fundamental aspect of the Cocoa design.
Wouldn't it be more accurate to say that it's not a realistic option for objects that come from or depend on Cocoa library code? Or would the mere act of using cocoa in one part of my application somehow prevent me from exploiting such an opportunity in another part of my application? My instinct says that, for example, a plain C library that used such techniques would not cease to function just by being linked into…
What I meant, however, is that most nontrivial Cocoa apps are likely to end up with a checkerboard allocation pattern, where the client allocated, controlled-lifetime objects are interspersed with Cocoa library allocated autoreleased objects with somewhat longer lifetimes, which may interfere to some extent with any strategy relying on controlling your object lifetime.
Still, people can and do avoid autoreleasing objects if their lifetimes are well known in advance.
Earlier quoted context omitted.
The context of the copy-on-write win was the bytecode for modules. I don't know that you'd have anybody meddling with the reference counts for that...but I haven't really looked.
Bytecode is stored in function objects which IIRC are reference-counted.
Say you do "import smtplib" in your main file. Now that module is imported -- forever. I don't know the internals of Python well enough, but I bet that the module reference has strong references to its contents, so that even if nobody is actually calling anything in smtplib, it will be there in case someone does. The same should be true about modules importing other modules; they stay visible at the scope-level, so they are permanently loaded.
So for those cases it would make sense to keep them separate from global garbage collection. I'm pretty sure that the method tables of all the classes in the system take up considerable space, probably in the order of megabytes for many apps.
Earlier quoted context omitted.
~$5k for 7 KLOC of bug free C code is a steal, that's impossible to do in less than a couple of months
It's nearly impossible to do in any timeframe. I can think of perhaps two examples in human history where I think it's been done: qmail and seL4. And there may still be bugs in qmail. There may be a few other non-public projects that have achieved less than one bug per 7000 lines of C, but probably not more than one or two.
There are also some DNS-related bugs that are not on this list.
Earlier quoted context omitted.
I meant reprocessing the same set of header files for every single cpp file including them. Precompiled headers suppose to speed it up. But they still need to be read in and re-created in memory for each cpp file. Why not just compile all the cpp files in one process rather than spawning off a compiler process for every file? That can ensure reusing all the header files processed and are still in memory. My point is:…
> But they still need to be read in and re-created in memory for each cpp file. This is just mmap for Clang. For GCC it... isn't. The other one you mentioned is called a compile server and nobody seems to have cared enough to implement it. > If they ran the profiler and L1/L2 cache misses are really the problem, then I have nothing else to say. http://gcc.gnu.org/ml/gcc/2011-04/msg00315.html
That's an interesting problem in doing a lot of lookup from main memory since the data structures are too big to fit in L1/L2. But that usage is not allocating a lot of short lived objects and freeing them, and reusing the freed memory right the way for next allocations. That's what Linus arguing for to reused the L1/L2 for the short lived objects, and thus GC is inappropriate. I would imagine compilers typically allocate objects that have long lifetime, such as declarations that have scope through the whole compile cycle. Also if memory allocation/deallocation is really a performance problem, then don't deallocate, just reuse the buffers. Reusing the same set of buffers would make sure they are hot in L1/L2.
Anyway it has been an interesting discussion.