1.) The GC article on wikipedia that you linked to starts off by saying "garbage collection (GC) is a form of automatic memory management." Your own source directly contradicted one of your statements!
2.) One argument for the more specific use of "garbage collection" to refer to just tracing collectors is by way of the other use of "garbage collection", which is the process that happens usually once a week where people come by and get your trash cans, then take all the garbage you've generated over the course of that week and take it to the dump. They don't come by every time you unwrap or empty a food container, just like tracing collectors don't come by as soon as the program generates new garbage by making part of the heap graph unreachable; yet that would be the analog to reference counting.
Looks like you are too insistent on there being exactly one definition for "garbage collection."
First, you say that garbage collection can be automatic or manual. And while it's true that you'll sometimes see "automatic garbage collection" used to be specific, you essentially never hear people use "garbage collection" to refer to anything but automatic GC. It's possible that the only times I have is in statements like "we use the term 'automatic garbage collection' to make it clear that it is not manual." I can't find a citation for where the term was first used. Remember, you can't always say that the meaning of a compound term is just the composition of its parts! (Look how many Slashdotters think that "kliobyte" is rightfully 1024 bytes.)
Second, it's not even the case that the common use of GC refers to just automatic memory management in general. It's definitely commonly used to refer specifically to tracing collectors, excluding (pure) reference counting. I don't particularly like this usage, but it's widespread enough I think it's really hard to say it's wrong. (I like to use "automatic memory management" for the catchall and "tracing GC" for, well, tracing GCs.)
stdio is part of standard libc, so you don't need to link in any libraries to use putc(string,stdout).
You need to check yourself on that. You don't need to explicitly instruct the compiler to include additional libraries because, as Kielistic says, compilers include it by default.
Here's a hint: libc... is a library.
Here, I'll prove it:
$ cat printf.c #include <stdio.h>
int main() {
printf("Hello %s!\n", "world"); }
$ gcc -o empty -nostdlib printf.c /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000400144 /tmp/ccwbCMMw.o: In function `main': printf.c:(.text+0x17): undefined reference to `printf' collect2: ld returned 1 exit status
See, I would describe "generational" as a GC algorithm where you have separate memory spaces for objects of different ages. And I really don't see how you can do that without moving objects -- ergo not mark-and-sweep by my definition.
He made two freaking posts in this story! I've gone a lot more crazy than that on stories where half the comments are asinine statements not grounded in reality, with conflict of interest in any of the topics being discussed. Since when is wanting to correct misunderstandings or misconceptions so defensive as to warrant calling someone a shill?
So I just checked, and the dragon book does agree with my interpretation that mark-and-sweep is a specific GC algorithm that is non-moving and runs in time proportional to the total number of heap blocks (live and dead). It also agrees that generational GCs are moving collectors.
The reason why more memory makes it seem like GC is faster is simply because with more memory you can just let junk sit around longer, and then destroy the entire heap all at once. At least, for web pages, which tend to be ephemeral. That doesn't work well for long-lived server processes though, in Java or C#, which can't avoid constantly cycling through all memory.
It's more than that though, and it's not just that it seems faster -- it is faster. And it's not just because your program may end before needing to collect or something like that.
The reason that GCs are memory intensive is because of the design of good GCs, which are usually generational. They have multiple memory spaces, and move objects between them. The presence of those spaces are what increases the memory requirement, because you need to make them big enough to contain a bunch of dead objects too or you'll hit the performance wall I'll talk about in a second. The GC will actually move objects from one space to another.
The reason that having too little memory hurts is not just because your GC runs more frequently, but you start losing out on the benefits of having those multiple spaces. The division between long-lived and short-lived objects starts to diminish, because an object doesn't have to live as long to get promoted to the next generation. You might promote objects to the oldest generation sooner, and the older generation loses out on some of the mitigating reasons why GC doesn't have to be so bad.
In short, GC actually works well speedwise even for long-lived processes, in spite of them churning through memory. They just need more memory (3-5x) to get the same performance.
Generational GC can still be mark and sweep (and most of them are).
So looking around, it seems like "mark and sweep" does not have a single meaning. I didn't actually know this, and it means that I was wrong to say that the AC I replied to was wrong.
However, I learned "mark and sweep" (and my use is supported by this survey paper and, I believe, the second edition of the dragon book (see, e.g., the lecture 17 slides from here) though I can't check right now) to be a specific GC algorithm that basically works like an automated free() that traces and marks reachable objects then walks all heap blocks and frees any unmarked blocks. Specifically, this is a non-moving collector.
I also learned generational GCs to necessarily be moving collectors, though I suppose you could come up with some somewhat convoluted scheme that does not do this and would still be somewhat deserving of the term.
I'm not sure, but suspect that my usage is more standard.
As opposed to the standard mark and sweep garbage collecting like those in Java where every few seconds everything grinds to a hold to clean up memory.
Not to say that tracing collectors don't have a bit of a stuttring problem and I don't want to get into tracing vs reference counting, but:
1) Decent tracing collectors (and the Java VM has had one for a while) are not nearly as bad as you make them out to be, and
2) You mean "tracing collector" rather than mark-and-sweep. The latter is just the simplest form of tracing collectors, which is really pretty bad and is essentially never used. The JVM uses a generational collector,.Net uses a semispace collector (I think), all three of which differ pretty significantly in both mechanics and performance characteristics.
The second point is a bit pedantic and in many stories I probably wouldn't even reply, but in a discussion that is basically specifically about GC it is a good idea to use correct terminology.
It's a win in spreadsheets and anything with sparse matrices.
It can be; doesn't have to be. No one says you have to represent sparse matrices in a dense manner; that's a choice like text vs binary. Of course you could do the same thing in text, but the more complicated the textual format, the fewer benefits from using text you get.
It's a lose in databases, which are almost always data-intensive,
I would also put configuration files as a loss, actually. (In some sense those are databases.) A lot of keys "have to" be written out explicitly, whereas a binary format can use either a shorter characterization or even none at all.
Of course, the non-efficiency benefits from making config files editable in text editors and such outweighs the efficiency arguments there.
We did a number of sanity-tests before using it in Ability, and later did a check using customer data that had been given to us, from which comes the characterization above.
And, just to add injury to insult, a 64-bit binary floating point zero is four times the length of an ascii zero followed by a space or newline.
Of course the flip side of that is that "100\n" is four times longer than 0x64.
And not only that, but if you aren't interested in the value of that field, in the text format you have to parse it anyway to find the end.
There are cases where text is more efficient (e.g. your spreadsheet example), but I would guess that, on balance, it goes the other way more of the time.
When's the last time you heard someone complain about the gzip header being binary instead of text? (Header, not actual payload.) Any other compression formats?
Heck, what about binary formats themselves? You have to use assemblers and disassemblers to deal with machine code; that certainly hasn't hurt their adoption. (Yes, of course there are reasons why a human-readable executable format wouldn't be practical -- for instance, the memory density would be too low, and it matters -- but it's still a binary format for which there are plenty of tools. And there's no technical reason why it couldn't be done, at least after macros are expanded and addresses patched in. That would still leave the executable format human-readable)
On the text side, you have things like XML formats which, while technically text, are still essentially completely opaque. So not only are there widely- and well-accepted open binary formats, but there are essentially-closed text formats. (Compare Impress's support of the binary PPT file vs the "text" PPTX file for instance, and see how much better the former is than the latter. Don't know what the story is with Writer/DOC/DOCX.)
You talk about how safety arises when there is a critical mass of adoption that resists embrace/extend/extinguish. And maybe 10 years ago I would have agreed that there was a danger of someone like MS pulling an embrace/extend/extinguish, but I think that no one has that clout to do it now. Possibly not even any two companies in collusion; you may need Google + MS + Apple. (Leave out Apple and you leave out a ton of mobile. Leave out Google and you leave out Chrome and, well, Google. Leave out MS and you leave out IE on Windows.)
We're talking about a format for something that even hardcore computer nerds rarely deal with; it's not something like HTML where every so often you might get an urge to scrape something from a web page or something like that.
Despite what you argue, I disagree that there's any real reason why a binary HTTP 2.0 would be any more or less likely to be co-opted than a textual format. Really I think the main reason to worry -- and it's a minor one until they release a spec -- is what it suggests of the mindset of the people working on it. But again, that's correlative rather than causative.
Finally, in case of HTTP there is exactly *zero* benefit from switching to binary representation....The only place where HTTP could be improved is latency as it scales slower than network bandwidth but that has nothing to do with the format.
I suspect it's more the fact that they were working on 2.0 anyway because of other reasons (e.g. multiplexing connections to improve latency, which I don't know enough about to contrast with the existing approaches), and just decided benefits of the binary format -- "tiny" is nonzero -- outweigh the (IMO) small cost.
I know. That's why I prefer machines that run assembly text directly, instead of that dreaded machine code that I have to use a disassembler to understand.
LibreOffice refers to this as "web layout", and its right there in the view menu.
No. LibreOffice's "web layout" is the same as Word's "web layout", which is different from Word's draft/normal view. And (at least IMO) it's even worse than page layout.
Page layout displays the page to too great of fidelity, because the top and bottom margins break up the flow of text. Web layout goes too far in the other direction, completely reflowing the text to the width of the window.
Displaying page boundaries, headers & footers, etc is of exactly zero benefit while one is composing the text of the document.
I beg to differ, sir!
It is not exactly zero benefit. It is actively distracting, and hence of negative benefit.
Incidentally, there's an 11-year-old bug report with 281 votes (there are only two bug reports with more votes) if you want to add your voice. I rarely use word processors (Latex here, as much as I hate it there's not really anything better for what I need), but if I did, I'd use Word almost on account of the lack of a normal view alone.
Films are shot with widescreen in mind because that's what everyone watches.
I disagree. Nearly all* films were widescreen before 16:9 monitors and TVs were really offered, and even now most are significantly wider than 16:9.
That's not quite what you said, but IMO them main reason widescreen became popular in the first place is because of what I said before: it's just better. There's much less reason to make them taller than there is wider. A taller screen means you can see more sky or ceiling. A wider screen means you can see more people around the room. I guess with a taller aspect ratio you could have people closer to the camera without them getting cut off.
* [citation needed] really, but it's an informal observation. I did look at the IMDB top 100 list, and looked at the top 10 movies created between 1985 and 1995 inclusive (a range I selected from after TVs were common but stopping well before 16:9 were even commonly sold, IIRC). Three of the movies were shot in 1.85:1, and the other seven were shot in 2.35:1.
And now you've lost your extra height.:-) Anyway, I find myself using the full height of the console a ton. This may be me just not being as good at doing stuff in emacs as I should be*, but things like compiler error messages (especially in C++, it's common for a single error to take several lines even before wrapping) or the result of a recursive grep are way harder to scan over if you can only see a few lines at once.
* OTOH, this doesn't really make a difference. I'd still rather have compiler messages displayed side-by-side regardless of what it's displayed in.
Actually I think 22" in portrait mode is pretty good if you want a single-width thing with lots of height, though I'm not sure what you mean by "document production" (I code).
Again, I guess this just boils down to preference. But personally, I think that the benefits of 4:3 are overrated. It would be nice if there were more options there though.
I agree code wrapping is annoying, but that's when you simply overlap windows (or use tabs) and get more vertical view for each window.
I guess this comes down to preference. You say "simply overlap windows"; I say "simply scroll". I'd rather have an editor and console open side-by-side than I would a few extra lines of text.
You can still make things narrower (or overlap) to fit side by side, you can't fix height cropping.
If you make things too narrow, they crop or wrap annoyingly. Things like code especially suffer, as if you get narrower than 80 characters it becomes almost unreadable.
Personally, my viewpoint on "you can't fix height cropping" is that in some ways the fact that text scrolls naturally vertically almost makes it better to crop that way. If I had to choose vertical cropping (within reason, e.g. the difference between 4:3 and 16:9) or horizontal cropping, I'd choose vertical in an instant and never regret it.
So you take a measurement that you claim is dumb because it means something different on different monitors, and suggest a replacement that.... is equally dumb and means something equally different on different monitors?
You suggest height probably because you consider height the most important monitor measure (along with many/.'ers). But this isn't the only viewpoint, by far.
Slashdot Mirror
Two additional points:
1.) The GC article on wikipedia that you linked to starts off by saying "garbage collection (GC) is a form of automatic memory management." Your own source directly contradicted one of your statements!
2.) One argument for the more specific use of "garbage collection" to refer to just tracing collectors is by way of the other use of "garbage collection", which is the process that happens usually once a week where people come by and get your trash cans, then take all the garbage you've generated over the course of that week and take it to the dump. They don't come by every time you unwrap or empty a food container, just like tracing collectors don't come by as soon as the program generates new garbage by making part of the heap graph unreachable; yet that would be the analog to reference counting.
Looks like you are too insistent on there being exactly one definition for "garbage collection."
First, you say that garbage collection can be automatic or manual. And while it's true that you'll sometimes see "automatic garbage collection" used to be specific, you essentially never hear people use "garbage collection" to refer to anything but automatic GC. It's possible that the only times I have is in statements like "we use the term 'automatic garbage collection' to make it clear that it is not manual." I can't find a citation for where the term was first used. Remember, you can't always say that the meaning of a compound term is just the composition of its parts! (Look how many Slashdotters think that "kliobyte" is rightfully 1024 bytes.)
Second, it's not even the case that the common use of GC refers to just automatic memory management in general. It's definitely commonly used to refer specifically to tracing collectors, excluding (pure) reference counting. I don't particularly like this usage, but it's widespread enough I think it's really hard to say it's wrong. (I like to use "automatic memory management" for the catchall and "tracing GC" for, well, tracing GCs.)
You need to check yourself on that. You don't need to explicitly instruct the compiler to include additional libraries because, as Kielistic says, compilers include it by default.
Here's a hint: libc... is a library.
Here, I'll prove it:
Feel like giving a citation?
See, I would describe "generational" as a GC algorithm where you have separate memory spaces for objects of different ages. And I really don't see how you can do that without moving objects -- ergo not mark-and-sweep by my definition.
with no conflict of interest in any of the topics being discussed
Fixed. Was changing around wording and didn't correct the positive/negative sense.
He made two freaking posts in this story! I've gone a lot more crazy than that on stories where half the comments are asinine statements not grounded in reality, with conflict of interest in any of the topics being discussed. Since when is wanting to correct misunderstandings or misconceptions so defensive as to warrant calling someone a shill?
So I just checked, and the dragon book does agree with my interpretation that mark-and-sweep is a specific GC algorithm that is non-moving and runs in time proportional to the total number of heap blocks (live and dead). It also agrees that generational GCs are moving collectors.
It's more than that though, and it's not just that it seems faster -- it is faster. And it's not just because your program may end before needing to collect or something like that.
The reason that GCs are memory intensive is because of the design of good GCs, which are usually generational. They have multiple memory spaces, and move objects between them. The presence of those spaces are what increases the memory requirement, because you need to make them big enough to contain a bunch of dead objects too or you'll hit the performance wall I'll talk about in a second. The GC will actually move objects from one space to another.
The reason that having too little memory hurts is not just because your GC runs more frequently, but you start losing out on the benefits of having those multiple spaces. The division between long-lived and short-lived objects starts to diminish, because an object doesn't have to live as long to get promoted to the next generation. You might promote objects to the oldest generation sooner, and the older generation loses out on some of the mitigating reasons why GC doesn't have to be so bad.
In short, GC actually works well speedwise even for long-lived processes, in spite of them churning through memory. They just need more memory (3-5x) to get the same performance.
So looking around, it seems like "mark and sweep" does not have a single meaning. I didn't actually know this, and it means that I was wrong to say that the AC I replied to was wrong.
However, I learned "mark and sweep" (and my use is supported by this survey paper and, I believe, the second edition of the dragon book (see, e.g., the lecture 17 slides from here) though I can't check right now) to be a specific GC algorithm that basically works like an automated free() that traces and marks reachable objects then walks all heap blocks and frees any unmarked blocks. Specifically, this is a non-moving collector.
I also learned generational GCs to necessarily be moving collectors, though I suppose you could come up with some somewhat convoluted scheme that does not do this and would still be somewhat deserving of the term.
I'm not sure, but suspect that my usage is more standard.
Not to say that tracing collectors don't have a bit of a stuttring problem and I don't want to get into tracing vs reference counting, but:
1) Decent tracing collectors (and the Java VM has had one for a while) are not nearly as bad as you make them out to be, and
2) You mean "tracing collector" rather than mark-and-sweep. The latter is just the simplest form of tracing collectors, which is really pretty bad and is essentially never used. The JVM uses a generational collector, .Net uses a semispace collector (I think), all three of which differ pretty significantly in both mechanics and performance characteristics.
The second point is a bit pedantic and in many stories I probably wouldn't even reply, but in a discussion that is basically specifically about GC it is a good idea to use correct terminology.
It can be; doesn't have to be. No one says you have to represent sparse matrices in a dense manner; that's a choice like text vs binary. Of course you could do the same thing in text, but the more complicated the textual format, the fewer benefits from using text you get.
I would also put configuration files as a loss, actually. (In some sense those are databases.) A lot of keys "have to" be written out explicitly, whereas a binary format can use either a shorter characterization or even none at all.
Of course, the non-efficiency benefits from making config files editable in text editors and such outweighs the efficiency arguments there.
That sounds totally reasonable.
Of course the flip side of that is that "100\n" is four times longer than 0x64.
And not only that, but if you aren't interested in the value of that field, in the text format you have to parse it anyway to find the end.
There are cases where text is more efficient (e.g. your spreadsheet example), but I would guess that, on balance, it goes the other way more of the time.
Heck, what about binary formats themselves?
Shoot, meant to say "what about the actual machine code formats themselves".
That's correlation, not causation.
When's the last time you've seen someone complain that an ELF header is specified as
instead of looking like
or something like that?
When's the last time you heard someone complain about the gzip header being binary instead of text? (Header, not actual payload.) Any other compression formats?
Heck, what about binary formats themselves? You have to use assemblers and disassemblers to deal with machine code; that certainly hasn't hurt their adoption. (Yes, of course there are reasons why a human-readable executable format wouldn't be practical -- for instance, the memory density would be too low, and it matters -- but it's still a binary format for which there are plenty of tools. And there's no technical reason why it couldn't be done, at least after macros are expanded and addresses patched in. That would still leave the executable format human-readable)
On the text side, you have things like XML formats which, while technically text, are still essentially completely opaque. So not only are there widely- and well-accepted open binary formats, but there are essentially-closed text formats. (Compare Impress's support of the binary PPT file vs the "text" PPTX file for instance, and see how much better the former is than the latter. Don't know what the story is with Writer/DOC/DOCX.)
You talk about how safety arises when there is a critical mass of adoption that resists embrace/extend/extinguish. And maybe 10 years ago I would have agreed that there was a danger of someone like MS pulling an embrace/extend/extinguish, but I think that no one has that clout to do it now. Possibly not even any two companies in collusion; you may need Google + MS + Apple. (Leave out Apple and you leave out a ton of mobile. Leave out Google and you leave out Chrome and, well, Google. Leave out MS and you leave out IE on Windows.)
We're talking about a format for something that even hardcore computer nerds rarely deal with; it's not something like HTML where every so often you might get an urge to scrape something from a web page or something like that.
Despite what you argue, I disagree that there's any real reason why a binary HTTP 2.0 would be any more or less likely to be co-opted than a textual format. Really I think the main reason to worry -- and it's a minor one until they release a spec -- is what it suggests of the mindset of the people working on it. But again, that's correlative rather than causative.
I suspect it's more the fact that they were working on 2.0 anyway because of other reasons (e.g. multiplexing connections to improve latency, which I don't know enough about to contrast with the existing approaches), and just decided benefits of the binary format -- "tiny" is nonzero -- outweigh the (IMO) small cost.
I know. That's why I prefer machines that run assembly text directly, instead of that dreaded machine code that I have to use a disassembler to understand.
No it doesn't.
And to finish my thought, the reason this is bad is because the text area is then too wide unless your window is too narrow to contain full toolbars.
No. LibreOffice's "web layout" is the same as Word's "web layout", which is different from Word's draft/normal view. And (at least IMO) it's even worse than page layout.
Page layout displays the page to too great of fidelity, because the top and bottom margins break up the flow of text. Web layout goes too far in the other direction, completely reflowing the text to the width of the window.
I beg to differ, sir!
It is not exactly zero benefit. It is actively distracting, and hence of negative benefit.
Incidentally, there's an 11-year-old bug report with 281 votes (there are only two bug reports with more votes) if you want to add your voice. I rarely use word processors (Latex here, as much as I hate it there's not really anything better for what I need), but if I did, I'd use Word almost on account of the lack of a normal view alone.
Films are shot with widescreen in mind because that's what everyone watches.
I disagree. Nearly all* films were widescreen before 16:9 monitors and TVs were really offered, and even now most are significantly wider than 16:9.
That's not quite what you said, but IMO them main reason widescreen became popular in the first place is because of what I said before: it's just better. There's much less reason to make them taller than there is wider. A taller screen means you can see more sky or ceiling. A wider screen means you can see more people around the room. I guess with a taller aspect ratio you could have people closer to the camera without them getting cut off.
* [citation needed] really, but it's an informal observation. I did look at the IMDB top 100 list, and looked at the top 10 movies created between 1985 and 1995 inclusive (a range I selected from after TVs were common but stopping well before 16:9 were even commonly sold, IIRC). Three of the movies were shot in 1.85:1, and the other seven were shot in 2.35:1.
And now you've lost your extra height. :-) Anyway, I find myself using the full height of the console a ton. This may be me just not being as good at doing stuff in emacs as I should be*, but things like compiler error messages (especially in C++, it's common for a single error to take several lines even before wrapping) or the result of a recursive grep are way harder to scan over if you can only see a few lines at once.
* OTOH, this doesn't really make a difference. I'd still rather have compiler messages displayed side-by-side regardless of what it's displayed in.
Actually I think 22" in portrait mode is pretty good if you want a single-width thing with lots of height, though I'm not sure what you mean by "document production" (I code).
Again, I guess this just boils down to preference. But personally, I think that the benefits of 4:3 are overrated. It would be nice if there were more options there though.
I agree code wrapping is annoying, but that's when you simply overlap windows (or use tabs) and get more vertical view for each window.
I guess this comes down to preference. You say "simply overlap windows"; I say "simply scroll". I'd rather have an editor and console open side-by-side than I would a few extra lines of text.
You can still make things narrower (or overlap) to fit side by side, you can't fix height cropping.
If you make things too narrow, they crop or wrap annoyingly. Things like code especially suffer, as if you get narrower than 80 characters it becomes almost unreadable.
Personally, my viewpoint on "you can't fix height cropping" is that in some ways the fact that text scrolls naturally vertically almost makes it better to crop that way. If I had to choose vertical cropping (within reason, e.g. the difference between 4:3 and 16:9) or horizontal cropping, I'd choose vertical in an instant and never regret it.
So you take a measurement that you claim is dumb because it means something different on different monitors, and suggest a replacement that.... is equally dumb and means something equally different on different monitors?
You suggest height probably because you consider height the most important monitor measure (along with many /.'ers). But this isn't the only viewpoint, by far.