Performing ACL surgery on the wrong knee is not unavoidable. In fact, there are numerous new safeguards to deal with this problem, since doctors have done it so many times.
Fundamentally, for people to switch, it would have to run all of their old applications at a similar or better price, and at a similar or better speed. Nothing else would really give anybody much reason. I'm not buying a more expensive computer and keeping Windows just so I can't play Medieval: Total War.
I'm the kind of guy who likes a chip just for its ISA, so I like the MIPS and the Itanium. Neither is a popular chip in the big scheme of things, for various reasons. I like small, orthogonal architectures, but this doesn't really do anything for me. Sure, the PPC is better in so many ways, but if I'm going to make the leap, I might as well switch to Linux or AIX. (Mac isn't my cuppa tea)
Now, if we were asked what chipset we would prefer to run our computers on, regardless of OS and software available, things would be more interesting. I think that the MIPS R3000 was probably one of the best designs out there, in that it was both small and powerful. In fact, I'd like to see a multicore implementation in 65 nm process just to see how fast it could go.
They also, interestingly enough, made M1 carbines for the US war effort in WWII. I guess the new conventional wisdom should be that nobody ever got shot for buying IBM.
The thing that's driving us crazy is the fact that adding more qubits is what makes a quantum computer fundamentally faster. For all intents and purposes, you can view a normal computer as a multicore 1-qubit quantum computer. That is, I have a computer that can handle a 32-bit word, so it's acting like 32 1-qubit quantum computers in parallel.
A 5-qubit quantum computer isn't really that fast. It's about 32 times faster than a comparable 5-bit computer, assuming that both can perform a similar number of instructions per second. Right now, these people have created one register on a quantum microcontroller. This is hard damn work. However, if they can get up to 32 qubits, then their computer would be about four billion times faster than mine at a comparable speed, on an appropriate problem.
This sounds damn fast, and it is. However, as I noted, this is working on an appropriate problem. Reversing a string, a typical example task that doesn't paralellize well at all, takes just as long on a quantum computer as it does on a normal computer. To add insult to this, by the time someone actually creates a 32-qubit quantum computer, normal computers will likely have outstripped it in most tasks, leaving it mainly for niche tasks like factoring huge numbers.
This isn't to disillusion anybody. Often in certain fields, people have greater expectations from some technology than is really possible. While quantum computers may not be magic, they will still be very, very fast computers for tasks which work well with them.
When designing something new, it's natural to want to improve it. One of the things that matters is adding new features or an easier to use UI. Really, a couple of LEDs and a dial may be enough for most applications, but a small LCD allows you to make things much easier.
For instance, I worked with an IBM robotic arm which had error lights on the control panel to tell you what was wrong. Each light was next to a two letter abbreviation or acronym. Sometimes some student would ask me why the robot wasn't working, and there was a light on the control panel. It would have made life ten times easier if the panel actually said that the arm was out of bounds, and they should manually reposition it to be within the working boundaries and turn the drive motors back on, rather than me having to tell them to do that every time.
Over time, when people replace the older robots and such from their factory, they switch to newer ones which tend to have more features, each of which needs more processing power. It may take time, but eventually 8-bit uCs are going to dissapear.
Colleges and schools still use copiers. They're cheaper than overpriced document stations, and they can run off 30 copies of some master that you did on a smaller printer in your office. They also have the undeniable virtue that they've already been paid for. However, as schools replace their older copier machines with newer models, I don't doubt that the newer ones will have the ability to double as print servers and do all of those neat things you're talking about, and you won't be able to find an older one without all of the features, but most High Schools don't really need that much power at the moment, and will hold off.
The usual defense against an artillery barrage is called a trenching spade. Unless you have some mystical powers that make artillery shells bounce off you, there's not much you can do. Making some sort of anti-artillery interceptor would be extremely expensive, and you'd need at least ten million of them for good coverage, and you'd need it in secret, and in a short period of time. I don't see that happening.
On the other hand, you wouldn't win any brownie points for being a nice guy, but an extremely hard hitting preemptive strike could disable them, and this is the sort of situation that Tactical Nuclear weapons were made for. Otherwise, the old fashioned stuff can kill just as effectively as ever before.
Propaganda and food might also work. Dump a few million pounds of food and other such supplies on them, along with leaflets, radios, and the occasional case of cigarettes, and you might just see how high their morale really is. Hell, if you're really perverse, just dump cold, hard cash on them. Of course, they can't spend it there....
Implementing generics the 'Right Way' would have required making the JVM incompatible with any previous versions. Java lives on its ability for the programs written for it to always work, no matte the platform, and getting rid of that was not an option, period. If they did it the 'Right Way' then nobody would really want to switch to the new VM and compiler. Thus, they went with the 'Wrong Way'.
It would be nice if Sun decided to open their intellectual property up, but right now they are in dire straits. Asking them to throw away all of their software sales in exchange for entering a different market is asking them to really risk their livlihoods and their business on something that may not pan out. Every time the open source community tells Sun to make the leap, I wonder if they've thought about the consequences and are willing to support Sun, or if they just want to cannibalize Solaris and Java, and just let the company falter.
Sounds like the cache. If a processor has no cache, then for most of the time, it's going to go about as fast as the memory bus in the vast majority of programs. That's the main reason I wouldn't go with a bargain CPU, no cache. However, to keep things on track, the Itanium does come with up to a 3 MB on chip L3 cache.
I think that it's inevitable. Every time you make a game, there's always a push to put in more content. One thing that I've seen that can work is to use a terrain generator for some game to make some large game world, and then save it for later use. This can be much quicker than doing it on the fly, and it's about the only way that you'd make a Paris-Dakar Rally game. When GTA4 comes out, you can be sure that it will use the size of the disc to some extent. Each iteration since GTA3 has doubled the game world, and this would allow another doubling, easy. I would have also liked it if Metal Gear Solid 2 were a bit longer, which a larger medium would allow.
Also, there's voice acting, which, when done correctly, makes a good game great. This takes up huge amounts of space if you want an entire game to be like that. In a related vein, music can be made more varied while still sounding just as good, or you can grab music that fits the game. More radio statons in a GTA game wouldn't hurt.
Finally, game code is getting longer and longer, and supporting files are also becoming bigger. I mean, the textures on the PS1 are enough to make baby Jesus cry, and the one advantage FF7 had over 8 and 9 was the fact that they just threw in the towel and used Gourand shading rather than trying to shove every texture you would need into (I think) 2 MB video memory.
Even though I mentioned this stuff, I don't really get as excited by it as I do by the ability to do stuff with more processing power. Game ecologies interest me in a way, as do game economies that really work. Imagine Ultima Online going into ecological ruin after the bunnies go extinct from too much hunting! OK, maybe not. However, it is gratifying to think that some day game programmers might not be stuck with some variety of C to write games just to get that last iota of performance out of the system. (I can dream.)
This would be fine except for the tiny little problem that your DIMM would have 64+ chips somehow put onto it. Since I usually see ones with about a fourth as much, I'd expect to see a 4 gig stick. Four of those, and you'd have your 16 GB storage. Not bad considering that most of the people here are probably 512 to 1024 MB right now.
We can't solve impossible-to-decrypt algorithms, but we could solve algorithms that are in common use today. The problem with trying to break them is not that we don't know how. It's just fourth-grade math. To break the code, you just need to factor a really, really big number with only two really big prime factors. This has some 'fast' solutions, and it has the BF&I solution.
Quantum computing, in this case, can provide the mother of all BF&I solutions. The idea is simple in practice. Try every damn number smaller than the number you're trying to factor with. Quantum computing changes that to try every damn number smaller than the number you're trying to factor, at once. If you're trying to factor a 128 bit number, you need at least a 128 qubit quantum computer. A quantum computer's power is measured in qubits, just like a regular computer is measured in bits. It takes just as many qubits as it does normal bits to encode some piece of data.
The problem with a 128 qubit quantum computer isn't possible as 128 1 qubit slices, as it is with regular digital computers. You have to be able to measure consistently 2^n different spin directions to be able to produce a n qubit quantum computer.
When people talk about this breaking strong encryption, its sort of like saying "Well, we've invented the horse-drawn carriage, now let's launch this bitch up to.995 c!" I'll believe it when L Ron Hubbard comes down from Heaven and starts the Rapture.
Don't underestimate the importance of a full pipeline. If you can avoid a bubble in the pipeline at any cost, odds are you would want to do so. That's one of the beauties of predication in a processor architecture. Although I'm sure that there's some way to make an instruction a whole frigging cache line long, that's more an exercise in perversity than a practical limitation if you don't unroll your loops too much. I could see a series of instructions being like that, though. If you're just adding an array of four numbers to another array of four numbers, then unrolling is the only sane choice. If it's two arrays of 100 numbers, then you should do some testing based on how big the instruction cache on your processor is. If it's a combined cache, then you might see a really substantial drop. As always, profile, profile, profile.
In any complex system, I'd doubt that even the gods could work on it. Some days to me, it seems that programming isn't a science, but a random walk. Some changes screw things up, and the program won't even run after they're implemented. Others make the whole program work quicker and more efficiently. What we do is get rid of the bad changes and add the good ones. Open source means in the long run that there will be more changes, but thankfully, if the people working on it care about the end product, then the program will get better quickly since the good changes will be kept and the bad ones culled.
No matter how good you think you are, and you may be one of the best, for all I know, compile time optimizations are often truly hairy, and sometimes the implementer doesn't even understand why they work. There's an old trick about how to add two 64-bit numbers in a computer with 32-bit registers in only four instructions. You can tell it to anyone, but the important thing is 'do they understand it?' If not then it's of little to no use in a properly written program. Otherwise, it's a neat little assembly trick taking advantage of the fact that a fairly complex algorithm for the carry bit can be broken down into one instruction.
Algorithms used to speed compiled code are much more complex than that one instruction. Changing them significantly without understanding them at all is stupid. You are lucky if it breaks cleanly. Otherwise, your fix may be around to haunt you for years to come.
I have my displays set to turn themselves off on sleep mode. It isn't perfect, since it still uses something like 3 watts, but it's better than a couple hundred by far. Another thing that helps is to search for computer equipment that's Energy Star compliant. It means that the equipment is guaranteed to use at most a certain amount of power when set to sleep mode. The bonus is that the computer starts back up in a matter of seconds. If that isn't fast enough for you, then you really need to take a break.
Well, Americans like fast cars, and we also like cars that are comforable to sit in for long distances. Driving from Dresden to Berlin may be cross-country in Germany, but the US is huge, and that isn't even across state lines in most of our states. My sister goes to college ten hours away. If you had to drive from Atlanta to Orlando, you'd prefer to do it in something other than a Smart. In order to get a 1500 kg car to go nice and zippy, you'd want a nice big engine. By the way, are you sure it's a 225 hp engine, and not a 225 kW engine? A 225 kW engine is about 300 hp, and that is a big engine just about anywhere you go.
I think that one group came up with some method using lava lamps to generate random numbers. They had some way to ensure an even distribution, but I don't know if it's practical.
It's inevitable that people are going to switch to Chinese in the long run, at least Unix sysadmins. Perl becomes so much more fun when you have tens of thousands of one-glyph variable names. Heck, there's probably some one-line-wonder OS written in Chinese, just waiting for us to find it.
Slashdot Mirror
Performing ACL surgery on the wrong knee is not unavoidable. In fact, there are numerous new safeguards to deal with this problem, since doctors have done it so many times.
Well, you must have misread. They use Windows CE. I shit you not.
I'm the kind of guy who likes a chip just for its ISA, so I like the MIPS and the Itanium. Neither is a popular chip in the big scheme of things, for various reasons. I like small, orthogonal architectures, but this doesn't really do anything for me. Sure, the PPC is better in so many ways, but if I'm going to make the leap, I might as well switch to Linux or AIX. (Mac isn't my cuppa tea)
Now, if we were asked what chipset we would prefer to run our computers on, regardless of OS and software available, things would be more interesting. I think that the MIPS R3000 was probably one of the best designs out there, in that it was both small and powerful. In fact, I'd like to see a multicore implementation in 65 nm process just to see how fast it could go.
Hey, us troubled loners need our coffee, too!
They also, interestingly enough, made M1 carbines for the US war effort in WWII. I guess the new conventional wisdom should be that nobody ever got shot for buying IBM.
Does this feature count as Karma-Whoring?
A 5-qubit quantum computer isn't really that fast. It's about 32 times faster than a comparable 5-bit computer, assuming that both can perform a similar number of instructions per second. Right now, these people have created one register on a quantum microcontroller. This is hard damn work. However, if they can get up to 32 qubits, then their computer would be about four billion times faster than mine at a comparable speed, on an appropriate problem.
This sounds damn fast, and it is. However, as I noted, this is working on an appropriate problem. Reversing a string, a typical example task that doesn't paralellize well at all, takes just as long on a quantum computer as it does on a normal computer. To add insult to this, by the time someone actually creates a 32-qubit quantum computer, normal computers will likely have outstripped it in most tasks, leaving it mainly for niche tasks like factoring huge numbers.
This isn't to disillusion anybody. Often in certain fields, people have greater expectations from some technology than is really possible. While quantum computers may not be magic, they will still be very, very fast computers for tasks which work well with them.
If every time some Slashdotter said "I can do this", it actually happened, then we would have solved the halting problem.
For instance, I worked with an IBM robotic arm which had error lights on the control panel to tell you what was wrong. Each light was next to a two letter abbreviation or acronym. Sometimes some student would ask me why the robot wasn't working, and there was a light on the control panel. It would have made life ten times easier if the panel actually said that the arm was out of bounds, and they should manually reposition it to be within the working boundaries and turn the drive motors back on, rather than me having to tell them to do that every time.
Over time, when people replace the older robots and such from their factory, they switch to newer ones which tend to have more features, each of which needs more processing power. It may take time, but eventually 8-bit uCs are going to dissapear.
Colleges and schools still use copiers. They're cheaper than overpriced document stations, and they can run off 30 copies of some master that you did on a smaller printer in your office. They also have the undeniable virtue that they've already been paid for. However, as schools replace their older copier machines with newer models, I don't doubt that the newer ones will have the ability to double as print servers and do all of those neat things you're talking about, and you won't be able to find an older one without all of the features, but most High Schools don't really need that much power at the moment, and will hold off.
On the other hand, you wouldn't win any brownie points for being a nice guy, but an extremely hard hitting preemptive strike could disable them, and this is the sort of situation that Tactical Nuclear weapons were made for. Otherwise, the old fashioned stuff can kill just as effectively as ever before.
Propaganda and food might also work. Dump a few million pounds of food and other such supplies on them, along with leaflets, radios, and the occasional case of cigarettes, and you might just see how high their morale really is. Hell, if you're really perverse, just dump cold, hard cash on them. Of course, they can't spend it there....
Implementing generics the 'Right Way' would have required making the JVM incompatible with any previous versions. Java lives on its ability for the programs written for it to always work, no matte the platform, and getting rid of that was not an option, period. If they did it the 'Right Way' then nobody would really want to switch to the new VM and compiler. Thus, they went with the 'Wrong Way'.
It would be nice if Sun decided to open their intellectual property up, but right now they are in dire straits. Asking them to throw away all of their software sales in exchange for entering a different market is asking them to really risk their livlihoods and their business on something that may not pan out. Every time the open source community tells Sun to make the leap, I wonder if they've thought about the consequences and are willing to support Sun, or if they just want to cannibalize Solaris and Java, and just let the company falter.
Sounds like the cache. If a processor has no cache, then for most of the time, it's going to go about as fast as the memory bus in the vast majority of programs. That's the main reason I wouldn't go with a bargain CPU, no cache. However, to keep things on track, the Itanium does come with up to a 3 MB on chip L3 cache.
Also, there's voice acting, which, when done correctly, makes a good game great. This takes up huge amounts of space if you want an entire game to be like that. In a related vein, music can be made more varied while still sounding just as good, or you can grab music that fits the game. More radio statons in a GTA game wouldn't hurt.
Finally, game code is getting longer and longer, and supporting files are also becoming bigger. I mean, the textures on the PS1 are enough to make baby Jesus cry, and the one advantage FF7 had over 8 and 9 was the fact that they just threw in the towel and used Gourand shading rather than trying to shove every texture you would need into (I think) 2 MB video memory.
Even though I mentioned this stuff, I don't really get as excited by it as I do by the ability to do stuff with more processing power. Game ecologies interest me in a way, as do game economies that really work. Imagine Ultima Online going into ecological ruin after the bunnies go extinct from too much hunting! OK, maybe not. However, it is gratifying to think that some day game programmers might not be stuck with some variety of C to write games just to get that last iota of performance out of the system. (I can dream.)
Xenosaga is in some way related to Xenogears, another Square game with impossibly long cutscenes, but was still a very good game.
This would be fine except for the tiny little problem that your DIMM would have 64+ chips somehow put onto it. Since I usually see ones with about a fourth as much, I'd expect to see a 4 gig stick. Four of those, and you'd have your 16 GB storage. Not bad considering that most of the people here are probably 512 to 1024 MB right now.
Quantum computing, in this case, can provide the mother of all BF&I solutions. The idea is simple in practice. Try every damn number smaller than the number you're trying to factor with. Quantum computing changes that to try every damn number smaller than the number you're trying to factor, at once. If you're trying to factor a 128 bit number, you need at least a 128 qubit quantum computer. A quantum computer's power is measured in qubits, just like a regular computer is measured in bits. It takes just as many qubits as it does normal bits to encode some piece of data.
The problem with a 128 qubit quantum computer isn't possible as 128 1 qubit slices, as it is with regular digital computers. You have to be able to measure consistently 2^n different spin directions to be able to produce a n qubit quantum computer.
When people talk about this breaking strong encryption, its sort of like saying "Well, we've invented the horse-drawn carriage, now let's launch this bitch up to .995 c!" I'll believe it when L Ron Hubbard comes down from Heaven and starts the Rapture.
Don't underestimate the importance of a full pipeline. If you can avoid a bubble in the pipeline at any cost, odds are you would want to do so. That's one of the beauties of predication in a processor architecture. Although I'm sure that there's some way to make an instruction a whole frigging cache line long, that's more an exercise in perversity than a practical limitation if you don't unroll your loops too much. I could see a series of instructions being like that, though. If you're just adding an array of four numbers to another array of four numbers, then unrolling is the only sane choice. If it's two arrays of 100 numbers, then you should do some testing based on how big the instruction cache on your processor is. If it's a combined cache, then you might see a really substantial drop. As always, profile, profile, profile.
No matter how good you think you are, and you may be one of the best, for all I know, compile time optimizations are often truly hairy, and sometimes the implementer doesn't even understand why they work. There's an old trick about how to add two 64-bit numbers in a computer with 32-bit registers in only four instructions. You can tell it to anyone, but the important thing is 'do they understand it?' If not then it's of little to no use in a properly written program. Otherwise, it's a neat little assembly trick taking advantage of the fact that a fairly complex algorithm for the carry bit can be broken down into one instruction.
Algorithms used to speed compiled code are much more complex than that one instruction. Changing them significantly without understanding them at all is stupid. You are lucky if it breaks cleanly. Otherwise, your fix may be around to haunt you for years to come.
I have my displays set to turn themselves off on sleep mode. It isn't perfect, since it still uses something like 3 watts, but it's better than a couple hundred by far. Another thing that helps is to search for computer equipment that's Energy Star compliant. It means that the equipment is guaranteed to use at most a certain amount of power when set to sleep mode. The bonus is that the computer starts back up in a matter of seconds. If that isn't fast enough for you, then you really need to take a break.
Electrocuting small children is arguably a worse use of electricity than producing heat through resistance.
Well, Americans like fast cars, and we also like cars that are comforable to sit in for long distances. Driving from Dresden to Berlin may be cross-country in Germany, but the US is huge, and that isn't even across state lines in most of our states. My sister goes to college ten hours away. If you had to drive from Atlanta to Orlando, you'd prefer to do it in something other than a Smart. In order to get a 1500 kg car to go nice and zippy, you'd want a nice big engine. By the way, are you sure it's a 225 hp engine, and not a 225 kW engine? A 225 kW engine is about 300 hp, and that is a big engine just about anywhere you go.
I think that one group came up with some method using lava lamps to generate random numbers. They had some way to ensure an even distribution, but I don't know if it's practical.
It's inevitable that people are going to switch to Chinese in the long run, at least Unix sysadmins. Perl becomes so much more fun when you have tens of thousands of one-glyph variable names. Heck, there's probably some one-line-wonder OS written in Chinese, just waiting for us to find it.