Sony dumped a ton of R&D resources into the Cell, and what they got was a processor that was not obviously superior to what their competition was doing. It was just different. Cell, as shipped, has one PPE (a general-purpose core that's almost identical to one of the 360's three cores), and eight SPEs (very simple in-order processors with no branch prediction). The SPEs are great at doing math or DSP-style processing, but horrible at general-purpose code execution. Of the eight SPEs that shipped, one is disabled to improve yields (survive manufacturing defects), and one is reserved for the OS.
The end result of this was that Cell wasn't really better or worse than the 360's Xenon, it was just better at some things, and worse at other things. There wasn't a huge difference between the GPUs in the consoles either. The only real differentiating factor between the PS3 and the 360 was the BluRay drive, but the advantages in terms of capacity that were offered were largely outweighed by by the delays they caused in the manufacturing process (although to be fair, Cell had severe yield issues early on, which also constrained supply). The storage capacity advantages were unable to counterbalance the 360's lead in marketshare, and the BluRay drive in the PS3 had some limitations; it actually has significantly lower read speeds than the DVD drive in the 360.
All this is to basically say that the success or failure of the PS3 or 360 had little to do with the specific hardware inside. It had to do with the timing of the introduction of the hardware, and the software libraries available, the pricing, and potentially cultural stigmas (such as the 360's failure in Japan). If Sony had gone with a DVD drive and more traditional (and more mature) processor in the PS3, they would likely have come to market faster, at a lower price point, and probably would have captured a decent chunk more market share in the process.
Sony is smart not to go down the same path with the PS4 as they did with the PS3. In terms of storage capacity, no significant work must be done there. BluRay has matured, and the PS4's BluRay drive can easily ship with much higher throughput rates than the PS3, as well as higher capacity (BDXL bumped up the capacity of discs from 50GB to 128GB). The processor design can be left to a third party vendor (be it Intel, AMD, ARM, or IBM). The graphics processor design wasn't theirs in the PS3 anyhow (it was nVidia's), so no major change is needed in that regard. In short, they can produce a viable successor with a relative minimum of R&D, and it'll probably do just fine.
My understanding is that d-wave's product isn't a general-purpose quantum turing machine, and that the applications are rather specific (optimization problems). It's not a general-purpose quantum computer.
That's incorrect. They can magically crack encryption based on integer factorization or discrete logarithms. There are potential speedups for other types of encryption. Symmetric ciphers like AES are believed to be safe.
PHP doesn't properly support multithreading. It must also be unsuitable for server-side scripting. And because running each script in a separate process is way too expensive, nobody would ever try to use something like mpm_prefork or fastcgi to get around that limitation. That'd be silly.
PHP is also single-threaded per server; PHP doesn't jive well with multithreading. So what we get is mpm_prefork with one instance of mod_php per process, or alternatively, a web server using fastcgi that spawns multiple PHP processes.
True, but often a human can add additional information that can enable you to do more with what imagery you do have.
For example: you have a blurry picture, and you want to enhance it. Why is it blurry? If it's because the image was low resolution, we can't do much about that in the generic case, but if it's because the camera was out of focus, then you can add some extra information. If you can find out the properties of the camera (lens, incorrect focal length, desired focal length, etc), you can do a certain amount of correction, more than you could by simply sharpening the image. The information just isn't there in the image itself, but you're *adding* information, which in turn allows you to do more with what is there. I remember seeing some research papers on the subject. Similarly, motion blur is pretty easy to correct, although in this case it's pretty obvious that the information is there, and can be recovered. There are some pretty impressive examples at http://www.cse.cuhk.edu.hk/~leojia/projects/motion_deblurring/index.html
OK, so there's that, but what about information on what the image contains? Imagine you've got a blurry license plate, and you want to figure out what the plate number is. Well, a general-purpose enhancement of the image (beyond techniques dealing with motion or focus) might not help, but we do have some important extra information that the image does not. We know that it's a license plate, and that there are numbers and letters on it, and more than that, we know the exact shape of those numbers and letters; the nice thing about license plates is that the shapes are uniform. So even if there's not enough information in the image to reconstruct the general image, the fact that we can tell exactly what a given letter of the plate should look like at that distance, angle, resolution, etc, we can add that information to the problem space and get an answer that we couldn't get with the image data alone.
Because analog scaling artifacting is more pleasant than giant hard-edge blocks. A 1080p LCD looks fantastic displaying a 1080p image. Displaying a 240p image, on the other hand, doesn't look terribly good.
- Atom chips *are* x86 processors, they don't need to do any emulation. - A typical CPU from 2000 such as a late gen Pentium III (P4 was introduced in 2000) was definitely more than 10x faster than the IBM PC's original 4.77MHz 8088. Try, thousands of times faster at the very least. Tens of thousands of times faster, perhaps.
No offense to WINE, but compatibility isn't great, and even with fully compatible apps, it's never a polished experience. I'd take a solution that passes calls to real libraries over WINE libraries any day.
The real question is how integrated can we get? Emulating a full x86 PC and running x86 Windows inside of it is trivial; you can do that today on an ARM platform with existing software. But since ARM doesn't make desktop-class CPUs, it's slow.
What's more interesting is, how much can you integrate this with Windows? Can you emulate the application itself, intercepting API calls, and passing them off to the native ARM Windows libraries? That's the approach taken by Apple, and unlike the 68K -> PPC transition, for the PPC -> x86 transition they were doing it entirely in userspace...
I'm just old enough to have grown up playing DooM at 320x200, although that doesn't mean I wouldn't choose to play it at 1920x1080 with hardware acceleration; it's about the gameplay, not the graphics. Carmack is a genius, but...
DosBox can fairly faithfully reproduce the execution and the audio of the title, but input and display might not be quite up to spec. For input, I mean older gaming peripherals. Often just the keyboard; you can buy modern USB versions of the IBM model M keyboard, which should satisfy that part at least.
Display is a bit trickier. If you want a really authentic experience, you're going to need to plug a CRT monitor into your modern computer. Not impossible, and since computers back then tended to have fairly small screens, not necessarily all that space consuming either. Grab an old 15" CRT and you're set.
If you can't do that, there are still... possibilities. I don't know about DosBox specifically, but there have been many projects out there that aim to reproduce the feel of playing on an old CRT on modern displays. The higher resolution your modern display the better. There's hardware devices that intentionally fudge the video signal to reproduce classic effects (add scanlines, slightly blur on the horizontal), and there are software filters out there that go much further, trying to actually reproduce the CRT sub-pixel pattern on modern LCDs. One example can be found here: http://www.bogost.com/games/a_television_simulator.shtml
You'd be far better compiling to Javascript and executing the code directly. I know that Google Web Toolkit can compile Java to Javascript, there's probably compilers available for other languages out there too.
Johnson and Johnson has a total revenue of $61.9 billion USD, and a net income of $12.3 billion dollars. Now, I'm not a financial whiz, but $12.3 billion dollars seems like a rather lot of money to me.
Except, they don't. They're a business, they wouldn't be operating in Canada if they were making a loss here. They simply aren't able to inflate costs as insanely in Canada as they are in the US.
Except, Samsung doesn't design it, they just manufacture it. There's no particular requirement that Samsung be the one who produces the Apple-designed SoCs. Apple could just as easily contract any other SoC manufacturer (or even just a generic fab like TSMC) to produce the things.
The idea that Apple would replace ARM with Intel is a bit silly since at the present point in time Intel doesn't have anything even remotely competitive with ARM's products in the embedded market. The idea that Apple would replace ARM with Intel because of Samsung just doesn't make any sense.
How convenient, Ubisoft's largest studio happens to be in a city equipped for major motion picture production, Montreal. A city that can fill in both for European and American cities, with major sound stages and VFX companies.
Dragon has all the requisite maneuvering thrusters for an active docking. The current ISS contracts are all for unmanned supply missions, so I suspect the reason they'd rather use the canadarm to dock the thing has to do with the lack of a pilot in the Dragon capsule to perform the docking; they'd rather bring it in with the arm than trust an automated docking system.
SpaceX isn't doing just the rocketry. With the Dragon capsule, they'll be able to mount manned launches entirely by themselves. It's not all that big a leap between putting a man into orbit for a few days, versus sending a man around the moon on a free-return trajectory, my understanding is that all you really need is to get a decent-sized rocket into orbit for a TLI burn, and with Falcon Heavy, they'll be able to do that. So clearly they're capable of going a bit beyond the basic rocketry themselves.
Of course, Mars is a completely different ballgame, and I don't see SpaceX doing that by themselves. Not, at least, without massive funding from whoever wants to go there. They could probably do all the R&D in-house, but somebody else would have to pay for it.
Paying for multiple availability zones is not the same as paying for multiple locations. There are multiple availability zones in a single datacenter. Netflix got it right, they spread their infrastructure over multiple physical locations, and didn't suffer any downtime despite losing a significant chunk of their infrastructure; it was business as usual.
Like anything else, cloud computing still requires you to decide how much redundancy you're willing to pay for. If uptime is that important to you, spreading your infrastructure out over multiple datacenters is a no-brainer.
Data center robberies are actually rather common, so physical attackers should definitely be pretty high up on the list. A google search for "data center robbery" turns up tons of results. One particularly bad offender is C I Host, who had their data center broken into four times in three years. At least one of those times, someone cut through the wall of the datacenter to gain access. Other times, well, it turns out that pointing a gun at someone is a rather good way to get around all that fancy security.
Slashdot Mirror
Sony dumped a ton of R&D resources into the Cell, and what they got was a processor that was not obviously superior to what their competition was doing. It was just different. Cell, as shipped, has one PPE (a general-purpose core that's almost identical to one of the 360's three cores), and eight SPEs (very simple in-order processors with no branch prediction). The SPEs are great at doing math or DSP-style processing, but horrible at general-purpose code execution. Of the eight SPEs that shipped, one is disabled to improve yields (survive manufacturing defects), and one is reserved for the OS.
The end result of this was that Cell wasn't really better or worse than the 360's Xenon, it was just better at some things, and worse at other things. There wasn't a huge difference between the GPUs in the consoles either. The only real differentiating factor between the PS3 and the 360 was the BluRay drive, but the advantages in terms of capacity that were offered were largely outweighed by by the delays they caused in the manufacturing process (although to be fair, Cell had severe yield issues early on, which also constrained supply). The storage capacity advantages were unable to counterbalance the 360's lead in marketshare, and the BluRay drive in the PS3 had some limitations; it actually has significantly lower read speeds than the DVD drive in the 360.
All this is to basically say that the success or failure of the PS3 or 360 had little to do with the specific hardware inside. It had to do with the timing of the introduction of the hardware, and the software libraries available, the pricing, and potentially cultural stigmas (such as the 360's failure in Japan). If Sony had gone with a DVD drive and more traditional (and more mature) processor in the PS3, they would likely have come to market faster, at a lower price point, and probably would have captured a decent chunk more market share in the process.
Sony is smart not to go down the same path with the PS4 as they did with the PS3. In terms of storage capacity, no significant work must be done there. BluRay has matured, and the PS4's BluRay drive can easily ship with much higher throughput rates than the PS3, as well as higher capacity (BDXL bumped up the capacity of discs from 50GB to 128GB). The processor design can be left to a third party vendor (be it Intel, AMD, ARM, or IBM). The graphics processor design wasn't theirs in the PS3 anyhow (it was nVidia's), so no major change is needed in that regard. In short, they can produce a viable successor with a relative minimum of R&D, and it'll probably do just fine.
My understanding is that d-wave's product isn't a general-purpose quantum turing machine, and that the applications are rather specific (optimization problems). It's not a general-purpose quantum computer.
That's incorrect. They can magically crack encryption based on integer factorization or discrete logarithms. There are potential speedups for other types of encryption. Symmetric ciphers like AES are believed to be safe.
PHP doesn't properly support multithreading. It must also be unsuitable for server-side scripting. And because running each script in a separate process is way too expensive, nobody would ever try to use something like mpm_prefork or fastcgi to get around that limitation. That'd be silly.
PHP is also single-threaded per server; PHP doesn't jive well with multithreading. So what we get is mpm_prefork with one instance of mod_php per process, or alternatively, a web server using fastcgi that spawns multiple PHP processes.
True, but often a human can add additional information that can enable you to do more with what imagery you do have.
For example: you have a blurry picture, and you want to enhance it. Why is it blurry? If it's because the image was low resolution, we can't do much about that in the generic case, but if it's because the camera was out of focus, then you can add some extra information. If you can find out the properties of the camera (lens, incorrect focal length, desired focal length, etc), you can do a certain amount of correction, more than you could by simply sharpening the image. The information just isn't there in the image itself, but you're *adding* information, which in turn allows you to do more with what is there. I remember seeing some research papers on the subject. Similarly, motion blur is pretty easy to correct, although in this case it's pretty obvious that the information is there, and can be recovered. There are some pretty impressive examples at http://www.cse.cuhk.edu.hk/~leojia/projects/motion_deblurring/index.html
OK, so there's that, but what about information on what the image contains? Imagine you've got a blurry license plate, and you want to figure out what the plate number is. Well, a general-purpose enhancement of the image (beyond techniques dealing with motion or focus) might not help, but we do have some important extra information that the image does not. We know that it's a license plate, and that there are numbers and letters on it, and more than that, we know the exact shape of those numbers and letters; the nice thing about license plates is that the shapes are uniform. So even if there's not enough information in the image to reconstruct the general image, the fact that we can tell exactly what a given letter of the plate should look like at that distance, angle, resolution, etc, we can add that information to the problem space and get an answer that we couldn't get with the image data alone.
Because analog scaling artifacting is more pleasant than giant hard-edge blocks. A 1080p LCD looks fantastic displaying a 1080p image. Displaying a 240p image, on the other hand, doesn't look terribly good.
I think you're a little confused:
- Atom chips *are* x86 processors, they don't need to do any emulation.
- A typical CPU from 2000 such as a late gen Pentium III (P4 was introduced in 2000) was definitely more than 10x faster than the IBM PC's original 4.77MHz 8088. Try, thousands of times faster at the very least. Tens of thousands of times faster, perhaps.
No offense to WINE, but compatibility isn't great, and even with fully compatible apps, it's never a polished experience. I'd take a solution that passes calls to real libraries over WINE libraries any day.
The real question is how integrated can we get? Emulating a full x86 PC and running x86 Windows inside of it is trivial; you can do that today on an ARM platform with existing software. But since ARM doesn't make desktop-class CPUs, it's slow.
What's more interesting is, how much can you integrate this with Windows? Can you emulate the application itself, intercepting API calls, and passing them off to the native ARM Windows libraries? That's the approach taken by Apple, and unlike the 68K -> PPC transition, for the PPC -> x86 transition they were doing it entirely in userspace...
I'm just old enough to have grown up playing DooM at 320x200, although that doesn't mean I wouldn't choose to play it at 1920x1080 with hardware acceleration; it's about the gameplay, not the graphics. Carmack is a genius, but...
DosBox can fairly faithfully reproduce the execution and the audio of the title, but input and display might not be quite up to spec. For input, I mean older gaming peripherals. Often just the keyboard; you can buy modern USB versions of the IBM model M keyboard, which should satisfy that part at least.
Display is a bit trickier. If you want a really authentic experience, you're going to need to plug a CRT monitor into your modern computer. Not impossible, and since computers back then tended to have fairly small screens, not necessarily all that space consuming either. Grab an old 15" CRT and you're set.
If you can't do that, there are still... possibilities. I don't know about DosBox specifically, but there have been many projects out there that aim to reproduce the feel of playing on an old CRT on modern displays. The higher resolution your modern display the better. There's hardware devices that intentionally fudge the video signal to reproduce classic effects (add scanlines, slightly blur on the horizontal), and there are software filters out there that go much further, trying to actually reproduce the CRT sub-pixel pattern on modern LCDs. One example can be found here: http://www.bogost.com/games/a_television_simulator.shtml
You'd be far better compiling to Javascript and executing the code directly. I know that Google Web Toolkit can compile Java to Javascript, there's probably compilers available for other languages out there too.
Wups. I really ought to get more sleep.
Why do we think that? Well, I don't know about you, but take a look here: http://en.wikipedia.org/wiki/List_of_pharmaceutical_companies
Johnson and Johnson has a total revenue of $61.9 billion USD, and a net income of $12.3 billion dollars. Now, I'm not a financial whiz, but $12.3 billion dollars seems like a rather lot of money to me.
Except, they don't. They're a business, they wouldn't be operating in Canada if they were making a loss here. They simply aren't able to inflate costs as insanely in Canada as they are in the US.
Wouldn't it be 300 thousand people? The article cited 1 in 3000.
Except those same drugs from the same companies cost far less and still produce huge profits for the pharma companies. Fancy that.
Except, Samsung doesn't design it, they just manufacture it. There's no particular requirement that Samsung be the one who produces the Apple-designed SoCs. Apple could just as easily contract any other SoC manufacturer (or even just a generic fab like TSMC) to produce the things.
The idea that Apple would replace ARM with Intel is a bit silly since at the present point in time Intel doesn't have anything even remotely competitive with ARM's products in the embedded market. The idea that Apple would replace ARM with Intel because of Samsung just doesn't make any sense.
How convenient, Ubisoft's largest studio happens to be in a city equipped for major motion picture production, Montreal. A city that can fill in both for European and American cities, with major sound stages and VFX companies.
You've got it backwards. Gravity on Mars is much lower than on Earth. Martian gravity is 0.376g
It also has one third the gravity of earth, so that helps somewhat. Although that helps a lot more with lifting off than landing.
Dragon has all the requisite maneuvering thrusters for an active docking. The current ISS contracts are all for unmanned supply missions, so I suspect the reason they'd rather use the canadarm to dock the thing has to do with the lack of a pilot in the Dragon capsule to perform the docking; they'd rather bring it in with the arm than trust an automated docking system.
SpaceX isn't doing just the rocketry. With the Dragon capsule, they'll be able to mount manned launches entirely by themselves. It's not all that big a leap between putting a man into orbit for a few days, versus sending a man around the moon on a free-return trajectory, my understanding is that all you really need is to get a decent-sized rocket into orbit for a TLI burn, and with Falcon Heavy, they'll be able to do that. So clearly they're capable of going a bit beyond the basic rocketry themselves.
Of course, Mars is a completely different ballgame, and I don't see SpaceX doing that by themselves. Not, at least, without massive funding from whoever wants to go there. They could probably do all the R&D in-house, but somebody else would have to pay for it.
Paying for multiple availability zones is not the same as paying for multiple locations. There are multiple availability zones in a single datacenter. Netflix got it right, they spread their infrastructure over multiple physical locations, and didn't suffer any downtime despite losing a significant chunk of their infrastructure; it was business as usual.
Like anything else, cloud computing still requires you to decide how much redundancy you're willing to pay for. If uptime is that important to you, spreading your infrastructure out over multiple datacenters is a no-brainer.
Data center robberies are actually rather common, so physical attackers should definitely be pretty high up on the list. A google search for "data center robbery" turns up tons of results. One particularly bad offender is C I Host, who had their data center broken into four times in three years. At least one of those times, someone cut through the wall of the datacenter to gain access. Other times, well, it turns out that pointing a gun at someone is a rather good way to get around all that fancy security.