Water vapor only stays in the atmosphere for a week or so, and then it rains out. CO2 will stay for centuries, and will gradually build up as we emit more than is absorbed. Methane is also fairly short lived.
Other humans, with different interest, could re-interpret the same data, and publish their findings in a paper. It's a lot of work, but it's not impossible.
Actually, several group of people have done exactly this, and their results are in pretty good agreement.
This isn't even true; global temperatures haven't risen since 1998
Except that 9 of the 10 hottest years in our measurements have been after 1998.
1998 was a statistical fluke, an out-lier, due to a very active El-Nino during that particular year. In 2010, the same temperature was reached under very average circumstances.
When it's frozen, it's stacked up high on the Greenland bedrock., and does not effect sea level at all. When it's in the sea (frozen or not), it raises sea level.
Re:And Intel isn't happy about it.
on
Arduino Goes ARM
·
· Score: 1
Of course, this project has a low-end ARM. It is far away from any market that Intel is interested in.
The higher end ARMs that are used in tablets and phones are monsters compared to this one, and not really interesting for hobby use anyway. They are usually only available in BGA, and depend on external memory chips.
That we have the resources, at this moment, to utterly and permanently eliminate starvation is not an if.
No we don't, especially not permanently. Populations will grow exponentially, while resources are bounded.
Also, don't forget that our food productivity is so high only because people wasted money and time tinkering with science, rather than feeding the poor.
Also, it only saves power when you're actively using WiFi. Existing WiFi products already support a power save mode where the receiver is turned off completely for most of the time. It uses a timer to turn itself on briefly to receive beacons, and then turns itself off when there's no traffic indicated. This only leaves the radio on for a few % of the time. Additional power reduction from this mode will be very small.
The new invention is only useful when you're using the WiFi at such an activity level that the WiFi power save mode would affect throughput too much. For most users, that will not be a significant amount of time.
Of course, programs such as mplayer have plenty of hand optimized assembly code. The point is that if you take a random program like that, it will likely have a good optimized x86 port already, and a lesser optimized ARM version.
And that doesn't just apply to the application itself, but also any of the libraries that it uses.
Most of Android Linux is also the same old crap. Google only rewrote a small portion of it, and that already runs on x86 anyway.
Once Intel succeeds in creating a low power x86, it will take very little effort to turn it into a mobile platform, but with all the advantages of a standard and well-supported architecture.
For instance, having a x86 on your phone means that it's a lot easier to distribute native code apps in a single binary format. One of the problems with ARM is that there are so many incompatible versions in both core and SoC design, which would require the distributor to recompile for a bunch of targets, and running them all through QA.
ARM is working very hard to add shear complexity to their devices. In order to get high performance, they'll be forced to. Deep pipelines, speculative branching, complex instruction decoding, re-ordering, parallelizing, register renaming. It's all stuff that wasn't present in early ARM chips we all know and love for their simplicity.
The performance requirements on phones only go up, and as ARM will have to make their cores more complex, the disadvantage of a little bit of x86-specific cruft will be minor. The x86 instruction decoding is a solved problem, and it's not significantly harder than Cortex decoding taking into account the overall complexity of the whole chip. Beyond the x86 decoding, there's not much in the Intel core that needs to be kept as legacy. Everything else can be redesigned for lower power, and it's the same stuff that ARM is going to have to add to their new designs.
An Android phone is already running a lot of "unoptimized" desktop software, such as the Linux kernel and all related libraries. Of course, I wouldn't call that unoptimized either.
You seem to be missing the point that Intel is planning to make a lower power version, so you can run all your desktop software without draining the battery, just like you can do now with an ARM core.
People following computer architecture classes have produced mostly stuff that didn't work very well in the real world. Alpha, MIPS, HPPA, Itanium... nice on paper, but x86 beat them all.
Even ARM is now moving away from the nice clean architecture they had. Have you looked at Cortex ? It's a mess. But that mess is exactly what allows it to perform well.
Of course, if you're unlucky to have some optimized ARM code that you're porting to Cortex, you'll basically have to rewrite the whole thing again.
My point was that the word "legacy" was used by GP as a disadvantage. I'm saying that it's actually an advantage. Of course, you may argue exactly how big the advantage is, but it's certainly positive.
The only problem is the power consumption, and if Intel can solve that, they may end up with a superior platform.
For instance, a x86 JIT compiler doesn't require windows, dos, or a user interface, but is still tied very much to the target platform. Good compilers for the x86 already exist, and keep getting improved for the desktop platform.
The legacy cruft in a x86 that is actually not useful is very small, while other legacy cruft is actually working very well.
Actually, one of the disadvantages of ARM is that there's not enough legacy cruft. There are a bunch of different, incompatible architectures (I think they're up to v7 now). Big/little endian variations, and there's the ARM/Thumb/Thumb-2 and Jazelle instruction sets. This doesn't make it a very pleasant target, since you have to maintain several different versions of all your libraries. It especially sucks for optimized assembly code.
Whether ARM will always be lower power depends. ARM is getting to the point where they have to move into higher-performance arena, and they'll run into problems that Intel has already solved.
Operating systems, optimized multimedia libraries, codecs, encryption/decryption, device drivers for all the hardware, file systems, network stack. There's plenty of stuff that doesn't deal directly with the user interface, but you'd still find in a phone.
Of course, intel engineers have a lot more experience in high performance design. It's probably easier to take existing high performance circuits, and make them run at lower power, than it is to design high-performance/low power circuits from scratch.
It wouldn't have been a problem if Microsoft hadn't released Vista when it was so crappy, and convinced nearly all the vendors to discontinue XP in favor of it.
I wanted a decent/cheap laptop, and they all came with Vista. Laptops with XP were hard to find at that time, especially with all the other specifications that I would have liked, and for a price I was willing to pay. I tried dowgrading to XP, but there were no drivers for some of the hardware.
Slashdot Mirror
Water vapor only stays in the atmosphere for a week or so, and then it rains out. CO2 will stay for centuries, and will gradually build up as we emit more than is absorbed. Methane is also fairly short lived.
Other humans, with different interest, could re-interpret the same data, and publish their findings in a paper. It's a lot of work, but it's not impossible.
Actually, several group of people have done exactly this, and their results are in pretty good agreement.
Thermometer readings are not subject to interpretation. The post-processing is, but that part can be replicated in some lab in Oslo.
Except that 9 of the 10 hottest years in our measurements have been after 1998.
1998 was a statistical fluke, an out-lier, due to a very active El-Nino during that particular year. In 2010, the same temperature was reached under very average circumstances.
It wasn't a matter of exaggerating a claim. Somebody grabbed the wrong map, and didn't consult with a scientist.
When it's frozen, it's stacked up high on the Greenland bedrock., and does not effect sea level at all. When it's in the sea (frozen or not), it raises sea level.
Of course, this project has a low-end ARM. It is far away from any market that Intel is interested in.
The higher end ARMs that are used in tablets and phones are monsters compared to this one, and not really interesting for hobby use anyway. They are usually only available in BGA, and depend on external memory chips.
No we don't, especially not permanently. Populations will grow exponentially, while resources are bounded.
Also, don't forget that our food productivity is so high only because people wasted money and time tinkering with science, rather than feeding the poor.
Also, it only saves power when you're actively using WiFi. Existing WiFi products already support a power save mode where the receiver is turned off completely for most of the time. It uses a timer to turn itself on briefly to receive beacons, and then turns itself off when there's no traffic indicated. This only leaves the radio on for a few % of the time. Additional power reduction from this mode will be very small.
The new invention is only useful when you're using the WiFi at such an activity level that the WiFi power save mode would affect throughput too much. For most users, that will not be a significant amount of time.
Of course, programs such as mplayer have plenty of hand optimized assembly code. The point is that if you take a random program like that, it will likely have a good optimized x86 port already, and a lesser optimized ARM version.
And that doesn't just apply to the application itself, but also any of the libraries that it uses.
Most of Android Linux is also the same old crap. Google only rewrote a small portion of it, and that already runs on x86 anyway.
Once Intel succeeds in creating a low power x86, it will take very little effort to turn it into a mobile platform, but with all the advantages of a standard and well-supported architecture.
For instance, having a x86 on your phone means that it's a lot easier to distribute native code apps in a single binary format. One of the problems with ARM is that there are so many incompatible versions in both core and SoC design, which would require the distributor to recompile for a bunch of targets, and running them all through QA.
ARM is working very hard to add shear complexity to their devices. In order to get high performance, they'll be forced to. Deep pipelines, speculative branching, complex instruction decoding, re-ordering, parallelizing, register renaming. It's all stuff that wasn't present in early ARM chips we all know and love for their simplicity.
The performance requirements on phones only go up, and as ARM will have to make their cores more complex, the disadvantage of a little bit of x86-specific cruft will be minor. The x86 instruction decoding is a solved problem, and it's not significantly harder than Cortex decoding taking into account the overall complexity of the whole chip. Beyond the x86 decoding, there's not much in the Intel core that needs to be kept as legacy. Everything else can be redesigned for lower power, and it's the same stuff that ARM is going to have to add to their new designs.
An Android phone is already running a lot of "unoptimized" desktop software, such as the Linux kernel and all related libraries. Of course, I wouldn't call that unoptimized either.
You seem to be missing the point that Intel is planning to make a lower power version, so you can run all your desktop software without draining the battery, just like you can do now with an ARM core.
People following computer architecture classes have produced mostly stuff that didn't work very well in the real world. Alpha, MIPS, HPPA, Itanium... nice on paper, but x86 beat them all.
Even ARM is now moving away from the nice clean architecture they had. Have you looked at Cortex ? It's a mess. But that mess is exactly what allows it to perform well.
Of course, if you're unlucky to have some optimized ARM code that you're porting to Cortex, you'll basically have to rewrite the whole thing again.
My point was that the word "legacy" was used by GP as a disadvantage. I'm saying that it's actually an advantage. Of course, you may argue exactly how big the advantage is, but it's certainly positive.
The only problem is the power consumption, and if Intel can solve that, they may end up with a superior platform.
For instance, a x86 JIT compiler doesn't require windows, dos, or a user interface, but is still tied very much to the target platform. Good compilers for the x86 already exist, and keep getting improved for the desktop platform.
The legacy cruft in a x86 that is actually not useful is very small, while other legacy cruft is actually working very well.
Actually, one of the disadvantages of ARM is that there's not enough legacy cruft. There are a bunch of different, incompatible architectures (I think they're up to v7 now). Big/little endian variations, and there's the ARM/Thumb/Thumb-2 and Jazelle instruction sets. This doesn't make it a very pleasant target, since you have to maintain several different versions of all your libraries. It especially sucks for optimized assembly code.
Whether ARM will always be lower power depends. ARM is getting to the point where they have to move into higher-performance arena, and they'll run into problems that Intel has already solved.
Why does it need to be an application ? How about an optimized codec written in x86 assembly ?
Operating systems, optimized multimedia libraries, codecs, encryption/decryption, device drivers for all the hardware, file systems, network stack. There's plenty of stuff that doesn't deal directly with the user interface, but you'd still find in a phone.
Of course, intel engineers have a lot more experience in high performance design. It's probably easier to take existing high performance circuits, and make them run at lower power, than it is to design high-performance/low power circuits from scratch.
Of course not, but there is plenty of software that doesn't deal directly with the user.
x86 legacy means large amounts of existing software that can now be easily ported to the phone. It's an advantage.
The only advantage for ARM is the lower power requirement, so if Intel can make their chips less power hungry, they can take over some of the market.
I await your better definitions. In the mean time, I'll use Turing's.
It wouldn't have been a problem if Microsoft hadn't released Vista when it was so crappy, and convinced nearly all the vendors to discontinue XP in favor of it.
I always build my own desktop, but it runs Linux anyway. Laptops I always buy at the local store when they have a decent one for a special sale price.
I wanted a decent/cheap laptop, and they all came with Vista. Laptops with XP were hard to find at that time, especially with all the other specifications that I would have liked, and for a price I was willing to pay. I tried dowgrading to XP, but there were no drivers for some of the hardware.