That is, encryption using a key of x bits could be broken by the non-deterministic machine trying all 2^x possible keys in parallel. I think I recall Bruce Schneier saying something to this effect in one of the "Crypto-gram" newsletters, but I may be misremembering. Any theorist slashdotters willing to comment?
If you have a good way of recognizing decrypted data, then you could indeed solve any fixed-key-size cryptographic problem in exponential time, just by counting through all possible keys and checking to see if you get readable data after using each one.
However, I'm not sure that a P=NP proof would help with this. You'd have to prove that iterating through each possible key is a problem in NP, as opposed to NP-hard and worse than NP-complete.
It might be better to analyze each cryptography algorithm separately, and see if you can prove any of them to be in NP. These would be vulnerable to a P=NP proof.
Quantum computers of the type previously described could certainly iterate through all of these keys within a reasonable length of time. The construction of practical quantum computers, OTOH, is left as an exercise:). It will be neat if it turns out to be practical.
As a side note, cryptography schemes that use a "one-time pad" of noise that they xor with the message would *not* be vulnerable to QC or P=NP attacks. If you iterate through all possible keys, you get all possible messages, which gains you nothing. Only if the key length is significantly shorter than the total amount of traffic sent will a brute-force search work. This is true for most cryptography systems, for practical reasons.
X-Window is especially a piece of crap compared to the BeOS graphic system. (do I smell flames ? sorry but if you have ever tried to play 8 quicktime movies at the same time on both X-windows and BeOS you know what I mean).
I use BeOS regularly, and while it is indeed quite nice, I think that there are some features of X-Windows that BeOS should adopt. Specifically, the BeOS GUI was written with the assumption that there is a single display device, always on the local machine, that has a frame buffer that can be directly accessed in memory space. This is fine for a single-monitor desktop machine, but will present problems if they try to support multi-monitor systems or remote terminals.
I'm not saying that everything about X-Windows is good; just that this is a useful feature that X-Windows has that BeOS's GUI and graphics API lacks. I look forward to seeing future revisions of both systems.
Hopefully the next step will be a curtain monitor so I can play Quake3 on my wall.
You could do this with a projection system; IIRC the pricing on these was semi-sane (though still several $k), and they aren't intrinsically expensive to build. In fact, it might be cheaper to use a projector for very-large displays. I'd like to see more research done on this, but projectors don't seem to be in vogue at the moment:).
Can anyone explain why some articles have ?'s instead of 's?
If I understand correctly, this is because Microsoft's browser and web page design software disagree with the rest of the world over how to encode backquotes. The result is that these show up as question marks on other browsers.
That, or else what everyone else sees as backquotes show up as question marks on Microsoft browsers. It's been a long time since I read the article that discussed this, so I'm hazy on the details.
K6/3 had 256k on-chip L2; the K7 looks a larger chip (because of the 128k L1), and AMD have been having enough problems fabricating the K6/3 that I'm not surprised they're rolling out the K7 with FSB L2.
If I recall the presentatino sheets correctly, the K7's L2 cache is a _backside_ cache and can be clocked at whatever speed they decide to ship it as. The front-side cache is an L3 cache.
Since 1 GHz is in the microwave domain, I can imagine it being mind blowingly incredibly expensive. And I don't want my computer to sterlize me either. (makes me nervous to think of holding a laptop radiating those frequencies)
There's nothing magical about operating in the microwave frequency range. In fact, your cell phone already does. 0.18 micron chips will be able to do it fairly easily, and will cost no more than any other chips made with the same process technologies.
Re. microwave emission, I wouldn't worry. Designers go to great lengths to minimize emissions (microwave or radio) from chips and bus traces because that causes cross-talk between lines. Modern motherboards put a lot of ground wires and plates around active wiring to shield them and reduce capacitive coupling between signal wires (at the expense of capacitive coupling to ground, but that's a tolerable tradeoff). If communication was done using microwave waveguides instead of wires, then there would still be little or no leakage - because leakage would again mean cross-talk, and waveguides are by nature very well shielded.
Even if an incredibly poorly designed motherboard did manage to radiate microwaves in quantity, you'd end up with an output power no greater than your input power. A few tens of watts (the amount of power that the eletronics consumes, as opposed to the drive motors and monitor (if you plug that into your power supply). It takes a couple of minutes at over a _kilowatt_, confined, to nuke a hot dog. I wouldn't worry about being near an unconfined (radiating in all directions) source in the range of a few tens of watts.
Re. sterilization, I've been hearing mixed information about whether or not that actually happens and under what conditions. It's generally associated with people stepping into microwave relay beams, which are *far* more powerful than anything your motherboard would produce. More information on this, with hard references, would be appreciated, though.
If the liquefaction takes power plant exhaust as its input we can get liquid CO, CO2 etc as a byproduct of making the liquid nitrogen. Then you take these and put them in the empty coal mine shafts. Viola! Its almost totally emmision free.
Firstly, CO2 doesn't have a liquid phase at atmospheric pressure - you'd get dry ice "snow" instead of a liquid. I don't know about the CO.
However, more importantly, you would get gaseous CO2 and _CO_ boiling out of the mine shaft as soon as it warmed up a bit. This is not a practical disposal method.
I suppose that you could get rid of CO2 by binding it chemically to form carbonate rocks, but that's probably more effort than it's worth. Plant more trees instead:).
CO you get rid of by building more efficient furnaces. It's the product of incomplete combustion, and so will form CO2 if fully oxidized. SO2 is more of a problem. That is usually extracted by chemical reaction to form sulphate minerals (this is what "scrubbers" do).
IMO, the most convenient solution to the fluel problem is to run vehicles on methanol. You don't have to worry about CO2 buildup, because the plants you grow to produce the methanol take in as much CO2 as you get out by bruning the methanol and/or the plants themselves. The resource will last as long as the sun will, and methanol has a very high energy density (the energy density of liquid nitrogen is miserable IIRC).
Quake will not run much faster unless you cool your fav 3D card as well or unless you use only software renderer (absent in Quake3Arena). Hence, your example of "benchmark" is not relevant.
Geometry acceleration is still done by the processor for the time being. AI and physics for your game will always be. Go to Tom's Hardware Guide and check out figures for the same game on the same card using different processors.
Any game that performs better on a PII-400 than on a K6-2-400 is CPU-bound.
Any game that performs better on a PII-450 than on a Celeron "450A" is cache-bound.
Any game that performs equally well on most processors, differing only with the video card, is bus-limited or fill-rate limited.
This looks very neat. However, after trying to move my hand into the various required positions, I think that it would be hard to use. The keyboard encoding map is wonderful, though; this would let me hack together an arbitrary input device with conventional hardware. Thanks to the author for posting it.
First of all, performance won't be terribly stellar for applications that thrash the K7's cache. Main memory isn't cooled, and still has a _latency_ in the 6-10ns range (bus speed notwithstanding).
OTOH, things like Quake that fit within the cache will run more quickly.
Secondly, 0.18 micron fabrication should start some time this summer, and should have decent yields for high clock speeds by the end of the year. You should be able to pick up a chip in the 800 MHz - 1 GHz range *without* cooling around then. Drool over what will come out of AMD/Kryotech then, as opposed to now (at the tail end of 0.25 micron):).
Anything bought now will depreciate rapidly in value over the next few months, as 0.18 micron fabs are almost due to come online.
Also SGI's are plain jane intel boxes nowadays(except for the 3d hardware stuff). Subtract the 3d hardware and what does that leave you?
A non-crippled system architecture.
Conventional PC architecture is a series of patches on top of patches, with inefficient communications layouts, backwards-compatible cruft, and lowest-common-denominator busses. A PC motherboard is designed to let a single processor control a host of peripherals of varying ages and kludginess. Memory access is set up for a single processor, and is geared towards slow, inexpensive standards. Things like AGP are kludges on top of this system that try to squeeze extra performance out of them by circumventing some of the architectural bottlenecks.
Workstations, on the other hand, are a different story. They are specifically optimized to allow high bandwidth communications between many processors, lots of memory, and a few peripherals. They can use more-expensive-but-better architectures because they are priced an order of magnitude or two higher than PCs. They are designed to be scalable and to be extremely well optimized for certain classes of task (the type of task depending on the type of workstation).
So, far from getting a "plain" Intel box, you are getting a decent workstation with crappy processors. IMO, SGI should put the MIPS chips back in.
SGI makes its own hardware. Not intel based AFAIK.
Not any more, I don't think. IIRC, they spun off MIPS into its own company and are now building workstations based on x86 processors with SGI-style motherboards and memory architectures.
HP tried embracing Intel and is now having second thoughts. I hope that SGI too has second thoughts before MIPS vanishes.
It is enforced by the students but it must come from the instructors and parents - where else would the students be getting it?
How about each other?
Instructors and parents most certainly aren't blameless, but the primary social influence for students is other students. This is a very nice feedback loop. My comments on the problem in general are posted elsewhere in this thread, so I won't spam you with them here.
The real question here is, how do you get kids to respect one another?
We can't, I think. IMO the best we can do is actively punish the ones that we catch being actively disrespectful/bullying, so as to limit the harm that they do. However, jerks exist, and it will always be an ego boost to tease the outcasts who are so teasable.
However, damage control is IMO better than nothing. The only problem is that that requires most teachers and administrators to be competent and seriously interested in smoothing out the social dynamics in high school. Some schools have many such teachers. Many schools don't. I don't know how this problem can be solved.
Well, I think that the best way to do this is for parents to raise their kids that way. Parents set the most prominent examples for their kids in their early years, and a good model will go a long way toward keeping the jocks and popular kids from picking on the geeks and outcasts.
Having good parental models will help somewhat, but there will still be many kids who are jerks (or worse) because it feels good, regardless of what their parents try to do. IMO the best approach is to attack the problem from many fronts, with this being just one of them (albeit a useful one).
On a related note, crazy and/or intrinsically violent people will always exist, no matter how well parents raise their children. However, competent parents can recognize when their kids are on the road to a gun rampage and turn them over to the authorities. The catch is that this takes competent, benevolent parents. Some parents are like this. Others aren't. Parents are a lot harder to impose quality control on than teachers, too, in a free society.
But what about kids today? Is there any way to drive the culture out of the kids who are in school today? You can't allow the culture to fester, because the older kids just indoctrinate the younger ones by example. I'm not sure there's a good answer to this.
The best approach that I can think of is a crackdown on _bullying_, but this requires a lot of effort by a lot of capable teachers, as mentioned above. It's an imperfect solution, but would probably help somewhat.
And yet, do other countries have the same problem with school violence? A friend from Canada claimed the only random act of violence he remembers recently was someone breaking into the house of some high ranking official while armed with a butter knife.
Violence happens up here all right; it's just knifings more often than shootings, as we have a scarcity of guns (thank goodness, IMO).
I survived elementary school and high school by making friends with the teachers. Most of them were nice people. I avoided elementary school recess by going to the office and helping with filing/checking purchase orders/etc. (which I find enjoyable and relaxing, twisted soul that I am O:)).
I have move up to Anhydrous Ammonia (R-717) in order to achieve sub -100C. Standard CMOS devices today can operate in -120C to -150C without problems but can be clock at twice the speed that is safe at 50C. Improvements in the "doping" process at a relatively cheap cost will allow further cooling to sub -150C and at -202C you are restricted by the quality of the PLC and not the processor. 1.6GHZ would be the theshold of the crystal today.
This doesn't address the problems that I raised - thermal expansion/contraction difficulties and electromigration. While you do mention the limits imposed by the way the threshold voltage changes with temperature, the other two factors mentioned may be what limits your ability to cool and overclock chips.
An integrated circuit chip is a chunk of silicon with aluminum wires on top of it embedded in a thick layer of silicon dioxide. These three materials have different coefficients of thermal expansion. As you cool them, they will change sizes at different rates, causing stress in the chip. Cool them enough, and your chip will break. I'm told that the temperature at which this occurs is lower that I had originally assumed, but it *will* happen. Possibly with liquid nitrogen (though some successful liquid-nitrogen-cooled systems have been built), and almost certainly if you do something silly like cool a chip with liquid helium. Likewise, the card on which the chip sits is glass fibers in an organic resin with plates and traces of copper. These materials all expand at different rates. You also have a lead alloy connecting the pins of the chip to the copper traces on the board. Size changes due to temperature will put stress on these solder joints - and size changes in the plastic casing that holds the pins and integrated circuit chip will put a lot of shear stress on these weakened solder connections.
So, this is not something that can safely be ignored forever.
Likewise, electromigration will seriously reduce the lifetime of any chip being run significantly faster than its standard clock speed at room temperature. Electromigration is the tendency of metal atoms in wire traces on a chip to flow along with the direction of current. The higher the level of current, the greater this effect. If a chip is operated with too-high current levels for too long, enough metal atoms flow that the trace becomes brittle enough to snap under mechanical and thermal stresses, or develops a gap, or gets thin enough that resistive heating melts the trace or increases its resistance enough that it can't transmit signals properly. Electromigration effects were a common cause of failure in older chips. To compensate for this, chip designs nowadays specify maximum currents for given sizes of traces and are careful not to exceed them. However, overclocking _does_ exceed them. In order to clock a chip more quickly, you have to charge and discharge the parasitic capacitances within it more quickly - which is done by increasing the amount of current flowing through transistors in their "on" states. Conventionally, this is done by cranking up the core voltage. Cooling does this by lowering the threshold voltage and fiddling with a few other transistor behavior parameters. In both cases, for a chip clocked n times more quickly, you have n times the amount of current flowing through the same traces. Clock a chip at twice its normal speed, and you have twice the current through the traces - and a chip that will burn out far sooner due to electromigration. Copper is more resistant to electromigration than aluminum, but the metal traces in copper chips are correspondingly thinner than the metal traces in aluminum chips. This is why copper was adopted; the aluminum traces had to be made wide enough that bulk and parasitic capacitances were becoming real problems. Modern chips - copper or aluminum based - are designed to run just below the threshold for electromigration damage. Overclocking them to the degree being done with these cooled setups _will_ push them over the threshold.
OTOH, if you don't care if the chip burns out in a year or two, go for it. Just be aware of the limits and side effects.
I just cant wait till someone get's upto date w/ x86 structure.. Full 128 bit x86 would be nice..
Full 64-bit would be nice, even. However, even 32-bit is a kludge with the way it's currently implemented.
The floating-point/MMX registers on an x86 are 64-bit. I'm not sure how wide the SSE registers are, but I'd guess 128 off-hand. The general-purpose registers have been 32-bit since the 386, and are accessed using a hack on top of the old 16-bit access method (put 0x66 before the opcode for your instruction to make it work on 32-bit operands instead of 16-bit).
There are many fixes that could be made to the x86 register set and instruction set, but the best fix of all would be a complete redesign to a new system. However, Intel can't do that without breaking compatibility with its established software base. Breaking compatibility would leave them at a disadvantage to people like Apple, who already have a more cleanly designed processor with an installed software base. What they're actually doing is hedging their bets and giving the Merced the ability to emulate x86 operating modes. However, this will be done at the cost of either more silicon on the Merced, a slower chip, or both.
I use x86 machines, and for the time being they're competative performance-wise, but it's just a matter of time before the architecture runs into the ground, because it's a mess of patches on top of patches that wasn't built to be extensible. Intel's best bet is to phase out x86 support once there's a significant amount of Merced-native software available. Whether it succeeds in competing with the G4 and whatever Sun, DEC^H^H^HCompaq, and others offer remains to be seen. HP seems less than enthusiastic about it, and they helped Intel design the thing.
I tried this, using very small copper tubing. It is VERY IMPORTANT that you find out what the DEW POINT is and not cool below it! You'll condense water on your motherboard, as I did. If you live in a humid climate or a dry climate with a swamp cooler, you must be very careful!
The author of the article took care to insulate everything, including the pipes, to prevent this from happening. Look carefully at the pictures of the finished system and you'll see the insulation.
Can semiconductors even operator correctly at that temperature?
Yes. In fact, they operate more efficiently, which is why he could boost the clock rate. This is also why processors fail at higher temperatures; they work _less_ well as the temperature increases. If I understand correctly the transistor threshold voltage and a few other parameters vary with temperature. I'd have to dig out my old electronics textbook to give you a detailed explanation, but the gist of it is that the transistors end up passing more current, which decreases switching time.
Limits to clocking with this kind of scheme are chip failure due to electromigration (the traces in the chip can only take so much current), and chip or module failure due to cracking caused by different rates of thermal expansion in the materials used.
This is a very impressive setup. The authour took the time to do proper research and put in the effort to build a cooling system that was structurally sound and reliable.
He'll run into problems when he tries to reach -80, though. Sooner or later traces in the chips or on the chip modules will crack due to differing rates of thermal expansion in the materials used. An interesting read nonetheless, though.
As far as a speed comparison goes, it wouldn't surprise me at all if LinuxPPC or even MkLinux are faster servers at this point. This is the first real release of the OS on PPC hardware, after all. I have access to a bunch of MOSXS machines (mostly Blue&White G3s) though, so if anyone wants to propose a particular test, I could probably set it up. ..
Why not use the standard Spec set of benchmarks? IIRC there were several that assessed web/network serving performance, which seems to be an issue with some of the posters, and the straight processor performance figures should still give some idea of the amount of overhead that the OS takes up.
Maybe I'm stupid but what's the point of the decoder? To use like a mpman or to decode mp3's on your computer instead of using CPU power? (which, would rule for those times when your stuck with a computer that doesn't have enough CPU power to decode MP3's.)
AFAICT, this is intended as a neat hardware project for people who like building their own hardware. See my previous message for other possible uses.
sounds cool if you have a 8086 or something that can't handle a 160kbps encoded MP3. But I think most of the system out there in cyber-lala-land that have a sound card in them can handle it. The only place where I think this might come in handy, is elimnating any "noise" the sound card puts out in the sound stream due to other cards in the system.
Actually, this would probably be more vulnerable to noise, as the board won't be very well shielded and the parallel cable *certainly* won't be.
AFAICT, this is a kit intended for people who like hardware projects, and that's about it. I suppose that you could build a portable MP3 player with the parts if you wanted to (if you also bought a microcontroller chip and maybe a flash card reader). Hardware MP3 decoding would be useful on sound cards if it isn't there already, but that would be integrated into the sound card ASIC instead of added as discrete components like this.
This looks like a build-your-own-MP3-decoder-board kit. Neat, if you're into building hardware yourself (I was a while back). It looks like they have moderately general-purpose chips for this and boards with sample layouts that you can buy if you don't feel like designing your own.
Slashdot Mirror
If you have a good way of recognizing decrypted data, then you could indeed solve any fixed-key-size cryptographic problem in exponential time, just by counting through all possible keys and checking to see if you get readable data after using each one.
However, I'm not sure that a P=NP proof would help with this. You'd have to prove that iterating through each possible key is a problem in NP, as opposed to NP-hard and worse than NP-complete.
It might be better to analyze each cryptography algorithm separately, and see if you can prove any of them to be in NP. These would be vulnerable to a P=NP proof.
Quantum computers of the type previously described could certainly iterate through all of these keys within a reasonable length of time. The construction of practical quantum computers, OTOH, is left as an exercise
As a side note, cryptography schemes that use a "one-time pad" of noise that they xor with the message would *not* be vulnerable to QC or P=NP attacks. If you iterate through all possible keys, you get all possible messages, which gains you nothing. Only if the key length is significantly shorter than the total amount of traffic sent will a brute-force search work. This is true for most cryptography systems, for practical reasons.
I use BeOS regularly, and while it is indeed quite nice, I think that there are some features of X-Windows that BeOS should adopt. Specifically, the BeOS GUI was written with the assumption that there is a single display device, always on the local machine, that has a frame buffer that can be directly accessed in memory space. This is fine for a single-monitor desktop machine, but will present problems if they try to support multi-monitor systems or remote terminals.
I'm not saying that everything about X-Windows is good; just that this is a useful feature that X-Windows has that BeOS's GUI and graphics API lacks. I look forward to seeing future revisions of both systems.
You could do this with a projection system; IIRC the pricing on these was semi-sane (though still several $k), and they aren't intrinsically expensive to build. In fact, it might be cheaper to use a projector for very-large displays. I'd like to see more research done on this, but projectors don't seem to be in vogue at the moment
If I understand correctly, this is because Microsoft's browser and web page design software disagree with the rest of the world over how to encode backquotes. The result is that these show up as question marks on other browsers.
That, or else what everyone else sees as backquotes show up as question marks on Microsoft browsers. It's been a long time since I read the article that discussed this, so I'm hazy on the details.
If I recall the presentatino sheets correctly, the K7's L2 cache is a _backside_ cache and can be clocked at whatever speed they decide to ship it as. The front-side cache is an L3 cache.
There's nothing magical about operating in the microwave frequency range. In fact, your cell phone already does. 0.18 micron chips will be able to do it fairly easily, and will cost no more than any other chips made with the same process technologies.
Re. microwave emission, I wouldn't worry. Designers go to great lengths to minimize emissions (microwave or radio) from chips and bus traces because that causes cross-talk between lines. Modern motherboards put a lot of ground wires and plates around active wiring to shield them and reduce capacitive coupling between signal wires (at the expense of capacitive coupling to ground, but that's a tolerable tradeoff). If communication was done using microwave waveguides instead of wires, then there would still be little or no leakage - because leakage would again mean cross-talk, and waveguides are by nature very well shielded.
Even if an incredibly poorly designed motherboard did manage to radiate microwaves in quantity, you'd end up with an output power no greater than your input power. A few tens of watts (the amount of power that the eletronics consumes, as opposed to the drive motors and monitor (if you plug that into your power supply). It takes a couple of minutes at over a _kilowatt_, confined, to nuke a hot dog. I wouldn't worry about being near an unconfined (radiating in all directions) source in the range of a few tens of watts.
Re. sterilization, I've been hearing mixed information about whether or not that actually happens and under what conditions. It's generally associated with people stepping into microwave relay beams, which are *far* more powerful than anything your motherboard would produce. More information on this, with hard references, would be appreciated, though.
Firstly, CO2 doesn't have a liquid phase at atmospheric pressure - you'd get dry ice "snow" instead of a liquid. I don't know about the CO.
However, more importantly, you would get gaseous CO2 and _CO_ boiling out of the mine shaft as soon as it warmed up a bit. This is not a practical disposal method.
I suppose that you could get rid of CO2 by binding it chemically to form carbonate rocks, but that's probably more effort than it's worth. Plant more trees instead
CO you get rid of by building more efficient furnaces. It's the product of incomplete combustion, and so will form CO2 if fully oxidized. SO2 is more of a problem. That is usually extracted by chemical reaction to form sulphate minerals (this is what "scrubbers" do).
IMO, the most convenient solution to the fluel problem is to run vehicles on methanol. You don't have to worry about CO2 buildup, because the plants you grow to produce the methanol take in as much CO2 as you get out by bruning the methanol and/or the plants themselves. The resource will last as long as the sun will, and methanol has a very high energy density (the energy density of liquid nitrogen is miserable IIRC).
Hence, your example of "benchmark" is not relevant.
Geometry acceleration is still done by the processor for the time being. AI and physics for your game will always be. Go to Tom's Hardware Guide and check out figures for the same game on the same card using different processors.
Any game that performs better on a PII-400 than on a K6-2-400 is CPU-bound.
Any game that performs better on a PII-450 than on a Celeron "450A" is cache-bound.
Any game that performs equally well on most processors, differing only with the video card, is bus-limited or fill-rate limited.
This looks very neat. However, after trying to move my hand into the various required positions, I think that it would be hard to use. The keyboard encoding map is wonderful, though; this would let me hack together an arbitrary input device with conventional hardware. Thanks to the author for posting it.
I remember hearing early June at one point. AMD's page might have a better answer, if they've kept it up to date.
OTOH, things like Quake that fit within the cache will run more quickly.
Secondly, 0.18 micron fabrication should start some time this summer, and should have decent yields for high clock speeds by the end of the year. You should be able to pick up a chip in the 800 MHz - 1 GHz range *without* cooling around then. Drool over what will come out of AMD/Kryotech then, as opposed to now (at the tail end of 0.25 micron)
Anything bought now will depreciate rapidly in value over the next few months, as 0.18 micron fabs are almost due to come online.
A non-crippled system architecture.
Conventional PC architecture is a series of patches on top of patches, with inefficient communications layouts, backwards-compatible cruft, and lowest-common-denominator busses. A PC motherboard is designed to let a single processor control a host of peripherals of varying ages and kludginess. Memory access is set up for a single processor, and is geared towards slow, inexpensive standards. Things like AGP are kludges on top of this system that try to squeeze extra performance out of them by circumventing some of the architectural bottlenecks.
Workstations, on the other hand, are a different story. They are specifically optimized to allow high bandwidth communications between many processors, lots of memory, and a few peripherals. They can use more-expensive-but-better architectures because they are priced an order of magnitude or two higher than PCs. They are designed to be scalable and to be extremely well optimized for certain classes of task (the type of task depending on the type of workstation).
So, far from getting a "plain" Intel box, you are getting a decent workstation with crappy processors. IMO, SGI should put the MIPS chips back in.
Not any more, I don't think. IIRC, they spun off MIPS into its own company and are now building workstations based on x86 processors with SGI-style motherboards and memory architectures.
HP tried embracing Intel and is now having second thoughts. I hope that SGI too has second thoughts before MIPS vanishes.
How about each other?
Instructors and parents most certainly aren't blameless, but the primary social influence for students is other students. This is a very nice feedback loop. My comments on the problem in general are posted elsewhere in this thread, so I won't spam you with them here.
We can't, I think. IMO the best we can do is actively punish the ones that we catch being actively disrespectful/bullying, so as to limit the harm that they do. However, jerks exist, and it will always be an ego boost to tease the outcasts who are so teasable.
However, damage control is IMO better than nothing. The only problem is that that requires most teachers and administrators to be competent and seriously interested in smoothing out the social dynamics in high school. Some schools have many such teachers. Many schools don't. I don't know how this problem can be solved.
Well, I think that the best way to do this is for parents to raise their kids that way. Parents set the most prominent examples for their kids in their early years, and a good model will go a long way toward keeping the jocks and popular kids from picking on the geeks and outcasts.
Having good parental models will help somewhat, but there will still be many kids who are jerks (or worse) because it feels good, regardless of what their parents try to do. IMO the best approach is to attack the problem from many fronts, with this being just one of them (albeit a useful one).
On a related note, crazy and/or intrinsically violent people will always exist, no matter how well parents raise their children. However, competent parents can recognize when their kids are on the road to a gun rampage and turn them over to the authorities. The catch is that this takes competent, benevolent parents. Some parents are like this. Others aren't. Parents are a lot harder to impose quality control on than teachers, too, in a free society.
But what about kids today? Is there any way to drive the culture out of the kids who are in school today? You can't allow the culture to fester, because the older kids just indoctrinate the younger ones by example. I'm not sure there's a good answer to this.
The best approach that I can think of is a crackdown on _bullying_, but this requires a lot of effort by a lot of capable teachers, as mentioned above. It's an imperfect solution, but would probably help somewhat.
Violence happens up here all right; it's just knifings more often than shootings, as we have a scarcity of guns (thank goodness, IMO).
I survived elementary school and high school by making friends with the teachers. Most of them were nice people. I avoided elementary school recess by going to the office and helping with filing/checking purchase orders/etc. (which I find enjoyable and relaxing, twisted soul that I am O:)).
This doesn't address the problems that I raised - thermal expansion/contraction difficulties and electromigration. While you do mention the limits imposed by the way the threshold voltage changes with temperature, the other two factors mentioned may be what limits your ability to cool and overclock chips.
An integrated circuit chip is a chunk of silicon with aluminum wires on top of it embedded in a thick layer of silicon dioxide. These three materials have different coefficients of thermal expansion. As you cool them, they will change sizes at different rates, causing stress in the chip. Cool them enough, and your chip will break. I'm told that the temperature at which this occurs is lower that I had originally assumed, but it *will* happen. Possibly with liquid nitrogen (though some successful liquid-nitrogen-cooled systems have been built), and almost certainly if you do something silly like cool a chip with liquid helium. Likewise, the card on which the chip sits is glass fibers in an organic resin with plates and traces of copper. These materials all expand at different rates. You also have a lead alloy connecting the pins of the chip to the copper traces on the board. Size changes due to temperature will put stress on these solder joints - and size changes in the plastic casing that holds the pins and integrated circuit chip will put a lot of shear stress on these weakened solder connections.
So, this is not something that can safely be ignored forever.
Likewise, electromigration will seriously reduce the lifetime of any chip being run significantly faster than its standard clock speed at room temperature. Electromigration is the tendency of metal atoms in wire traces on a chip to flow along with the direction of current. The higher the level of current, the greater this effect. If a chip is operated with too-high current levels for too long, enough metal atoms flow that the trace becomes brittle enough to snap under mechanical and thermal stresses, or develops a gap, or gets thin enough that resistive heating melts the trace or increases its resistance enough that it can't transmit signals properly. Electromigration effects were a common cause of failure in older chips. To compensate for this, chip designs nowadays specify maximum currents for given sizes of traces and are careful not to exceed them. However, overclocking _does_ exceed them. In order to clock a chip more quickly, you have to charge and discharge the parasitic capacitances within it more quickly - which is done by increasing the amount of current flowing through transistors in their "on" states. Conventionally, this is done by cranking up the core voltage. Cooling does this by lowering the threshold voltage and fiddling with a few other transistor behavior parameters. In both cases, for a chip clocked n times more quickly, you have n times the amount of current flowing through the same traces. Clock a chip at twice its normal speed, and you have twice the current through the traces - and a chip that will burn out far sooner due to electromigration. Copper is more resistant to electromigration than aluminum, but the metal traces in copper chips are correspondingly thinner than the metal traces in aluminum chips. This is why copper was adopted; the aluminum traces had to be made wide enough that bulk and parasitic capacitances were becoming real problems. Modern chips - copper or aluminum based - are designed to run just below the threshold for electromigration damage. Overclocking them to the degree being done with these cooled setups _will_ push them over the threshold.
OTOH, if you don't care if the chip burns out in a year or two, go for it. Just be aware of the limits and side effects.
Full 64-bit would be nice, even. However, even 32-bit is a kludge with the way it's currently implemented.
The floating-point/MMX registers on an x86 are 64-bit. I'm not sure how wide the SSE registers are, but I'd guess 128 off-hand. The general-purpose registers have been 32-bit since the 386, and are accessed using a hack on top of the old 16-bit access method (put 0x66 before the opcode for your instruction to make it work on 32-bit operands instead of 16-bit).
There are many fixes that could be made to the x86 register set and instruction set, but the best fix of all would be a complete redesign to a new system. However, Intel can't do that without breaking compatibility with its established software base. Breaking compatibility would leave them at a disadvantage to people like Apple, who already have a more cleanly designed processor with an installed software base. What they're actually doing is hedging their bets and giving the Merced the ability to emulate x86 operating modes. However, this will be done at the cost of either more silicon on the Merced, a slower chip, or both.
I use x86 machines, and for the time being they're competative performance-wise, but it's just a matter of time before the architecture runs into the ground, because it's a mess of patches on top of patches that wasn't built to be extensible. Intel's best bet is to phase out x86 support once there's a significant amount of Merced-native software available. Whether it succeeds in competing with the G4 and whatever Sun, DEC^H^H^HCompaq, and others offer remains to be seen. HP seems less than enthusiastic about it, and they helped Intel design the thing.
The author of the article took care to insulate everything, including the pipes, to prevent this from happening. Look carefully at the pictures of the finished system and you'll see the insulation.
Yes. In fact, they operate more efficiently, which is why he could boost the clock rate. This is also why processors fail at higher temperatures; they work _less_ well as the temperature increases. If I understand correctly the transistor threshold voltage and a few other parameters vary with temperature. I'd have to dig out my old electronics textbook to give you a detailed explanation, but the gist of it is that the transistors end up passing more current, which decreases switching time.
Limits to clocking with this kind of scheme are chip failure due to electromigration (the traces in the chip can only take so much current), and chip or module failure due to cracking caused by different rates of thermal expansion in the materials used.
He'll run into problems when he tries to reach -80, though. Sooner or later traces in the chips or on the chip modules will crack due to differing rates of thermal expansion in the materials used. An interesting read nonetheless, though.
Why not use the standard Spec set of benchmarks? IIRC there were several that assessed web/network serving performance, which seems to be an issue with some of the posters, and the straight processor performance figures should still give some idea of the amount of overhead that the OS takes up.
AFAICT, this is intended as a neat hardware project for people who like building their own hardware. See my previous message for other possible uses.
Actually, this would probably be more vulnerable to noise, as the board won't be very well shielded and the parallel cable *certainly* won't be.
AFAICT, this is a kit intended for people who like hardware projects, and that's about it. I suppose that you could build a portable MP3 player with the parts if you wanted to (if you also bought a microcontroller chip and maybe a flash card reader). Hardware MP3 decoding would be useful on sound cards if it isn't there already, but that would be integrated into the sound card ASIC instead of added as discrete components like this.
This looks like a build-your-own-MP3-decoder-board kit. Neat, if you're into building hardware yourself (I was a while back). It looks like they have moderately general-purpose chips for this and boards with sample layouts that you can buy if you don't feel like designing your own.