As well as the water they supposedly get "for free" my friend they also get an amount of flouride, chlorine, and arsenic in the same "free" water.
I'll bite.
By what twist of logic do you put fluoride and chlorine in the same category as arsenic?
If you brush and floss religiously, good for you. The rest of us are thankful for fluoride in the water.
If you have perfect faith in the measures taken by bottled water companies to decontaminate any water they bottle, good for you. The rest of us are thankful for the trace amounts of chlorine in tap water.
Arsenic in the water is a problem. Lead from pipes and solder in the water is a problem. Additives that are there for a _good_ _reason_ aren't.
IP law isn't as bad as you think, just imagine the safe and secure world we'd be living in today if this evil technology had remained a secret.
You do realize that if the patent had been granted, it would have disseminated the information more *widely*, due to the fact that patents are available for anyone to read?
You also realize that a cyclotron is about as useful for making nuclear weapons as pocket lint would be?
One question, though (as you're obviously well versed in these things) - if you're using plasma as your radiation shield, why bother making the surface optically flat?
A radiation shield wouldn't need to be flat. Light would be scattered randomly, not focused. However, it would need enough plasma to be opaque, which may prove difficult to hold around your station. The magnetic bottle configurations that I know of would also produce a donut-shaped ring of plasma, so building an all-around shield would get complicated.
This would also only affect light. Most of the worrisome radiation is in the form of charged particles. The magnetic containment field might deflect some of them, but a substantial fraction of cosmic rays are high enough energy not to be deflected by a practical magnetic shield. Either way, you only need the containment field for this - not the plasma.
There were proposals a while back for using strong electric or magnetic fields to repel cosmic rays. Interesting reading, but a good thick wall is probably more practical and would have fewer side effects (a one-tesla magnetic field inside the station would make life interesting).
For one, you need thick radiation-sheilds if you are not in near-Earth orbit, so I don't see large windows very safe. And, even in NEO, radiation is still a problem.
This problem is solved in most of the canonical torus designs - including the one the picture's of, I think - by having mirrors divert sunlight through a zig-zagging trough in a (non-spinning) rock shield around the station (station pictured is the inner tube, shield is the tire). From the inside, you see sky, but there's no straight-line path from the inside of the tube to space.
Look up the "Stanford Torus" for information on one of the earlier designs.
(Anybody know how thick glass has to be to shield enough radiation to match Earth ground-levels? Apollo had windows, but the astronaut's exposure was only about a week's worth, not a life-time.)
As another poster pointed out, you need ten tons of mass per square metre. This corresponds to a wall of water/ice about 10 metres thick, or a wall of glass or rock about 3-4 metres thick, or a wall of iron about 1.3 metres thick, or a wall of lead about 0.8 metres thick, if I remember lead's density correctly.
Were I building the station, I'd wrap the tube in fiberglass cables strung between aluminum rings every few tens or hundreds of metres on the tube, and spin the whole thing. These materials are more than strong enough to be the primary structural support for the station, and are easily available from the moon. Make the walls of the superstructure a few metres thick, and the radiation problem is solved.
And, it would probably be based on seal-able sections so that no one leak threatens the whole station. Thus, a clear "tunnel view" like that is not likely IMO.
It turns out that any meteorite small enough to not tear the station to bits would make a relatively small hole in the wall. Even a hole a metre or two wide (from an impact far larger than the maximum tolerable) would still need several minutes to drain the station of oxygen, especially given that the atmosphere would likely be at lower than sea level pressure (0.2-0.3 atm oxygen, and only as much nitrogen as the plants and bacteria need to survive).
That's why we need a new and cheaper space launch system.
Or to establish a moonbase, to get our materials for about 1/20th of the theoretical energy cost per kilogram, from an airless environment where devices like rail-cannons are practical. Send rock, aluminum, glass blocks or fiber, or anything you like up to the station to be used.
A station in the vicinity is the most logical first step, as it would provide a springboard for emergency rescue and would be a warehouse for supplies en route to the ground base. An emergency rescue or resupply mission from Earth would take far too long to reach a moonbase.
An earth-orbit-to-lunar-orbit-or-L1 shuttle could use slow but energy-efficient drives for cargo transport, eliminating much of the cost of supplying a moonbase, as well. A space station on either end is a winning proposition.
My take on the subject is that we don't have any materials heavy/stable enough to reflect high energy radiation.
The problem is that conventional materials of all types misbehave as photon energy substantially exceeds the chemical binding energies. You go from having materials acting like ideal classical conductors or dielectrics interacting with photons that act more or less like classical EM waves [normal reflection and transmission], to having materials that act like a set of quantum energy levels and photons that act like particles [photoelectric effect], to having materials that act like a diffuse sea of particles that scatter photons which also behave like particles [Compton scattering].
As the valence shell binding energies in atoms are at most on the order of a few tens of eV, there is a hard upper limit on the frequency of radiation that conventional optical elements made of normal matter can handle.
The limit's mushy in one respect, in that grazing-incidence devices see an effective frequency that's inversely proportional to the angle of incidence. However, practical devices limit the benefit of this to between a factor of 10 and a factor of 100 (so you can see some x-rays, but gamma rays are still tricky).
Non-conventional optics made of normal matter can still work under some conditions. Because the inter-atomic spacings in crystals are in the same ballpark as high-energy photon wavelengths, you can get diffraction occurring when an x- or gamma-ray beam passes through a crystal (due to scattering off of inner-shell electrons and the nuclei). This is commonly used to identify materials (x-ray diffraction patterns have been used to image atoms in everything up to and including crystals of viruses). Gamma ray telescopes using crystalline blocks to construct diffractive optics have been built.
Lastly, the final and most difficult way to cheat involves using plasma as a mirror. As it's a gas of free ions, it should have near-perfect reflection even at high wavelengths (subject to a few probably-nontrivial conditions). Keeping a cloud of ions confined to an optically flat surface is left as an exercise for the reader.
my dreams have been filled with visions of large processor cores with no fixed pipeline that can reconfigure themselves for different tasks, and have several operations in progress at once, taking several pathways through the core.
To some extent, this is done already.
Any superscalar processor will at least potentially have multiple operations being performed at once, in different pipelines as well as the same pipeline. The pipeline typically forks manyfold after the fetch/decode stages and recombines when results are ready to be committed and instructions retired. Under ideal conditions, most or all of the functional unit pathways in a processor could be busy at the same time (though code that does this is very rare - usually you're limited by data availability and by mismatch between the processor's facilities and the resources needed by the code).
As for self-reconfiguring processors, there is much work yet to be done. I've seen a handful of papers on partly reconfigurable processors; a few are on my prof's page. However, reconfigurable functional units suffer from the twin problems of being slower than a hard-wired functional unit at a specific task, and being extremely difficult to produce optimized code for (generally, the more ways you can use something to change the workings of a program, the harder it is to find an optimal use for it).
It's still an interesting idea with potential in several types of situation, though.
Asynchronous logic also doesn't affect the reconfigurability of a block of logic. Reconfigurability happens at a higher level of the design.
I suppose, for the immediate future, that asynchronous logic elements will simply augment current processor designs as you (and others) have outlined in this discussion. How long, then, until we reach a paradigm shift and start designing our processors in a fundamentally different way?
Pulling a number out of a hat, I get 10-15 years. Superscalar, highly-pipelined architectures have almost reached the limits of extendability without a major breakthrough in design, but there are still performance-enhancing tweaks to be made. CMP - multiple cores on one die - is the way of the future, but the number of cores involved will be small for the next few linewidth shrinks. Beyond a certain point, though, we're going to have to change from using conventional cores on a fast crossbar-type interconnect to something that more closely resembles the larger parallel machines of today. It is at that point that new opportunities for optimization and design changes will arise, which may (or may not) lead to significant changes in the way individual processor cores are designed (as the place of a core in the system will have changed).
It's also possible that there never will be a drastic paradigm shift. Modern superscalar processors represent a fairly mature solution that matches the nature of most computing problems fairly well. Only time will tell whether something radically better will come along.
In the meantime, asynchronous logic may very well replace synchronous logic for the low-level implementation of processor circuitry.
A good example of where async logic might be useful:
ALU multiply operation takes 20 pS, LOTS of transistors
ALU add/subtract op takes 5, FAR fewer transistors
In current designs, this usually means that add/subtract ops have to run at a clock rate that is slow enough to accomodate that 20 pS clock
In an async design, the add/subtract instructions can run 4 times as fast.
Actually, this turns out to be much less of a problem than you're painting it.
This is why pipelining exists. If your shortest functional unit time is 5 ps, then you build a chip that has (for the sake of argument) a 5 ps cycle time, and make a multiply take four pipeline stages.
In practice, register overhead reduces the benefit somewhat, but you'll still never have a discrepancy that large (at least if the functional units are your rate-limiting step; doing an add in 5 ps doesn't help if your dependency interlock logic needs 10 ps).
In this context, your notions of parallel computing will change greatly. Currently, individual nodes in a cluster are islands of computation, separated by (comparably) vast distances. Messages between nodes take orders of magnitude more time than messages within a node.
When you set out to build a supercomputing cluster in the asynchronous world, ideally the entire cluster would be within a single die.
This would be nice, but in order to fit a thousand-node cluster on one die, we'd need a thousand times our current transistor density.
And asynchronous computation isn't required to do this - look up "CMP" (Chip Multi-Processing) to see synchronous multi-core designs that have been studied (and built, in the Power4's case).
Asynchronous logic affects low-level circuit implementation. Often this has significant consequences, but the high-level structure of a computer system doesn't change.
So, which will come first: cheap fusion or reliable asynchronous logic?
My money's on reliable asynch logic. A hybrid synch/asynch design can gain many of the benefits of asynch while being almost as easily tested as synch, and can be built _now_. Much work is underway on verification tools for more complex asynch, and especially if we trade off speed for testability, the problem is tractable.
Most of all, though, the barrier to research is lower. Asynch design verification can be studied for the cost of employing a few graduate students, with the multi-billion-dollar fabs required already built. Fusion research usually involves building similarly expensive pieces of equipment from scratch.
I'm wondering how asynchronous logic stand up against transiant errors induced by a cosmic ray?
On a synchronous circuit most of the time such glitch won't do anything because it won't occur at the same time the clock "ring" so the incorrect transient value will be ignored.
Yes and no. The setup and hold times for registered logic is a significant fraction of the clock cycle, leaving much opportunity for data corruption from transient events. An upset within a register also stands a chance of flipping a bit value even while holding.
Synchronous chips already have error-correction measures built in to handle transient faults. Many other mechanisms have been studied over the years, ready for the day that chips are complex enough to need them. Most of these can be applied to asynchronous chips/logic as well.
As the "drawing size" of circuits gets lower and lower, every circuit must be hardened against radiations, not only circuits which must go on space or in planes.
Actually, smaller linewidth makes faults less likely (or so says my father, who did an extensive study of radiation effects). Smaller features mean less of a chance of a ray hitting any given gate. A design with a constant number of gates actually improves in reliability as it is shrunk.
If you scale linewidth but hold chip area constant, then you'll have the same number of radiation events per second, of course. But you have more transistors to allocate to error correction, and the probability of an event per clock cycle still goes down (as event rate stays constant but clock frequency increases).
It's an interesting problem, and not a new one (look up "alpha particles" in the Jargon File some time).
Brains use async logic elements. Maybe the only way to achieve good artificial intelligence with practical speeds is with async logic.
The way to achieve good artificial intelligence is to have a good understanding of how intelligence in general works, at all levels. I doubt the low-level implementation matters much at all.
Arguing about synch vs. asynch is like trying to decide whether to use vacuum tubes or relays to build a computer, while having no knowledge of combinational logic.
And IMO, arguing about neural nets versus other pattern-processing devices is like arguing about whether to use static CMOS or dynamic logic, while having no knowledge of the system-level design of processors.
We'll see what happens when our understanding of the nature of the human mind and of intelligence in general improves.
Within the space of a single clock cycle, the Pentium (or other designs) might make use of asynchronous logic, but (and this is the important bit) the asynchronicity only exists within the domain of the CPU. The external interface to the CPU is still governed by a clock: you supply the CPU with inputs, trigger its clock, and a short (fixed) while later it supplies you with outputs. Asynchronous logic removes the clock entirely.
Not strictly true - that's just asynchronous logic taken to its extreme.
A more practical approach, which I'm told has already been used here and there, is to build functional units that are asynchronous, while keeping the chip as a whole synchronous. Either the functional unit takes a varying number of cycles to produce its result, or the rest of the chip assumes that it will take the longest possible time, but the (multi-stage, multi-cycle) calculation is performed without the need for internal clocking.
Even an entirely asynchronous chip would have to have synchronous I/O if it was to be used in any conventional system. Redesigning all parts of a computer system from scratch would be a vast amount of work and result in a system that was far more expensive than necessary.
The feature of asynchronous logic that distinguishes it from a big block of arbitrary combinational logic is that asynchronous circuits have a way of indicating when computation has completed. This allows you to string them together in more complicated patterns without fear of race conditions, and means you don't have to always assume it will take the longest possible time to complete.
While asynchronous logic has yet to show a substantial speed benefit over well-designed synchronous logic, it tends to consume considerably less power, as you don't have to propagate clock signals to all parts of a functional unit. Clock gating only buys you so much.
The disadvantage is that it's often somewhat larger than the equivalent synchronous logic, and that verifying the correctness of an asynchronous design is a nightmare (a more difficult mathematical problem, and one with less background research at present). It's also hard to assess maximum power dissipation (you have to prove that no pathological one-in-a-trillion state transition that can cause vast amounts of current to be shunted can exist).
No, they do seem "easy" to build - what you saw is what I think is normally called a "cloud particle trail chamber" - I have seen plans for these type chambers in older SciAm issues (Amature Scientist column), as well as in old (ie, pre-1970) "science fair" experiment books aimed at kids. They aren't super difficult to build, I believe they involve using mainly oil droplets (rather than water).
The one I saw a few years back used alcohol vapour. It sat on a styrofoam carton of dry ice, so it wasn't exactly "high tech":).
A quick search found a page with home-building instructions. You get pretty trails from cosmic rays every few seconds.
Fun with anti-matter? It deffinatly would be interesting.....
I've wanted to do this for a long time. It turns out that an electron synchrotron capable of producing antiprotons could, *barely*, fit in a back yard...
You could make positrons fairly efficiently with a slightly-enhanced version of the cyclotron described in this article, or with a few-MeV electrostatic accelerator, but where's the challenge in that?:)
OTOH, given my budget or lack thereof, it'll probably be a while before I'm in a position to _build_ a synchrotron. Which is likely for the best, given the quantities of X and gamma rays produced by such a beast.
The quantity of energy you'd get would be less than the energy of a decaying isotope, which is not very much. Even with advances in technology, this can't be very much.
Actually, this turns out not to be the case.
Consulting Ye Rubber Bible, Nickel-63 liberates about 67 KeV per decay (quite low; decays are typically in the 1 MeV range). This gives an energy density of about 35 kW/hr per _gram_ over the lifetime of the battery. _Energy_ density is far higher than anything based on chemical reactions.
It's _power_ density that's low for most practical battery materials. With a half-life of 92 years, you get about 20 mW per gram released (actually a bit more than that at first; it _averages_ to this as it emits half its decay energy over the whole 92 years).
The nice thing about Nickel-63 is that the decay produces beta rays (high-energy electrons) and nothing else. This could be shielded by a thick sheet of plywood, or a thin sheet of lead. Most radioisotopes aren't nearly as friendly (there is usually gamma emission as the decay product sheds excess energy, which is difficult to shield against). [ObDisclaimer: I'm assuming that the lead also blocks the x-rays produced as the high-energy electrons smack into the shielding.]
The other nice thing is that the decay product is stable and is a solid (Copper), and so both inert and likely to stay in the battery. Carbon-14, the other "friendly" radioisotope that I can think of offhand, has a lower power density (though a higher energy density), and produces a gas as a byproduct (Nitrogen), which could eventually cause problems if allowd to build up near your MEMS devices.
Why should executable code be "pretty"? Nobody (except the rare reverse-engineer hacker) will ever look at it. Better to have it be correct and as efficient as possible (no matter how "ugly" that makes it).
I believe the original poster meant "pretty" in the sense of "efficient". Gcc's optimized code is.. sub-optimal. I've heard varying stories as to why (one says the compiler internals make certain types of optimization difficult, another says that all of the good optimization methods are patented).
However, for an assignment a few years back I had to tune C code by hand, flagging scratch variables and loop indices as "register" and doing unrolling, software pipelining, and memory checkerboarding by hand (writing C statements that mapped 1:1 with assembly).
The results of hand-tuning for a relatively simple operation beat the pants off GCC's version with optimization, on both x86 and Sparc. This surprised the heck out of me.
It's been a couple of years since I tried this. GCC may have improved. But it's dangerous to assume that any compiler is perfect or even near-perfect without testing.
4) What's the advantage again of a 64 bit processor? Sure, more RAM. Is it faster? Does it do more? Anyone?
Larger memory space, and fewer levels to the page table, which means faster RAM access even for smaller memory spaces.
4-16 gigs may seem like a lot now, but remember when 4 megs was a lavish amount and 16 unheard-of?
Re. calculations, some will speed up, but FP registers are already 64 bits (so FP math won't benefit from 64-bit integer registers), and 64-bit integer calculations are done relatively rarely (they're used for a few things commonly, but 32-bit math is much *more* common on a cycle-per-cycle basis).
The memory data path itself is already 64 bits or wider for all of the recent chips I've heard of, so there's no speedup there.
The 970 divides up the iop stream into "groups" of five iops a piece. So first it cracks the PPC instructions down into iops, then it collects the iops back together into groups. The iops are placed the group's five slots in program order with the stipulation that all branch instructions must go in slot 4 (the last slot). Furthermore, slot 4 can hold only branch instructions and nothing else.
This sounds like a trace processor (a processor that groups segments of instructions known to execute in sequence - i.e. containing at most one branch instruction at the end, and having no entry points from other branches [a fragment of a basic block]). Traces are rescheduled, cached in decoded form, etc. The P4 *does* use trace processing, contrary to the poster's original statement, if I understand correctly. Trace processors have been studied for quite a while, and there are many interesting papers about them.
As has been well-documented, Macs perform just as well as Windows machines. The slower clock speed of PowerPC compared to Intel is made up by the lack of code bloat is Mac OS compated to Windows.
A couple of points to throw water on this:
Not all x86 machines run Windows.
Windows "code bloat" mainly slows down the interface, as opposed to number crunching, which is where you'll be processor limited. It also eats memory for breakfast, but if you're doing anything computation-intensive you'd *better* be throwing memory at the machine no matter what.
Apple became allergic to producing useful benchmark comparisons some time ago. Find me SPECmarks on an actual Apple machine submitted within the past 3-4 years. All you find are photoshop benchmarks.
Apples are certainly wonderful machines, and Windows certainly is icky most of the time, but be prepared to back up any benchmark statements with actual benchmarks.
Also, PowerPC and Intel/AMD are two different types of processing, so they can't really even be compared.
Um, no.
All general-purpose microprocessors perform certain basic tasks upon which everything else is built - integer and FP math, memory access, and control flow operations. Processors take different approaches in how they implement these functions, but the interfaces presented to programmers - even assembly programmers - are very similar [and yes, I've done assembly on multiple platforms].
You can also completely ignore architecture and take test programs that you think are representative of the kinds of tasks found in different types of application, compile them for both platforms, and measure how long it takes to do the same amount of work on each machine. This is the _foundation_ of benchmarking.
If the machines were completely different, you wouldn't be able to do the same tasks on them!
One of the things that makes window managers slow , and ugly IMO is XFree86 behind it. Ever wonder why the latest KDE/Distro runs slow on a 400mhz PC ?
Well yes it;s KDE's fault.. but XFree86 using it's "network" everytime you start an app doesn't help either.
Load twm, or fvwm, or any other light window manager. Notice how zippy things are?
Xfree86 isn't the problem. Features in window managers aren't free.
Slashdot Mirror
As well as the water they supposedly get "for free" my friend they also get an amount of flouride, chlorine, and arsenic in the same "free" water.
I'll bite.
By what twist of logic do you put fluoride and chlorine in the same category as arsenic?
If you brush and floss religiously, good for you. The rest of us are thankful for fluoride in the water.
If you have perfect faith in the measures taken by bottled water companies to decontaminate any water they bottle, good for you. The rest of us are thankful for the trace amounts of chlorine in tap water.
Arsenic in the water is a problem. Lead from pipes and solder in the water is a problem. Additives that are there for a _good_ _reason_ aren't.
IP law isn't as bad as you think, just imagine the safe and secure world we'd be living in today if this evil technology had remained a secret.
You do realize that if the patent had been granted, it would have disseminated the information more *widely*, due to the fact that patents are available for anyone to read?
You also realize that a cyclotron is about as useful for making nuclear weapons as pocket lint would be?
I know, I know, IHBT...
One question, though (as you're obviously well versed in these things) - if you're using plasma as your radiation shield, why bother making the surface optically flat?
A radiation shield wouldn't need to be flat. Light would be scattered randomly, not focused. However, it would need enough plasma to be opaque, which may prove difficult to hold around your station. The magnetic bottle configurations that I know of would also produce a donut-shaped ring of plasma, so building an all-around shield would get complicated.
This would also only affect light. Most of the worrisome radiation is in the form of charged particles. The magnetic containment field might deflect some of them, but a substantial fraction of cosmic rays are high enough energy not to be deflected by a practical magnetic shield. Either way, you only need the containment field for this - not the plasma.
There were proposals a while back for using strong electric or magnetic fields to repel cosmic rays. Interesting reading, but a good thick wall is probably more practical and would have fewer side effects (a one-tesla magnetic field inside the station would make life interesting).
grazing-incidence devices see an effective wavelength that's inversely proportional to the angle of incidence
Frequency is _directly_ proportional to angle of incidence. Teaches me to post at 2am.
For one, you need thick radiation-sheilds if you are not in near-Earth orbit, so I don't see large windows very safe. And, even in NEO, radiation is still a problem.
This problem is solved in most of the canonical torus designs - including the one the picture's of, I think - by having mirrors divert sunlight through a zig-zagging trough in a (non-spinning) rock shield around the station (station pictured is the inner tube, shield is the tire). From the inside, you see sky, but there's no straight-line path from the inside of the tube to space.
Look up the "Stanford Torus" for information on one of the earlier designs.
(Anybody know how thick glass has to be to shield enough radiation to match Earth ground-levels? Apollo had windows, but the astronaut's exposure was only about a week's worth, not a life-time.)
As another poster pointed out, you need ten tons of mass per square metre. This corresponds to a wall of water/ice about 10 metres thick, or a wall of glass or rock about 3-4 metres thick, or a wall of iron about 1.3 metres thick, or a wall of lead about 0.8 metres thick, if I remember lead's density correctly.
Were I building the station, I'd wrap the tube in fiberglass cables strung between aluminum rings every few tens or hundreds of metres on the tube, and spin the whole thing. These materials are more than strong enough to be the primary structural support for the station, and are easily available from the moon. Make the walls of the superstructure a few metres thick, and the radiation problem is solved.
And, it would probably be based on seal-able sections so that no one leak threatens the whole station. Thus, a clear "tunnel view" like that is not likely IMO.
It turns out that any meteorite small enough to not tear the station to bits would make a relatively small hole in the wall. Even a hole a metre or two wide (from an impact far larger than the maximum tolerable) would still need several minutes to drain the station of oxygen, especially given that the atmosphere would likely be at lower than sea level pressure (0.2-0.3 atm oxygen, and only as much nitrogen as the plants and bacteria need to survive).
That's why we need a new and cheaper space launch system.
Or to establish a moonbase, to get our materials for about 1/20th of the theoretical energy cost per kilogram, from an airless environment where devices like rail-cannons are practical. Send rock, aluminum, glass blocks or fiber, or anything you like up to the station to be used.
A station in the vicinity is the most logical first step, as it would provide a springboard for emergency rescue and would be a warehouse for supplies en route to the ground base. An emergency rescue or resupply mission from Earth would take far too long to reach a moonbase.
An earth-orbit-to-lunar-orbit-or-L1 shuttle could use slow but energy-efficient drives for cargo transport, eliminating much of the cost of supplying a moonbase, as well. A space station on either end is a winning proposition.
My take on the subject is that we don't have any materials heavy/stable enough to reflect high energy radiation.
The problem is that conventional materials of all types misbehave as photon energy substantially exceeds the chemical binding energies. You go from having materials acting like ideal classical conductors or dielectrics interacting with photons that act more or less like classical EM waves [normal reflection and transmission], to having materials that act like a set of quantum energy levels and photons that act like particles [photoelectric effect], to having materials that act like a diffuse sea of particles that scatter photons which also behave like particles [Compton scattering].
As the valence shell binding energies in atoms are at most on the order of a few tens of eV, there is a hard upper limit on the frequency of radiation that conventional optical elements made of normal matter can handle.
The limit's mushy in one respect, in that grazing-incidence devices see an effective frequency that's inversely proportional to the angle of incidence. However, practical devices limit the benefit of this to between a factor of 10 and a factor of 100 (so you can see some x-rays, but gamma rays are still tricky).
Non-conventional optics made of normal matter can still work under some conditions. Because the inter-atomic spacings in crystals are in the same ballpark as high-energy photon wavelengths, you can get diffraction occurring when an x- or gamma-ray beam passes through a crystal (due to scattering off of inner-shell electrons and the nuclei). This is commonly used to identify materials (x-ray diffraction patterns have been used to image atoms in everything up to and including crystals of viruses). Gamma ray telescopes using crystalline blocks to construct diffractive optics have been built.
Lastly, the final and most difficult way to cheat involves using plasma as a mirror. As it's a gas of free ions, it should have near-perfect reflection even at high wavelengths (subject to a few probably-nontrivial conditions). Keeping a cloud of ions confined to an optically flat surface is left as an exercise for the reader.
my dreams have been filled with visions of large processor cores with no fixed pipeline that can reconfigure themselves for different tasks, and have several operations in progress at once, taking several pathways through the core.
To some extent, this is done already.
Any superscalar processor will at least potentially have multiple operations being performed at once, in different pipelines as well as the same pipeline. The pipeline typically forks manyfold after the fetch/decode stages and recombines when results are ready to be committed and instructions retired. Under ideal conditions, most or all of the functional unit pathways in a processor could be busy at the same time (though code that does this is very rare - usually you're limited by data availability and by mismatch between the processor's facilities and the resources needed by the code).
As for self-reconfiguring processors, there is much work yet to be done. I've seen a handful of papers on partly reconfigurable processors; a few are on my prof's page. However, reconfigurable functional units suffer from the twin problems of being slower than a hard-wired functional unit at a specific task, and being extremely difficult to produce optimized code for (generally, the more ways you can use something to change the workings of a program, the harder it is to find an optimal use for it).
It's still an interesting idea with potential in several types of situation, though.
Asynchronous logic also doesn't affect the reconfigurability of a block of logic. Reconfigurability happens at a higher level of the design.
I suppose, for the immediate future, that asynchronous logic elements will simply augment current processor designs as you (and others) have outlined in this discussion. How long, then, until we reach a paradigm shift and start designing our processors in a fundamentally different way?
Pulling a number out of a hat, I get 10-15 years. Superscalar, highly-pipelined architectures have almost reached the limits of extendability without a major breakthrough in design, but there are still performance-enhancing tweaks to be made. CMP - multiple cores on one die - is the way of the future, but the number of cores involved will be small for the next few linewidth shrinks. Beyond a certain point, though, we're going to have to change from using conventional cores on a fast crossbar-type interconnect to something that more closely resembles the larger parallel machines of today. It is at that point that new opportunities for optimization and design changes will arise, which may (or may not) lead to significant changes in the way individual processor cores are designed (as the place of a core in the system will have changed).
It's also possible that there never will be a drastic paradigm shift. Modern superscalar processors represent a fairly mature solution that matches the nature of most computing problems fairly well. Only time will tell whether something radically better will come along.
In the meantime, asynchronous logic may very well replace synchronous logic for the low-level implementation of processor circuitry.
A good example of where async logic might be useful:
ALU multiply operation takes 20 pS, LOTS of transistors
ALU add/subtract op takes 5, FAR fewer transistors
In current designs, this usually means that add/subtract ops have to run at a clock rate that is slow enough to accomodate that 20 pS clock
In an async design, the add/subtract instructions can run 4 times as fast.
Actually, this turns out to be much less of a problem than you're painting it.
This is why pipelining exists. If your shortest functional unit time is 5 ps, then you build a chip that has (for the sake of argument) a 5 ps cycle time, and make a multiply take four pipeline stages.
In practice, register overhead reduces the benefit somewhat, but you'll still never have a discrepancy that large (at least if the functional units are your rate-limiting step; doing an add in 5 ps doesn't help if your dependency interlock logic needs 10 ps).
In this context, your notions of parallel computing will change greatly. Currently, individual nodes in a cluster are islands of computation, separated by (comparably) vast distances. Messages between nodes take orders of magnitude more time than messages within a node.
When you set out to build a supercomputing cluster in the asynchronous world, ideally the entire cluster would be within a single die.
This would be nice, but in order to fit a thousand-node cluster on one die, we'd need a thousand times our current transistor density.
And asynchronous computation isn't required to do this - look up "CMP" (Chip Multi-Processing) to see synchronous multi-core designs that have been studied (and built, in the Power4's case).
Asynchronous logic affects low-level circuit implementation. Often this has significant consequences, but the high-level structure of a computer system doesn't change.
So, which will come first: cheap fusion or reliable asynchronous logic?
My money's on reliable asynch logic. A hybrid synch/asynch design can gain many of the benefits of asynch while being almost as easily tested as synch, and can be built _now_. Much work is underway on verification tools for more complex asynch, and especially if we trade off speed for testability, the problem is tractable.
Most of all, though, the barrier to research is lower. Asynch design verification can be studied for the cost of employing a few graduate students, with the multi-billion-dollar fabs required already built. Fusion research usually involves building similarly expensive pieces of equipment from scratch.
I'm wondering how asynchronous logic stand up against transiant errors induced by a cosmic ray?
On a synchronous circuit most of the time such glitch won't do anything because it won't occur at the same time the clock "ring" so the incorrect transient value will be ignored.
Yes and no. The setup and hold times for registered logic is a significant fraction of the clock cycle, leaving much opportunity for data corruption from transient events. An upset within a register also stands a chance of flipping a bit value even while holding.
Synchronous chips already have error-correction measures built in to handle transient faults. Many other mechanisms have been studied over the years, ready for the day that chips are complex enough to need them. Most of these can be applied to asynchronous chips/logic as well.
As the "drawing size" of circuits gets lower and lower, every circuit must be hardened against radiations, not only circuits which must go on space or in planes.
Actually, smaller linewidth makes faults less likely (or so says my father, who did an extensive study of radiation effects). Smaller features mean less of a chance of a ray hitting any given gate. A design with a constant number of gates actually improves in reliability as it is shrunk.
If you scale linewidth but hold chip area constant, then you'll have the same number of radiation events per second, of course. But you have more transistors to allocate to error correction, and the probability of an event per clock cycle still goes down (as event rate stays constant but clock frequency increases).
It's an interesting problem, and not a new one (look up "alpha particles" in the Jargon File some time).
Brains use async logic elements. Maybe the only way to achieve good artificial intelligence with practical speeds is with async logic.
The way to achieve good artificial intelligence is to have a good understanding of how intelligence in general works, at all levels. I doubt the low-level implementation matters much at all.
Arguing about synch vs. asynch is like trying to decide whether to use vacuum tubes or relays to build a computer, while having no knowledge of combinational logic.
And IMO, arguing about neural nets versus other pattern-processing devices is like arguing about whether to use static CMOS or dynamic logic, while having no knowledge of the system-level design of processors.
We'll see what happens when our understanding of the nature of the human mind and of intelligence in general improves.
Within the space of a single clock cycle, the Pentium (or other designs) might make use of asynchronous logic, but (and this is the important bit) the asynchronicity only exists within the domain of the CPU. The external interface to the CPU is still governed by a clock: you supply the CPU with inputs, trigger its clock, and a short (fixed) while later it supplies you with outputs. Asynchronous logic removes the clock entirely.
Not strictly true - that's just asynchronous logic taken to its extreme.
A more practical approach, which I'm told has already been used here and there, is to build functional units that are asynchronous, while keeping the chip as a whole synchronous. Either the functional unit takes a varying number of cycles to produce its result, or the rest of the chip assumes that it will take the longest possible time, but the (multi-stage, multi-cycle) calculation is performed without the need for internal clocking.
Even an entirely asynchronous chip would have to have synchronous I/O if it was to be used in any conventional system. Redesigning all parts of a computer system from scratch would be a vast amount of work and result in a system that was far more expensive than necessary.
The feature of asynchronous logic that distinguishes it from a big block of arbitrary combinational logic is that asynchronous circuits have a way of indicating when computation has completed. This allows you to string them together in more complicated patterns without fear of race conditions, and means you don't have to always assume it will take the longest possible time to complete.
While asynchronous logic has yet to show a substantial speed benefit over well-designed synchronous logic, it tends to consume considerably less power, as you don't have to propagate clock signals to all parts of a functional unit. Clock gating only buys you so much.
The disadvantage is that it's often somewhat larger than the equivalent synchronous logic, and that verifying the correctness of an asynchronous design is a nightmare (a more difficult mathematical problem, and one with less background research at present). It's also hard to assess maximum power dissipation (you have to prove that no pathological one-in-a-trillion state transition that can cause vast amounts of current to be shunted can exist).
No, they do seem "easy" to build - what you saw is what I think is normally called a "cloud particle trail chamber" - I have seen plans for these type chambers in older SciAm issues (Amature Scientist column), as well as in old (ie, pre-1970) "science fair" experiment books aimed at kids. They aren't super difficult to build, I believe they involve using mainly oil droplets (rather than water).
:).
The one I saw a few years back used alcohol vapour. It sat on a styrofoam carton of dry ice, so it wasn't exactly "high tech"
A quick search found a page with home-building instructions. You get pretty trails from cosmic rays every few seconds.
Fun with anti-matter? It deffinatly would be interesting.....
:)
I've wanted to do this for a long time. It turns out that an electron synchrotron capable of producing antiprotons could, *barely*, fit in a back yard...
You could make positrons fairly efficiently with a slightly-enhanced version of the cyclotron described in this article, or with a few-MeV electrostatic accelerator, but where's the challenge in that?
OTOH, given my budget or lack thereof, it'll probably be a while before I'm in a position to _build_ a synchrotron. Which is likely for the best, given the quantities of X and gamma rays produced by such a beast.
Now you will die before your battery does!
ObGhostbusters:
"Will the equipment still work?"
"It _should_. The power cells have a half-life of five thousand years..."
The quantity of energy you'd get would be less than the energy of a decaying isotope, which is not very much. Even with advances in technology, this can't be very much.
Actually, this turns out not to be the case.
Consulting Ye Rubber Bible, Nickel-63 liberates about 67 KeV per decay (quite low; decays are typically in the 1 MeV range). This gives an energy density of about 35 kW/hr per _gram_ over the lifetime of the battery. _Energy_ density is far higher than anything based on chemical reactions.
It's _power_ density that's low for most practical battery materials. With a half-life of 92 years, you get about 20 mW per gram released (actually a bit more than that at first; it _averages_ to this as it emits half its decay energy over the whole 92 years).
The nice thing about Nickel-63 is that the decay produces beta rays (high-energy electrons) and nothing else. This could be shielded by a thick sheet of plywood, or a thin sheet of lead. Most radioisotopes aren't nearly as friendly (there is usually gamma emission as the decay product sheds excess energy, which is difficult to shield against). [ObDisclaimer: I'm assuming that the lead also blocks the x-rays produced as the high-energy electrons smack into the shielding.]
The other nice thing is that the decay product is stable and is a solid (Copper), and so both inert and likely to stay in the battery. Carbon-14, the other "friendly" radioisotope that I can think of offhand, has a lower power density (though a higher energy density), and produces a gas as a byproduct (Nitrogen), which could eventually cause problems if allowd to build up near your MEMS devices.
Fewer levels to the page table? All the 64-bit archs I've seen have more page table levels.
Hmm.
Ok, that was a brainfault on my part. I assumed page sizes would scale in a way that's insane in retrospect. Sorry about that.
The article said that the reactor explains why the poles flip every 200k years, not why they exist.
There are turbulence models that explain this too, without a concentrated core of uranium and thorium needing to be postulated.
See my post in the previous article for a more detailed critique.
Why should executable code be "pretty"? Nobody (except the rare reverse-engineer hacker) will ever look at it. Better to have it be correct and as efficient as possible (no matter how "ugly" that makes it).
I believe the original poster meant "pretty" in the sense of "efficient". Gcc's optimized code is.. sub-optimal. I've heard varying stories as to why (one says the compiler internals make certain types of optimization difficult, another says that all of the good optimization methods are patented).
However, for an assignment a few years back I had to tune C code by hand, flagging scratch variables and loop indices as "register" and doing unrolling, software pipelining, and memory checkerboarding by hand (writing C statements that mapped 1:1 with assembly).
The results of hand-tuning for a relatively simple operation beat the pants off GCC's version with optimization, on both x86 and Sparc. This surprised the heck out of me.
It's been a couple of years since I tried this. GCC may have improved. But it's dangerous to assume that any compiler is perfect or even near-perfect without testing.
4) What's the advantage again of a 64 bit processor? Sure, more RAM. Is it faster? Does it do more? Anyone?
Larger memory space, and fewer levels to the page table, which means faster RAM access even for smaller memory spaces.
4-16 gigs may seem like a lot now, but remember when 4 megs was a lavish amount and 16 unheard-of?
Re. calculations, some will speed up, but FP registers are already 64 bits (so FP math won't benefit from 64-bit integer registers), and 64-bit integer calculations are done relatively rarely (they're used for a few things commonly, but 32-bit math is much *more* common on a cycle-per-cycle basis).
The memory data path itself is already 64 bits or wider for all of the recent chips I've heard of, so there's no speedup there.
The 970 divides up the iop stream into "groups" of five iops a piece. So first it cracks the PPC instructions down into iops, then it collects the iops back together into groups. The iops are placed the group's five slots in program order with the stipulation that all branch instructions must go in slot 4 (the last slot). Furthermore, slot 4 can hold only branch instructions and nothing else.
This sounds like a trace processor (a processor that groups segments of instructions known to execute in sequence - i.e. containing at most one branch instruction at the end, and having no entry points from other branches [a fragment of a basic block]). Traces are rescheduled, cached in decoded form, etc. The P4 *does* use trace processing, contrary to the poster's original statement, if I understand correctly. Trace processors have been studied for quite a while, and there are many interesting papers about them.
A couple of points to throw water on this:
Apples are certainly wonderful machines, and Windows certainly is icky most of the time, but be prepared to back up any benchmark statements with actual benchmarks.
Also, PowerPC and Intel/AMD are two different types of processing, so they can't really even be compared.
Um, no.
All general-purpose microprocessors perform certain basic tasks upon which everything else is built - integer and FP math, memory access, and control flow operations. Processors take different approaches in how they implement these functions, but the interfaces presented to programmers - even assembly programmers - are very similar [and yes, I've done assembly on multiple platforms].
You can also completely ignore architecture and take test programs that you think are representative of the kinds of tasks found in different types of application, compile them for both platforms, and measure how long it takes to do the same amount of work on each machine. This is the _foundation_ of benchmarking.
If the machines were completely different, you wouldn't be able to do the same tasks on them!
One of the things that makes window managers slow , and ugly IMO is XFree86 behind it. Ever wonder why the latest KDE/Distro runs slow on a 400mhz PC ?
Well yes it;s KDE's fault.. but XFree86 using it's "network" everytime you start an app doesn't help either.
Load twm, or fvwm, or any other light window manager. Notice how zippy things are?
Xfree86 isn't the problem. Features in window managers aren't free.