These things are FAR from being nanotechnology. Cells are on the order of 1 micron...
That would certainly depend on the type of cell.
The largest cell I've seen when gazing at them through a microscope in Grade 12 biology was about 1000 microns (1 mm) across (vegetable cell of some kind).
The smallest that I've seen is a cell scraped from the inside of my own cheek with a toothpick. It was 50 microns across.
Bacteria are much smaller and are still single cells, but it's presumably animal cells that we'd mainly be dealing with.
At 650um by about 200 um, these robots are 13 cheek cells high by 4 cheek cells wide. The robots could maipulate them as easily as you could manipulate a can of food.
What on earth could you be basing your statements on? What tangible piece of evidence would lead you to this conclusion?
Um, the _article_? The one where Abrash, a well-respected graphics programmer, describes X-box hardware in detail, giving a description that's actually pretty plausible? Describing a graphics chip that is the next logical incremental improvement over nVidia's current chips, and realistic system specs?
The Xbox the most unadulterated case of vaporware I have ever witnessed and is all pie in the sky speculation.
If Microsoft already has a contract with nVidia, it's a bit beyond the "vapour" stage. It may be suddenly killed, but barring budget death should materialize in roughly the form described.
A Pentium III 733, 64Mb ram, Nvidia graphics chipset - sounds remarkably like the specs for a current PC (albiet with a smallish amount of ram), but not for a 'state of the art' console out towards the end of 2001. It's going to be 1 1/2 years before this thing is even out!
The X box looks like a GeForce III with a CPU and peripheral bus tacked on. In six months, it will be state of the art. In a year or so when it's released, it'll still get acceptable performance, and will be dirt cheap - and thus markettable in a console price range.
From what I can see, this looks like a good strategy. My only concern is that the article implied (didn't explicitly state) that the main graphics API would be Direct X.
Alternatively, you can do essentially the same thing, but rather than simply extending actions of the old instructions the new specifier could activate a whole new set of 64-bit instructions, preferably with a saner design.
There are two problems with this.
The first is instruction set bloat. This is generally agreed to be a Bad Thing, and also increases the area of the decoding circuitry by some marginal amount.
The second is shadowing of opcodes that other chips may use. If Intel decides to extend x86 yet again, and AMD has already allocated the used opcodes to their own 64-bit instructions, binary compatibility will be broken. This is much less likely snagging only one opcode.
In summary, I don't really see the point of adding new instructions when the 64-bit-tag system works just as well (no slower than 32-bit code).
] If atmospheric and obstruction effects cut ] off everything above, say, 30 GHz
It won't cut off everything above 30 Ghz. As a counter example consider X-rays.
Please click "User Info" above and read my previous posts for a more detailed description.
Short version: Microwaves in double-digit GHz and higher are blocked by rain and by walls. They won't reach your PDA unless you're sitting under the tower or are standing out on a balcony with perfect line of sight with good weather. This is not acceptable.
X-rays and higher energy photons don't interact with matter much at all, which is why they can pass through most materials with impunity. For a better example, look at visible light. It too is blocked by rain and walls.
Certainly for apps that do a lot of 64-bit arithmetic, though that's probably mostly scientific applications rather than the familiar desktop application. Beyond that I'm not sure, and would like to hear opinions too. Will it help with things like graphics, since you would be able to wade through the masses of data involved in various transformations faster?
Memory copies on the x86 are already 64-bit due to a sneaky hack - MMX loads/stores have been 64-bit for a while, and thus take one clock. Of course, you still have the MMX/FP switching overhead.
I don't really see much that could speed up existing code. The only 64-bit transfers that go on (MMX and FP loads) are already handled as 64-bit transfers.
If you're writing a 64-bit application, then yes, many things will be faster (due to you now being able to hold double-precision floats in one register if nothing else), but that involves at least a recompile and possibly additional tweaking.
*Sparc: Poor in performance, but software application support keeps these Sun processors alive. Even the not-yet-released UltraSparc 3 will have disappointing performance relative to modern processors *MIPS: Fading out.
Sun's market isn't on the desktop or even in low-end servers - it's at the very high end. Their processors and motherboard architectures are optimized to work in machines with hundreds to thousands of processors. While they pay a penalty for this on the low end, you can always be sure that a Sun box can scale well to truly insane processor counts.
I also like their sneaky register file trick that masks calling latency.
MIPS, OTOH, is one of the cleanest, sanest processor designs that I've seen. It's not an FP powerhouse, but it's still respectable. Its primary market is as a licensed core, because of its easily extendible architecture. The Playstation and Playstation 2 are both based on MIPS cores, which counts for quite a bit of volume.
SGI boxes are also mainly based on MIPS chips, and are still the reigning champions for heavy-duty rendering due to a very intelligent system bus design.
In summary, I think that the conclusions you quote are premature.
Any potential extention of the x86 ISA to 64-bits will take one of two forms, neither of which is neccesarily pleasant:
You overlook the third way - apply the same kind of extension as is used for 32-bit.
Early x86s were 16-bit chips. When the 80386 came along, a kludge was implemented to allow 32-bit - add 0x66 in front of any 16-bit instruction to make it work on 32-bit operands.
The obvious way to add support for 64-bit instructions without adding a new processing mode or bloating the instruction set is to find another unused byte code and declare it to be the 64-bit specifier.
Code looks very similar to 32-bit code, all old code still works, and you have very few headaches porting a compiler to the new platform.
The _best_ thing to do is abandon the architecture completely, but if that's not an option, this is probably the cleanest way of extending x86.
Excuse me for being clueless on this but how does a different instruction set make coding more pleasant? Unless you're speaking about assembly, I dont see how this could affect how pleasant coding is.
You are correct - instruction set doesn't make a difference to most programmers' code. A few places where it _does_ make a difference are:
Letting the compiler optimize better. Some features of an instruction set and chip architecture make it easy to optimize code to run quickly. Some features make it harder. With 4 general-purpose registers, and only two or three more that you might be able to use for storage in a pinch (3 of ds/es/fs/gs), you have to keep fetching operands from memory if you're dealing with many variables at once. Even with a cache, this is slow. It also makes things like loop unrolling much harder.
Optimizing graphics routines. The core of any optimized graphics driver will have hand-tuned assembly. This isn't just for software rasterizers - this is for geometry engines and the like also, which are still around in abundance.
Writing and maintaining operating system kernels. As these do much deep mucking about with the processor state, many pieces of these have to be written in assembly (take a look in/usr/src/linux/arch for examples). A bad instruction set design, or more importantly, a bad register set design will make things much, much harder here.
None of these will be issues for most programmers, but they still do come up, and all programmers working on code where speed is important will notice the effect on compiler optimizations.
A while back there was a/. story about Ultra Wideband radio technology. According to Time Domain's webpage, the FCC has recently (May 10, 2000) "adopted a proposal to consider permitting the operation of Ultra-wideband (UWB) technology." If the US government ever decides to stop strangling this technology, there wouldn't be nearly as much of a need to move into the higher gigahertz frequencies.
The problem is that, while UWB transmitters might be easier to build than conventional transmistters, they still _use_ the higher spectrum frequencies (data is just spread out over the time and frequency domains instead of just the time domain).
If atmospheric and obstruction effects cut off everything above, say, 30 GHz, and your wideband transmitter makes use of parts of the spectrum above the cutoff point, the received data will be garbled (what will actually happen is that the pulses will smear out and start interfering with each other).
UWB is an interesting technology, but the data rate limits imposed by bandwidth limits are independent of the encoding of the data (see my posts re. analog transmission for the caveat to this).
No, multi-bit operations aren't the same thing as analog at all. I don't think that they buy you anything, but that doesn't make them analog. Analog signals have fuzzy values between value transitions (that's more like an 8 than a 3, to take an example from my handwriting). Digital signals have precise definitions (e.g., a 1 is.5 V and a 0 is -.5 V). This allows digital signals to be reconsitiuted precisely.
We seem to be using the term "analog" differently.
I am assuming a discrete-time signal for all cases - i.e. a signal that is being sampled at regular intervals.
I am defining a "digital" signal to be a discrete-amplitude signal with two permissible amplitude values.
What I am calling an analog signal is any signal with more than two permissible amplitude values. My justification for calling it "analog" is that it is no longer directly processable by binary logic.
A true analog signal - one with a continuous range of permissible amplitude values - can't be meaningfully talked about for sampled data transmission because there will always be uncertainty in the sample measurement, both due to instrument noise and due to fundamental limits on measuring photon or electron counts.
] The only way to pack in more data is to use ] analog transmission, and the power required to ] get more bits grows exponentially with the ] number of bits per sample (gets impractical very ]quickly).
Huh? You need to use more granualarity, which means more sensitive receivers and more transmission power to achieve the same range, but what's this analogue crap
What do you mean by "granularity?"
If you mean having narrower frequency bands that are more finely spaced, then your assertation does not make sense. A frequency band that is Hz wide gives you at most samples per second of data. Pick up a book on signal processing for more information on why this is a fundamental law.
If you mean packing in more bits of data per sample - that is *done* by having more than two data levels per sample. By definition, this is analog. This is how your 56k modem works (carrier is at 14.4, and you get 4 bits per sample).
See my previous message for why power requirements grow exponentially under these conditions.
Put another way, 1 MHz of radio bandwith does not equal 1 million bits per second, at least not as far as my limited knowlege implies.
While this is true, there are strong practical limits to how many bits per sample you can have.
The problem is that to encode n bits in one sample, you need to have 2^n distinguishable analog levels in your sample. You also can't space these levels arbitrarily closely - noise from your electronics and fundamental limits to the certainty with which you can count the number of radio photons in your sample both limit your spacing. As spacing grows exponentially with the number of bits, you soon reach a limit for any given power level.
In principle, you can just increase the power to compensate, but the power required goes up exponentially once you hit your level spacing limit.
In practice, you typically have only a handful of bits per sample to keep the power requirements sane.
FM, AM, visible spectrum, and audible sound are mere blips in the size of the spectrum. You're talking about Ghz of space available, while these take up mere Khz.
Um, no.
The FM and AM spectra take up on the order of a few MHz, not kHz. Each station needs several kHz to sound decent, and there are many stations.
TV needs about 10 MHz per station to transmit video data, and there are many stations on your UHF dial.
Visible light runs from around 700 nm to 400 nm - a bandwidth of about 3.2e14 Hz (320 THz).
The question being asked is, "what is the total usable bandwidth within Earth's atmosphere for carrying digital data". Ignoring other things that use bandwidth, this ranges from 0 Hz up to the frequency range where rain and fog and walls block your broadcast data - somewhere in the double-digit GHz range.
This bandwidth has to be shared with all users within a tower's transmission radius. In a city, this will be a lot of users.
The nice thing is it's mostly packet data, meaning you can have many devices use the same frequency if you throw in some collision avoidance, same that's used for Ethernet.
Collision avoidance works by _reducing_ the data rate on each device when too many devices are trying to use a data pipe at once. It does NOT give you more total bandwidth - it just makes sure that any bandwidth available is allocated fairly and not wasted in an electronic shouting match.
For a bandwidth of "foo" GHz, you will have _roughly_ "foo" gigabits of _shared_ bandwidth between all users in range of one tower. The only way to pack in more data is to use analog transmission, and the power required to get more bits grows exponentially with the number of bits per sample (gets impractical very quickly).
While the upper frequency limit for radio transmission is pretty mushy, there are a few factors that give you diminishing returns as you move beyond single-digit gigahertz:
Walls. Penetration distance of radio waves through a non-conducting substance (like concrete) is proportional to the wavelength of the signal (very roughly). This means that ordinary radio has no problem going trough walls and floors, but that things like cell phone signals in the GHz range are more easily blocked if there are a couple of buildings between you and the tower. This problem will get much, much worse as frequency increases. Expect your 20 GHz wireless PDA to stop working indoors (unless you have a repeater).
Rain and smog. Radio of conventional wavelengths will pass through rain, smog, and clouds with little difficulty. Higher frequencies, however, have problems. Again, this is just a question of there being a lot of matter between the transmitter and the receiver. This means that as wireless transmission moves higher up the microwave scale, you'll either have to space the towers more closely or have signal cut out whenever it rains.
IMO, the practial limit is going to be in the 10-30 GHz range, with degradation setting in long before that. This is more than enough for rural areas. In cities, the best approach IMO is to provide wireless service on a per-building basis, with a short-range wireless hub inside the building connected to a fiber grid networking the city. The frequency is practical, and the hubs will serve few enough users that everyone will still be able to download all the video clips and pr0n they want.
If you want live news and TV like Video? Doing it over the Internet and by passing the Cable companies deterministic network is not an option at this time.
I don't see why not. For the news, at least, a 10-second delay for buffering (or even a couple of minutes delay, if you have the buffer capacity) is perfectly acceptable.
As the previous poster pointed out, buffering is only *not* a viable option when you need interactivity.
I don't know much about the ARM family of processors. How does a 233mhz ARM compare to, for example, a 233mhz Pentium II?
The ARM will burn far less power, will (probably) be comparable for integer operations, but will be much, much worse at floating-point (earlier versions didn't have a FPU; that might or might not still be the case).
ARM chips are targetted at embedded integer applications and things like PDAs that require low power and don't require strong floating-point performance.
Sure, I guess you'd know the difference between a DIMM slot made for cpu cache vs. main memory. I don't know anything about macintosh hardware, for all I know those dimms were there for caching accesses to main memory.
From the article:
Memory: Two 168 DIMM sites, support for up to 512Mb of SDRAM, 3.3V, unbuffered PC-100 DIMMs.
As distinct from:
Level 2 Cache: 1Mb of L2 "Backside Cache" per processor.
The board design would be far simpler with the DIMMs as dedicated memory instead of cache, the DIMMs are described as "memory", and the article makes no mention of direct access to system memory; the only reasonable conclusion is that the DIMMs are standalone memory, as the previous poster pointed out to you.
IANAHardware Engineer, but it seems to me that RAM is already designed to do one simple thing (okay, two things: peek and poke) and to do it absolutely as fast as possible. This technology inevitably will degrade RAM performance by a finite amount. Is their chip fast enough that this degredation will be negligible?
The saving grace for RAM compression is that DRAM is very slow by logic standards. As long as they're doing something simple like short-run run length compression, the compression/decompression could easily be fast enough to not be noticed compared to the DRAM latency.
I get the same sort of feeling about wearable computers. I dont think it will ever get beyond the point of being a novelty. Like beer hats at baseball games, or shower radios, it will appeal to few, and life will go on as it always has.
This was more or less my opinion too, until recently. However, Prof. Mann had raised a few genuinely useful points on the topic back when I was studying under him (working on video drivers for the WearComps):
Genuinely _useful_ videophones - showing you what the other person sees. Video phones were another interesting idea that nobody actually wants; there are few good reasons to stare at the face of the person you're talking to, and several good reasons not to (say they just got out of the shower...). However, being able to have my co-worker look at the computer I'm trying to fix while I'm asking for advice _would_ be useful. Plus, the whole voyeuristic thrill of posessing another person's viewpoint comes in. This just strikes me as a genuinely neat and often useful idea that's easy to implement with wearable computers.
Sometimes you don't want to be looking at a screen. Data overlay on your vision is, for the most part, another failed idea - but there are a few niche markets where it's useful. Another design project group working at the same time I was developed an oscilliscope attachment to a WearComp, that let you view and manipulate signal traces without taking your eyes off of the probe you were sticking into the circuit. This is a Very Useful Thing when you're just trying to sanity-check a signal and are trying to hold a probe to a millimetre-wide trace while under the influence of sleep deprivation and caffiene.
Another point, which Prof. Mann didn't bring up but that I think will be the main selling point of wearable display visors:
A 2048x1536 wearable display with a 3-foot-wide projected image is cheaper than a 3-foot-wide 2048x1536 LCD screen. Wearable computers don't currently have that kind of resolution, but when they do, notebooks will get a whole lot nicer. No power-hungry flat panel, and a better-looking display to boot.
In summary, I think that there are enough useful points to wearable computer technology that wearable computers will become ubiquitous in some form within the next few years.
But what about the cost of mining the ore? Surely it must take quite a bit of energy (most likely in the form of, once again, gasoline) to run the machines that mine the ore. And that transport it to the place where it is smelted. And that transport the resulting steel to the factory.
This does indeed take energy; however, the point to bear in mind is that smelting takes a *huge* amount of energy - comparable to the chemical binding energy of the ore (for obvious reasons).
One kg of ore has a chemical binding energy in the realm of 2 MJ (assuming 200 kJ per mol of oxygen molecules stripped).
By contrast, to haul that 1 kg of ore and 99 more kg of rock bearing it up a 1 km mine shaft takes about 1 MJ. And that's under pretty extreme conditions.
And then there are all of the plastics, and electronic equipment that go into cars. Not only is there a cost in terms of the chemicals and energies needed to produce this stuff, there's the cost of disposing of this stuff when the car is no longer needed.
Producing plastics is cheap - it's just fractional distillation and catalyzed reactions, neither of which take up much energy.
Similarly, disposal is cheap, as there isn't much hazardous waste in a car (just the battery, mainly).
Again, the important thing to bear in mind is how mind-bogglingly dense chemical energy storage is. That's why smelting is so substantial a chunk of the energy cost of building a car, and that's also why even the smelting cost is dwarfed by the gasoline consumed in driving the car.
Finally, the resulting car has to be shipped typically several thousand miles (at least) to the dealer. Surely there is quite a bit of fuel being used up in this process as well.
Not at all. Hauling a car in a transport cart is actually less energy-expensive than driving it the same distance (that's why transport carts are used). Over its lifetime, the car will have easily a hundred times that distance put on it - the dealer transport distance is insignificant by comparison.
From this vantage point it really looks to me like burning gas is actually more environmentally friendly than building the car which is going to burn it.
I'm afraid that I still disagree, for the reasons stated above. However, I do compliment you on a very well though-out argument (I don't see that very often).
I wonder which does more damage to the environment - burning up more gas in an old car, or building a new one.
That's simple enough to estimate.
Most of the effort (not cost) that goes into making a car goes into smelting the metals used in its construction. Even very complex manufacturing processes take much less energy, and hence cause much less pollution.
The amount of energy needed to smelt the metals in a car is an inefficiency factor times the weight of the oxides you'd get by burning that metal. Lumping all of this together, it Fermis to around a factor of 10.
Let's say you have a tonne of metal (overestimate), and about 33 kg of gasoline in the tank (1/3 of 100).
1000 * 10 / 33 = 300.
If, over the course of the lifetime of the car, you fill the gas tank 300 times or more, you've caused more pollution by burning gasoline than was caused by the fossil fuels burned to smelt metal and produce electricity to manufacture the car.
My computer is in my living room. My stereo is in my living room. For those who are still starving students, substitute "bedroom" for "livingroom" above.
Most of us who are geeky enough to use MP3s are geeky enough to either a) have our computer in the room in which we spend the most time - which probably also has our stereo, or b) have a spare computer kicking around which may already be in the stereo room.
I question whether a storage-less MP3-to-stereo device is aiming for a market that exists.
One of the books we studied was The Process Is The Punishment. One of its central tenets is, when you get down to it, the bureaucracy isn't accidental or undesired. It's part of the process of criminal law, meant to break down and assault those caught in its maw.
What you ascribe to deliberate malice here is more plausibly explained by selfishness and laziness.
There is no incentive for the government to make their bureaucracy more pleasant than necessary for people, so they don't. There are local management pressures to increase headcount and budget. So the departments become more bloated, as other posters have pointed out. The people working in the department have no desire to actually deal with the "customers", so they don't go out of their way to do anything that would encourage them to come back.
Nice, neat, and no oppressive conspiracy required.
Slashdot Mirror
These things are FAR from being nanotechnology. Cells are on the order of 1 micron...
That would certainly depend on the type of cell.
The largest cell I've seen when gazing at them through a microscope in Grade 12 biology was about 1000 microns (1 mm) across (vegetable cell of some kind).
The smallest that I've seen is a cell scraped from the inside of my own cheek with a toothpick. It was 50 microns across.
Bacteria are much smaller and are still single cells, but it's presumably animal cells that we'd mainly be dealing with.
At 650um by about 200 um, these robots are 13 cheek cells high by 4 cheek cells wide. The robots could maipulate them as easily as you could manipulate a can of food.
What on earth could you be basing your statements on? What tangible piece of evidence would lead you to this conclusion?
Um, the _article_? The one where Abrash, a well-respected graphics programmer, describes X-box hardware in detail, giving a description that's actually pretty plausible? Describing a graphics chip that is the next logical incremental improvement over nVidia's current chips, and realistic system specs?
The Xbox the most unadulterated case of vaporware I have ever witnessed and is all pie in the sky speculation.
If Microsoft already has a contract with nVidia, it's a bit beyond the "vapour" stage. It may be suddenly killed, but barring budget death should materialize in roughly the form described.
A Pentium III 733, 64Mb ram, Nvidia graphics chipset - sounds remarkably like the specs for a current PC (albiet with a smallish amount of ram), but not for a 'state of the art' console out towards the end of 2001. It's going to be 1 1/2 years before this thing is even out!
The X box looks like a GeForce III with a CPU and peripheral bus tacked on. In six months, it will be state of the art. In a year or so when it's released, it'll still get acceptable performance, and will be dirt cheap - and thus markettable in a console price range.
From what I can see, this looks like a good strategy. My only concern is that the article implied (didn't explicitly state) that the main graphics API would be Direct X.
MIPS is a notoriously unreliable measure, because different architectures do a different amount of work with a given number of instructions.
New metrics that would probably be useful:
These benchmarks are straightforward to compute, given an appropriate testing rig.
Alternatively, you can do essentially the same thing, but rather than simply extending actions of the old instructions the new specifier could activate a whole new set of 64-bit instructions, preferably with a saner design.
There are two problems with this.
The first is instruction set bloat. This is generally agreed to be a Bad Thing, and also increases the area of the decoding circuitry by some marginal amount.
The second is shadowing of opcodes that other chips may use. If Intel decides to extend x86 yet again, and AMD has already allocated the used opcodes to their own 64-bit instructions, binary compatibility will be broken. This is much less likely snagging only one opcode.
In summary, I don't really see the point of adding new instructions when the 64-bit-tag system works just as well (no slower than 32-bit code).
] If atmospheric and obstruction effects cut
] off everything above, say, 30 GHz
It won't cut off everything above 30 Ghz. As a counter example consider X-rays.
Please click "User Info" above and read my previous posts for a more detailed description.
Short version: Microwaves in double-digit GHz and higher are blocked by rain and by walls. They won't reach your PDA unless you're sitting under the tower or are standing out on a balcony with perfect line of sight with good weather. This is not acceptable.
X-rays and higher energy photons don't interact with matter much at all, which is why they can pass through most materials with impunity. For a better example, look at visible light. It too is blocked by rain and walls.
Certainly for apps that do a lot of 64-bit arithmetic, though that's probably mostly scientific applications rather than the familiar desktop application. Beyond that I'm not sure, and would like to hear opinions too. Will it help with things like graphics, since you would be able to wade through the masses of data involved in various transformations faster?
Memory copies on the x86 are already 64-bit due to a sneaky hack - MMX loads/stores have been 64-bit for a while, and thus take one clock. Of course, you still have the MMX/FP switching overhead.
I don't really see much that could speed up existing code. The only 64-bit transfers that go on (MMX and FP loads) are already handled as 64-bit transfers.
If you're writing a 64-bit application, then yes, many things will be faster (due to you now being able to hold double-precision floats in one register if nothing else), but that involves at least a recompile and possibly additional tweaking.
*Sparc: Poor in performance, but software application support keeps these Sun processors alive. Even the not-yet-released UltraSparc 3 will have disappointing performance relative to modern processors
*MIPS: Fading out.
Sun's market isn't on the desktop or even in low-end servers - it's at the very high end. Their processors and motherboard architectures are optimized to work in machines with hundreds to thousands of processors. While they pay a penalty for this on the low end, you can always be sure that a Sun box can scale well to truly insane processor counts.
I also like their sneaky register file trick that masks calling latency.
MIPS, OTOH, is one of the cleanest, sanest processor designs that I've seen. It's not an FP powerhouse, but it's still respectable. Its primary market is as a licensed core, because of its easily extendible architecture. The Playstation and Playstation 2 are both based on MIPS cores, which counts for quite a bit of volume.
SGI boxes are also mainly based on MIPS chips, and are still the reigning champions for heavy-duty rendering due to a very intelligent system bus design.
In summary, I think that the conclusions you quote are premature.
Any potential extention of the x86 ISA to 64-bits will take one of two forms, neither of which is neccesarily pleasant:
You overlook the third way - apply the same kind of extension as is used for 32-bit.
Early x86s were 16-bit chips. When the 80386 came along, a kludge was implemented to allow 32-bit - add 0x66 in front of any 16-bit instruction to make it work on 32-bit operands.
The obvious way to add support for 64-bit instructions without adding a new processing mode or bloating the instruction set is to find another unused byte code and declare it to be the 64-bit specifier.
Code looks very similar to 32-bit code, all old code still works, and you have very few headaches porting a compiler to the new platform.
The _best_ thing to do is abandon the architecture completely, but if that's not an option, this is probably the cleanest way of extending x86.
You are correct - instruction set doesn't make a difference to most programmers' code. A few places where it _does_ make a difference are:
Some features of an instruction set and chip architecture make it easy to optimize code to run quickly. Some features make it harder. With 4 general-purpose registers, and only two or three more that you might be able to use for storage in a pinch (3 of ds/es/fs/gs), you have to keep fetching operands from memory if you're dealing with many variables at once. Even with a cache, this is slow. It also makes things like loop unrolling much harder.
The core of any optimized graphics driver will have hand-tuned assembly. This isn't just for software rasterizers - this is for geometry engines and the like also, which are still around in abundance.
As these do much deep mucking about with the processor state, many pieces of these have to be written in assembly (take a look in
None of these will be issues for most programmers, but they still do come up, and all programmers working on code where speed is important will notice the effect on compiler optimizations.
A while back there was a /. story about Ultra Wideband radio technology. According to Time Domain's webpage, the FCC has recently (May 10, 2000) "adopted a proposal to consider permitting the operation of Ultra-wideband (UWB) technology." If the US government ever decides to stop strangling this technology, there wouldn't be nearly as much of a need to move into the higher gigahertz frequencies.
The problem is that, while UWB transmitters might be easier to build than conventional transmistters, they still _use_ the higher spectrum frequencies (data is just spread out over the time and frequency domains instead of just the time domain).
If atmospheric and obstruction effects cut off everything above, say, 30 GHz, and your wideband transmitter makes use of parts of the spectrum above the cutoff point, the received data will be garbled (what will actually happen is that the pulses will smear out and start interfering with each other).
UWB is an interesting technology, but the data rate limits imposed by bandwidth limits are independent of the encoding of the data (see my posts re. analog transmission for the caveat to this).
No, multi-bit operations aren't the same thing as analog at all. I don't think that they buy you anything, but that doesn't make them analog. Analog signals have fuzzy values between value transitions (that's more like an 8 than a 3, to take an example from my handwriting). Digital signals have precise definitions (e.g., a 1 is .5 V and a 0 is -.5 V). This allows digital signals to be reconsitiuted precisely.
We seem to be using the term "analog" differently.
I am assuming a discrete-time signal for all cases - i.e. a signal that is being sampled at regular intervals.
I am defining a "digital" signal to be a discrete-amplitude signal with two permissible amplitude values.
What I am calling an analog signal is any signal with more than two permissible amplitude values. My justification for calling it "analog" is that it is no longer directly processable by binary logic.
A true analog signal - one with a continuous range of permissible amplitude values - can't be meaningfully talked about for sampled data transmission because there will always be uncertainty in the sample measurement, both due to instrument noise and due to fundamental limits on measuring photon or electron counts.
] The only way to pack in more data is to use
] analog transmission, and the power required to
] get more bits grows exponentially with the
] number of bits per sample (gets impractical very ]quickly).
Huh? You need to use more granualarity, which means more sensitive receivers and more transmission power to achieve the same range, but what's this analogue crap
What do you mean by "granularity?"
If you mean having narrower frequency bands that are more finely spaced, then your assertation does not make sense. A frequency band that is Hz wide gives you at most samples per second of data. Pick up a book on signal processing for more information on why this is a fundamental law.
If you mean packing in more bits of data per sample - that is *done* by having more than two data levels per sample. By definition, this is analog. This is how your 56k modem works (carrier is at 14.4, and you get 4 bits per sample).
See my previous message for why power requirements grow exponentially under these conditions.
Put another way, 1 MHz of radio bandwith does not equal 1 million bits per second, at least not as far as my limited knowlege implies.
While this is true, there are strong practical limits to how many bits per sample you can have.
The problem is that to encode n bits in one sample, you need to have 2^n distinguishable analog levels in your sample. You also can't space these levels arbitrarily closely - noise from your electronics and fundamental limits to the certainty with which you can count the number of radio photons in your sample both limit your spacing. As spacing grows exponentially with the number of bits, you soon reach a limit for any given power level.
In principle, you can just increase the power to compensate, but the power required goes up exponentially once you hit your level spacing limit.
In practice, you typically have only a handful of bits per sample to keep the power requirements sane.
FM, AM, visible spectrum, and audible sound are mere blips in the size of the spectrum. You're talking about Ghz of space available, while these take up mere Khz.
Um, no.
The FM and AM spectra take up on the order of a few MHz, not kHz. Each station needs several kHz to sound decent, and there are many stations.
TV needs about 10 MHz per station to transmit video data, and there are many stations on your UHF dial.
Visible light runs from around 700 nm to 400 nm - a bandwidth of about 3.2e14 Hz (320 THz).
The question being asked is, "what is the total usable bandwidth within Earth's atmosphere for carrying digital data". Ignoring other things that use bandwidth, this ranges from 0 Hz up to the frequency range where rain and fog and walls block your broadcast data - somewhere in the double-digit GHz range.
This bandwidth has to be shared with all users within a tower's transmission radius. In a city, this will be a lot of users.
The nice thing is it's mostly packet data, meaning you can have many devices use the same frequency if you throw in some collision avoidance, same that's used for Ethernet.
Collision avoidance works by _reducing_ the data rate on each device when too many devices are trying to use a data pipe at once. It does NOT give you more total bandwidth - it just makes sure that any bandwidth available is allocated fairly and not wasted in an electronic shouting match.
For a bandwidth of "foo" GHz, you will have _roughly_ "foo" gigabits of _shared_ bandwidth between all users in range of one tower. The only way to pack in more data is to use analog transmission, and the power required to get more bits grows exponentially with the number of bits per sample (gets impractical very quickly).
Penetration distance of radio waves through a non-conducting substance (like concrete) is proportional to the wavelength of the signal (very roughly). This means that ordinary radio has no problem going trough walls and floors, but that things like cell phone signals in the GHz range are more easily blocked if there are a couple of buildings between you and the tower. This problem will get much, much worse as frequency increases. Expect your 20 GHz wireless PDA to stop working indoors (unless you have a repeater).
Radio of conventional wavelengths will pass through rain, smog, and clouds with little difficulty. Higher frequencies, however, have problems. Again, this is just a question of there being a lot of matter between the transmitter and the receiver. This means that as wireless transmission moves higher up the microwave scale, you'll either have to space the towers more closely or have signal cut out whenever it rains.
IMO, the practial limit is going to be in the 10-30 GHz range, with degradation setting in long before that. This is more than enough for rural areas. In cities, the best approach IMO is to provide wireless service on a per-building basis, with a short-range wireless hub inside the building connected to a fiber grid networking the city. The frequency is practical, and the hubs will serve few enough users that everyone will still be able to download all the video clips and pr0n they want.
If you want live news and TV like Video? Doing it over the Internet and by passing the Cable companies deterministic network is not an option at this time.
I don't see why not. For the news, at least, a 10-second delay for buffering (or even a couple of minutes delay, if you have the buffer capacity) is perfectly acceptable.
As the previous poster pointed out, buffering is only *not* a viable option when you need interactivity.
I don't know much about the ARM family of processors. How does a 233mhz ARM compare to, for example, a 233mhz Pentium II?
The ARM will burn far less power, will (probably) be comparable for integer operations, but will be much, much worse at floating-point (earlier versions didn't have a FPU; that might or might not still be the case).
ARM chips are targetted at embedded integer applications and things like PDAs that require low power and don't require strong floating-point performance.
Sure, I guess you'd know the difference between a DIMM slot made for cpu cache vs. main memory. I don't know anything about macintosh hardware, for all I know those dimms were there for caching accesses to main memory.
From the article:
Memory:
Two 168 DIMM sites, support for up to 512Mb of SDRAM, 3.3V, unbuffered PC-100 DIMMs.
As distinct from:
Level 2 Cache:
1Mb of L2 "Backside Cache" per processor.
The board design would be far simpler with the DIMMs as dedicated memory instead of cache, the DIMMs are described as "memory", and the article makes no mention of direct access to system memory; the only reasonable conclusion is that the DIMMs are standalone memory, as the previous poster pointed out to you.
IANAHardware Engineer, but it seems to me that RAM is already designed to do one simple thing (okay, two things: peek and poke) and to do it absolutely as fast as possible. This technology inevitably will degrade RAM performance by a finite amount. Is their chip fast enough that this degredation will be negligible?
The saving grace for RAM compression is that DRAM is very slow by logic standards. As long as they're doing something simple like short-run run length compression, the compression/decompression could easily be fast enough to not be noticed compared to the DRAM latency.
YMMV, though.
This was more or less my opinion too, until recently. However, Prof. Mann had raised a few genuinely useful points on the topic back when I was studying under him (working on video drivers for the WearComps):
Video phones were another interesting idea that nobody actually wants; there are few good reasons to stare at the face of the person you're talking to, and several good reasons not to (say they just got out of the shower...). However, being able to have my co-worker look at the computer I'm trying to fix while I'm asking for advice _would_ be useful. Plus, the whole voyeuristic thrill of posessing another person's viewpoint comes in. This just strikes me as a genuinely neat and often useful idea that's easy to implement with wearable computers.
Data overlay on your vision is, for the most part, another failed idea - but there are a few niche markets where it's useful. Another design project group working at the same time I was developed an oscilliscope attachment to a WearComp, that let you view and manipulate signal traces without taking your eyes off of the probe you were sticking into the circuit. This is a Very Useful Thing when you're just trying to sanity-check a signal and are trying to hold a probe to a millimetre-wide trace while under the influence of sleep deprivation and caffiene.
Another point, which Prof. Mann didn't bring up but that I think will be the main selling point of wearable display visors:
Wearable computers don't currently have that kind of resolution, but when they do, notebooks will get a whole lot nicer. No power-hungry flat panel, and a better-looking display to boot.
In summary, I think that there are enough useful points to wearable computer technology that wearable computers will become ubiquitous in some form within the next few years.
But what about the cost of mining the ore? Surely it must take quite a bit of energy (most likely in the form of, once again, gasoline) to run the machines that mine the ore. And that transport it to the place where it is smelted. And that transport the resulting steel to the factory.
This does indeed take energy; however, the point to bear in mind is that smelting takes a *huge* amount of energy - comparable to the chemical binding energy of the ore (for obvious reasons).
One kg of ore has a chemical binding energy in the realm of 2 MJ (assuming 200 kJ per mol of oxygen molecules stripped).
By contrast, to haul that 1 kg of ore and 99 more kg of rock bearing it up a 1 km mine shaft takes about 1 MJ. And that's under pretty extreme conditions.
And then there are all of the plastics, and electronic equipment that go into cars. Not only is there a cost in terms of the chemicals and energies needed to produce this stuff, there's the cost of disposing of this stuff when the car is no longer needed.
Producing plastics is cheap - it's just fractional distillation and catalyzed reactions, neither of which take up much energy.
Similarly, disposal is cheap, as there isn't much hazardous waste in a car (just the battery, mainly).
Again, the important thing to bear in mind is how mind-bogglingly dense chemical energy storage is. That's why smelting is so substantial a chunk of the energy cost of building a car, and that's also why even the smelting cost is dwarfed by the gasoline consumed in driving the car.
Finally, the resulting car has to be shipped typically several thousand miles (at least) to the dealer. Surely there is quite a bit of fuel being used up in this process as well.
Not at all. Hauling a car in a transport cart is actually less energy-expensive than driving it the same distance (that's why transport carts are used). Over its lifetime, the car will have easily a hundred times that distance put on it - the dealer transport distance is insignificant by comparison.
From this vantage point it really looks to me like burning gas is actually more environmentally friendly than building the car which is going to burn it.
I'm afraid that I still disagree, for the reasons stated above. However, I do compliment you on a very well though-out argument (I don't see that very often).
I wonder which does more damage to the environment - burning up more gas in an old car, or building a new one.
That's simple enough to estimate.
Most of the effort (not cost) that goes into making a car goes into smelting the metals used in its construction. Even very complex manufacturing processes take much less energy, and hence cause much less pollution.
The amount of energy needed to smelt the metals in a car is an inefficiency factor times the weight of the oxides you'd get by burning that metal. Lumping all of this together, it Fermis to around a factor of 10.
Let's say you have a tonne of metal (overestimate), and about 33 kg of gasoline in the tank (1/3 of 100).
1000 * 10 / 33 = 300.
If, over the course of the lifetime of the car, you fill the gas tank 300 times or more, you've caused more pollution by burning gasoline than was caused by the fossil fuels burned to smelt metal and produce electricity to manufacture the car.
...A 20-foot stereo patch cord.
My computer is in my living room. My stereo is in my living room. For those who are still starving students, substitute "bedroom" for "livingroom" above.
Most of us who are geeky enough to use MP3s are geeky enough to either a) have our computer in the room in which we spend the most time - which probably also has our stereo, or b) have a spare computer kicking around which may already be in the stereo room.
I question whether a storage-less MP3-to-stereo device is aiming for a market that exists.
One of the books we studied was The Process Is The Punishment. One of its central tenets is, when you get down to it, the bureaucracy isn't accidental or undesired. It's part of the process of criminal law, meant to break down and assault those caught in its maw.
What you ascribe to deliberate malice here is more plausibly explained by selfishness and laziness.
There is no incentive for the government to make their bureaucracy more pleasant than necessary for people, so they don't. There are local management pressures to increase headcount and budget. So the departments become more bloated, as other posters have pointed out. The people working in the department have no desire to actually deal with the "customers", so they don't go out of their way to do anything that would encourage them to come back.
Nice, neat, and no oppressive conspiracy required.