You missed my pet SW quality issue: Modular Testing. Simply put, it's very difficult to test a module throughly when it's part of a large program. Getting the program to take a submodule through its entire range of functionality is difficult enough. It generally impossible to try every combination of operating modes for all of the program's modules. The way around this is to test test the modules stand-alone (in addition to full-program tests).
I am an electrical engineer working in the networking field. The group that I head just released for fabrication a large (~100 million transistors) ASIC (Application Specific Integrated Circuit). There is no way that a device of this size could have been adequately tested by simulating the whole chip. Standard practice in the chip industry is to break the code down into relatively small modules with simple, easily understood, and easily verified interfaces. This usually allows us to get 100% test coverage. It's not a perfect system and bugs do occasionally slip through. However, the relative quality of chips compared to most software products I work with is very high.
For a more extreme example, consider the Space Shuttle. AFAIK, it's the only launcher ever to have put humans into space without a single full-up system test. Would you want to be sitting in the cabin of the first shuttle if you didn't have the knowledge that every component had been tested as throroughly as possible?
I'm not suggesting that all software be developed as is done in the space program or even chip development. Basically, it comes down to a tradoff between reliabity and development cost. However, it seems to me that a lot of the software problems we live with every day are a result of failure of SW development groups to address the problems and just plain laziness (as opposed to any meaningful tradeoff analysis).
Relatively few triangles (almost all of which are flat shaded), no textures, etc. As a CG engineer, I find it difficult enough to watch on analog TV. Watching sharper artifacts isn't my idea of a great time in front of the tube.
In any of the theories I've ever seen of how the
Egyptians raised obelisks, pyramids, etc. I've
never seen anyone mention animal power. They
always seem to assume that multitudes of humans
did all the work. It seems to me that animals
would likely have done most of the heavy work.
Surely cattle, oxen, or camels could have been
used, at least. Perhaps elephants were used,
though Egypt is (in modern times anyway) a bit far
from elephant territory. Hippos would have likely
been plentiful and are very powerful but I don't
know how possible it is to train them for labor.
Sometimes I get the feeling that the assumption of
hundreds of people pulling on ropes got started in
the film "The Ten Commandments" and no one ever
went back to challange it.
So what's the deal? Is there some good reason for
ruling out animal power?
You're an ancient Egyptian whose job it is to
raise an obelisk. You've built a 100+ foot
derrick capable of supporting 50+ tons (not an
easy feat in itself). You've arranged a bunch of
pulleys and a lot of rope to get a large
mechanical advantage (at least 100:1). You bring
the rope out through a final pulley anchored to
the ground. Now you have to decide how to pull on
the rope. Do you get a bunch of guys to grab onto
the rope and start pulling or do you rig up a huge
kite and hope:
a) the wind starts blowing
b) you can control it
c) it produces enough lift.
Much is made in the aptly named pyramidiots web
site about the fact that they raised their test
obelisk in 25 seconds. If the ancient Egyptians
were engaged in obelisk raising races, then maybe
they would have chosen the kite method.
Otherwise, it's a really dumb theory.
The NEC is not the only building code for
electrical wiring. Many state and local
governments have their own codes (though based
on the NEC). I have done a lot of house wiring
in my time in various jobs. My own home is the
only one I've seen with aluminum in the branch
circuits though I grant that it is often used for
the mains. Here's a link to support my statement:
My point about current has to do with the
rating of actual circuits. I've often heard
it stated that a 100A circuit was more dangerous
(electocution-wise) than a 20A circuit of the
same votage which is false. Looking back at your
original post, I see that you didn't actually
write that. Sorry for mis-reading.
Aluminum wire is not just fine. It's not just a matter of sizing it properly. Many house fires have been caused by its use. To my
knowledge, it is now banned by most local building codes for use within homes. The problem is that it deforms more easily when
heated than does copper. When the wire heats up, it extrudes somwhat within its connector (such as a wall socket). After it cools,
it leaves a tiny gap which quickly fills with aluminum oxide. After many tempurature cycles, the resistance of the oxide causes even
more heating. Eventually it gets hot enough to cause a fire. My house was built in the late 60's and contains aluminum wire. I pay
close attention to electrical problems. About twice a year, I have to tighten a connection. It's scary.
As to the relative lethality of the current and voltage ratings of power circuits, I've seen this fallacy before. It amazes me how
many people believe this (including many who should know better).
Yes, current is what kills. But the amount of current required to kill is measured in milliamps. The minimum current rating of any
residential power circuit I know of is 10 amps. Unless its of the ground-fault interruption type, no circuit breaker is going to pop
if you're being electrocuted. Even a ground-fault interrupter won't help if you touch both the "hot" and "neutral" wires
simultaneously.
The lethality of a circuit is generally based on its voltage rating. The higher the voltage, the more likely it is to drive enough
current into ones body to kill. For example, a 12 volt car battery can easily source more than 1000 amps into a short ciruit and 500
amps into a reasonable load. I've touched both terminals of car batteries many times and usually don't feel it at all. The few times
I've been shocked by 120VAC have gotten my attention instantly!
The reason it's taken so long to get a dual
processor Athlon and no larger configurations
have appeared is that the Athlon's FSB makes it
difficult to do.
Unlike the intel processors, the Athlon connects
to the Northbridge via a point-to-point connection
(i.e. not really a "bus" at all). The interface
is named (inacurately) the "Socket 2000 bus" or
"S2K bus" for short.
The problems with S2K for SMP are several:
1) The Northbridge has to have a complete set of
data and address signals for each processer.
This is a lot of pins; especially if you're
talking about more than 2 proccessors.
2) Even if you had the pins, the drivers for S2K
need to be quite powerful (~50 mA per signal to
ground). So you need to add a lot more ground
pins to handle the current and the power
dissipated by the drivers starts to be a
problem.
3) The biggest issue is the manner in which SMP
cache coherency is managed. Because there is
no shared bus, the northbridge must "probe"
all of the other processors whenever one of
them changes the state of a cache line (read,
write, evict, etc.). Now, the bandwidth of the
interface used to probe an Athlon is equal to
that of its output address bus. So, a dual
processor system is relatively easily handled
by sending all of the addresses issued by one
processor to the other. Going beyond two
processors with this scheme fails due to
poll bandwidth limitations. Adding I/O
bandwith to the mix only makes things worse.
Problems #1 and #2 above are solvable by brute
force (e.g. big packages, multiple chips, heatsinks, etc.).
Problem #3 is much harder to solve. The only way
I know to do it is have the Northbridge maintain a
separate set cache tags that duplicates the tags
in all of the processors. That way, a processor
needs only be probed when the state of a cache
line that it actually holds is changed. It's
doable but makes for a very large chip that's
difficult to verify. That's how Hotrail was
implementing their 8-way Athlon server chipset.
It's a real shame that they decided to drop it.
I suspect that part of Hotrail's decision was
based on AMD releasing their plans for
Sledgehammer and the "LDT" bus (which has many
advantages over S2K).
Slashdot Mirror
You missed my pet SW quality issue: Modular Testing. Simply put, it's very difficult to test a module throughly when it's part of a large program. Getting the program to take a submodule through its entire range of functionality is difficult enough. It generally impossible to try every combination of operating modes for all of the program's modules. The way around this is to test test the modules stand-alone (in addition to full-program tests).
I am an electrical engineer working in the networking field. The group that I head just released for fabrication a large (~100 million transistors) ASIC (Application Specific Integrated Circuit). There is no way that a device of this size could have been adequately tested by simulating the whole chip. Standard practice in the chip industry is to break the code down into relatively small modules with simple, easily understood, and easily verified interfaces. This usually allows us to get 100% test coverage. It's not a perfect system and bugs do occasionally slip through. However, the relative quality of chips compared to most software products I work with is very high.
For a more extreme example, consider the Space Shuttle. AFAIK, it's the only launcher ever to have put humans into space without a single full-up system test. Would you want to be sitting in the cabin of the first shuttle if you didn't have the knowledge that every component had been tested as throroughly as possible?
I'm not suggesting that all software be developed as is done in the space program or even chip development. Basically, it comes down to a tradoff between reliabity and development cost. However, it seems to me that a lot of the software problems we live with every day are a result of failure of SW development groups to address the problems and just plain laziness (as opposed to any meaningful tradeoff analysis).
SCSG
Relatively few triangles (almost all of which
are flat shaded), no textures, etc. As a CG
engineer, I find it difficult enough to watch
on analog TV. Watching sharper artifacts
isn't my idea of a great time in front of the
tube.
SCSG
Can you imagine Beowulf cluster of those things?
In any of the theories I've ever seen of how the
Egyptians raised obelisks, pyramids, etc. I've
never seen anyone mention animal power. They
always seem to assume that multitudes of humans
did all the work. It seems to me that animals
would likely have done most of the heavy work.
Surely cattle, oxen, or camels could have been
used, at least. Perhaps elephants were used,
though Egypt is (in modern times anyway) a bit far
from elephant territory. Hippos would have likely
been plentiful and are very powerful but I don't
know how possible it is to train them for labor.
Sometimes I get the feeling that the assumption of
hundreds of people pulling on ropes got started in
the film "The Ten Commandments" and no one ever
went back to challange it.
So what's the deal? Is there some good reason for
ruling out animal power?
You're an ancient Egyptian whose job it is to
raise an obelisk. You've built a 100+ foot
derrick capable of supporting 50+ tons (not an
easy feat in itself). You've arranged a bunch of
pulleys and a lot of rope to get a large
mechanical advantage (at least 100:1). You bring
the rope out through a final pulley anchored to
the ground. Now you have to decide how to pull on
the rope. Do you get a bunch of guys to grab onto
the rope and start pulling or do you rig up a huge
kite and hope:
a) the wind starts blowing
b) you can control it
c) it produces enough lift.
Much is made in the aptly named pyramidiots web
site about the fact that they raised their test
obelisk in 25 seconds. If the ancient Egyptians
were engaged in obelisk raising races, then maybe
they would have chosen the kite method.
Otherwise, it's a really dumb theory.
http://www.onlineathens.com/stories/121299/new_121 2990009.shtml
My point about current has to do with the rating of actual circuits. I've often heard it stated that a 100A circuit was more dangerous (electocution-wise) than a 20A circuit of the same votage which is false. Looking back at your original post, I see that you didn't actually write that. Sorry for mis-reading.
scsg
Aluminum wire is not just fine. It's not just a matter of sizing it properly. Many house fires have been caused by its use. To my knowledge, it is now banned by most local building codes for use within homes. The problem is that it deforms more easily when heated than does copper. When the wire heats up, it extrudes somwhat within its connector (such as a wall socket). After it cools, it leaves a tiny gap which quickly fills with aluminum oxide. After many tempurature cycles, the resistance of the oxide causes even more heating. Eventually it gets hot enough to cause a fire. My house was built in the late 60's and contains aluminum wire. I pay close attention to electrical problems. About twice a year, I have to tighten a connection. It's scary.
As to the relative lethality of the current and voltage ratings of power circuits, I've seen this fallacy before. It amazes me how many people believe this (including many who should know better).
Yes, current is what kills. But the amount of current required to kill is measured in milliamps. The minimum current rating of any residential power circuit I know of is 10 amps. Unless its of the ground-fault interruption type, no circuit breaker is going to pop if you're being electrocuted. Even a ground-fault interrupter won't help if you touch both the "hot" and "neutral" wires simultaneously.
The lethality of a circuit is generally based on its voltage rating. The higher the voltage, the more likely it is to drive enough current into ones body to kill. For example, a 12 volt car battery can easily source more than 1000 amps into a short ciruit and 500 amps into a reasonable load. I've touched both terminals of car batteries many times and usually don't feel it at all. The few times I've been shocked by 120VAC have gotten my attention instantly!
scsg
The reason it's taken so long to get a dual
processor Athlon and no larger configurations
have appeared is that the Athlon's FSB makes it
difficult to do.
Unlike the intel processors, the Athlon connects
to the Northbridge via a point-to-point connection
(i.e. not really a "bus" at all). The interface
is named (inacurately) the "Socket 2000 bus" or
"S2K bus" for short.
The problems with S2K for SMP are several:
1) The Northbridge has to have a complete set of
data and address signals for each processer.
This is a lot of pins; especially if you're
talking about more than 2 proccessors.
2) Even if you had the pins, the drivers for S2K
need to be quite powerful (~50 mA per signal to
ground). So you need to add a lot more ground
pins to handle the current and the power
dissipated by the drivers starts to be a
problem.
3) The biggest issue is the manner in which SMP
cache coherency is managed. Because there is
no shared bus, the northbridge must "probe"
all of the other processors whenever one of
them changes the state of a cache line (read,
write, evict, etc.). Now, the bandwidth of the
interface used to probe an Athlon is equal to
that of its output address bus. So, a dual
processor system is relatively easily handled
by sending all of the addresses issued by one
processor to the other. Going beyond two
processors with this scheme fails due to
poll bandwidth limitations. Adding I/O
bandwith to the mix only makes things worse.
Problems #1 and #2 above are solvable by brute
force (e.g. big packages, multiple chips, heatsinks, etc.).
Problem #3 is much harder to solve. The only way
I know to do it is have the Northbridge maintain a
separate set cache tags that duplicates the tags
in all of the processors. That way, a processor
needs only be probed when the state of a cache
line that it actually holds is changed. It's
doable but makes for a very large chip that's
difficult to verify. That's how Hotrail was
implementing their 8-way Athlon server chipset.
It's a real shame that they decided to drop it.
I suspect that part of Hotrail's decision was
based on AMD releasing their plans for
Sledgehammer and the "LDT" bus (which has many
advantages over S2K).