The entire product line is one chip design. They burn out fuses in the chips to disable features to make the lower end ones.
When you make chips, you produce a big wafer that gets cut into individual chips. There will be defects in the wafer. You can generally predict roughly how many defects there will be, but not where they will be. So you design your chips so that portions of them can be disabled.
You get a perfect chip with no flaws? That gets sold as the top of the line part. You get a chip with defective cores? That one has cores disabled and gets sold as a lower end chip. Maybe the cores are fine, but there's flaws in the L2 cache? Disable part of the cache and put it in a lower end bin. Or maybe everything works, but the chip starts to get unreliable if you clock it too fast. Again, into a lower end bin.
Chips get designed this way because it means you can still sell most of the chips that have flaws in them. You'll still get some unusable chips, but most flaws can be worked around to produce a product you can sell.
If the market wants a lot of low end chips, sometimes you end up disabling working features to meet demand. It's way, way cheaper to do that than it is to set up a separate manufacturing line just for the lower end chips. This is more likely to happen later in the lifecycle of a particular chip, after manufacturing has been running for a while and the flaws have been worked out. It's usually not worth setting up another manufacturing line to make lower end chips when this happens.
On Steam, download codes are infinite and people used to have your attitude. The problem here is that people caught on to that and took advantage of it. They just try to get as many codes as they can and resell them.
On consoles, you receive a finite number of download codes, and it's easy to blow through them all on legit reviewers. You have to prioritize who you give them to.
It's pretty much impossible to mitigate these types of exploit completely without disabling speculative execution completely which isn't possible without savagely affecting performance
The performance you would get with Speculative Execution disabled is the performance we should have had all along.
Instead of concentrating on making CPUs better and faster and more efficient, Intel decided to cheat, AKA, Speculative Execution. And It worked wonderfully. Until it didn't.
Speculative Execution is little more than a marketing gimmick created by Intel so they could claim that their chips were faster than the competition, which then forced other companies to do the same thing, so it wouldn't appear that they weren't "competitive".
Speculative execution is a massive improvement. It gets rid of a ton of CPU stalls and lets you execute more instructions at the same time. It's one of the biggest improvements to performance that Intel ever added.
You're confusing the concept of speculative execution with a quirk of Intel's implementation. Intel's flaw is the CPUs don't check memory access permissions until the end of speculative execution instead of the beginning. It's a small performance optimization. There was no intent to cheat here. About 25 years ago, they realized they could get a small performance gain by delaying the permission check a little bit. The behavior has been documented the entire time. If it was obvious that the design was problematic, people would've found the flaw a long time ago.
If we're going to go down this reductionist security-trumps-all argument then OpenBSD should disable networking too.
There's a fundamental difference between I/O and hyperthreading. Without I/O the computer can do nothing. Without hyperthreading it might be a little slower.
By that logic you should just disable the CPU cache instead. Remove the cache and you 100% prevent Spectre, Meltdown, and anything related. You can still do everything you could do before. It's just slower. Orders of magnitude slower, but everything still works.
Because CISC doesn't scale nearly as well as RISC in terms of CPU horsepower per unit heat/power
What you're seeing has nothing to do with CISC vs RISC and everything to do with the design philosophy behind x86 and ARM.
x86 chips were designed for decades to favor raw power over efficiency. ARM was designed from the start to optimize for power efficiency.
Any time you add a feature or an optimization to a chip, the designers ask if it's worth the cost both in terms of transistors required and power usage. Intel focused on chips running off wall power that sold for hundreds of dollars, so it was generally pretty easy to justify adding things. ARM focused on chips that cost tens of dollars and had to run off small batteries. Features don't get added to ARM chips unless they add a lot of performance for the transistor/power cost.
If you look at Power or Sparc instead of x86, you'll find similar results. If anything, those RISC chips are probably even more power inefficient, as they were designed for customers who demanded top of the line performance and were willing to pay a lot for it.
They demoed the system in public. The case was open. There were large pipes running into it for the water cooling, and a large water chiller unit next to it. There were pictures of the setup included in the initial articles about it.
They didn't explicitly state that it was overclocked because it couldn't possibly be more obvious.
The 8th gen Kaby Lake Refresh processors support 32 GB. Business oriented ultrabooks with 8th gen processors often have 32 GB as an option. Laptops like Thinkpads, Dell Inspiron, HP EliteBook, etc. It's just an option on customized orders. No one's mass producing laptops with that much built in, as the demand isn't there.
You're in the area where land is cheap and Walmarts are huge. If you get into more densely populated regions, Walmarts are a tiny fraction of the size they are by you. Up in the northeast, a Walmart and a Toys R Us are often about the same size. While Toys R Us has a little baby stuff, Babies R Us is a separate store that's almost as big.
They explain that the report includes any drive they have at least 45 of in use. They don't say why that's the cutoff, but they do point out that the stats aren't meaningful with the low numbers of drives.
Those 60 drives were running for an average of 21 days each. One drive failed in that time. (1 failure / 60 drives) * (365 days/year / 21 days) = 29% drives fail yearly
It's not enough data to conclude anything. They just started deploying a new model and one drive died immediately, which looks awful if you scale that data up to a year. It tells you nothing about long term trends though.
The processors all start executing instructions ahead of the current one when possible. If the code branches in a different direction than expected, they discard the results of any future instructions, and make it look like the CPU never even attempted to run that future code.
For 25 years or so, all chip designers assumed that the state of the CPU cache was sufficiently complex that software wouldn't be able to predict what memory was or wasn't in the cache. This meant that they didn't have to worry about the cache state when discarding instructions that shouldn't be executed.
Meltdown and Spectre both showed that a) it's possible to manipulate the cache and learn what data is or isn't in it and b) you can use that knowledge to gain insight into the contents of that memory.
It all boils down to the entire chip industry believing that the cache wasn't exploitable. It took about 25 years for anyone to put together the pieces and figure out the flaw.
I don't remember the numbers, but there are tools you can download off the app store to find out the CPU clockspeed. You have to wear the battery down a lot for the slowdown to kick in. I've got a 6S that's over two years old and the battery is still fine. The phone is still running the CPU at full speed.
The previous two winters I had a bunch of unexpected shutdowns when walking in cold weather, but so far it hasn't happened this winter. The feature seems to be working as designed.
It's been an issue for several years. It was definitely an issue with the 6S running iOS 9. It took Apple a while to pinpoint the problem. At first they found a batch of batteries with manufacturing flaws and thought that was the problem and did a recall. Then they realized it was a bigger issue and came up with the software fix.
Also remember that each year phones get more features added. More CPU cores, another camera, additional sensors, newer wireless standards, etc. As they add more components, the difference between average and peak power draw gets bigger. The issue didn't become obvious until the phones got more complex. Nobody is going to think much of it if an old phone suddenly shutoffs off with 10-15% battery remaining, because the battery meter tends not to be that accurate anymore.
The issue isn't about how long the battery lasts. It's about how much power the battery can supply at a given moment. There's a huge variance in how much power the phone needs depending on what you're doing at the moment. Accessing flash memory, enabling GPS/camera/bluetooth, downloading data, stressing the CPU, are all things that will make the power draw go up. You need to make sure the battery can handle the power spikes. If the battery can't handle the load, the phone just shuts off with no warning.
The update slows the phone down any time the battery can't output enough power. Most of the attention is focused on old batteries, but cold weather can trigger it too. The original reason for the change was to deal with new phones with plenty of battery power remaining abruptly shutting off in winter weather. The phones wouldn't turn on again until you got them indoors in warmer air, at which point they'd realize they had plenty of power remaining.
They didn't make it configurable because their main concern was making sure people outdoors with ice & snow on the ground had functional phones.
As a game developer, it's easy to get over 16 GB used. Lots of large assets to work with. Lots of tools open at once - editors, Visual Studio, Photoshop, etc. Multiplatform developers often have multiple workspaces going at once to test things on different platforms, with an instance per platform of many tools. I often to sit around 20 GB used, peaking around 25 GB. I expect my memory usage to go up when I move to Coffee Lake with the extra cores - more build processes running simultaneously.
I can work with 16 GB if I need to, but 32 GB certainly makes things a lot nicer.
Being opposite handed is an advantage for the batter, not the pitcher. There's two big reason for that:
1) The batter can see the ball easier while it's still in the pitcher's hand. You're looking across the plate toward the pitcher. In a same handed matchup, the pitcher's release point can be behind your back. You loose sight of the ball during the windup and can't track it as quickly. Being opposite handed buys you a little bit more reaction time.
2) In a same handed matchup, most pitches will have horizontal movement away from the batter. This leads to a lot of contact toward the end of the bat instead of the middle, which results in weaker hits. In an opposite handed matchup, the ball will be coming in toward the batter. This makes it a lot easier to make contact with the sweet spot of the bat.
Left handed hitters have a huge advantage. It's also relatively easy for a right to learn to bat lefty - far easier than learning to throw with the opposite hand. You want the left handed pitchers to counter the left handed hitter advantage.
I find it hilarious when TV announcers say asinine things about lefties, such as that they "throw across their bodies."
A pitcher steps forward as he throws. If you plant your foot off center, your upper body won't rotate smoothly and it makes your throw less accurate. That's called throwing across your body. Both righties and lefties can do it. When pitching it's a bad thing.
Pickoff throws are a very different story though. When throwing a pickoff to first, a left would normally step straight forward, telegraphing his move to the runner. If he lands his foot off center toward the home plate side, it takes longer for the runner to figure out if the throw is going to first or to home. You don't need nearly as much accuracy on a pickoff throw as you do on a pitch, so throwing across your body can be a good tradeoff. Giving up a little accuracy to make your move harder to read is well worth it.
A right handed pitcher is facing third, so he has to spin around to throw to first. There's no room for deception there, so there wouldn't be any benefit to throwing across his body.
Here's a slow motion video of Andy Pettite throwing a pickoff to first. Look how far off to the right his foot lands, and the awkward arm motion it results in. It's incredibly deceptive and one of the best pickoff moves of all time.
Do you know where the XBox got it's name? Microsoft wanted to make a box that runs DirectX and sits on your TV. This "DirectX Box" got shortened to "XBox", which stuck as the final product name.
The very core idea driving the project was that the system would run Windows & DirectX. You're coding against high level APIs on the Xbox, and can't opt out of it. It was a key design goal to have people coding against Microsoft's APIs instead of coding to the hardware.
As for the 8 and 16 bit consoles, syscalls were irrelevant. There was no operating system on those systems. You might have had some *really* simple, common features coded into the system rom, but otherwise *all* the code was contained within the individual game. These systems only had a bare minimal amount of storage in them - just enough to store any code needed to boot the system and hand off control to the game. Including storage in the system was too expensive to have any significant amount of code built in.
They realized that they can make way more money selling items in games like Team Fortress and DOTA than they can off a game like Half Life. That's the main issue here.
As a father planning for his children's education, many years hence. I go to these schools websites and look at their tuition. It is beyond all reason for all but the very wealthiest. My house doesn't cost that much. And I have two children. So yes, unless their academics are far beyond the pale and their SAT scores are maxed out, I'd discourage them from applying.
Never judge the cost of a college by the posted tuition fees. Schools give lots of financial aid. The only people that actually pay the posted rates are the people who can look at those numbers and not even flinch at the thought of them.
The high posted rates serve one purpose - to shift some expenses toward the really rich people that attend. Most people will get some form of financial aid, usually knocking off a large portion of the expense.
The high base rate + lots of aid available approach lets them shift more of the cost to the students with plenty of money and cut more breaks for those with less money.
Rogue One is a *horrible* example of 3D movies. Probably the worst I've ever seen in a theater.
For 3D to really shine, you generally want your depth of field to be a little bigger than you do normally. Anything that's out of focus is going to appear as a blurry 2D object. A tiny bit of blur is ok, but any more than that and an object will appear completely flat, defeating the 3D effect.
For large parts of Rogue One (especially the darker scenes earlier in the movie) there's a very narrow depth of field. Often you'll see scenes with two characters talking and the only thing in focus is the person speaking at the moment. If you shoot a movie like that, it's going to look horrible in 3D. If you go as blurry as the more extreme shots in Rogue One were, it can cause eye strain.
When I dealt with mine for my dual tuner Tivo HD a few years ago, they brought a multi-stream capable card with no issues. I got the impression that's standard now.
On the bright side, shortly after that the FCC ruled that cable companies have to let you install the cable card yourself if you want to, and I believe they're not allowed to charge a fee for that either.
Slashdot Mirror
The entire product line is one chip design. They burn out fuses in the chips to disable features to make the lower end ones.
When you make chips, you produce a big wafer that gets cut into individual chips. There will be defects in the wafer. You can generally predict roughly how many defects there will be, but not where they will be. So you design your chips so that portions of them can be disabled.
You get a perfect chip with no flaws? That gets sold as the top of the line part. You get a chip with defective cores? That one has cores disabled and gets sold as a lower end chip. Maybe the cores are fine, but there's flaws in the L2 cache? Disable part of the cache and put it in a lower end bin. Or maybe everything works, but the chip starts to get unreliable if you clock it too fast. Again, into a lower end bin.
Chips get designed this way because it means you can still sell most of the chips that have flaws in them. You'll still get some unusable chips, but most flaws can be worked around to produce a product you can sell.
If the market wants a lot of low end chips, sometimes you end up disabling working features to meet demand. It's way, way cheaper to do that than it is to set up a separate manufacturing line just for the lower end chips. This is more likely to happen later in the lifecycle of a particular chip, after manufacturing has been running for a while and the flaws have been worked out. It's usually not worth setting up another manufacturing line to make lower end chips when this happens.
Part of it is these people are reselling the download codes, so they get the profit instead of you.
Part of it is download codes for consoles are finite and it's easy to run out of them.
Most of these scams are for download codes to resell, not to keep. Some of the scams are for console games, where it's harder to pirate.
On Steam, download codes are infinite and people used to have your attitude. The problem here is that people caught on to that and took advantage of it. They just try to get as many codes as they can and resell them.
On consoles, you receive a finite number of download codes, and it's easy to blow through them all on legit reviewers. You have to prioritize who you give them to.
The review copies are distributed the same way the retail copies are. Through Steam, PSN, Xbox Live, eShop, etc.
Maybe on Steam there might be a way to separate review copies and do something like you're suggesting, but there certainly isn't on the consoles.
Think pro-photographers in multi-hour photo sessions with high res cameras.
Think people recording 4K video.
Think gamers on a Nintendo Switch that prefer downloading their games.
As storage options get larger, people find ways to use the extra space.
It's pretty much impossible to mitigate these types of exploit completely without disabling speculative execution completely which isn't possible without savagely affecting performance
The performance you would get with Speculative Execution disabled is the performance we should have had all along.
Instead of concentrating on making CPUs better and faster and more efficient, Intel decided to cheat, AKA, Speculative Execution. And It worked wonderfully. Until it didn't.
Speculative Execution is little more than a marketing gimmick created by Intel so they could claim that their chips were faster than the competition, which then forced other companies to do the same thing, so it wouldn't appear that they weren't "competitive".
Speculative execution is a massive improvement. It gets rid of a ton of CPU stalls and lets you execute more instructions at the same time. It's one of the biggest improvements to performance that Intel ever added.
You're confusing the concept of speculative execution with a quirk of Intel's implementation. Intel's flaw is the CPUs don't check memory access permissions until the end of speculative execution instead of the beginning. It's a small performance optimization. There was no intent to cheat here. About 25 years ago, they realized they could get a small performance gain by delaying the permission check a little bit. The behavior has been documented the entire time. If it was obvious that the design was problematic, people would've found the flaw a long time ago.
If we're going to go down this reductionist security-trumps-all argument then OpenBSD should disable networking too.
There's a fundamental difference between I/O and hyperthreading. Without I/O the computer can do nothing. Without hyperthreading it might be a little slower.
By that logic you should just disable the CPU cache instead. Remove the cache and you 100% prevent Spectre, Meltdown, and anything related. You can still do everything you could do before. It's just slower. Orders of magnitude slower, but everything still works.
What you're seeing has nothing to do with CISC vs RISC and everything to do with the design philosophy behind x86 and ARM.
x86 chips were designed for decades to favor raw power over efficiency. ARM was designed from the start to optimize for power efficiency.
Any time you add a feature or an optimization to a chip, the designers ask if it's worth the cost both in terms of transistors required and power usage. Intel focused on chips running off wall power that sold for hundreds of dollars, so it was generally pretty easy to justify adding things. ARM focused on chips that cost tens of dollars and had to run off small batteries. Features don't get added to ARM chips unless they add a lot of performance for the transistor/power cost.
If you look at Power or Sparc instead of x86, you'll find similar results. If anything, those RISC chips are probably even more power inefficient, as they were designed for customers who demanded top of the line performance and were willing to pay a lot for it.
They demoed the system in public. The case was open. There were large pipes running into it for the water cooling, and a large water chiller unit next to it. There were pictures of the setup included in the initial articles about it.
They didn't explicitly state that it was overclocked because it couldn't possibly be more obvious.
The 8th gen Kaby Lake Refresh processors support 32 GB. Business oriented ultrabooks with 8th gen processors often have 32 GB as an option. Laptops like Thinkpads, Dell Inspiron, HP EliteBook, etc. It's just an option on customized orders. No one's mass producing laptops with that much built in, as the demand isn't there.
You're in the area where land is cheap and Walmarts are huge. If you get into more densely populated regions, Walmarts are a tiny fraction of the size they are by you. Up in the northeast, a Walmart and a Toys R Us are often about the same size. While Toys R Us has a little baby stuff, Babies R Us is a separate store that's almost as big.
They explain that the report includes any drive they have at least 45 of in use. They don't say why that's the cutoff, but they do point out that the stats aren't meaningful with the low numbers of drives.
Those 60 drives were running for an average of 21 days each. One drive failed in that time. (1 failure / 60 drives) * (365 days/year / 21 days) = 29% drives fail yearly
It's not enough data to conclude anything. They just started deploying a new model and one drive died immediately, which looks awful if you scale that data up to a year. It tells you nothing about long term trends though.
The processors all start executing instructions ahead of the current one when possible. If the code branches in a different direction than expected, they discard the results of any future instructions, and make it look like the CPU never even attempted to run that future code.
For 25 years or so, all chip designers assumed that the state of the CPU cache was sufficiently complex that software wouldn't be able to predict what memory was or wasn't in the cache. This meant that they didn't have to worry about the cache state when discarding instructions that shouldn't be executed.
Meltdown and Spectre both showed that a) it's possible to manipulate the cache and learn what data is or isn't in it and b) you can use that knowledge to gain insight into the contents of that memory.
It all boils down to the entire chip industry believing that the cache wasn't exploitable. It took about 25 years for anyone to put together the pieces and figure out the flaw.
I don't remember the numbers, but there are tools you can download off the app store to find out the CPU clockspeed. You have to wear the battery down a lot for the slowdown to kick in. I've got a 6S that's over two years old and the battery is still fine. The phone is still running the CPU at full speed.
The previous two winters I had a bunch of unexpected shutdowns when walking in cold weather, but so far it hasn't happened this winter. The feature seems to be working as designed.
It's been an issue for several years. It was definitely an issue with the 6S running iOS 9. It took Apple a while to pinpoint the problem. At first they found a batch of batteries with manufacturing flaws and thought that was the problem and did a recall. Then they realized it was a bigger issue and came up with the software fix.
Also remember that each year phones get more features added. More CPU cores, another camera, additional sensors, newer wireless standards, etc. As they add more components, the difference between average and peak power draw gets bigger. The issue didn't become obvious until the phones got more complex. Nobody is going to think much of it if an old phone suddenly shutoffs off with 10-15% battery remaining, because the battery meter tends not to be that accurate anymore.
The issue isn't about how long the battery lasts. It's about how much power the battery can supply at a given moment. There's a huge variance in how much power the phone needs depending on what you're doing at the moment. Accessing flash memory, enabling GPS/camera/bluetooth, downloading data, stressing the CPU, are all things that will make the power draw go up. You need to make sure the battery can handle the power spikes. If the battery can't handle the load, the phone just shuts off with no warning.
The update slows the phone down any time the battery can't output enough power. Most of the attention is focused on old batteries, but cold weather can trigger it too. The original reason for the change was to deal with new phones with plenty of battery power remaining abruptly shutting off in winter weather. The phones wouldn't turn on again until you got them indoors in warmer air, at which point they'd realize they had plenty of power remaining.
They didn't make it configurable because their main concern was making sure people outdoors with ice & snow on the ground had functional phones.
It's not *just* about battery age. It's age + operating temperature + momentary peaks in power usage.
The 6S in particular had a lot of issues where fairly new phones would just stop working at 20-30% battery when outside in the winter months.
As a game developer, it's easy to get over 16 GB used. Lots of large assets to work with. Lots of tools open at once - editors, Visual Studio, Photoshop, etc. Multiplatform developers often have multiple workspaces going at once to test things on different platforms, with an instance per platform of many tools. I often to sit around 20 GB used, peaking around 25 GB. I expect my memory usage to go up when I move to Coffee Lake with the extra cores - more build processes running simultaneously.
I can work with 16 GB if I need to, but 32 GB certainly makes things a lot nicer.
Being opposite handed is an advantage for the batter, not the pitcher. There's two big reason for that:
1) The batter can see the ball easier while it's still in the pitcher's hand. You're looking across the plate toward the pitcher. In a same handed matchup, the pitcher's release point can be behind your back. You loose sight of the ball during the windup and can't track it as quickly. Being opposite handed buys you a little bit more reaction time.
2) In a same handed matchup, most pitches will have horizontal movement away from the batter. This leads to a lot of contact toward the end of the bat instead of the middle, which results in weaker hits. In an opposite handed matchup, the ball will be coming in toward the batter. This makes it a lot easier to make contact with the sweet spot of the bat.
Left handed hitters have a huge advantage. It's also relatively easy for a right to learn to bat lefty - far easier than learning to throw with the opposite hand. You want the left handed pitchers to counter the left handed hitter advantage.
I find it hilarious when TV announcers say asinine things about lefties, such as that they "throw across their bodies."
A pitcher steps forward as he throws. If you plant your foot off center, your upper body won't rotate smoothly and it makes your throw less accurate. That's called throwing across your body. Both righties and lefties can do it. When pitching it's a bad thing.
Pickoff throws are a very different story though. When throwing a pickoff to first, a left would normally step straight forward, telegraphing his move to the runner. If he lands his foot off center toward the home plate side, it takes longer for the runner to figure out if the throw is going to first or to home. You don't need nearly as much accuracy on a pickoff throw as you do on a pitch, so throwing across your body can be a good tradeoff. Giving up a little accuracy to make your move harder to read is well worth it.
A right handed pitcher is facing third, so he has to spin around to throw to first. There's no room for deception there, so there wouldn't be any benefit to throwing across his body.
Here's a slow motion video of Andy Pettite throwing a pickoff to first. Look how far off to the right his foot lands, and the awkward arm motion it results in. It's incredibly deceptive and one of the best pickoff moves of all time.
Do you know where the XBox got it's name? Microsoft wanted to make a box that runs DirectX and sits on your TV. This "DirectX Box" got shortened to "XBox", which stuck as the final product name.
The very core idea driving the project was that the system would run Windows & DirectX. You're coding against high level APIs on the Xbox, and can't opt out of it. It was a key design goal to have people coding against Microsoft's APIs instead of coding to the hardware.
As for the 8 and 16 bit consoles, syscalls were irrelevant. There was no operating system on those systems. You might have had some *really* simple, common features coded into the system rom, but otherwise *all* the code was contained within the individual game. These systems only had a bare minimal amount of storage in them - just enough to store any code needed to boot the system and hand off control to the game. Including storage in the system was too expensive to have any significant amount of code built in.
They realized that they can make way more money selling items in games like Team Fortress and DOTA than they can off a game like Half Life. That's the main issue here.
As a father planning for his children's education, many years hence. I go to these schools websites and look at their tuition. It is beyond all reason for all but the very wealthiest. My house doesn't cost that much. And I have two children. So yes, unless their academics are far beyond the pale and their SAT scores are maxed out, I'd discourage them from applying.
Never judge the cost of a college by the posted tuition fees. Schools give lots of financial aid. The only people that actually pay the posted rates are the people who can look at those numbers and not even flinch at the thought of them.
The high posted rates serve one purpose - to shift some expenses toward the really rich people that attend. Most people will get some form of financial aid, usually knocking off a large portion of the expense.
The high base rate + lots of aid available approach lets them shift more of the cost to the students with plenty of money and cut more breaks for those with less money.
Rogue One is a *horrible* example of 3D movies. Probably the worst I've ever seen in a theater.
For 3D to really shine, you generally want your depth of field to be a little bigger than you do normally. Anything that's out of focus is going to appear as a blurry 2D object. A tiny bit of blur is ok, but any more than that and an object will appear completely flat, defeating the 3D effect.
For large parts of Rogue One (especially the darker scenes earlier in the movie) there's a very narrow depth of field. Often you'll see scenes with two characters talking and the only thing in focus is the person speaking at the moment. If you shoot a movie like that, it's going to look horrible in 3D. If you go as blurry as the more extreme shots in Rogue One were, it can cause eye strain.
When I dealt with mine for my dual tuner Tivo HD a few years ago, they brought a multi-stream capable card with no issues. I got the impression that's standard now.
On the bright side, shortly after that the FCC ruled that cable companies have to let you install the cable card yourself if you want to, and I believe they're not allowed to charge a fee for that either.