"So, to answer your question - you *may* be able to achieve instantaneous transmission of information, but you can never observe that information in a causal fashion less than the speed of light. Did that make sense?:)"
What if that information is a person? What happens then? Does the person get instantaneously transmitted to the other side or not? e.g. you transport the blackbox, even though you never look inside, the blackbox still gets to the other side.
Or is it impossible to set the state of the original particles reliably before the transfer?
Curious tho - why the poorer code density then(compared to say Alpha or x86)? Compilers not good enough? That's going to hurt performance.
If a bunch of instructions can be executed in any order, and can be variable length, then is it possible to compress them in a packet so they take up less space and bandwidth, and decompress them on-the-fly in the CPU?
Would probably be easier if they started with dense code, but is code compression possible?
For most speakers there's a big difference between being in front of it, and being behind it.
If your ear is right next to the ear piece, when the "ringtone" speaker blasts away it's not blasting your ear - it's blasting away from your ear. Maybe someone sitting next to you on the train may be annoyed, but since that person's ear is likely to be > 10 cm away it's a lot better than the 0.5 cm scenario.
Uh. In my experience most users don't read the dialogs anyway. No matter how simple you make the error dialog they won't read it. Some even deny ever seeing them! Until you point them out right in front of their face - then they go "Oh! [insert stupid remark here]"
Most people are specialists. I don't expect users to respond intelligently at all to problems beyond their domain of expertise (e.g. making coffee and collating). So please put the ugly error messages where Tech Support can easily get the the users to read them over the phone.
And make the ugly error messages distinct and concise enough to read over the phone without error.
"Hardware that knows when you're holding the phone is by no means impossible,"
Actually an alternative solution would be to have two speakers. One for ringing and one for the ear. The ringing one would be somewhere else - like tha back of the phone or something.
Of course that's still more expensive and takes more space than just one speaker.
It is not really safer to fly than to drive if you do the numbers on a per trip basis, IIRC it's safer to drive on a per trip basis. It is safer to fly if it's on a per distance basis. I can't remember about the stats if it's on a per time basis. And that's when the "pros" are flying.
Air cars are likely to be used for short trips.
We're more likely to see the air taxis, patrol cars and other nonpersonal vehicles decades before personal flying cars become feasible.
You'll have to have mechanisms to prevent Joe Average from flying anywhere except to refuelling stations if there's not enough fuel to go elsewhere, or to maintenance stations if maintenance is overdue. The override mechanism will probably have to alert the authorities - so if there's a valid excuse (emergency) you get forgiven.
Not sure if Joe Average is going to pay big money for such a vehicle.
"Instructions are bundled together on the assumption that the target machine is infinitely parallel."
Yeah, but bandwidth isn't infinite, and there's always latency. You also say there's no guarantee on the execution order in a bundle - do they have to keep padding some bundles with NOPs, or can bundles be variable length? So I don't see the problem going away- e.g. old code needing to be recompiled.
Still it's a matter of percentages - if most old code doesn't need to be recompiled for improved performance (e.g. opteron, P4) then that's great. But so far it seems that corollary of EPIC is recompilation is needed.
The Itanium seems to need super huge caches. So it's using large amounts of silicon anyway. Maybe that's coz of all the duds in the bundles? Itanium code appears to take up more space than Alpha and x86 code.
Planned obsolescence isn't always a sign of imperfect engineering. The RIAA seem to like that sort of stuff too - self-destructing copies.
Maybe there are too many modified humans around as well, so genetic assays don't work so well.
So whether you're a replicant or a human physiologically could be debateable. Whereas if you had to have most of your (false) memories implanted into you, you're probably a replicant...
Actually the Matrix bunch of movies can make sense if you see it as the machines (at least the Oracle) trying to evolve. Why should Morpheus be right that the machines keep humans around for an energy power source?
There's a theory that Neo gets his upgrades from the Oracle via the cookies she feeds him. And Neo may not be as human as other "normal" humans- one of the smiths took over and had a human body.
Smith merges with everyone (humans and machines), the Oracle merges with Smith (and isn't really eliminated), Smith+Oracle merges with Neo (who learns a few things), and then the Oracle's back (and hopefully new and improved:) ).
How do you ensure that most common failures are graceful?
If a flamingo makes a mistake a few get bruised. If a driver of a 500kg flying vehicle makes a mistake (or intentionally crashes it), it's not just bruises.
And how do you make sure enough people maintain them to a decent standard?
Flying buses/taxis operated and maintained by a few licensed companies is one thing. Flying cars haphazardly maintained by a hundred thousand different individuals is a totally different ball game.
Personal air cars? Looking at the general incompetence and diversity of people, I doubt it's a good idea.
Then the prob would be if Itanium 3 or Itanium n+1 comes out, all your binaries would be rather suboptimal if the Itaniums don't do the fancy rescheduling themselves (which is the whole point of EPIC).
Solution would be recompilation (whether dynamic/automatic or manual), or sticking to the same architecture all the time.
"I like Itanium. It's a pretty neat architecture which crushes most before it in FP intensive tasks. It is clear why it has done well in HPC. But HPC is nothing more than a niche."
Getting a processor with "great FP performance IF you have a smart compiler" is actually relatively easy.
Just have more FPUs. Look at the video card GPUs which do something similar.
It's whether it's worth the silicon for your purpose. The target market for x86 doesn't need FP performance _that_ much, so you don't get as many FP units - the silicon goes to something else.
I'm not a CPU engineer but it may be harder to make a unified cache design where if one of the cores is a dud they can still sell the whole chip as a single core chip.
Depends. There's this inconvenient thing called seek time.
How long does it take for the drive head to move to part holding the data you want? If it takes 150 ms (typical for optical drives) then you'll still be needing hard drives (which are 10x to 20x faster and still considered too slow).
Slashdot Mirror
"So, to answer your question - you *may* be able to achieve instantaneous transmission of information, but you can never observe that information in a causal fashion less than the speed of light. Did that make sense? :)"
What if that information is a person? What happens then? Does the person get instantaneously transmitted to the other side or not? e.g. you transport the blackbox, even though you never look inside, the blackbox still gets to the other side.
Or is it impossible to set the state of the original particles reliably before the transfer?
OK. Now I think I get it.
Curious tho - why the poorer code density then(compared to say Alpha or x86)? Compilers not good enough? That's going to hurt performance.
If a bunch of instructions can be executed in any order, and can be variable length, then is it possible to compress them in a packet so they take up less space and bandwidth, and decompress them on-the-fly in the CPU?
Would probably be easier if they started with dense code, but is code compression possible?
Actually it does.
For most speakers there's a big difference between being in front of it, and being behind it.
If your ear is right next to the ear piece, when the "ringtone" speaker blasts away it's not blasting your ear - it's blasting away from your ear. Maybe someone sitting next to you on the train may be annoyed, but since that person's ear is likely to be > 10 cm away it's a lot better than the 0.5 cm scenario.
Uh. In my experience most users don't read the dialogs anyway. No matter how simple you make the error dialog they won't read it. Some even deny ever seeing them! Until you point them out right in front of their face - then they go "Oh! [insert stupid remark here]"
Most people are specialists. I don't expect users to respond intelligently at all to problems beyond their domain of expertise (e.g. making coffee and collating). So please put the ugly error messages where Tech Support can easily get the the users to read them over the phone.
And make the ugly error messages distinct and concise enough to read over the phone without error.
Actually, if Verisign had kept up what they were doing and pointed all nonexistent domains to their servers, wouldn't it be easy to legally DDoS them?
.somecountrycode and pointed it at someone else.
I mean, they said they wanted ALL traffic to nonexistent domains right? So like we care if they can't handle all the traffic.
Imagine if one day someone took over
"Hardware that knows when you're holding the phone is by no means impossible,"
Actually an alternative solution would be to have two speakers. One for ringing and one for the ear. The ringing one would be somewhere else - like tha back of the phone or something.
Of course that's still more expensive and takes more space than just one speaker.
Couldn't you just switch the computer off? You're talking about PC speaker right?
Doh.
It is not really safer to fly than to drive if you do the numbers on a per trip basis, IIRC it's safer to drive on a per trip basis. It is safer to fly if it's on a per distance basis. I can't remember about the stats if it's on a per time basis. And that's when the "pros" are flying.
Air cars are likely to be used for short trips.
We're more likely to see the air taxis, patrol cars and other nonpersonal vehicles decades before personal flying cars become feasible.
You'll have to have mechanisms to prevent Joe Average from flying anywhere except to refuelling stations if there's not enough fuel to go elsewhere, or to maintenance stations if maintenance is overdue. The override mechanism will probably have to alert the authorities - so if there's a valid excuse (emergency) you get forgiven.
Not sure if Joe Average is going to pay big money for such a vehicle.
You forgot the rest of my post: Who maintains them and keeps them fueled?
If the flying car computers would also give me wads of cash for fuel, maintenance and misc expenses, I'll happily buy one (I may even buy two).
Let's see a computer successfully correct for no fuel or FUBAR scenarios due to zero/incompetent maintenance. And there's always sheer bad luck.
I'm sure you've seen those vehicles by the side of the road (and their owners/operators).
Now where are those "you insensitive" jokes about slashdotters not having sex?
How about Predator?
:).
More governors and politician wannabes in one movie than any other I've watched
"Instructions are bundled together on the assumption that the target machine is infinitely parallel."
Yeah, but bandwidth isn't infinite, and there's always latency. You also say there's no guarantee on the execution order in a bundle - do they have to keep padding some bundles with NOPs, or can bundles be variable length? So I don't see the problem going away- e.g. old code needing to be recompiled.
Still it's a matter of percentages - if most old code doesn't need to be recompiled for improved performance (e.g. opteron, P4) then that's great. But so far it seems that corollary of EPIC is recompilation is needed.
The Itanium seems to need super huge caches. So it's using large amounts of silicon anyway. Maybe that's coz of all the duds in the bundles? Itanium code appears to take up more space than Alpha and x86 code.
Planned obsolescence isn't always a sign of imperfect engineering. The RIAA seem to like that sort of stuff too - self-destructing copies.
Maybe there are too many modified humans around as well, so genetic assays don't work so well.
So whether you're a replicant or a human physiologically could be debateable. Whereas if you had to have most of your (false) memories implanted into you, you're probably a replicant...
Actually the Matrix bunch of movies can make sense if you see it as the machines (at least the Oracle) trying to evolve. Why should Morpheus be right that the machines keep humans around for an energy power source?
:) ).
There's a theory that Neo gets his upgrades from the Oracle via the cookies she feeds him. And Neo may not be as human as other "normal" humans- one of the smiths took over and had a human body.
Smith merges with everyone (humans and machines), the Oracle merges with Smith (and isn't really eliminated), Smith+Oracle merges with Neo (who learns a few things), and then the Oracle's back (and hopefully new and improved
And "maintain" them...
Some people have appear to have problems just keeping their vehicles fueled.
I bet personal flying cars won't be widespread within the next 30 years.
But flying taxis or buses (and other special vehicles - ambulances, patrol cars) could be a different matter.
It's not just air traffic control.
Who flies them? People can't flock properly.
How do you ensure that most common failures are graceful?
If a flamingo makes a mistake a few get bruised. If a driver of a 500kg flying vehicle makes a mistake (or intentionally crashes it), it's not just bruises.
And how do you make sure enough people maintain them to a decent standard?
Flying buses/taxis operated and maintained by a few licensed companies is one thing. Flying cars haphazardly maintained by a hundred thousand different individuals is a totally different ball game.
Personal air cars? Looking at the general incompetence and diversity of people, I doubt it's a good idea.
Then the prob would be if Itanium 3 or Itanium n+1 comes out, all your binaries would be rather suboptimal if the Itaniums don't do the fancy rescheduling themselves (which is the whole point of EPIC).
Solution would be recompilation (whether dynamic/automatic or manual), or sticking to the same architecture all the time.
"I like Itanium. It's a pretty neat architecture which crushes most before it in FP intensive tasks. It is clear why it has done well in HPC. But HPC is nothing more than a niche."
Getting a processor with "great FP performance IF you have a smart compiler" is actually relatively easy.
Just have more FPUs. Look at the video card GPUs which do something similar.
It's whether it's worth the silicon for your purpose. The target market for x86 doesn't need FP performance _that_ much, so you don't get as many FP units - the silicon goes to something else.
"The theory behind charging per cpu is that you pay for the value, or at least the work (valuable or not) that the software does"
I disagree. The theory behind charging per CPU is much closer to the "how much milk you can squeeze from the cow before you get kicked" theory.
I'm not a CPU engineer but it may be harder to make a unified cache design where if one of the cores is a dud they can still sell the whole chip as a single core chip.
By the way, I've got a special thermobridging system for your friend that will help his CPU run at 3GHz, only USD599.
If he's interested, let me know ASAP.
Yeah in excitement, they will soon be able to sue people for 1000x more.
Well if it's 1TB, write once isn't so bad for many types of usage.
How delicate is it?
Depends. There's this inconvenient thing called seek time.
How long does it take for the drive head to move to part holding the data you want? If it takes 150 ms (typical for optical drives) then you'll still be needing hard drives (which are 10x to 20x faster and still considered too slow).
Also, how many times can you write to the disk?
What if you hashed (include) the output of the first hash as well when doing the 2nd hash?