A game is far easier to move into WinRT compared to a desktop app using a window-based GUI with GDI for drawing. You get access to a fullscreen surface and you can manipulate that surface using DirectX. I wouldn't find a Windows 8-style requirement as much of a problem for a lot of titles. It will probably start off with touch-based titles similar to what you find for iOS and Android, but if that succeeds, I think you will see a lot of more "serious" desktop games ported over.
However, you are not only polluting RAM with duplicate versions of code. You are also polluting L2 (and instruction L1, but that will probably be flushed anyway). No reason to make those context switches more expensive than what is really needed. And a large statically linked executable is in no way trivial to ignore, you can easily reach 10s of MBs.
The main problem in bandiis not the chip, it is the neuron-chip interface. Just "throw a bunch of conducting needles down into the tissue and let it fuse to whatever when the wound heals" will most likely not scale to original resolution, and it will definitely have problems with color encoding.
Everything I've read suggests the opposite: that manned spaceflight is hugely more expensive that unmanned, and I've never seen any evidence that suggests that any space flights had to be redone to correct robot error. (Human error, OTOH... *cough* Hubble *cough*) I'd like to see anything you have that suggests differently. (j/k about the Hubble telescope, btw, since they waited until the first regularly scheduled servicing mission to fix it, rather than making a special trip)
How would you define robot error in this case? We have unmanned missions that have failed spectacularly in many ways. However, of course you can attribute them all to human error. Even if an independent navigation program fails, or whatever, you will not blame the machine, but the development team. When AI has reached point where it would be relevant to blame robot error, then manned missions are truly unnecessary.
It's all dependent on the power. As the beam is concentrated, a direct beam into the eye can relatively quickly cause permanent damage. However, you can also easily enough disperse the beam a little, or use very low power. I would suppose that the beam is dispersed in an application like this, as you wouldn't want to identify explosives just within a narrow line of sight.
As anecdotal evidence, an intended direct flight from Las Vegas to Frankfurt was changed in the last minute to include a refuelling stop in Iceland, due to very high temperatures in Vegas. I suppose the main point was to reduce the weight at original liftoff and this way was cheaper to the airline compared to refusing passengers and cargo. We were only about an hour late at our destination, if memory serves me.
The main problem with this article is that it seems like the authors are simply reporting the compound number for Memory - Working Set for all browser processes. This is problematic in so many ways it ain't even funny. Foremost, multiple processes requiring the same page mapped into RAM will count that page multiple times. With architectures involving a lot of cross-process communication and multiple instances, like IE and Chrome, all code pages that are mapped into multiple processes will be counted multiple times (including any Windows OS DLLs mapped by IE), as long as they are part of the active working set. In addition some of the inter-process communication is probably handled by mapping common regions of memory, and thus also counted multiple times.
So, in one sense, IE and Chrome are losing out big in the multi-tab test. On the other hand, when tabs are closed, the related processes are also completely closed. This means that the associated heap is returned in full. In Firefox, even if some regions of the heap are freed back to the OS, Windows will not actively reclaim that working set. Slowly, the untouched pages will be removed and replaced by caching, but if there is no memory load, the best guess by the OS is that a process that just used a lot of memory and freed it might start doing it again. It is possible that Firefox, due to the monolithic process structure, ends up with a more fragmented heap (or a heap implementation that is not returning pages to the OS) so the OS could not successfully reclaim the pages (and only page them out to disk as a last resort), but we do not know that from these tests. It is easy to try this yourself, write up some small C program allocating a big buffer, freeing it and then pausing for a scanf/gets or something.
It is relatively easy to measure CPU usage or amount of I/O. Total time usage is also easy to measure and it says something about the conditions even under load. Memory is quite different. Memory is allocated all the time and the total bandwidth usage is closely related to the actual computations of the CPU. Even in a fully virtualized environment, the hypervisor cannot keep too detailed stats on memory usage - the overhead would balloon. At the same time, memory is a constrained resource with complicated temporal dependencies. You cannot free some memory from a process now and just give it back later. And when you bring multiple related processes into the mix, what you measure is all depending on how you define your tests. In many situations, the best metric is probably to look at full system metrics anyway, i.e. delta on total available/free memory in Windows. Many of the same issues will still apply, though. The question really becomes why you are interested in memory usage. If you want to know how the OS will behave when another process is allocating a lot of memory, test for that and verify memory usage as well as load times when you bring back the browser.
Sales tax most certainly does apply for digital downlaod transactions within the EU. However, there have been disputes regarding which tax should be applied. Stating that the app store vendor is in e.g. the U.S. will not necessarily hold water, either. That's precisely the kind of issues that MS needs to handle in some way.
Very good points, but an important correction: at 100 fps, 2 frames constitute 20 ms. Agreed, though, that up to about 50 ms should probably be acceptable, if jitter is kept to a minimum. A 60 Hz refresh rate can be to low from a jitter perspective, rather than relating to the latency itself.
I think you are missing how many open source projects that are essentially the same. In many cases, when you are actually interested in digging into the source, you are trying to do something that's orthogonal to the plans of the mother project. There might be docs, but in many projects, they are thin. Maybe not in the largest ones, mind you, but frequently written for either end-users or developers using an external API, or really internal stuff that's even less useful for an external reader than the code itself. The middle ground "orientation map and design guidelines for the internal architecture" is simply not there, most of the time. A code dump in itself is frequently immensely useful, especially when the license is permissive enough that you can use it for a bit more than just debugging fun and actually build on it yourself.
Well, we don't know the mission. If it was imaging that would of course take quite a bit of attitude control thrusters. Space debris is seriously overstated as a general problem in most orbits. The risk is real, but the cases where the debris has a well-enough known orbit that you can currently do anything about it are few, except for in a few specific bands.
In other news, Aristotle is suing you for infringing his intellectural property rights on fictional physics. Maintaining speed relative to another object does not, generally, require any continuous supply of additional energy. Free fall elliptical orbits are one example.
The point is that you have a flesh-and-blood driver in the front car. Therefore, you "only" need to consider what can happen within the tightly controlled corridor of vehicles forming the train. In heavy weather etc, things can still get messy. However, the software could possibly adapt by lengthening distances (causing less than optimal drag) or simply disabling the automatic train. At this point, it is a convenience and efficiency-improving measure while on the highway, not a replacement for a human driver that should be ready to retake control. It is adaptive cruise control on seriously heavy steroids, but no auto-pilot avoiding pedestrians à la Google.
I think that Firefly contained quite a bit of digital post-production, especially considering its age. Doing that on a per-episode basis, with the additional requirements on aligning shots etc to do composite could easily drive up the costs. Riding around in nature is also more expensive compared to work on a soundstage. You need to build the stage, but you don't exactly go out and shoot in unchanged nature anyway. And shooting outside limits your access to proper conditions regarding lighting etc.
And any streaming video mobile device with great battery life does that by offloading the decoding to the GPU or a fixed function specific video decoder, which in both cases will be separate IP within the SoC.
Intel is certainly planning to get Atom to 22 nm soon. And the roadmaps point at a 14nm Atom in 2014, that is, at the same time as the architecture tick following Haswell. This means that Atom will see three process transitions in as many years to get up to speed. I guess the Medfield design was too far gone and that the 22nm capacity was already booked in to simply switch over.
ARM can easily grab something in the server market. Many server tasks are already bound to be able to scale out and parallelize to tens or hundreds or thousands of chips (serving millions of concurrent requests). In that setting, replacing each big x86 core with e.g. 16 ARM cores with lower total TDP is a viable concept. It is only in tasks where single-thread latency is a critical thing where ARM cannot compete. And that's an ever slimmer part of high-performance desktop workloads, as well as some specific server and HPC tasks. Some algorithms simply do not parallelize well, but serving loads of independent web users is relatively easy to parallelize and that's honestly what most servers are doing.
However, I am quite confident that Intel will stay and become quite viable in tablets and high-end smartphones. They have the process knowledge and they are certainly good enough at designing chips. And the x86 ISA itself, to the dismay of many, is not that much of an issue.
And you are delusional. When the power of the engine is anywhere close to the toprated level of 400bhp, the gas demand is staggering. The point is that at no point, those engines are more efficient in terms of hp actually developed. You are paying, in dollars and gallons of gas, for a lot of headroom that is never used. As this is a car debate, I guss one should use a software development analogy, and I give you... this... Sure, a lot of headroom in your design for any possible need is a nice thing, but it is hard to say that it is efficient.
I think you are seriously over-estimating the transport cost. Figure how many CFLs fit in a transport container. Figure how many containers fit on a freighter ship. For electric vehicles, the most important aspect in the comparison is the source of the electricity. With current battery longevity, production of a car once again takes a minor part in the total energy consumed, just like the case is for an incandescent light and most CFLs. Consumer electronics, on the other hand, can be quite a different story. Apple's life-cycle analysis for the iPad put quite a lot of the energy use during production. Again, transport was a minor part. Transport and distribution costs really ony start to matter for stuff which is cheap per kg (foodstuff) or where air freight starts to matter. Air transport might be used to deliver individual pieces ordered from China directly, but not imports for general distribution of anything but specialty articles.
And not all Wifi iPad2s, either. At least not among those currently in the channel, just so you don't go buying one for the sole purpose of getting the improved battery life.
They are. However, their relative FP64 performance has dropped compared to the previous generation. If I remember correctly, there is now separate silicon to do FP64, rather than just a modified path in the FP32 cores. In the previous architecture, we were down to 1/12 of FP32 performance, only a third of some of the Fermi chip cores could do FP64, and at half speed. In the new chip, the FP64 cores can do full-speed calculations, but there are only 8 such cores, versus 192 conventional cores, giving a 1/24 performance ration.
However, Ryan Smith at Anandtech speculated that the existence of dedicated FP64 cores means that a future Fermi based on Kepler will be a mean beast, if they do a tape-out with exclusively FP64 cores. The only thing holding back double-precision then will be memory bandwidth (which would be a large enough deterrent in many cases).
Slashdot Mirror
A game is far easier to move into WinRT compared to a desktop app using a window-based GUI with GDI for drawing. You get access to a fullscreen surface and you can manipulate that surface using DirectX. I wouldn't find a Windows 8-style requirement as much of a problem for a lot of titles. It will probably start off with touch-based titles similar to what you find for iOS and Android, but if that succeeds, I think you will see a lot of more "serious" desktop games ported over.
And you are supposed to learn how renting works (and whether you are being shafted or making a good deal), without math?
However, you are not only polluting RAM with duplicate versions of code. You are also polluting L2 (and instruction L1, but that will probably be flushed anyway). No reason to make those context switches more expensive than what is really needed. And a large statically linked executable is in no way trivial to ignore, you can easily reach 10s of MBs.
The main problem in bandiis not the chip, it is the neuron-chip interface. Just "throw a bunch of conducting needles down into the tissue and let it fuse to whatever when the wound heals" will most likely not scale to original resolution, and it will definitely have problems with color encoding.
Everything I've read suggests the opposite: that manned spaceflight is hugely more expensive that unmanned, and I've never seen any evidence that suggests that any space flights had to be redone to correct robot error. (Human error, OTOH... *cough* Hubble *cough*) I'd like to see anything you have that suggests differently. (j/k about the Hubble telescope, btw, since they waited until the first regularly scheduled servicing mission to fix it, rather than making a special trip)
How would you define robot error in this case? We have unmanned missions that have failed spectacularly in many ways. However, of course you can attribute them all to human error. Even if an independent navigation program fails, or whatever, you will not blame the machine, but the development team. When AI has reached point where it would be relevant to blame robot error, then manned missions are truly unnecessary.
It's all dependent on the power. As the beam is concentrated, a direct beam into the eye can relatively quickly cause permanent damage. However, you can also easily enough disperse the beam a little, or use very low power. I would suppose that the beam is dispersed in an application like this, as you wouldn't want to identify explosives just within a narrow line of sight.
As anecdotal evidence, an intended direct flight from Las Vegas to Frankfurt was changed in the last minute to include a refuelling stop in Iceland, due to very high temperatures in Vegas. I suppose the main point was to reduce the weight at original liftoff and this way was cheaper to the airline compared to refusing passengers and cargo. We were only about an hour late at our destination, if memory serves me.
The main problem with this article is that it seems like the authors are simply reporting the compound number for Memory - Working Set for all browser processes. This is problematic in so many ways it ain't even funny. Foremost, multiple processes requiring the same page mapped into RAM will count that page multiple times. With architectures involving a lot of cross-process communication and multiple instances, like IE and Chrome, all code pages that are mapped into multiple processes will be counted multiple times (including any Windows OS DLLs mapped by IE), as long as they are part of the active working set. In addition some of the inter-process communication is probably handled by mapping common regions of memory, and thus also counted multiple times.
So, in one sense, IE and Chrome are losing out big in the multi-tab test. On the other hand, when tabs are closed, the related processes are also completely closed. This means that the associated heap is returned in full. In Firefox, even if some regions of the heap are freed back to the OS, Windows will not actively reclaim that working set. Slowly, the untouched pages will be removed and replaced by caching, but if there is no memory load, the best guess by the OS is that a process that just used a lot of memory and freed it might start doing it again. It is possible that Firefox, due to the monolithic process structure, ends up with a more fragmented heap (or a heap implementation that is not returning pages to the OS) so the OS could not successfully reclaim the pages (and only page them out to disk as a last resort), but we do not know that from these tests. It is easy to try this yourself, write up some small C program allocating a big buffer, freeing it and then pausing for a scanf/gets or something.
It is relatively easy to measure CPU usage or amount of I/O. Total time usage is also easy to measure and it says something about the conditions even under load. Memory is quite different. Memory is allocated all the time and the total bandwidth usage is closely related to the actual computations of the CPU. Even in a fully virtualized environment, the hypervisor cannot keep too detailed stats on memory usage - the overhead would balloon. At the same time, memory is a constrained resource with complicated temporal dependencies. You cannot free some memory from a process now and just give it back later. And when you bring multiple related processes into the mix, what you measure is all depending on how you define your tests. In many situations, the best metric is probably to look at full system metrics anyway, i.e. delta on total available/free memory in Windows. Many of the same issues will still apply, though. The question really becomes why you are interested in memory usage. If you want to know how the OS will behave when another process is allocating a lot of memory, test for that and verify memory usage as well as load times when you bring back the browser.
Sales tax most certainly does apply for digital downlaod transactions within the EU. However, there have been disputes regarding which tax should be applied. Stating that the app store vendor is in e.g. the U.S. will not necessarily hold water, either. That's precisely the kind of issues that MS needs to handle in some way.
Very good points, but an important correction: at 100 fps, 2 frames constitute 20 ms. Agreed, though, that up to about 50 ms should probably be acceptable, if jitter is kept to a minimum. A 60 Hz refresh rate can be to low from a jitter perspective, rather than relating to the latency itself.
I think you are missing how many open source projects that are essentially the same. In many cases, when you are actually interested in digging into the source, you are trying to do something that's orthogonal to the plans of the mother project. There might be docs, but in many projects, they are thin. Maybe not in the largest ones, mind you, but frequently written for either end-users or developers using an external API, or really internal stuff that's even less useful for an external reader than the code itself. The middle ground "orientation map and design guidelines for the internal architecture" is simply not there, most of the time. A code dump in itself is frequently immensely useful, especially when the license is permissive enough that you can use it for a bit more than just debugging fun and actually build on it yourself.
Well, we don't know the mission. If it was imaging that would of course take quite a bit of attitude control thrusters. Space debris is seriously overstated as a general problem in most orbits. The risk is real, but the cases where the debris has a well-enough known orbit that you can currently do anything about it are few, except for in a few specific bands.
In other news, Aristotle is suing you for infringing his intellectural property rights on fictional physics. Maintaining speed relative to another object does not, generally, require any continuous supply of additional energy. Free fall elliptical orbits are one example.
The point is that you have a flesh-and-blood driver in the front car. Therefore, you "only" need to consider what can happen within the tightly controlled corridor of vehicles forming the train. In heavy weather etc, things can still get messy. However, the software could possibly adapt by lengthening distances (causing less than optimal drag) or simply disabling the automatic train. At this point, it is a convenience and efficiency-improving measure while on the highway, not a replacement for a human driver that should be ready to retake control. It is adaptive cruise control on seriously heavy steroids, but no auto-pilot avoiding pedestrians à la Google.
I think that Firefly contained quite a bit of digital post-production, especially considering its age. Doing that on a per-episode basis, with the additional requirements on aligning shots etc to do composite could easily drive up the costs. Riding around in nature is also more expensive compared to work on a soundstage. You need to build the stage, but you don't exactly go out and shoot in unchanged nature anyway. And shooting outside limits your access to proper conditions regarding lighting etc.
And any streaming video mobile device with great battery life does that by offloading the decoding to the GPU or a fixed function specific video decoder, which in both cases will be separate IP within the SoC.
you aren't getting those A15s in large quantities until next year when Intel will have the next iteration of Atom ready anyway
Atom is an overheading underpowered piece of junk. I hate my atom notebook, I love my dual ARM Xoom.
Have you tried running the same OS and applications on both?
Intel is certainly planning to get Atom to 22 nm soon. And the roadmaps point at a 14nm Atom in 2014, that is, at the same time as the architecture tick following Haswell. This means that Atom will see three process transitions in as many years to get up to speed. I guess the Medfield design was too far gone and that the 22nm capacity was already booked in to simply switch over.
ARM can easily grab something in the server market. Many server tasks are already bound to be able to scale out and parallelize to tens or hundreds or thousands of chips (serving millions of concurrent requests). In that setting, replacing each big x86 core with e.g. 16 ARM cores with lower total TDP is a viable concept. It is only in tasks where single-thread latency is a critical thing where ARM cannot compete. And that's an ever slimmer part of high-performance desktop workloads, as well as some specific server and HPC tasks. Some algorithms simply do not parallelize well, but serving loads of independent web users is relatively easy to parallelize and that's honestly what most servers are doing.
However, I am quite confident that Intel will stay and become quite viable in tablets and high-end smartphones. They have the process knowledge and they are certainly good enough at designing chips. And the x86 ISA itself, to the dismay of many, is not that much of an issue.
And you are delusional. When the power of the engine is anywhere close to the toprated level of 400bhp, the gas demand is staggering. The point is that at no point, those engines are more efficient in terms of hp actually developed. You are paying, in dollars and gallons of gas, for a lot of headroom that is never used. As this is a car debate, I guss one should use a software development analogy, and I give you... this... Sure, a lot of headroom in your design for any possible need is a nice thing, but it is hard to say that it is efficient.
I think you are seriously over-estimating the transport cost. Figure how many CFLs fit in a transport container. Figure how many containers fit on a freighter ship. For electric vehicles, the most important aspect in the comparison is the source of the electricity. With current battery longevity, production of a car once again takes a minor part in the total energy consumed, just like the case is for an incandescent light and most CFLs. Consumer electronics, on the other hand, can be quite a different story. Apple's life-cycle analysis for the iPad put quite a lot of the energy use during production. Again, transport was a minor part. Transport and distribution costs really ony start to matter for stuff which is cheap per kg (foodstuff) or where air freight starts to matter. Air transport might be used to deliver individual pieces ordered from China directly, but not imports for general distribution of anything but specialty articles.
And not all Wifi iPad2s, either. At least not among those currently in the channel, just so you don't go buying one for the sole purpose of getting the improved battery life.
Uh, replying to myself. I of course meant that a future TESLA based on Kepler would be a beast, not Fermi.
They are. However, their relative FP64 performance has dropped compared to the previous generation. If I remember correctly, there is now separate silicon to do FP64, rather than just a modified path in the FP32 cores. In the previous architecture, we were down to 1/12 of FP32 performance, only a third of some of the Fermi chip cores could do FP64, and at half speed. In the new chip, the FP64 cores can do full-speed calculations, but there are only 8 such cores, versus 192 conventional cores, giving a 1/24 performance ration.
However, Ryan Smith at Anandtech speculated that the existence of dedicated FP64 cores means that a future Fermi based on Kepler will be a mean beast, if they do a tape-out with exclusively FP64 cores. The only thing holding back double-precision then will be memory bandwidth (which would be a large enough deterrent in many cases).
Can it mine bitcoins while running Crysis n at 240 FPS and 4K resolution?