OTOH, there are many circumstances where the programmer has no choice, such as with most built-in C++ string implementations. This is a bad design decision. Library implementors, especially standard library implementors, should not dictate a specific performance model for you.
Let's ignore circular references for a moment. To be honest, cycles don't turn up as often as people claim in programs where reference counting is done manually (or through smart pointers) because people are smart enough to know the issues and avoid them (e.g. by using weak references or other non-owning pointers to break cycles).
For a start, reference counting interacts badly with multithreading. The reference count has to be protected against concurrent updates, and that can cost a lot, especially if the count is already effectively protected in some other way (e.g. by only being used single-threadedly). This is such a problem that many C++ library vendors are doing away with reference counting in their std::basic_strings.
Secondly, every time you copy a pointer, you modify the reference count. Every single time. Sometimes (e.g. if you take a temporary local copy) that will be in cache, but not always. If there's contention between CPUs (see previous point), for example, the count will bounce between them. Sometimes it's an almost guaranteed cache miss.
Admittedly, this isn't such a big problem in C++-implemented reference counting, because the programmer is usually far more aware of what's going on with pointer copying and will go to some lengths to avoid copying, but it can cost if reference counting is automatic. Have a look at the Python source code some time and see just how much trouble it goes to to avoid manipulating reference counts.
A previous poster noted that most GC algorithms are distinctly unfriendly to virtual memory systems.
It depends on the language. Haskell, for example, has very different memory access patterns than Java. Being lazy, a value is produced only when it's time to be first consumed, at which point it often becomes garbage immediately. It follows that most of the garbage that a decent generational GC will be collecting will probably be in cache.
Anybody who thinks languages like Haskell or ML are fundamentally more powerful than C++ must be unaware of the Boost Lambda library [...]
I'm one of those rarest of beasts, a programmer who regularly uses (and likes) both Haskell and C++. (Disclaimer: I'm not familiar with FC++, though from what I've read it doesn't really support lazy evaluation, which is one of Haskell's most important distinguishing features.)
From a reductionist point of view, of course, neither is more powerful than the other. However, even with Boost.Lambda and the likw, I still find Haskell almost always allows for far more rapid development than C++ does, all other things being equal. Naturally, all other things are rarely equal, and speed of development is not always the greatest concern, and I won't be drawn into ranking one of my two favourite languages over the other.
To be fair, PJ isn't really a geek. She's that rarest of creatures: a non-geek who gets it. So even though she may not wear black and big boots (or she may; I have no idea), we adopt her as one of our own.
And I will hug him and pet him and I will call him "George".
Interestingly, there have been long-running court cases which had to decide questions exactly like this. Here in Australia, we had a case where someone on one side of a state border was shot from the other side, and the courts had to decide whose laws it broke.
In that case, the court found that the murder occurs in the place where the death occurs. I'm not sure about US/Mexican law, but it'd be a hell of an interesting case to follow.
Five years ago, you were right. Today, you're almost right.
It's still true that professional studios AVOID ray tracing if they can get away with cheating. However, it has always been the case that the cost of a human is greater than the cost of a computer (per unit time). Computer speeds have finally gotten to the point such that if the task is "small enough", it can be cheaper to spend all night using the render farm than to spend all day setting up reflection/refraction maps, tweaking the shaders and painting occlusion maps by hand.
We still won't see ray tracing any time soon on "big" shots (e.g. the room with all the doors in Monster's, Inc), but we will see it happening more often on "small" shots (e.g. the volume caustics in Finding Nemo).
While I love to pick on Java as much as the next person, I am curious how much it actually makes a difference for raytracing - does anyone know?
On non-trivial scenes, the biggest hit in raytracing is cache misses. Because raytracers "probe" the geometry database, the accesses are incoherent compared with, say, a scanline renderer.
On raytracers which support complex curved surfaces (e.g. NURBS, subdivision surfaces) but don't tesselate them, the second biggest hit is intersection testing. People who notice these sorts of things have found 10x speedups by tesselating, and according to Pixar, even a modest 30Mb tesselated grid cache using a simple LRU replacement policy can result in 99%+ cache hit rates even on fairly complex (2Gb+ gzipped geometry) scenes.
Chances are that this scene isn't very complex from a geometry database point of view. Using peoples' spare CPU cycles is one thing. Using all of their available memory is quite something else! Given that, I'd say they're probably on par, and the estimated ~20% slowdown (assuming a good JVM) is probably accurate.
Not true. PRMan added raytracing support to PRMan 11, and it was used in Finding Nemo, mostly for the underwater volume caustics.
Most of the effects that "look" raytraced (the fish tank, the bags, reflections etc) were, of course, done with scanline rendering with various mapping tricks. Ray tracing is definitely in there, though.
I'm a parent of a child who is mildly developmentally delayed. One other possibility that the report doesn't mention, but which I'd find far more likely, is that parents tend to use TV just to calm down a child with ADHD because otherwise it's the only way you could get them to sit still for a while.
If you don't go out of the house, you can't justify the purchase of your mobile (cell) phone, PDA, portable MP3 player and so on. So clearly, one important reason to go outside is to use your personal gadgetry.
Python and Perl users would argue that those languages are just as "well documented" as PHP, and have a better set of client libraries to boot, and are GPL'd so don't suffer from the licensing problems. I suppose that "simple to use" is a debatable point, but in my experience, Perl at least is no harder to integrate with Apache to get the same "embedded code" functionality as PHP is. I suspect that people who have tried it with Python would agree.
I'd like to avoid a language war here. PHP definitely hits a "sweet spot" on the web backend language tradeoff curves. Particularly if your web application doesn't need much "business logic", and only needs to use the specific bindings that PHP supports, using PHP can often make your rapid application development more rapid than with Python or Perl. I would hardly say that it has no adequate replacements, however.
Only if that Microsoft executive was acting as a representative, surely?
Why hasn't it apparently occurred to anyone that it might be a Microsoft executive or two who privately held SCO stock, and wanted to inflate the share price for private reasons unrelated to Microsoft's fortunes?
The "naked egg drop" is a hAX0R competition where you try to take down machines with older operating systems using malformed network packets while wearing no clothes.
Did you notice what happened in the 2000 election?
Yes. Gore lost by less than the number of votes that went to the Communist Party candidate. Nader was blamed because his party was the "third party". Behind the third, party, though, were a lot of "minor parties", any one of which could have swung the election.
The problem here is the US electoral system. Your only hope is to vote strategically. Vote for a third party if you're in a "safe" district and vote for a major party if you're not. This way, the third party gets over the magic 5% threshold, and a not-so-bad major party gets in. This was the essence of "Nader trading" in 2000.
I'd feel much more comfortable if Google would purge its records of searches, or at least remove the IP addresses, but I suppose they have their reasons. I'll let you guess what those reasons might be.
It's well known that Google uses this information to improve the quality of the searches. By examining how people "repair" their queries when they don't find what they're looking for straight away, the can tune the ranking algorithm to return more relevant queries first.
Bruce Schneier made the point that if you have nothing to hide, logically you should send all of your correspondence on postcards rather than using envelopes. After all, it's much cheaper.
gun owners don't care about civil rights: My experience does not coincide with your assertion, but...maybe my experience is different from yours.
I'm not even American, so your experience is probably better than mine! Having said that, I suspect that people that you personally know may well, as a rule, care about civil rights. I contend that you don't know the majority of gun owners or NRA members. You may want to consider, for example, how many NRA members are also ACLU members. (Yes, this is a highly unscientific measure, but it's good as a thought experiment.)
The questions that I want to consider are:
How likely is it that the US government would ever put the gun-owning population into a position where they would even contemplate armed resistance/revolution?
If it's plausible, how successful would such a resistance/revolution be?
If the answer to either question is "not very", then the question of owning guns to protect the people from the government is moot. Moreover, even if guns are for personal defence, one might also ask how successful defending oneself from the US government with firearms would be. If history is any judge, not very.
I therefore feel justified in saying that guns will never protect any subset of the US citizenry from the US government.
Slashdot Mirror
I believe I said precisely that.
OTOH, there are many circumstances where the programmer has no choice, such as with most built-in C++ string implementations. This is a bad design decision. Library implementors, especially standard library implementors, should not dictate a specific performance model for you.
No idea. Ask the person who wrote your post's grandparent.
It can be.
Let's ignore circular references for a moment. To be honest, cycles don't turn up as often as people claim in programs where reference counting is done manually (or through smart pointers) because people are smart enough to know the issues and avoid them (e.g. by using weak references or other non-owning pointers to break cycles).
For a start, reference counting interacts badly with multithreading. The reference count has to be protected against concurrent updates, and that can cost a lot, especially if the count is already effectively protected in some other way (e.g. by only being used single-threadedly). This is such a problem that many C++ library vendors are doing away with reference counting in their std::basic_strings.
Secondly, every time you copy a pointer, you modify the reference count. Every single time. Sometimes (e.g. if you take a temporary local copy) that will be in cache, but not always. If there's contention between CPUs (see previous point), for example, the count will bounce between them. Sometimes it's an almost guaranteed cache miss.
Admittedly, this isn't such a big problem in C++-implemented reference counting, because the programmer is usually far more aware of what's going on with pointer copying and will go to some lengths to avoid copying, but it can cost if reference counting is automatic. Have a look at the Python source code some time and see just how much trouble it goes to to avoid manipulating reference counts.
It depends on the language. Haskell, for example, has very different memory access patterns than Java. Being lazy, a value is produced only when it's time to be first consumed, at which point it often becomes garbage immediately. It follows that most of the garbage that a decent generational GC will be collecting will probably be in cache.
I'm one of those rarest of beasts, a programmer who regularly uses (and likes) both Haskell and C++. (Disclaimer: I'm not familiar with FC++, though from what I've read it doesn't really support lazy evaluation, which is one of Haskell's most important distinguishing features.)
From a reductionist point of view, of course, neither is more powerful than the other. However, even with Boost.Lambda and the likw, I still find Haskell almost always allows for far more rapid development than C++ does, all other things being equal. Naturally, all other things are rarely equal, and speed of development is not always the greatest concern, and I won't be drawn into ranking one of my two favourite languages over the other.
To be fair, PJ isn't really a geek. She's that rarest of creatures: a non-geek who gets it. So even though she may not wear black and big boots (or she may; I have no idea), we adopt her as one of our own.
And I will hug him and pet him and I will call him "George".
Thanks to the wonders of the Internet, you can look at Mount Ararat for yourself. Happy ark hunting!
Interestingly, there have been long-running court cases which had to decide questions exactly like this. Here in Australia, we had a case where someone on one side of a state border was shot from the other side, and the courts had to decide whose laws it broke.
In that case, the court found that the murder occurs in the place where the death occurs. I'm not sure about US/Mexican law, but it'd be a hell of an interesting case to follow.
Five years ago, you were right. Today, you're almost right.
It's still true that professional studios AVOID ray tracing if they can get away with cheating. However, it has always been the case that the cost of a human is greater than the cost of a computer (per unit time). Computer speeds have finally gotten to the point such that if the task is "small enough", it can be cheaper to spend all night using the render farm than to spend all day setting up reflection/refraction maps, tweaking the shaders and painting occlusion maps by hand.
We still won't see ray tracing any time soon on "big" shots (e.g. the room with all the doors in Monster's, Inc), but we will see it happening more often on "small" shots (e.g. the volume caustics in Finding Nemo).
On non-trivial scenes, the biggest hit in raytracing is cache misses. Because raytracers "probe" the geometry database, the accesses are incoherent compared with, say, a scanline renderer.
On raytracers which support complex curved surfaces (e.g. NURBS, subdivision surfaces) but don't tesselate them, the second biggest hit is intersection testing. People who notice these sorts of things have found 10x speedups by tesselating, and according to Pixar, even a modest 30Mb tesselated grid cache using a simple LRU replacement policy can result in 99%+ cache hit rates even on fairly complex (2Gb+ gzipped geometry) scenes.
Chances are that this scene isn't very complex from a geometry database point of view. Using peoples' spare CPU cycles is one thing. Using all of their available memory is quite something else! Given that, I'd say they're probably on par, and the estimated ~20% slowdown (assuming a good JVM) is probably accurate.
Not true. PRMan added raytracing support to PRMan 11, and it was used in Finding Nemo, mostly for the underwater volume caustics.
Most of the effects that "look" raytraced (the fish tank, the bags, reflections etc) were, of course, done with scanline rendering with various mapping tricks. Ray tracing is definitely in there, though.
I'm a parent of a child who is mildly developmentally delayed. One other possibility that the report doesn't mention, but which I'd find far more likely, is that parents tend to use TV just to calm down a child with ADHD because otherwise it's the only way you could get them to sit still for a while.
A couple my wife used to know named their daughter Jenna Taylor.
Poor kid.
"Train spotting" is now a loaded term, being associated with heroin use.
The politically correct term for someone who does this is "railway enthusiast" or "rail fan". If you wear an anorak, "gunzel" may also be appropriate.
If you don't go out of the house, you can't justify the purchase of your mobile (cell) phone, PDA, portable MP3 player and so on. So clearly, one important reason to go outside is to use your personal gadgetry.
I hope you don't forget to round 0.5 to the nearest even integer. Don't want any bias creeping into your mental arithmetic!
Not on a boolean counter. There's prbbably a joke in here about people who engage in binary thinking, but I'm damned if I can find it.
Python and Perl users would argue that those languages are just as "well documented" as PHP, and have a better set of client libraries to boot, and are GPL'd so don't suffer from the licensing problems. I suppose that "simple to use" is a debatable point, but in my experience, Perl at least is no harder to integrate with Apache to get the same "embedded code" functionality as PHP is. I suspect that people who have tried it with Python would agree.
I'd like to avoid a language war here. PHP definitely hits a "sweet spot" on the web backend language tradeoff curves. Particularly if your web application doesn't need much "business logic", and only needs to use the specific bindings that PHP supports, using PHP can often make your rapid application development more rapid than with Python or Perl. I would hardly say that it has no adequate replacements, however.
Only if that Microsoft executive was acting as a representative, surely?
Why hasn't it apparently occurred to anyone that it might be a Microsoft executive or two who privately held SCO stock, and wanted to inflate the share price for private reasons unrelated to Microsoft's fortunes?
Don't people know anything? Espresso is not "Joe".
(Melburnian and proud of it.)
The "naked egg drop" is a hAX0R competition where you try to take down machines with older operating systems using malformed network packets while wearing no clothes.
Yes. Gore lost by less than the number of votes that went to the Communist Party candidate. Nader was blamed because his party was the "third party". Behind the third, party, though, were a lot of "minor parties", any one of which could have swung the election.
The problem here is the US electoral system. Your only hope is to vote strategically. Vote for a third party if you're in a "safe" district and vote for a major party if you're not. This way, the third party gets over the magic 5% threshold, and a not-so-bad major party gets in. This was the essence of "Nader trading" in 2000.
It's well known that Google uses this information to improve the quality of the searches. By examining how people "repair" their queries when they don't find what they're looking for straight away, the can tune the ranking algorithm to return more relevant queries first.
Bruce Schneier made the point that if you have nothing to hide, logically you should send all of your correspondence on postcards rather than using envelopes. After all, it's much cheaper.
Huh? SYSENTER/SYSEXIT are lightning fast, assuming you're not switching address spaces.
You are using SYSENTER/SYSEXIT, right? Plus an INT-based layer for backwards compatability?
I'm not even American, so your experience is probably better than mine! Having said that, I suspect that people that you personally know may well, as a rule, care about civil rights. I contend that you don't know the majority of gun owners or NRA members. You may want to consider, for example, how many NRA members are also ACLU members. (Yes, this is a highly unscientific measure, but it's good as a thought experiment.)
The questions that I want to consider are:
If the answer to either question is "not very", then the question of owning guns to protect the people from the government is moot. Moreover, even if guns are for personal defence, one might also ask how successful defending oneself from the US government with firearms would be. If history is any judge, not very.
I therefore feel justified in saying that guns will never protect any subset of the US citizenry from the US government.