Mark and sweep doesn't use reference counting. The mark stage looks at all pointers (references in Java), follows those pointers (and anything pointed to by the targets of those pointers) and marks all the things it finds as "reachable." Then the sweep stage goes through memory and deletes everything that wasn't marked as reachable.
In the case I mentioned (not many objects but constantly-changing pointers to them) this could have lower overhead, because you only do the mark stage periodically, instead of having to update a reference-count variable every time a pointer to the object changes (which could be potentially millions of times more often than the mark-and-sweep GC runs).
The other bits of philosophical content (epistemological skepticism, etc.) were introduced in the first film and not further developed any significant amount in this one (besides merely being reiterated).
Depending on how your program uses memory, it could be that other standard sorts of garbage collection -- mark and sweep, for example -- actually peform faster than reference counting. This would be true if, for example, you have a small number of objects being referred to by a constantly-changing large number of pointers; then the reference-counting overhead would be enormous, while the mark-and-sweep overhead would be fairly small.
In situations where CPU time is more important than RAM usage reference-counting could also be suboptimal, as you may not want to delete objects as soon as their reference count drops to 0 (instead you might want to wait for a lull in CPU usage and let an idle-priority thread clean them up when convenient). This is especially true if you have lots and lots of small objects (the CPU overhead of deleting objects 100x/second might be large, and if they're 50 bytes each, the RAM overhead of keeping them around a bit longer before deletion might be small).
Well, I don't remember details, but I was pretty sure there were some fundamental flaws found in the SSH1 protocol, though I'm not sure how severe they were.
Even just keeping diverse implementations is difficult though. If you wrote your software for Apache, you usually have to run Apache on all your webservers; if you need to use 3rd-party software written for Apache, the same goes. The only way this is really sustainable is if there are a small number of very major players of about equal strength (say, IIS and Apache) so that your 3rd-party stuff is readily available for both. Even this is hard to maintain for any length of time, and I think hoping for say 5-6 viable major implementations of any particular service is rather optimistic.
If I couldn't trust someone to use new and delete correctly, I wouldn't trust them to do much at all for me. Yes, there are many programmers that mess things up with these operators, but they aren't very good programmers. If you can't use new and delete or free and malloc correctly, then there's probably a lot of other things you can't do well either. Memory management is rather fundamental to computer science.
Sure, every good programmer should be able to do basic memory management, but in large complex programs it's not really as simple as you imply. In many cases, where an object can be referred to by arbitrarily many pointers in arbitrarily many locations, the programmer essentially has to manually implement their own garbage collection mechanism (most commonly through reference counting). This is often sub-optimal.
I do agree that it might be a good idea to allow more tuning to the garbage collector. Instead of telling it "delete, now" though, I'd prefer something along the lines of "force the GC to run now."
Heterogeneity is hard to maintain, because it's often the direct opposite of interoperability and maintainability. For example, the impact of various SSH vulnerabilities would've been minimized if people used a variety of secure shell methods instead of standardizing on SSH; but then it'd be a nightmare to connect to systems (you'd have to try out 5 clients or something).
The movie I saw wasn't "chock full of plot and philosophy" with "a few stylish action scenes". The movie I saw spent more than 60% of its screen time on action scenes, most of which were tediously drawn out far longer than they should've been, and which in any case lacked the subtle style of the first movie. The "philosophy" was a pretty half-baked discussion of the age-old question of free will.
Are you really saying that the two Matrix movies, the two LoTR movies, and Shawshank Redemption are the five best movies ever?
Perhaps you should watch the following, any of which are better than those five: A Clockwork Orange Apocalypse Now The Manchurian Candidate Citizen Kane One Flew Over the Cuckoo's Nest
I'd personally add a bunch more (Taxi Driver, Lawrence of Arabia, Bridge On the River Kwai, Ben-Hur, Full Metal Jacket, Dr. Strangelove, Mulholland Drive, etc.) but I think that's enough for now.
I do agree this is a problem, but in many cases the Java behavior is actually better; a lot of C/C++ slowdown is from realtime memory management, and could be sped up by saving up stuff to do later (this can be done manually with C++ allocators, but is often a pain in the ass).
A lot of them are things that actually used to be good advice, but for some reason or another (changes in hardware, compilers, etc.) aren't anymore. For example, it used to be a good idea in C to iterate through arrays by incrementing a pointer and dereferencing it instead of incrementing an index and then using array subscripting -- that way you had one increment per iteration, instead of one increment plus one offset calculation (basically you saved the addition that takes place during the array subscripting). However, on many modern C and C++ compilers in many situations, array subscripting will actually be faster than the pointer-incrementing method, because it's easier for the compiler to perform certain optimizations with. [Reference: Michael J. Scott, Programming Language Pragmatics (Morgan Kaufmann, 2000).]
There's quite a bit of other stuff like this out there as well.
but you can do that all without Ogg
on
Ogg Now An RFC
·
· Score: 1
There's no reason to use Ogg FLAC -- FLAC itself already supports all that. Ogg adds absolutely nothing (not even metadata tagging! Ogg says it's the responsibility of the bitstream it encapsulates to implement that itself).
I've seen numbers anywhere from 5%-200% penalty, though I don't have any references at the moment. It really depends on the app and where your main execution time lies. If you do a lot of tight loops over arrays, it's going to give you a significant performance hit. If you don't, it won't. So it's probably going to slow down your MP3 encoder a lot, but probably won't result in a noticeable slowdown for most userland apps. For most apps, which are I/O- rather than CPU-bound anyway, it's a good idea for security reasons. Same reason strncpy() is recommended over strcpy(), despite the performance hit due to bounds checking (in fact, strncpy() is just a special-case example of bounds checking).
I do realize that using base-2 has been standard in measuring storage space in computing for a while; I was referring to the prefix "Giga" itself, which has been an SI prefix for "10^9" for quite some time, with common usage in the sciences dating back at least 100-200 years. I'd imagine 2^10 was called "kilo" because it was close enough to an actual kilo, but 2^(10x) and 10^(3x) diverge as x increases, so that's getting increasingly confusing.
And the base-10 version is standard in everything now except for storage space, even computer-related stuff. Audio file bitrate as I mentioned is in base-10, network bandwidth is in base 10 (that's why 10 Mbps != 1.25 MiB/s. 10 Mbps = 10 000 000 bytes/s = 9.56 MiB/s), and so on.
giga = 10^9, and an 80 GB hard drive has 80 x 10^9 (10 billion) bytes. This is standard notation that has been in use for at least a hundred years. Perhaps what you're looking for is 80 GiB, which the hard drives are not advertised as.
This is standard even in most other parts of computing (anything engineering-oriented especially). For example, that 128kbps mp3 you downloaded is 128000 bits/second, not 128*1024 bits/second.
You just use fixed-point arithmetic instead of floating-point (i.e. a fixed 32 bits of precision, or 16 bits, or whatever). A simple way of doing is is to make INT_MAX/2 = 1.0, -INT_MAX/2 = -1.0, and everything in between scaled appropriately. (/2 to avoid overflow). Then you implement fixed-point addition, multiplication, division, and subtraction (as commonly doing in hardware DSP chips) and you've got yourself an integer-only FFT.
Some really old C code doing something along these lines is available here.
In the first Matrix, the fight scenes seemed to have a point. Here it seems like you could've taken most them out without any loss of continuity (with the exception of two or so). There simply wasn't anything that happened. Like in the first scene fighting lots of Smiths where he flies away at the end, why the hell didn't he fly away five minutes earlier?
I distracted greatly from the movie IMO, because something like 60-70% of the total screen time was taken up by mostly pointless fights that after a while didn't even look all that cool.
The pseudo-mathematical shit with the 'architect' was horrible. It reminded me of the movie The Net's attempt to use techno-jargon.
They also never explained why all fighting between programs is done with wire-fu, rather than through more powerful techniques such as "instantly make your head explode."
Slashdot Mirror
Mark and sweep doesn't use reference counting. The mark stage looks at all pointers (references in Java), follows those pointers (and anything pointed to by the targets of those pointers) and marks all the things it finds as "reachable." Then the sweep stage goes through memory and deletes everything that wasn't marked as reachable.
In the case I mentioned (not many objects but constantly-changing pointers to them) this could have lower overhead, because you only do the mark stage periodically, instead of having to update a reference-count variable every time a pointer to the object changes (which could be potentially millions of times more often than the mark-and-sweep GC runs).
The other bits of philosophical content (epistemological skepticism, etc.) were introduced in the first film and not further developed any significant amount in this one (besides merely being reiterated).
Depending on how your program uses memory, it could be that other standard sorts of garbage collection -- mark and sweep, for example -- actually peform faster than reference counting. This would be true if, for example, you have a small number of objects being referred to by a constantly-changing large number of pointers; then the reference-counting overhead would be enormous, while the mark-and-sweep overhead would be fairly small.
In situations where CPU time is more important than RAM usage reference-counting could also be suboptimal, as you may not want to delete objects as soon as their reference count drops to 0 (instead you might want to wait for a lull in CPU usage and let an idle-priority thread clean them up when convenient). This is especially true if you have lots and lots of small objects (the CPU overhead of deleting objects 100x/second might be large, and if they're 50 bytes each, the RAM overhead of keeping them around a bit longer before deletion might be small).
Reference counting is most certainly sub-optimal for a great many situations.
Well, I don't remember details, but I was pretty sure there were some fundamental flaws found in the SSH1 protocol, though I'm not sure how severe they were.
Even just keeping diverse implementations is difficult though. If you wrote your software for Apache, you usually have to run Apache on all your webservers; if you need to use 3rd-party software written for Apache, the same goes. The only way this is really sustainable is if there are a small number of very major players of about equal strength (say, IIS and Apache) so that your 3rd-party stuff is readily available for both. Even this is hard to maintain for any length of time, and I think hoping for say 5-6 viable major implementations of any particular service is rather optimistic.
If I couldn't trust someone to use new and delete correctly, I wouldn't trust them to do much at all for me. Yes, there are many programmers that mess things up with these operators, but they aren't very good programmers. If you can't use new and delete or free and malloc correctly, then there's probably a lot of other things you can't do well either. Memory management is rather fundamental to computer science.
Sure, every good programmer should be able to do basic memory management, but in large complex programs it's not really as simple as you imply. In many cases, where an object can be referred to by arbitrarily many pointers in arbitrarily many locations, the programmer essentially has to manually implement their own garbage collection mechanism (most commonly through reference counting). This is often sub-optimal.
I do agree that it might be a good idea to allow more tuning to the garbage collector. Instead of telling it "delete, now" though, I'd prefer something along the lines of "force the GC to run now."
Heterogeneity is hard to maintain, because it's often the direct opposite of interoperability and maintainability. For example, the impact of various SSH vulnerabilities would've been minimized if people used a variety of secure shell methods instead of standardizing on SSH; but then it'd be a nightmare to connect to systems (you'd have to try out 5 clients or something).
The movie I saw wasn't "chock full of plot and philosophy" with "a few stylish action scenes". The movie I saw spent more than 60% of its screen time on action scenes, most of which were tediously drawn out far longer than they should've been, and which in any case lacked the subtle style of the first movie. The "philosophy" was a pretty half-baked discussion of the age-old question of free will.
Are you really saying that the two Matrix movies, the two LoTR movies, and Shawshank Redemption are the five best movies ever?
Perhaps you should watch the following, any of which are better than those five:
A Clockwork Orange
Apocalypse Now
The Manchurian Candidate
Citizen Kane
One Flew Over the Cuckoo's Nest
I'd personally add a bunch more (Taxi Driver, Lawrence of Arabia, Bridge On the River Kwai, Ben-Hur, Full Metal Jacket, Dr. Strangelove, Mulholland Drive, etc.) but I think that's enough for now.
I do agree this is a problem, but in many cases the Java behavior is actually better; a lot of C/C++ slowdown is from realtime memory management, and could be sped up by saving up stuff to do later (this can be done manually with C++ allocators, but is often a pain in the ass).
A lot of them are things that actually used to be good advice, but for some reason or another (changes in hardware, compilers, etc.) aren't anymore. For example, it used to be a good idea in C to iterate through arrays by incrementing a pointer and dereferencing it instead of incrementing an index and then using array subscripting -- that way you had one increment per iteration, instead of one increment plus one offset calculation (basically you saved the addition that takes place during the array subscripting). However, on many modern C and C++ compilers in many situations, array subscripting will actually be faster than the pointer-incrementing method, because it's easier for the compiler to perform certain optimizations with. [Reference: Michael J. Scott, Programming Language Pragmatics (Morgan Kaufmann, 2000).]
There's quite a bit of other stuff like this out there as well.
There's no reason to use Ogg FLAC -- FLAC itself already supports all that. Ogg adds absolutely nothing (not even metadata tagging! Ogg says it's the responsibility of the bitstream it encapsulates to implement that itself).
I've seen numbers anywhere from 5%-200% penalty, though I don't have any references at the moment. It really depends on the app and where your main execution time lies. If you do a lot of tight loops over arrays, it's going to give you a significant performance hit. If you don't, it won't. So it's probably going to slow down your MP3 encoder a lot, but probably won't result in a noticeable slowdown for most userland apps. For most apps, which are I/O- rather than CPU-bound anyway, it's a good idea for security reasons. Same reason strncpy() is recommended over strcpy(), despite the performance hit due to bounds checking (in fact, strncpy() is just a special-case example of bounds checking).
In Soviet Russia, the money coughs up YOU.
No wonder all you jackasses are complaining about the poor economy and being unable to get jobs. :-P
If Al Sharpton was the point man, I think we can pretty safely say the claims were completely fabricated.
10 Mbps = 10 000 000 bytes/s = 1.12 MiB/s.
I do realize that using base-2 has been standard in measuring storage space in computing for a while; I was referring to the prefix "Giga" itself, which has been an SI prefix for "10^9" for quite some time, with common usage in the sciences dating back at least 100-200 years. I'd imagine 2^10 was called "kilo" because it was close enough to an actual kilo, but 2^(10x) and 10^(3x) diverge as x increases, so that's getting increasingly confusing.
And the base-10 version is standard in everything now except for storage space, even computer-related stuff. Audio file bitrate as I mentioned is in base-10, network bandwidth is in base 10 (that's why 10 Mbps != 1.25 MiB/s. 10 Mbps = 10 000 000 bytes/s = 9.56 MiB/s), and so on.
giga = 10^9, and an 80 GB hard drive has 80 x 10^9 (10 billion) bytes. This is standard notation that has been in use for at least a hundred years. Perhaps what you're looking for is 80 GiB, which the hard drives are not advertised as.
This is standard even in most other parts of computing (anything engineering-oriented especially). For example, that 128kbps mp3 you downloaded is 128000 bits/second, not 128*1024 bits/second.
You just use fixed-point arithmetic instead of floating-point (i.e. a fixed 32 bits of precision, or 16 bits, or whatever). A simple way of doing is is to make INT_MAX/2 = 1.0, -INT_MAX/2 = -1.0, and everything in between scaled appropriately. (/2 to avoid overflow). Then you implement fixed-point addition, multiplication, division, and subtraction (as commonly doing in hardware DSP chips) and you've got yourself an integer-only FFT.
Some really old C code doing something along these lines is available here.
djb (of qmail fame) has some rather uncomplimentary things to say about the accuracy of FFTW's speed claims.
In the first Matrix, the fight scenes seemed to have a point. Here it seems like you could've taken most them out without any loss of continuity (with the exception of two or so). There simply wasn't anything that happened. Like in the first scene fighting lots of Smiths where he flies away at the end, why the hell didn't he fly away five minutes earlier?
I distracted greatly from the movie IMO, because something like 60-70% of the total screen time was taken up by mostly pointless fights that after a while didn't even look all that cool.
I can save myself a lot of effort by just pointing people to that review instead of rewriting basically the same points myself.
more tits = more cash
You did notice none of this organic life happened to be unfit or over 25 didn't you?
The pseudo-mathematical shit with the 'architect' was horrible. It reminded me of the movie The Net's attempt to use techno-jargon.
They also never explained why all fighting between programs is done with wire-fu, rather than through more powerful techniques such as "instantly make your head explode."