People don't read the EULA because it doesn't matter wht the EULA says. If the EULA says that you have to give your first-born child to them, you click yes and don't give them your first-born child. The EULA contains a large amount of shit, most of which is illegible, much of which is illegal, and all of which is usually unenforceable. The only purpose to it is to give the BSA etc. a shred of credibilty when they demand your first-born child.
Um... you do realize that 64 bit IP addresses allow 18,446,744,073,709,551,616 IP addresses? And that each IP address could have many devices on it, since UDP & TCP both add another 16 bits to the source & destination size? That's enough for 500 IPs per person, for 10 billion people per planet for 10 planets per solar system, for 9000 solar systems per galaxy, for 10 galaxies. By the time we come close to running out of 64-bit IP addresses, we'll be more worried about running out of galaxies than some archiac network protocal. The "reason" why they chose 128-bit IP addresses was so that 64-bit MAC addresses could be used as subnet addresses, slightly simplifying DHCP & the like. Well, they also wanted to have enough bits in the upper portion to make routing simpler. But in they process they double the amount of bandwidth used by small packets, like games. IPv4 is already kinda bloated, but 128-bit IPs is moreso.
A little, but not much. It keeps most of the ugly instruction decode of tradition x86, but adds an extra 8 GPRs (accessed via an additional opcode prefix). It also does a few minor other things, like I think it adds IP relative addressing.
Basically, they did what they could to make it better while still using the same hardware to decode instructions. I'd have preferred it if they had a second, simpler decode unit to handle the new stuff so that the overcomplicated x86 decode could eventually be phased out, but it didn't make sense business-wise for them to do so.
Spriggan is among the worst anime I've ever seen. Not the worst, but in the bottom 20%. If you really liked both Ninja Scroll and Akira then maybe you'll think Spriggan is acceptable. Maybe.
A few anime that I'd actually recommend, and their genres, listed best to worst (but they're all good):
Dragon Half (comedy) Ayashi no Ceres / Ceres! Celestial Legend (romance, action) Trigun (action, comedy) Noir (action, music, inconsistent plot, but very nice) Rurouni Kenshin OAVs / Samurai X OAVs (bloody action & romance, with a historical theme) note: The OAVs for Kenshin are VERY different from the TV series Utena (weird... I've only seen the TV series) Ghost in the Shell (a classic... themed, action) Ah! My Goddess / Aa! Megami-sama (romance) New Angel (porn) Record of Lodoss War (D&D, like LOTR)
note: "/" is used for anime that have multiple names
Are there difficulties licensing ARMs instruction set? That would seem bizarre to me (why hasn't Intel patented IA32?), but I guess weirder things happen.
I realize that ARM is called a RISC instruction set, and has all the RISC goodness: load/store instructions, 3-operand arithmetic, simple decode, simple operations, and (almost) a flat register file. However, unlike "classic" RISC instruction sets, it has multiple instruction sizes, and therefore achieves noticably better code density.
My impression, I could be mistaken, was that MIPS16 was simply a 16-bit variant of the MIPS instruction set, and not capable of being arbitrarily intermixed with ordinary MIPS instructions.
There's nothing wrong with the ARM instruction set.
There's nothing wrong with the MIPS instruction set. However, like most "classic" RISC instruction sets, it has poor code density. This doesn't matter much in the workstation market, but in the embedded market it can be very important sometimes.
Competition is good thing, but it seems to me like ARM is a better instruction set for the market.
IMO Blizzard has always done a good job differentiating the races. (emphasis added)
Anyone who says this obviously never played WarCraft 1, where the race differentiation was basically non-existant and there was only 1 viable strategy for multiplayer: train mages/warlocks, summon water elementals / daemons, repeat.
WarCraft IIs unit differentiations were pretty bad also (Knight vs. Ogre, Archer vs. Spearthrower, Gryphon vs. Dragon, they're all pretty much the same).
It wasn't until StarCraft that they finally started actually making decent racial differentiation.
Under win2k, the only ways I can reliably crash the system involve DOS boxes. And even that is difficult with service pack 2.
But win95/98 was a bitch for debugging. Every win95/98 box I've tried crashes about 1/3rd of the time I suspend a program for debugging with MSVC. Maybe this is because I'm primarily debugging DirectX programs, I dunno, but that's the main reason I switched to win2k.
Compilers were available for Itaniums long before Itaniums were available. What the poster was refering to was the lack of decent optimizing compilers for Itanium ; there are none, because the Itaniums instruction set is REALLY hard to write optimizing compilers for.
You're not going to be getting an Itanium based system for $2000 anytime soon.
First of all, Intel has said ever since the Itaniums much-delayed release that it couldn't really compete and is primarily released to get some infrastructure ready for when the McKinley is ready (IIRC, it's scheduled for about 3 months from now...).
Secondly, the die size for the McKinley is HUGE. On todays top-of-the-line.13 micron process, the manufacturing costs are likely to be too high for this chip to make it into high-end workstations, let alone $2000 consumer computers.
Thirdly, the competition isn't dead yet. Sparc and PA-RISC may be dead, but Sun offers competition, and IBMs Power4 will be a decent competitor. Alpha does indeed look to have disappeared, but I thought I heard something about some Japanese company buying rights to some Alpha stuff, and planning on a big die shrink and integrating a large cache (which is all the Alpha really needs to compete, for the near future).
Fourth of all, the performance of even the McKinley is questionable. Compilers for it's IA64 instruction set are still quite poor, with little sign of the anticipated improvements. It's predecessors, the Merced/Itanium, was dog-slow at most tasks (though good at floating-point). The most recent benchmarks show the McKinleys 32-bit performance as terrible, though it's floating-point performance is supposed to be stellar, and its integer performance decent (when combined with an enormous on-die L3 cache...).
Anyway. Intel just likes the Itanium because the the instruction set is sufficiently complex that the prohibitive cost of designing a compatible would raise the cost of entry to the market enough to give them a more secure monopoly for the next decade.
Currently, when you use a GPS, the longer you stand still the more accurate it gets. This is because it can average out the errors that occur over time. However, once you start moving, it can't do that, because it has a hard time telling movements from measurement errors.
If on the other hand, they included an accelerometer in the GPS unit they could tell with great precision which changes were due to movements, and which were due to errors. Thus, with some algorithm changes, such a GPS unit could continue to refine its measurements to greater and greater precision as long as it was turned on, even if it was moving about.
Ideally, the accelerometer would be integrated on to the same chip as the GPS or Galeon reciever, along with the logic for coorelating the results as well. Accelerometers can be built entirely on-chip, so no extra parts would be needed. I believe modern accelerometers can achieve high accuracy over a very wide range of accelerations using just 2 square millimeters of chip area, so this shouldn't add much to the manufacturing cost.
This would also increase safety in a number of ways. If an airplane in flight lost GPS signal, perhaps due to flying into a low narrow valley, it could continue to navigate electronically for a while (albiert with less precision) using only the accelerometer. If for some reason the GPS or Galeon network became suddenly unavailable due to unforseen circumstances (US goverment getting pissed off, technical issues, bizarre weather, interference, terrorists, etc.), critical systems would have a little extra time to deal with the situation before global positioning equipment failed completely.
Does this make sense to people? Think it's a good idea / bad idea?
It's not a rumor anymore, since Intel put out a press release about it a while ago. I think the press release said that it was going to show up in the server (Xeon) chips in 2002, and in the desktops in 2003.
My presumption is that Intel provided some kind of documentation to Linux kernel developers about how to be compatible with HyperThreading, but I don't really know.
The MJ5200 from Sun? I think it was supposed to be released about 4 months ago but got delayed... It supposedly some some simliar stuff, w/ 4 registers sets per core, and switching which thread is active anytime a stall occurs. (and not counting that it's also doing CMP, with 2 cores per die)
Also, I think IBM has some significant research project on the subject, and a few of the smaller-name designers of embedded processors are seriously contemplating that stuff.
1. Each core in the Power4 is very superscalar, possibly more-so than any processor shipping today.
2. I don't think that such a test (superscalar vs. SMP) would be usefull, as the results would be very, very, VERY heavily influenced by the multi-threadedness (or lack thereof) of the benchmarks, and any two processors available will have enough other differences in architecture to invalidate the tests.
3. Both cores have small (16 or 32 k, I think) L1 caches, but share a large (1.5M or 2M) L2 cache. Furthermore, several chips share L2s via a ring-arrangement of uni-directional 128-bit 500 Mhrz buses, moving things around such that all cached data exists in the L2 of the chip that most recently accessed it, and in no other L2.
Current chips are superscalar, meaning that they have multiple execution units, but all execution units are working on instructions from the same instruction stream (thread). Complicated hardware analyzes dependancies and tries to translate that single thread into a parrallel mesh of instructions that can be executed simultaneously, but doing that is very difficult, and sometimes impossible.
This would be different because two threads would be executing simultaneously, so as long as the OS could find two threads that need cpu-time, the hardware would gain a lot of parallelism without having to do more scheduling.
This approach is good because it offers a way to use the excess die space without requiring too much extra effort from the designers. In the last decade or two the # of transistors per chip has gone up several orders of magnitude, while the # of man-years per chip-designer has not come close to keeping pace. It's also nice because the other common approaches are obviously reaching the point of diminishing return.
What Compaq is doing is more interesting though... they are processing multiple threads simultaneously... on the same set of execution units! If one thread doesn't have enough parallelism... that's O.K.. The other 7 can pick up the slack!
The two processor cores is really cool, and something a lot of people have been hoping for for a long time, although not quite as cool as some of the stuff Compaq/Alpha is doing, but
This article doesn't mention the most interesting detail I heard about the Power4: They're supposed to come in small rings of about four chips connected by ultra-high frequency 128 bit uni-directional buses that allow multiple chips to share their L2 caches, with fairly intelligent coherency stuff handled in hardware.
The only bad stuff is that they're really targeting the highend server market, where I want most of that stuff for the low-end too. It's supposed to be 400 mm^2 on a.18 micron process w/ copper, so even after it moves to.13 micron it'll still be too expensive to mainstream use.
Other tidbits include: 1. It's dropping a few of the more complex instructions from it's instruction set and depending on the OS to emulate them, 2. To simplify instruction scheduling, they're keeping track of packets of instructions instead of individual instructions, and 3. The per chip L2 size is supposed to be 1.5 megabytes.
Slashdot Mirror
People don't read the EULA because it doesn't matter wht the EULA says. If the EULA says that you have to give your first-born child to them, you click yes and don't give them your first-born child. The EULA contains a large amount of shit, most of which is illegible, much of which is illegal, and all of which is usually unenforceable. The only purpose to it is to give the BSA etc. a shred of credibilty when they demand your first-born child.
I said "an extra 8 GPRs", meaning that it now has 16 (there were already 8 GPRs in traditional x86).
Um... you do realize that 64 bit IP addresses allow 18,446,744,073,709,551,616 IP addresses? And that each IP address could have many devices on it, since UDP & TCP both add another 16 bits to the source & destination size? That's enough for 500 IPs per person, for 10 billion people per planet for 10 planets per solar system, for 9000 solar systems per galaxy, for 10 galaxies. By the time we come close to running out of 64-bit IP addresses, we'll be more worried about running out of galaxies than some archiac network protocal.
The "reason" why they chose 128-bit IP addresses was so that 64-bit MAC addresses could be used as subnet addresses, slightly simplifying DHCP & the like. Well, they also wanted to have enough bits in the upper portion to make routing simpler. But in they process they double the amount of bandwidth used by small packets, like games.
IPv4 is already kinda bloated, but 128-bit IPs is moreso.
IPv6 addresses are 128 bits, not 64. God knows why.
And I guess theoretically it would speed it up, but I doubt that looking at IP addesses is a limiting factor on performance.
A little, but not much. It keeps most of the ugly instruction decode of tradition x86, but adds an extra 8 GPRs (accessed via an additional opcode prefix). It also does a few minor other things, like I think it adds IP relative addressing.
Basically, they did what they could to make it better while still using the same hardware to decode instructions. I'd have preferred it if they had a second, simpler decode unit to handle the new stuff so that the overcomplicated x86 decode could eventually be phased out, but it didn't make sense business-wise for them to do so.
Spriggan is among the worst anime I've ever seen. Not the worst, but in the bottom 20%. If you really liked both Ninja Scroll and Akira then maybe you'll think Spriggan is acceptable. Maybe.
A few anime that I'd actually recommend, and their genres, listed best to worst (but they're all good):
Dragon Half (comedy)
Ayashi no Ceres / Ceres! Celestial Legend (romance, action)
Trigun (action, comedy)
Noir (action, music, inconsistent plot, but very nice)
Rurouni Kenshin OAVs / Samurai X OAVs (bloody action & romance, with a historical theme)
note: The OAVs for Kenshin are VERY different from the TV series
Utena (weird... I've only seen the TV series)
Ghost in the Shell (a classic... themed, action)
Ah! My Goddess / Aa! Megami-sama (romance)
New Angel (porn)
Record of Lodoss War (D&D, like LOTR)
note: "/" is used for anime that have multiple names
"all males of legal age"
I believe that both genders are required to join the armed forces there.
Are there difficulties licensing ARMs instruction set? That would seem bizarre to me (why hasn't Intel patented IA32?), but I guess weirder things happen.
I realize that ARM is called a RISC instruction set, and has all the RISC goodness: load/store instructions, 3-operand arithmetic, simple decode, simple operations, and (almost) a flat register file. However, unlike "classic" RISC instruction sets, it has multiple instruction sizes, and therefore achieves noticably better code density.
My impression, I could be mistaken, was that MIPS16 was simply a 16-bit variant of the MIPS instruction set, and not capable of being arbitrarily intermixed with ordinary MIPS instructions.
There's nothing wrong with the ARM instruction set.
There's nothing wrong with the MIPS instruction set. However, like most "classic" RISC instruction sets, it has poor code density. This doesn't matter much in the workstation market, but in the embedded market it can be very important sometimes.
Competition is good thing, but it seems to me like ARM is a better instruction set for the market.
Star Control/
/ timewarp/
http://www.classicgaming.com/starcontrol
Star Control: TimeWarp (fan sequel)
http://www.classicgaming.com/starcontrol
Anyone who says this obviously never played WarCraft 1, where the race differentiation was basically non-existant and there was only 1 viable strategy for multiplayer: train mages/warlocks, summon water elementals / daemons, repeat.
WarCraft IIs unit differentiations were pretty bad also (Knight vs. Ogre, Archer vs. Spearthrower, Gryphon vs. Dragon, they're all pretty much the same).
It wasn't until StarCraft that they finally started actually making decent racial differentiation.
Under win2k, the only ways I can reliably crash the system involve DOS boxes. And even that is difficult with service pack 2.
But win95/98 was a bitch for debugging. Every win95/98 box I've tried crashes about 1/3rd of the time I suspend a program for debugging with MSVC. Maybe this is because I'm primarily debugging DirectX programs, I dunno, but that's the main reason I switched to win2k.
Compilers were available for Itaniums long before Itaniums were available. What the poster was refering to was the lack of decent optimizing compilers for Itanium ; there are none, because the Itaniums instruction set is REALLY hard to write optimizing compilers for.
You're not going to be getting an Itanium based system for $2000 anytime soon.
.13 micron process, the manufacturing costs are likely to be too high for this chip to make it into high-end workstations, let alone $2000 consumer computers.
First of all, Intel has said ever since the Itaniums much-delayed release that it couldn't really compete and is primarily released to get some infrastructure ready for when the McKinley is ready (IIRC, it's scheduled for about 3 months from now...).
Secondly, the die size for the McKinley is HUGE. On todays top-of-the-line
Thirdly, the competition isn't dead yet. Sparc and PA-RISC may be dead, but Sun offers competition, and IBMs Power4 will be a decent competitor. Alpha does indeed look to have disappeared, but I thought I heard something about some Japanese company buying rights to some Alpha stuff, and planning on a big die shrink and integrating a large cache (which is all the Alpha really needs to compete, for the near future).
Fourth of all, the performance of even the McKinley is questionable. Compilers for it's IA64 instruction set are still quite poor, with little sign of the anticipated improvements. It's predecessors, the Merced/Itanium, was dog-slow at most tasks (though good at floating-point). The most recent benchmarks show the McKinleys 32-bit performance as terrible, though it's floating-point performance is supposed to be stellar, and its integer performance decent (when combined with an enormous on-die L3 cache...).
Anyway. Intel just likes the Itanium because the the instruction set is sufficiently complex that the prohibitive cost of designing a compatible would raise the cost of entry to the market enough to give them a more secure monopoly for the next decade.
Okay, someone applied some patches to 2.4 and named the result after himself. This is front pages slashdot news, why?
Currently, when you use a GPS, the longer you stand still the more accurate it gets. This is because it can average out the errors that occur over time. However, once you start moving, it can't do that, because it has a hard time telling movements from measurement errors.
If on the other hand, they included an accelerometer in the GPS unit they could tell with great precision which changes were due to movements, and which were due to errors. Thus, with some algorithm changes, such a GPS unit could continue to refine its measurements to greater and greater precision as long as it was turned on, even if it was moving about.
Ideally, the accelerometer would be integrated on to the same chip as the GPS or Galeon reciever, along with the logic for coorelating the results as well. Accelerometers can be built entirely on-chip, so no extra parts would be needed. I believe modern accelerometers can achieve high accuracy over a very wide range of accelerations using just 2 square millimeters of chip area, so this shouldn't add much to the manufacturing cost.
This would also increase safety in a number of ways. If an airplane in flight lost GPS signal, perhaps due to flying into a low narrow valley, it could continue to navigate electronically for a while (albiert with less precision) using only the accelerometer. If for some reason the GPS or Galeon network became suddenly unavailable due to unforseen circumstances (US goverment getting pissed off, technical issues, bizarre weather, interference, terrorists, etc.), critical systems would have a little extra time to deal with the situation before global positioning equipment failed completely.
Does this make sense to people? Think it's a good idea / bad idea?
Neither, I think.
It's not a rumor anymore, since Intel put out a press release about it a while ago. I think the press release said that it was going to show up in the server (Xeon) chips in 2002, and in the desktops in 2003.
My presumption is that Intel provided some kind of documentation to Linux kernel developers about how to be compatible with HyperThreading, but I don't really know.
It seems to be /.ed already.
The MJ5200 from Sun? I think it was supposed to be released about 4 months ago but got delayed... It supposedly some some simliar stuff, w/ 4 registers sets per core, and switching which thread is active anytime a stall occurs. (and not counting that it's also doing CMP, with 2 cores per die) Also, I think IBM has some significant research project on the subject, and a few of the smaller-name designers of embedded processors are seriously contemplating that stuff.
True, but not really "The" reason.
2. I don't think that such a test (superscalar vs. SMP) would be usefull, as the results would be very, very, VERY heavily influenced by the multi-threadedness (or lack thereof) of the benchmarks, and any two processors available will have enough other differences in architecture to invalidate the tests.
3. Both cores have small (16 or 32 k, I think) L1 caches, but share a large (1.5M or 2M) L2 cache. Furthermore, several chips share L2s via a ring-arrangement of uni-directional 128-bit 500 Mhrz buses, moving things around such that all cached data exists in the L2 of the chip that most recently accessed it, and in no other L2.
This would be different because two threads would be executing simultaneously, so as long as the OS could find two threads that need cpu-time, the hardware would gain a lot of parallelism without having to do more scheduling.
This approach is good because it offers a way to use the excess die space without requiring too much extra effort from the designers. In the last decade or two the # of transistors per chip has gone up several orders of magnitude, while the # of man-years per chip-designer has not come close to keeping pace. It's also nice because the other common approaches are obviously reaching the point of diminishing return.
What Compaq is doing is more interesting though... they are processing multiple threads simultaneously... on the same set of execution units! If one thread doesn't have enough parallelism... that's O.K.. The other 7 can pick up the slack!
This article doesn't mention the most interesting detail I heard about the Power4: They're supposed to come in small rings of about four chips connected by ultra-high frequency 128 bit uni-directional buses that allow multiple chips to share their L2 caches, with fairly intelligent coherency stuff handled in hardware.
The only bad stuff is that they're really targeting the highend server market, where I want most of that stuff for the low-end too. It's supposed to be 400 mm^2 on a .18 micron process w/ copper, so even after it moves to .13 micron it'll still be too expensive to mainstream use.
Other tidbits include: 1. It's dropping a few of the more complex instructions from it's instruction set and depending on the OS to emulate them, 2. To simplify instruction scheduling, they're keeping track of packets of instructions instead of individual instructions, and 3. The per chip L2 size is supposed to be 1.5 megabytes.