I wonder if they could scale this up to shoot payloads into orbit? With a relatively low trajectory they could concievably build a long enough barrel to prevent acceleration from damaging the cargo. Probably would flatten a human but maybe not hurt computer hardware, or fuel, or O2, H2O or other necessary supplies.
This or any of a number of other magnetic cannon techniques could work, or even a compressed gas gun (like the "Super Gun" from years ago).
The problems are twofold:
Your barrel has to be stupidly long, making your gun extremely expensive.
To reach orbit, you need an energy of about 30 MJ/kg (for a velocity of about 8 km/sec). Energy is force (mass times acceleration) times distance, so for a given acceleration, you can calculate the barrel length of the gun required. For a 3g accelerator for humans, you get a gun 1000 km long. If you can overcome the engineering problems and build a gun that accelerates cargo at *3000* gravities... you still have a gun 1 km long (about 0.62 miles, if you were wondering).
This can be built, but it's *expensive*. There would have to be a very strong incentive to build it, and amortizing the cost of the gun will raise your launch costs by quite a bit.
The atmosphere will cause big problems.
You'll notice that the experiment discussed in the article was done in vacuum.
Your gun will have to have an enclosed barrel (even if it's a magnetic gun). Otherwise, the mach-16 sonic boom will tear the firing coils off their mountings or otherwise harm the gun's structure.
Your gun (and anything near it!) is still going to have a lot of wear from the effects of a hypersonic projectile smacking into the atmosphere on leaving its muzzle.
Lastly, your projectile is going to have to have shielding around it to keep it from burning up while leaving the atmosphere. This will add weight to the projectile, and require a higher muzzle velocity (because the projectile will slow down).
All of these problems are manageable, but they increase the cost of the gun and the cost per kilogram of payload even more.
In summary, yes, we can scale up this and other guns like it; however, they're a royal pain to build and use, and there isn't enough demand at present to make them practical.
OTOH, this is one of the best ways known to get material off the moon. Required energy (and hence barrel length) is much lower, and there's no atmosphere to cause problems.
My own system is the following. It isn't perfect, but it's pretty robust:
Use a RAID 1 (drive mirroring) for day-to-day data storage.
Back things up on to CDROM.
Burn two (or more) copies of everything per CD (just copy the directory tree two or more times, so that the copies are widely separated physically).
Burn multiple copies of each backup CD, and store them in different locations (ideally different buildings).
I'm blithely pretending that CDs will last forever. If they don't, then I should check the integrity of all of my backup CDs every couple of years, and copy the data from failing sets to new sets. This involves doing something like calculating a CRC code for all files in the archive, and storing a copy of this with each copy of the backup tree.
I also keep a paper copy of anything really important (that will fit on paper, at least).
There's also an active system that I'm interested in trying, but it would have to be continually maintained (CDs and tapes can be left unattended for years, if they're stored well). The active system would be a bunch of servers with RAID drives that stored the files to be preserved, along with CRC information for the files. These servers actively mirror content from each other, trying to each keep a complete set of the data (updates propagate through the mirroring network). They'd also perform integrity checks on their own data and data from other servers (let the other server know that its data differs from the local copy). As long as the servers are maintained and swapped out when they fail, the data should be preserved intact forever.
The catch is that, while you could in principle preserve storage media for a century, I wouldn't want to bet on a server network being maintained (in whatever form) for a century.
Could anyone with closer ties to this project brief me on exactly what the working principles of this are? The article doesn't go into very much detail.
Before I get six different descriptions of how railguns work - I already know how most varieties of magnetic gun work. I want to know *which* this uses.
My best guess is something that uses the same principles as a coilgun (conducting object is repelled by the rapidly changing magnetic field), but the article still doesn't go into enough detail to confirm this.
Earth escape velocity is ~7 MILES/second or ~ 11.3 KILOMETERS/second. But the officials at our national lab says in the article that it is 7 KILOMETERS/second and then goes on to use that to show just how fast this thing is...
Perhaps they meant the velocity required to attain orbit; this is about 8 km/sec.
The jamming system should be able to filter out a signal comming from a phone, and if the number dialed on the phone is one of the emergency numbers, it should let it through.
That's not how jammers work, unfortunately. Jammers just produce enough radio noise in the frequency band used by the jammed devices to prevent them from working. You either block everything or you block nothing.
A 911 cell phone call looks exactly like any other call to someone snooping radio signals. There's no way that a jammer, no matter how smart, could tell the difference.
The environmental Nazis claim the USA is a polluting nation, but with technology like this, we have demonstrated quite clearly how we will dominate the market for 'green' automobiles in the future.
Um, you do realize that this is an article in *Canada* reporting the development of this technology in *England*?
In summary, you can keep most of the design the same as for a single-thread machine, and make relatively minor changes in a few places to implement SMT. This takes far less silicon than dual cores, and lets you use the functional units more efficiently and use a wide issue unit efficiently (by boosting parallelism in the instruction stream).
I'm not sure I buy this argument. It is far easier to duplicate an existing design to make another core than to modify the design to support SMT. SMT requires big fetch/decode/rename hardware, a big register file and probably big caches, too. All of this stuff is in the critical path and will be difficult to run at the high clock speeds expected from modern cores.
Actually, unless you want to take a moderate speed hit from recycling external bus protocols internally, you'll have quite a bit of design work on your hands building the internal communications bus for a multi-core system. Whether this is comparable to the amount of work needed for a SMT system is an open question, but it's definitely not negligible.
The fetch/decode hardware is a straight duplication of the existing hardware - it doesn't take up any more space than for two duplicated cores.
The architectural register file is in two independent banks; again, no more space than you'd have normally. Your physical register file is probably in the form of distributed reservation stations on the functional units; again, no more space than for duplicate cores.
You do need more bandwidth on your result busses if you want to use more functional units at once, but this holds true for an aggressively-superscalar single-thread processor too. This is a manageable problem. If necessary, you can trade off bandwidth and latency when building the thing, because your execution stream is much less sensitive to latency than it would be with a single-thread machine.
Renaming hardware is manageable. You'd need the bandwidth anyways on a wide-issue single-thread processor with the same issue rate.
Caches will have less locality, which can be partly addressed by the operating system (keeping related threads on the same die), but will still be a problem. I don't think this will kill performance. You can pull tricks like having multiple cache banks to fake multiporting, or you can pipeline the cache and run it at a higher clock speed (as you don't mind _some_ extra latency), or do a number of other things. We're reaching the point of diminishing returns with cache size anyways, so you'll probably still have enough cache to effectively handle both threads.
Re. clock speed, again, you don't mind a _moderate_ amount of extra latency, because you have enough parallelism to reschedule around it. You also can get away with a smaller instruction window, because you won't have to work as hard to find independent instructions. This saves latency in the scheduler.
In summary, while you raise legitimate concerns, I don't think that they'll be significant problems.
Why not just use multiple cores on a single chip? Last time I heard, that's what Power4 was going to do, right? Also, are you saying that the 8 execution units are split between several separate threads? If so, does anybody know if it's a fixed split (4 for first thread running, 4 for second) or dynamic (which would be surprising, but cool. ..)?
The multiple cores idea has been around for a while, and certainly works; SMT is just more resource-efficient.
My impression is that the Power4 is going to have two cores, but I haven't been following it closely, so I could easily be wrong about that.
In a SMT system, functional units are indeed shared dynamically between the threads. As far as most of the chip's concerned, there's only one instruction stream, composed of interleaved instructions from the two threads (well, not interleaved in lockstep, but close enough). All you'd need to do would be to add an extra bit onto the register specifier tags (so that the two threads access non-overlapping sections of the register file) and give each thread its own page table identifier (selected by a few bits tacked on to the address). You could even get away with having a single TLB cache.
In summary, you can keep most of the design the same as for a single-thread machine, and make relatively minor changes in a few places to implement SMT. This takes far less silicon than dual cores, and lets you use the functional units more efficiently and use a wide issue unit efficiently (by boosting parallelism in the instruction stream).
What set of benchmarks were you running when you collected those numbers? I assume you were using a benchmark suite such as SPEC. This is only one measure, useful to a certain audience.
For that particular project, I was using the go and cc1 integer benchmarks from the SPEC suite (not sure which year). No special reason; these were just the ones I had on-hand, and for the project it didn't really matter (as I was interested in relative and not absolute results).
I cite the figures from that project as a reference point to give some idea of the ballpark values that can be expected. A 50% increase in ILP for "average" code I might believe. A 400% increase I wouldn't.
Yes, certain scientific applications can be written to be easily parallelized, but this is only one niche. For most code, I am deeply skeptical of filling 8 issue units per clock. SMT offers the potential for across-the-board speedup (as long as you're running more than one CPU-bound thread on the machine at once).
Doing this kind of parallelism extraction in the compiler just plain makes more sense than doing it on the chip (with SMT). The compiler can see all of the source code at once and spend a huge amount of time studying the problem which can be extremely complicated, if you want a really good, inter-procedural, flow-sensitive analysis) and then spit out code that bundles it up in explicit parallelism.
You seem to have an incomplete picture of what SMT is.
SMT - Symmetrical Multi-Threading - is simply the ability to have multiple threads running on a chip at the same time, with separate fetch units and register files but with the instruction window and the functional units still shared.
The threads don't even have to be from the same program, or in the same address space (though it'll reduce TLB and cache load if they are).
No extra effort is needed on the part of the programmer, and you get N times as much instruction level parallelism with N threads as you would for one thread. In one instruction stream, you'll always have dependencies that can't be avoided - true dependencies. Parallel threads don't have any shared dependencies for register operations, and are much less likely to have dependencies for memory operations (under most conditions).
A compiler, on the other hand, has to be made extremely complex to extract much more parallelism than is currently extracted, and still won't be able to capture a lot of it. I know this far too well, having seen the guts of compilers on a few occasions. You'll also get no benefit for legacy code or for code that was compiled with a mediocre compiler (as almost all code is, to Intel's continuing dismay).
SMT is especially nice because there's almost no extra hardware overhead for implementing SMT. It's a winning strategy from all angles.
"Unlike a typical PC microprocessor, the chip features eight execution units fed by a 6.4 gigabyte-per-second memory subsystem, allowing the POWER3 to outperform competitors' processors running at two to three times the clock speed"
Eight execution units! I recall that the x86 line have half of that. And 6.4Gb/s memory is not to be laughed at either!
Memory bandwidth is a good thing. Low latency cache hits are great thing, if you can get them (no idea if PPC does this or not).
However, adding more execution units won't buy you much beyond a fairly small number. The reason: you just don't have that much extractable parallelism in the serial instruction stream.
I had the good fortune to be playing with this recently via simulation. If you give the processor a *huge* instruction window (256 instructions) and the ability to execute *any* number of instructions of *any* type in parallel (except for memory accesses - see below), you still get an average Instructions Per Clock of about 2.1-2.2. 95% of the time, you're getting four instructions or fewer issued (and most of the time, far fewer than that).
When SMT is put in silicon, wider issue will become practical (due to increased parallelism in the instruction stream), but as it is, you're better off spending the silicon on other improvements.
Re. memory accesses; the reason why it's extremely difficult to do memory accesses out-of-order with each other is that you have to check to see if any given two memory accesses refer to the same location (indicating a dependence). You often don't know what the target address is until late in the pipeline, and you'll still need to do a TLB translation to get the physical address, and compare two large bit vectors (the addresses).
Remember, to be useful for scheduling, you have to be able to do all of this very quickly and very early in the pipeline.
All of this makes out-of-order memory accesses very difficult to implement theoretically, and a nightmare to implement in real silicon. It's still sometimes done in a limited manner, but this doesn't affect the IPC very much.
Peer reviews cut out any of the really 'wayout' ideas, making conservative judgements that restrict the opportunity for scientific advance.
Firstly, peer review is hardly a new thing - the scientific community has *always* relied on peer review, as it's the best method we've found to date to sort out ideas that make sense from ideas that don't.
Secondly, while peer review may cut out a brilliant "way out" idea once in a while, it also cuts out the several hundred corresponding _idiotic_ "way out" ideas that were also submitted. This is an acceptable tradeoff.
In summary, I think that your complaints about peer review are misplaced.
There's also the problem of superconductors breaking down in strong magnetic fields, which renders them useless for high-field applications. High-temperature superconductors are especially bad for this.
I disagree. Most modern HTC's have a property called 'flux pinning' Under high magnetic fields, the superconductor allows the magnetic field to recide in small 'tubes' within the superconductor. these tubes run through impurities in the ceramic, (which is non superconducting in any event) and is surrounded by supercurrents that keep the field lines in place. as long as the circular currents is not so hing as to dissallow superconductivity, the bulk of the superconductor behaves as any normal one, that is it is superconducting.
The problem is that breakdown (caused by these flux tubes widening until they meet) *still* occurs at a much lower field strength in type II than in very cold type I superconductors. The strongest superconducting magnet I've ever heard of was an 8-T liquid helium-cooled magnet designed for use in a particle accelerator. If I understand correctly, breakdown for known type II materials is closer to 1 T.
Still, if they can get one transistor in 25 microns square, and handle all the wiring in other layers:
The original 80386 (with 275,000 transistors) fits in a 13.1 by 13.1 mm square.
It turns out that it's much worse than this. The minimum feature size gives you the minimum gate width you can use (if you're lucky). A transistor, contacts and all, takes up easily ten times this in both directions (after spacing rules and so forth have been taken into account).
Speed is also inversely proportional to the square of the feature size. Going from 0.25 micron to 25 micron slows you down by a factor of about 10,000 (give or take). You'll end up with microchip wallpaper that runs at 50 kHz.
There are uses for this (big active displays comes to mind), but computers aren't one of them.
One problem is that subscription costs (for library usage, which is what you need to get for >1 scientist at $LOCATION to make use of the information) are really, really high, and have been rising far faster than inflation I seem to recall that in my field, something like 90% of the journals are controlled by
While I agree that this is an inconvenient trend, it still doesn't prevent researchers from accessing the articles.
For starters, they can always just walk across the street to the local large university's library, which in all likelihood does stock the journal.
For seconds, they can write/email the authour of the article and ask for more information. When I did this, the authour was overjoyed to send me a huge stack of paper (the thesis upon which the article was based).
For thirds, the silliness of the library fee is capped at the point where it becomes cheaper for every scientist just to get a personal subscription to the journals in question, and save library trips for looking up past research (though admittedly this is what the lion's share of journal use is for).
In summary, I don't think that this will ever be a catastrophic problem.
If I remember how a transistor works, it would be rather difficult to make one out of a superconductor. Essentially, the idea of increasing the conductance of a stretch of material by applying a voltage at a gate and thus drawing charge carriers into the area to conduct doesn't work where there is no significant resistance regardless of applied gate voltages. In fact the whole CPU would just be one open circuit.
The usual approaches are to either make wiring superconducting (reducing resistive losses a bit), or to use devices other than transistors to perform the switching (a few alternatives exist).
I've linked to my personal favourite method in another post in this article (click "user info" to find it).
I can't quite picture a superconducting semiconductor in my head. Would such a chip just have superconducting interconnections? How does it work?
There are several ways of using superconductors to build integrated circuits. Using superconducting interconnects would reduce RC time constant delays, but not by a vast amount (the transistors provide most of the resistance).
Maglev trains wouldn't be so electric thristy, no loss long distance power cable, super efficient turbines and of course fast processors. Which do you think is going to be the most important apllication of super conducters?
I think that the most important applications are going to be the ones that are impractical to accomplish with conventional conductors (logically enough). All of the applications you mention would be _helped_ by superconductors, but are getting by adequately without them (wheels work fine on most trains, for instance).
One of the more interesting applications on the horizon is plasma manipulation. We already have many tools that use plasma as a working medium (etchers, torches), but there are a number of fun things you can build if you don't have to worry about resistance in your magnet coils and related circuits.
My personal favourite plasma application is a fabricator that uses patterned plasma deposition. This would work with a wide variety of materials, unlike normal fabricators. You need a plasma because otherwise it's difficult to confine and pattern your source materials. Superconductors would be useful because the most interesting fabricator design I can think of requires wobbling of a very strong magnetic field TV-scan-style, which would have horrible resistive losses if implemented with conventional components.
Fabrication by plasma deposition is much too expensive to be competitive for most things, but there are niche markets.
Fusion power is one of the more interesting plasma applications, though superconductors may not ever be up to the task. You can Brute Force a better fusion reactor by using a stronger magnetic field, but resistive heating of the magnet coils is only part of the problem. Outward pressure on the coils due to magnetic is one of the main engineering design limits to magnetic confinement reactors. There's also the problem of superconductors breaking down in strong magnetic fields, which renders them useless for high-field applications. High-temperature superconductors are especially bad for this.
In practice, problems with fusion are likely to be solved by clever design as opposed to brute force and ignorance solutions.
Thinking of more applications is left as an exercise to the reader; these are just my personal favourites.
Re:Does no one here have respect for language?
on
Uplifting Dolphins
·
· Score: 2
I'm no Luddite, I'd love to be able to talk to dolphins and/or apes...but you can't teach language to apes and dolphins. Language isn't just a matter of brute processing power of the brain. It requires innate wiring created to handle it.
...Which is already present, because these species already use language to communicate with themselves.
The problem is teaching them a lanugage that _we_ can understand. This has already been done for apes and chimps (apes with sign language, chimps with keyboards). Dolphins are trickier, but that's mainly a practical issue (they can't sign or type, so we're working ona whistle code).
That apes and dolphins are capable of using language is not in question. The question is "are they smart enough to be considered people under the law", which can only be assessed by direct communication of better quality than we've managed to achieve to date. This is an engineering problem, not a theoretical problem (we know it can be done, but not how to do it).
Unless you spend more energy cooling the thing than you save in lower transmission loss. I guess we need perfect insulators too.
Firstly, we have several insulation schemes that will work well enough for this purpose. Least exotic: Put a vacuum gap between your cable pipe and a larger pipe around it. Most exotic: Aerogel insulation (they found a cheap method to produce it a few years back).
Secondly, transmission line losses are substantial enough that reducing them would be a Very Profitable Thing.
Thirdly, though, superconducting cables aren't likely to be the way to do it. Most of the transmission losses in the power grid are inductive.
Maybe if scientists cooperated (in an open source style) instead of hoarding their knowledge for the likes of Hoffman-LaRoche, Wellcome etc, the breakthroughs would come sooner.
...And this is precisely what publication is for. The goal of a scientist is to publish as many papers as possible to gain prestige (and associated benefits like money). Once a work is published, anyone else can see what the scientist did and build on it. Science is one of the few disciplines where there _is_ a direct incentive to share work.
I bet if they gave biotech grad students this 'source' to leprosy, they would come up with a fix pretty damn quick. With many eyes all bugs are shallow.
You've obviously never done research. Or coded on a complex project. More eyes are often helpful, but the eyes' owners must _understand_ the problem.
Furthermore, it's the biotech grad students that are _doing_ the research! Professors come up with project ideas based on their own readings and past research and the input of their students, and then hire as many students as they can get their hands on to implement the projects for them. This is how (university-based) research _works_.
Please spend a few minutes researching before posting.
So medical professionals are going to have to choose between the lives of older people and the lives of potential human babies.
If I understand correctly, stem cells are immortal (able to divide indefinitely). This means you'd need one sample for all future needs. I'm sure there's enough honestly-obtainable tissue for that.
Of course, all of this will be academic for another decade or so until research translates into practice.
Another promising avenue of exploration is transforming one form of stem cell into another. This would let us use a patient's own bone marrow stem cells to regenerate any kind of tissue (with the added bonus of not requiring immunosuppressant drugs forever after to prevent rejection). However, while research is promising, this will stay in the lab for quite a while.
Slashdot Mirror
This or any of a number of other magnetic cannon techniques could work, or even a compressed gas gun (like the "Super Gun" from years ago).
The problems are twofold:
To reach orbit, you need an energy of about 30 MJ/kg (for a velocity of about 8 km/sec). Energy is force (mass times acceleration) times distance, so for a given acceleration, you can calculate the barrel length of the gun required. For a 3g accelerator for humans, you get a gun 1000 km long. If you can overcome the engineering problems and build a gun that accelerates cargo at *3000* gravities... you still have a gun 1 km long (about 0.62 miles, if you were wondering).
This can be built, but it's *expensive*. There would have to be a very strong incentive to build it, and amortizing the cost of the gun will raise your launch costs by quite a bit.
You'll notice that the experiment discussed in the article was done in vacuum.
Your gun will have to have an enclosed barrel (even if it's a magnetic gun). Otherwise, the mach-16 sonic boom will tear the firing coils off their mountings or otherwise harm the gun's structure.
Your gun (and anything near it!) is still going to have a lot of wear from the effects of a hypersonic projectile smacking into the atmosphere on leaving its muzzle.
Lastly, your projectile is going to have to have shielding around it to keep it from burning up while leaving the atmosphere. This will add weight to the projectile, and require a higher muzzle velocity (because the projectile will slow down).
All of these problems are manageable, but they increase the cost of the gun and the cost per kilogram of payload even more.
In summary, yes, we can scale up this and other guns like it; however, they're a royal pain to build and use, and there isn't enough demand at present to make them practical.
OTOH, this is one of the best ways known to get material off the moon. Required energy (and hence barrel length) is much lower, and there's no atmosphere to cause problems.
I'm blithely pretending that CDs will last forever. If they don't, then I should check the integrity of all of my backup CDs every couple of years, and copy the data from failing sets to new sets. This involves doing something like calculating a CRC code for all files in the archive, and storing a copy of this with each copy of the backup tree.
I also keep a paper copy of anything really important (that will fit on paper, at least).
There's also an active system that I'm interested in trying, but it would have to be continually maintained (CDs and tapes can be left unattended for years, if they're stored well). The active system would be a bunch of servers with RAID drives that stored the files to be preserved, along with CRC information for the files. These servers actively mirror content from each other, trying to each keep a complete set of the data (updates propagate through the mirroring network). They'd also perform integrity checks on their own data and data from other servers (let the other server know that its data differs from the local copy). As long as the servers are maintained and swapped out when they fail, the data should be preserved intact forever.
The catch is that, while you could in principle preserve storage media for a century, I wouldn't want to bet on a server network being maintained (in whatever form) for a century.
You can access the full text here if you have a subscription. Unfortunately I don't understand their technique. Can you explain it to us ?
:).
Possibly. If I had a subscription
Could anyone with closer ties to this project brief me on exactly what the working principles of this are? The article doesn't go into very much detail.
Before I get six different descriptions of how railguns work - I already know how most varieties of magnetic gun work. I want to know *which* this uses.
My best guess is something that uses the same principles as a coilgun (conducting object is repelled by the rapidly changing magnetic field), but the article still doesn't go into enough detail to confirm this.
Earth escape velocity is ~7 MILES/second or ~ 11.3 KILOMETERS/second. But the officials at our national lab says in the article that it is 7 KILOMETERS/second and then goes on to use that to show just how fast this thing is...
Perhaps they meant the velocity required to attain orbit; this is about 8 km/sec.
The jamming system should be able to filter out a signal comming from a phone, and if the number dialed on the phone is one of the emergency numbers, it should let it through.
That's not how jammers work, unfortunately. Jammers just produce enough radio noise in the frequency band used by the jammed devices to prevent them from working. You either block everything or you block nothing.
A 911 cell phone call looks exactly like any other call to someone snooping radio signals. There's no way that a jammer, no matter how smart, could tell the difference.
The environmental Nazis claim the USA is a polluting nation, but with technology like this, we have demonstrated quite clearly how we will dominate the market for 'green' automobiles in the future.
Um, you do realize that this is an article in *Canada* reporting the development of this technology in *England*?
IHBT, I know...
In summary, you can keep most of the design the same as for a single-thread machine, and make relatively minor changes in a few places to implement SMT. This takes far less silicon than dual cores, and lets you use the functional units more efficiently and use a wide issue unit efficiently (by boosting parallelism in the instruction stream).
I'm not sure I buy this argument. It is far easier to duplicate an existing design to make another core than to modify the design to support SMT. SMT requires big fetch/decode/rename hardware, a big register file and probably big caches, too. All of this stuff is in the critical path and will be difficult to run at the high clock speeds expected from modern cores.
Actually, unless you want to take a moderate speed hit from recycling external bus protocols internally, you'll have quite a bit of design work on your hands building the internal communications bus for a multi-core system. Whether this is comparable to the amount of work needed for a SMT system is an open question, but it's definitely not negligible.
The fetch/decode hardware is a straight duplication of the existing hardware - it doesn't take up any more space than for two duplicated cores.
The architectural register file is in two independent banks; again, no more space than you'd have normally. Your physical register file is probably in the form of distributed reservation stations on the functional units; again, no more space than for duplicate cores.
You do need more bandwidth on your result busses if you want to use more functional units at once, but this holds true for an aggressively-superscalar single-thread processor too. This is a manageable problem. If necessary, you can trade off bandwidth and latency when building the thing, because your execution stream is much less sensitive to latency than it would be with a single-thread machine.
Renaming hardware is manageable. You'd need the bandwidth anyways on a wide-issue single-thread processor with the same issue rate.
Caches will have less locality, which can be partly addressed by the operating system (keeping related threads on the same die), but will still be a problem. I don't think this will kill performance. You can pull tricks like having multiple cache banks to fake multiporting, or you can pipeline the cache and run it at a higher clock speed (as you don't mind _some_ extra latency), or do a number of other things. We're reaching the point of diminishing returns with cache size anyways, so you'll probably still have enough cache to effectively handle both threads.
Re. clock speed, again, you don't mind a _moderate_ amount of extra latency, because you have enough parallelism to reschedule around it. You also can get away with a smaller instruction window, because you won't have to work as hard to find independent instructions. This saves latency in the scheduler.
In summary, while you raise legitimate concerns, I don't think that they'll be significant problems.
Why not just use multiple cores on a single chip? Last time I heard, that's what Power4 was going to do, right? Also, are you saying that the 8 execution units are split between several separate threads? If so, does anybody know if it's a fixed split (4 for first thread running, 4 for second) or dynamic (which would be surprising, but cool. . .)?
The multiple cores idea has been around for a while, and certainly works; SMT is just more resource-efficient.
My impression is that the Power4 is going to have two cores, but I haven't been following it closely, so I could easily be wrong about that.
In a SMT system, functional units are indeed shared dynamically between the threads. As far as most of the chip's concerned, there's only one instruction stream, composed of interleaved instructions from the two threads (well, not interleaved in lockstep, but close enough). All you'd need to do would be to add an extra bit onto the register specifier tags (so that the two threads access non-overlapping sections of the register file) and give each thread its own page table identifier (selected by a few bits tacked on to the address). You could even get away with having a single TLB cache.
In summary, you can keep most of the design the same as for a single-thread machine, and make relatively minor changes in a few places to implement SMT. This takes far less silicon than dual cores, and lets you use the functional units more efficiently and use a wide issue unit efficiently (by boosting parallelism in the instruction stream).
What set of benchmarks were you running when you collected those numbers? I assume you were using a benchmark suite such as SPEC. This is only one measure, useful to a certain audience.
For that particular project, I was using the go and cc1 integer benchmarks from the SPEC suite (not sure which year). No special reason; these were just the ones I had on-hand, and for the project it didn't really matter (as I was interested in relative and not absolute results).
I cite the figures from that project as a reference point to give some idea of the ballpark values that can be expected. A 50% increase in ILP for "average" code I might believe. A 400% increase I wouldn't.
Yes, certain scientific applications can be written to be easily parallelized, but this is only one niche. For most code, I am deeply skeptical of filling 8 issue units per clock. SMT offers the potential for across-the-board speedup (as long as you're running more than one CPU-bound thread on the machine at once).
Doing this kind of parallelism extraction in the compiler just plain makes more sense than doing it on the chip (with SMT). The compiler can see all of the source code at once and spend a huge amount of time studying the problem which can be extremely complicated, if you want a really good, inter-procedural, flow-sensitive analysis) and then spit out code that bundles it up in explicit parallelism.
You seem to have an incomplete picture of what SMT is.
SMT - Symmetrical Multi-Threading - is simply the ability to have multiple threads running on a chip at the same time, with separate fetch units and register files but with the instruction window and the functional units still shared.
The threads don't even have to be from the same program, or in the same address space (though it'll reduce TLB and cache load if they are).
No extra effort is needed on the part of the programmer, and you get N times as much instruction level parallelism with N threads as you would for one thread. In one instruction stream, you'll always have dependencies that can't be avoided - true dependencies. Parallel threads don't have any shared dependencies for register operations, and are much less likely to have dependencies for memory operations (under most conditions).
A compiler, on the other hand, has to be made extremely complex to extract much more parallelism than is currently extracted, and still won't be able to capture a lot of it. I know this far too well, having seen the guts of compilers on a few occasions. You'll also get no benefit for legacy code or for code that was compiled with a mediocre compiler (as almost all code is, to Intel's continuing dismay).
SMT is especially nice because there's almost no extra hardware overhead for implementing SMT. It's a winning strategy from all angles.
"Unlike a typical PC microprocessor, the chip features eight execution units fed by a 6.4 gigabyte-per-second memory subsystem, allowing the POWER3 to outperform competitors' processors running at two to three times the clock speed"
Eight execution units! I recall that the x86 line have half of that. And 6.4Gb/s memory is not to be laughed at either!
Memory bandwidth is a good thing. Low latency cache hits are great thing, if you can get them (no idea if PPC does this or not).
However, adding more execution units won't buy you much beyond a fairly small number. The reason: you just don't have that much extractable parallelism in the serial instruction stream.
I had the good fortune to be playing with this recently via simulation. If you give the processor a *huge* instruction window (256 instructions) and the ability to execute *any* number of instructions of *any* type in parallel (except for memory accesses - see below), you still get an average Instructions Per Clock of about 2.1-2.2. 95% of the time, you're getting four instructions or fewer issued (and most of the time, far fewer than that).
When SMT is put in silicon, wider issue will become practical (due to increased parallelism in the instruction stream), but as it is, you're better off spending the silicon on other improvements.
Re. memory accesses; the reason why it's extremely difficult to do memory accesses out-of-order with each other is that you have to check to see if any given two memory accesses refer to the same location (indicating a dependence). You often don't know what the target address is until late in the pipeline, and you'll still need to do a TLB translation to get the physical address, and compare two large bit vectors (the addresses).
Remember, to be useful for scheduling, you have to be able to do all of this very quickly and very early in the pipeline.
All of this makes out-of-order memory accesses very difficult to implement theoretically, and a nightmare to implement in real silicon. It's still sometimes done in a limited manner, but this doesn't affect the IPC very much.
Peer reviews cut out any of the really 'wayout' ideas, making conservative judgements that restrict the opportunity for scientific advance.
Firstly, peer review is hardly a new thing - the scientific community has *always* relied on peer review, as it's the best method we've found to date to sort out ideas that make sense from ideas that don't.
Secondly, while peer review may cut out a brilliant "way out" idea once in a while, it also cuts out the several hundred corresponding _idiotic_ "way out" ideas that were also submitted. This is an acceptable tradeoff.
In summary, I think that your complaints about peer review are misplaced.
There's also the problem of superconductors breaking down in strong magnetic fields, which renders them useless for high-field applications. High-temperature superconductors are especially bad for this.
I disagree. Most modern HTC's have a property called 'flux pinning' Under high magnetic fields, the superconductor allows the magnetic field to recide in small 'tubes' within the superconductor. these tubes run through impurities in the ceramic, (which is non superconducting in any event) and is surrounded by supercurrents that keep the field lines in place. as long as the circular currents is not so hing as to dissallow superconductivity, the bulk of the superconductor behaves as any normal one, that is it is superconducting.
The problem is that breakdown (caused by these flux tubes widening until they meet) *still* occurs at a much lower field strength in type II than in very cold type I superconductors. The strongest superconducting magnet I've ever heard of was an 8-T liquid helium-cooled magnet designed for use in a particle accelerator. If I understand correctly, breakdown for known type II materials is closer to 1 T.
The original 80386 (with 275,000 transistors) fits in a 13.1 by 13.1 mm square.
It turns out that it's much worse than this. The minimum feature size gives you the minimum gate width you can use (if you're lucky). A transistor, contacts and all, takes up easily ten times this in both directions (after spacing rules and so forth have been taken into account).
Speed is also inversely proportional to the square of the feature size. Going from 0.25 micron to 25 micron slows you down by a factor of about 10,000 (give or take). You'll end up with microchip wallpaper that runs at 50 kHz.
There are uses for this (big active displays comes to mind), but computers aren't one of them.
Bear in mind that Blizzard is probably taking the only reasonable course of action open to it - protecting its trademark.
If this ruling goes against Blizzard, I expect to see a lot more "Diablo"-labelled merchandise cropping up, claiming to be unrelated.
I'm not saying that Blizzard _should_ win the lawsuit. I'm just saying that this will be a decision with unpleasant consequences either way it goes.
I've heard that the particles in smoke will cause problems with keyboards, and also with things like floppy drives that are sensitive to dust.
DISCLAIMER: I haven't directly observed any smoking-related computer problems.
One problem is that subscription costs (for library usage, which is what you need to get for >1 scientist at $LOCATION to make use of the information) are really, really high, and have been rising far faster than inflation I seem to recall that in my field, something like 90% of the journals are controlled by
While I agree that this is an inconvenient trend, it still doesn't prevent researchers from accessing the articles.
For starters, they can always just walk across the street to the local large university's library, which in all likelihood does stock the journal.
For seconds, they can write/email the authour of the article and ask for more information. When I did this, the authour was overjoyed to send me a huge stack of paper (the thesis upon which the article was based).
For thirds, the silliness of the library fee is capped at the point where it becomes cheaper for every scientist just to get a personal subscription to the journals in question, and save library trips for looking up past research (though admittedly this is what the lion's share of journal use is for).
In summary, I don't think that this will ever be a catastrophic problem.
If I remember how a transistor works, it would be rather difficult to make one out of a superconductor. Essentially, the idea of increasing the conductance of a stretch of material by applying a voltage at a gate and thus drawing charge carriers into the area to conduct doesn't work where there is no significant resistance regardless of applied gate voltages. In fact the whole CPU would just be one open circuit.
The usual approaches are to either make wiring superconducting (reducing resistive losses a bit), or to use devices other than transistors to perform the switching (a few alternatives exist).
I've linked to my personal favourite method in another post in this article (click "user info" to find it).
I can't quite picture a superconducting semiconductor in my head. Would such a chip just have superconducting interconnections? How does it work?
/ 12/10/0925/1544 )
There are several ways of using superconductors to build integrated circuits. Using superconducting interconnects would reduce RC time constant delays, but not by a vast amount (the transistors provide most of the resistance).
The most promising approaches use devices other than transistors to perform switching. My favourite method was described in IEEE Spectrum a while back (kuro5hin article here: http://www.kuro5hin.org/?op=displaystory&sid=2000
Maglev trains wouldn't be so electric thristy, no loss long distance power cable, super efficient turbines and of course fast processors. Which do you think is going to be the most important apllication of super conducters?
I think that the most important applications are going to be the ones that are impractical to accomplish with conventional conductors (logically enough). All of the applications you mention would be _helped_ by superconductors, but are getting by adequately without them (wheels work fine on most trains, for instance).
One of the more interesting applications on the horizon is plasma manipulation. We already have many tools that use plasma as a working medium (etchers, torches), but there are a number of fun things you can build if you don't have to worry about resistance in your magnet coils and related circuits.
My personal favourite plasma application is a fabricator that uses patterned plasma deposition. This would work with a wide variety of materials, unlike normal fabricators. You need a plasma because otherwise it's difficult to confine and pattern your source materials. Superconductors would be useful because the most interesting fabricator design I can think of requires wobbling of a very strong magnetic field TV-scan-style, which would have horrible resistive losses if implemented with conventional components.
Fabrication by plasma deposition is much too expensive to be competitive for most things, but there are niche markets.
Fusion power is one of the more interesting plasma applications, though superconductors may not ever be up to the task. You can Brute Force a better fusion reactor by using a stronger magnetic field, but resistive heating of the magnet coils is only part of the problem. Outward pressure on the coils due to magnetic is one of the main engineering design limits to magnetic confinement reactors. There's also the problem of superconductors breaking down in strong magnetic fields, which renders them useless for high-field applications. High-temperature superconductors are especially bad for this.
In practice, problems with fusion are likely to be solved by clever design as opposed to brute force and ignorance solutions.
Thinking of more applications is left as an exercise to the reader; these are just my personal favourites.
I'm no Luddite, I'd love to be able to talk to dolphins and/or apes...but you can't teach language to apes and dolphins. Language isn't just a matter of brute processing power of the brain. It requires innate wiring created to handle it.
...Which is already present, because these species already use language to communicate with themselves.
The problem is teaching them a lanugage that _we_ can understand. This has already been done for apes and chimps (apes with sign language, chimps with keyboards). Dolphins are trickier, but that's mainly a practical issue (they can't sign or type, so we're working ona whistle code).
That apes and dolphins are capable of using language is not in question. The question is "are they smart enough to be considered people under the law", which can only be assessed by direct communication of better quality than we've managed to achieve to date. This is an engineering problem, not a theoretical problem (we know it can be done, but not how to do it).
Unless you spend more energy cooling the thing than you save in lower transmission loss. I guess we need perfect insulators too.
Firstly, we have several insulation schemes that will work well enough for this purpose. Least exotic: Put a vacuum gap between your cable pipe and a larger pipe around it. Most exotic: Aerogel insulation (they found a cheap method to produce it a few years back).
Secondly, transmission line losses are substantial enough that reducing them would be a Very Profitable Thing.
Thirdly, though, superconducting cables aren't likely to be the way to do it. Most of the transmission losses in the power grid are inductive.
Ok, I'll bite.
Maybe if scientists cooperated (in an open source style) instead of hoarding their knowledge for the likes of Hoffman-LaRoche, Wellcome etc, the breakthroughs would come sooner.
...And this is precisely what publication is for. The goal of a scientist is to publish as many papers as possible to gain prestige (and associated benefits like money). Once a work is published, anyone else can see what the scientist did and build on it. Science is one of the few disciplines where there _is_ a direct incentive to share work.
I bet if they gave biotech grad students this 'source' to leprosy, they would come up with a fix pretty damn quick. With many eyes all bugs are shallow.
You've obviously never done research. Or coded on a complex project. More eyes are often helpful, but the eyes' owners must _understand_ the problem.
Furthermore, it's the biotech grad students that are _doing_ the research! Professors come up with project ideas based on their own readings and past research and the input of their students, and then hire as many students as they can get their hands on to implement the projects for them. This is how (university-based) research _works_.
Please spend a few minutes researching before posting.
So medical professionals are going to have to choose between the lives of older people and the lives of potential human babies.
If I understand correctly, stem cells are immortal (able to divide indefinitely). This means you'd need one sample for all future needs. I'm sure there's enough honestly-obtainable tissue for that.
Of course, all of this will be academic for another decade or so until research translates into practice.
Another promising avenue of exploration is transforming one form of stem cell into another. This would let us use a patient's own bone marrow stem cells to regenerate any kind of tissue (with the added bonus of not requiring immunosuppressant drugs forever after to prevent rejection). However, while research is promising, this will stay in the lab for quite a while.