Keep in mind that the courts have universially held that people have the right to work a job they are qualified for.
Unless they have been satisfactorily rewarded for not working. Which is for the judge to decide after listening to the former employer's $300/hour lawyers.
In otherwords non-competes are the easiest things to break in court.
Thereby squandering thousands of dollars and many hours of your resources. And proving to future employers that (1) you don't care one whit about honoring contracts that you sign--that you are a cowboy who sells out in a heartbeat, and (2) that you don't have the business sense to negotiate a reasonable contract in the first place.
Well, as questionable an idea this project might seem, it won't kill you if the PSU is shorted. You see, a computer's case is grounded,...
However if you plumb it with plastic tubing, the water can behave as a wire, and carry the dangerous voltage out to your pump/reservoir/radiator. Even metal tubing with a lot of oxide/crud built up on the walls could carry current outside.
Keep in mind that the reason why microwaves heat things up is that they prey on a *specific* resonance frequency for water molecules.
Sorry to burst your bubble, but that's only a myth. You can actually warm water with a wide range of frequencies: every water molecule has a built-in electric polarization, and therefore flips back and forth as the ambient electric field changes. As it flips, there's a little drag from nearby molecules, and energy is dissipated as heat. The key to getting lots of heat is to use an intense field--microwave oven use on the order of a hundred thousand volts per meter!
The wonderful (not) thing about the DMCA is that anything can be considered a protection system, because protection is in the eye of the content provider. The only way you can tell if your actions are unlawful circumvention are to try them and see if you get sent to jail.
That's just the university covering its ass. They want to make sure the study is politically correct, and that you get signed release forms from the subjects. It gives them plausible deniability. (Cue Dean of Education saying "Well, I have no memory of that incident.";-)
For your purposes, just make sure to tell the subjects that participation is purely voluntary, and don't publicize personally-identifying information (or record it in the first place if you can help it).
0xff is the value for a string of all 1's and 0x00 is the value for a string of all 0's, but harddrives actually record entirely different bit sequences.
Possibly even variable-length sequences, if a run-length-limited code is used. In which case writing random data a few dozen times could easily leave a big chunk of slack space untouched. Erase/write simply isn't good enough.
The only way to be sure is to nuke the hard drive from orbit.;-)
Are you suggesting that environmentalists actually believe this? That some freaky alien ship is going to come to Earth and kill us all if the whales disappear?
Yeah, that's just silly.
Everybody knows that alien energy beams aren't for vaporizing oceans: they're for anal probing. If species loss continues at its current rate, in 30 years nobody will be able to sit down. The ironic thing is that increased vaseline use will probably just accelerate the species loss...
With the sniper stuff in Washington D.C. they were talking about taking 'barrel prints' of guns out of the factory, and the NRA opposed. Why, because they thought it was one step closer to taking the guns away!
During the sniper attacks, cops were harassing certain gun owners, trying to get a confession for the attacks. How did they know which people to harass? Records from gun purchase background checks that were supposed to have been destroyed after the purchase was approved. The gun control fascists turned it into a registration system, just like the NRA said would happen.
Or consider the case of Diane Feinstein, a politician who aggressively supports gun control. But only for the lower castes: she herself got a gun permit because she wasn't safe without it.
Understand this: the gun control freaks don't care about the truth, they don't care about safety, and they don't care about the law. They're after power. When they say "think of the children", they mean "think about how we can crank up the law enforcement budgets when people can't defend their kids".
So, yes, I would consider the NRA extreme, because they aren't thinking about what they are saying.
They think about it a great deal. If you read the NRA propaganda, you'll see that they put great emphasis on training and safety, and they don't whitewash the fact that bad things sometimes happen with guns. What they say is that, in their opinion, the good results outweigh the bad.
Compare that to most of the gun control organizations. They have nothing but bad things to say about guns. Give them any scenario involving a gun, and the answer will always be that the gun makes it worse. Liquor store owner in a rough area of town? They'll say the gun will provoke a robber to even greater crimes. Gun at home? Same story, it'll never stop a home invasion, just cause accidental shootings of the kiddies.
The whole client/server concept is so '01. We abandoned it in favor of something we call "(n-1) tier". No clients at all, just multiple levels of server. We don't even expose an interface, most of the time.
Gee, maybe all that's why people are going to things like multiple cores on one die, hyperthreading, etc. Programming-wise, these present the same interface as multiple physical CPUs, but they also ameliorate many of the problems you mention...
Hyperthreading doesn't gain a lot. (Where "a lot" == capable of improving performance by factor of 10.) Multi-core dice run out of steam at 2-4 cores/die. (Maybe it's 8-16. The point is it'll never get to 256.) And multi-core dice will still have substantial latency problems. Multi-chip modules are better than pins-and-traces, but not by a lot.
...everything you're presenting as a "killer" for multithreading is even worse for your multi-process model.
I was describing a multi-process system that ran in batch mode. To the extent that you can fit your problem into that framework, it makes comm latency much less important.
Getting rather far afield here, aren't you?
Huh? Describe the problem -> describe a solution.
Most serious programs outside of the scientific community are I/O bound anyway and the whole point of multithreading is to increase parallelism.
By "I/O bound" I mean "I/O bound at the ping rate". Which means "terribly slow".
You're forgetting that an operation's effect on performance is a product of its cost and frequency.
To repeat, I did not say it was important or unimportant, I said it was not identically zero.
What about those that can't?
They'll see no benefits. However very few problem spaces are truly sequential, especially if you are willing to trade latency for throughput.
That's a lot of applications, including important ones like databases which must preserve operation ordering across however many threads/processes/nodes are in use.
Indeed. Pipelining the algorithms will take considerable cleverness.
I wonder if databases will be that hard, though. Good ones already provide on-line replication and failover, multi-version concurrency, and transactions that automatically roll-back if a collision is detected.
You can't just point to some exceptional cases that are amenable to a particular approach, and then wave your hands about the others. Well, you can - you just did - but it doesn't convince anyone.
Did I say that all programs will be easily adaptable to that approach? No. I said that those programs that do not adapt will tend to have poor performance.
Since you're practically an AC I can't be sure, but odds are pretty good that I know more about what the Linux kernel is doing and excellent that I know more about what kernels in general are doing.
Ah, I state an inarguable and easily-verified fact, you talk about how much more you know. Smooth move, Ex-Lax.
Your appeal to (anonymous) authority won't get you anywhere.
Look, Mr. Smarty Pants, I don't have the time to write a frickin tutorial on things that are common knowledge, where the reader can find enlightenment at their nearest search engine nearly as fast I can write an essay on the topic.
But since you can't be arsed to do it, here's a link to search Google for "Linux per-cpu". See? Tens of thousands of hits. If you add "allocator" to the search criteria, this is the first hit. It assumes background knowledge, but should make sense.
The real point that we started with is your claim that any multithreaded application will "suck". That statement only has meaning relative to other approaches that accomplish the same goals.
Ladies and gentlemen, we have just lost cabin pressure.
The statement was "If you have a few million tasks to do, pretty much any threading system is going to suck."
The context makes it clear that "tasks" means "things that make the threads talk to each other". And it will, indeed, truly and royally suck.
In the future, multi-CPU machines will become more common, not less, and learning to use them efficiently will also become more important. Within the box, multithreading will perform better than alternatives, even if there's message passing going on between boxes.
That is identically the point I was trying to make. However, as I pointed out, core clock speeds are getting faster and faster. A 200 GHz clock speed will be practical within perhaps 5-10 years. That's an instruction cycle time of 5 picoseconds.
As I also pointed out, the minimum time to send a round-trip signal from one CPU to another is determined by the speed of light. Suppose you have two processors that are 6 centimeters apart. The round-trip time for light is 200 picoseconds. Electrical signals are about half that fast, or 400 picoseconds. Therefore the act of merely acquiring an inter-thread lock will waste 80 clock cycles waiting for the atomic lock instruction to execute, assuming there is no contention. After that the thread will perform memory reads on shared data. Each read from a cold cache line will have an additional 80 wait states while the data is snooped from the hot cache. Complex activity can easily touch 50 cache lines, which is 4,000 clock cycles.
And that's the best case scenario where the programmer has flawlessly layed out the variables in memory to minimize cache transfers. In the real world it is appalling easy to cause cache ping-pong, where two processes try to use the same cache line, and it keeps "bouncing" back and forth between multiple CPUs.
Oh, and that's assuming a zero-overhead protocol for coherency. Realistically you should expect a few hundred picoseconds or so of additional round-trip latency.
Finally, these numbers are for one node that contains a few CPUs. Going between nodes will be vastly worse. A four nanosecond cable (i.e., a one foot cable) between nodes means about 1000 wait states to acquire a lock. A two microsecond RTT (e.g., Myrinet) means 400,000 wait states.
The fact is that whatever's happening down below, at the programming-model level it's still more efficient to have multiple tasks coordinate by running in the same address space than by having them spend all their time packing and unpacking messages.
A shared memory space implies a coherency mechanism. A coherency mechanism implies round-trip messages. ("I need this, can I have it?"...wait... "Yes, you can have it, here it is."...wait...) Dependence on round-trip latency implies that the program is I/O bound.
The lower-level message-passing works precisely because it's very task-specific and carefully optimized to do particular things, but that all falls down when the messages have to be manipulated by the very same processors you were hoping to use for your real work.
Obviously the communication/networking hardware will have to be built directly into the CPU core. That's why I said HyperTransport is the writing on the wall. These CPUs will also have special instructions for message passing. Incoming messages will be stored in priority FIFOs.
Yes, yes, using parallelism to mask latency. Yawn. Irrelevant.
The I/O will be (at least) a thousand times slower than the core. Code that isn't batching up data 1,000 clock cycles in advance is pissing away CPU capability. Code that uses round-trip synchronization is benchmarking the I/O latency.
The thing is, I/O latency isn't improvable. You can only put chips so close together, and the speed of light is sort of non-negotiable. CPU speed, however, is improvable. So the ratio of I/O latency to clock period is going to keep increasing. Code that doesn't batch up data will not run any faster on the machines of tomorrow.
If context switches aren't all that bad, why were you bitching about context switching in multithreaded applications?
I wasn't bitching about it. I was correcting the misstatement that its influence on performance was zero.
I already referred to regularly decomposable applications with high compute-to-communicate ratios, and that's exactly what you're talking about. Yes, what you say is true for some applications, but does it work in general?
I was pointing out that all applications that want maximum performance will be designed that way. They will do whatever it takes to deserialize the algorithms. If several CPUs need to know the results of a simple calculation, they will each calculate it themselves, because calculation it in one place and distributing the results would take a thousand times longer.
Take a look at what the Linux kernel is doing sometime. Everything is moving to per-processor implementations. Each processors gets its own memory allocator, thread/process queue, interrupt handlers, and so forth. Inter-CPU locks and shared memory are avoided like a plague. They know that the I/O-to-core clock ratio is bad, and it's going to get much, much worse.
Let me preface this by saying that everything depends on the workload. Pretty much every approach is optimal for somebody's real-world workload.
You really will context-switch yourself to death that way, as every occasion where you need to coordinate between processes generates at least one IPC and every IPC generates at least one context switch (usually two or more)...and those are complete process/address-space switches, not relatively lightweight thread switches.
On a reasonable OS on a single-CPU machine, it isn't significantly worse than multi-threading. (Especially if the multi-threading system is using high-performance kernel threads.) On a multi-CPU machine, which I was referring to, the difference relative to multithreading is miniscule: a couple of system calls.
Writing software to run efficiently on even the best-provisioned loosely-coupled system is even more difficult than writing a good multithreaded program.
I must admit that I'm looking toward the future. I'm interested in program architectures that will saturate the machines of ten or twenty years in the future. A one-CPU future-generation system will have worse latency problems than a current-generation networked system. The future of high-performance computing is message passing.
Look at it this way: the best current transistors can switch at a rate of 200 GHz. That's a clock period of 5 picoseconds. These transistors will be in mass production within 20 years. (Possibly within a few years, but let's be pessimistic.) An electrical signal can travel only about 2 millimeters in that period of time. That means your arithmetic-logic unit cannot even fetch an operand from the L1 cache in a single clock cycle. These processors will use asynchronous message-passing logic at the very core, and farther out the system will be entirely based on messages. HyperTransport is the writing on the wall.
Also consider current-generation transactional systems. The request-producer doesn't have to block waiting for the first response: it can keep queueing requests. If the scheduler is good, this amounts to batching up a bunch of requests, processing them in one fell swoop, then sending the responses in one fell swoop. Of course whether this actually happens depends on the workload and the OS.
Incidentally, I'm typing this on a Unix machine that runs the graphics subsystem in a separate process. Every screen update requires at least one context switch. Does it suck? Not at all. The X11 protocol allows requests to be batched up and handled all at once. Whether the application draws a single character or renders a 3-D scene doesn't have much influence on the context switch overhead. Again, the appropriate solution depends on the workload, and the proper messaging abstraction can make separate processes quite practical. And if your compute jobs cannot possibly fit in a single machine, you have no choice but to use multiple processes.
Using separate processes instead of threads on a single machine might allow your other processes to stay alive if one dies, but your application will almost certainly be just as dead.
Not at all. What about Monte Carlo simulations? Losing the occassional random process is irrelevant. What about artificial intelligences running on really big machines? Getting erroneous answers from subsystems, or not getting timely answers at all, will be a fact of a-life. Being able to terminate processes at-will will be critical to building reliable AIs. What about graphics systems? Losing a frame or a part therof is nothing compared to a full crash. What about speech reconition systems? A momentary interruption for one user is nothing compared to a total disruption of all users.
Even in the present day, there are plenty of practical workloads that can withstand a subsystem dying, but would rather not see the whole system die hard. If the system is built on a foundation of multithreading, the only failure mode is a total crash.
Handling interthread scheduling such as pthread_cont_wait() and pthread_cond_signal() should be more efficiently handled by an user space scheduler and benefit from the NGTL model.
Don't the new futexes solve that? The common case of no-contention is handled entirely in userland via atomic operations in a shared memory page. If there is contention, the waiter calls the kernel to yield the processor, and the kernel wakes it up when the lock is released.
So you get the best of both worlds: the common case is handled with no overhead--not even a single system call--while scheduling is handled by an omniscient 1:1 kernel scheduler.
Meta comment: Why the fuck does Slash strip out HTML non-breaking space character entities? More proof that the/. operators don't care about content, they just want to milk the site for advertising money.
This is only a factor with a poor multithreaded design.
Wrong. Every context switch burns hundreds, if not tens of thousands, of clock cycles. As the parent comment said, changing from single threading to multithreading on a uniprocessor system necessarily reduces performance. How bad it does depend on the program design, but there is always a slowdown.
By contrast, single-threaded programs always fail to take advantage of multiple processors, no matter how well they're designed otherwise.
Wrong again. It's trivial to run multiple copies of a single-threaded program on the different CPUs, and let them interact over IPC. One benefit is that this approach scales trivially to large numbers of networked processors. (How bad the latency hurts depends on the network and the workload, of course.) Another benefit is that catastrophic failure of one process does not necessarily corrupt the state of another process. (While one thread crashing is almost certain to bring down an entire multi-threaded program.)
I suspect the 1%/1000 hours rate is very conservative. I personally wouldn't worry about putting them in an entertainment or convenience system, but I'd be leery about important devices.
Here's a link to Vishay's solid aluminum capacitors. They're apparently constructed like water-based electrolytics, but with a solid polymer instead of water. ESR is good: 10 milliohm. Reliability is good: 200,000 hours at 65 deg. C. Tempco is awesome: -5%/+10% value change from -55 to +105 deg. C. Major downside is that they hate excessive inrush current. I think they're also a bit pricey.
But if the GPL module is only useful as an interface to the secret, proprietary code, and does a lot of secret, mysterious things that no one knows how to use, courts would probably treat the whole thing as one work.
Nah, copyright doesn't care whether something is useful, only whether it is creative and tangible. You're perfectly free to create GPLed works that are totally worthless. The questions to as are:
1. Is the proprietary part clearly separated from the GPL part? If you cannot tell where one ends and the other begins (e.g., static linking), they are a single work, and thus the result is covered by the GPL. If they are separate files in a filesystem, they can have different licenses.
2. Does the proprietary part contain any GPLed code? (E.g., kernel header files were included during compilation.) If the answer is "yes", then the GPL applies to it. On the other hand, if the proprietary module includes only original code, it can have any license you want.
So: if you want to have a binary driver, make sure every single line of it original work, and use it as a loadable module.
Sometimes the FCC regulates how directional you're allowed to be.
They may be getting around this using multipath. (I.e., using reflections from large metal objects to provide more signal. Do a web search for rake receiver.) That way they can use multiple weak beams, keep the peak brightness in any direction to a reasonable level, but deliver more coherent power to the receiver. You can do it in reverse to make more coherent power available during reception. CDMA does this to great effect.
The fellow you mention from Motorola (and his associates) don't understand the problems with tantalums: they are extremely reliable, and have far superior specifications than equivalent electrolytics, if you simply derate the maximum voltage by a factor of 2.
I'm looking at an AVX data sheet and it shows that 50% derating produces a factor of 0.006 decrease in failure rate.
But the base failure rate for the standard grade is 1% max per 1000 hours, which is huge. Assuming 10 capacitors per device, the factor of 0.006 from voltage derating, and a factor of 0.4 from temperature derating, that's a failure rate of 240 ppm/1000 hours. Not exactly a six sigma quality level. For one year of operation, that's a failure rate of 0.2%. For three years, 0.63% failure rate. For ten years, 2.1%. For 50 years, 10%.
So what does 0.2% per year mean? If the device is a line card, and the telephone switch has 10,000 cards, that's a failure every 18 days. That's often enough that you'd have to have a $100k/year employee on call 24x7. That's $1 of expense per capacitor. Not so cheap. I don't even want to think about the cost for devices that are geographically deployed, like electric meters and embedded controllers.
There's also the failure-mode issue. When they fail, tantalums blast their (electrically conductive) guts all over the inside of the enclosure. That's an appalling thing to have happen in an enclosure filled with $50k processor cards.
I stand by my opinion that tantalums are ungood. If you just want to screw the consumer, electrolytics give more screwage per dollar. If you need high-rel and can afford scheduled replacements, good-quality electrolytics. Otherwise, ceramics.
Have you seen the new solid aluminum caps? Better volumetric capacity than tantalums, ESR nearly as good as ceramics. I haven't bothered to look up the data sheets, but I'd imagine that aluminum oxide has a lower failure rate than tantalum oxide.
Quality costs money, and money is limited. If you spend all your money improving one thing, you don't make it much better, but you can't afford quality anywhere else, and so the overall results are poor. Once something is "pretty good", you don't keep spending on it. You stop and ask "What's the cheapest way to improve results?" and that tells you where you should be spending.
While it is true about tantalumns having a particularly impressive failure mechanism, once you remember not to reverse the polarity you don't have problems.
Yes, you do. When a standard tantalum develops a fault, the resultant heating makes the fault worse. The slightest pinhole defect tends to turn into a catastrophic failure. Even when properly installed, they occassionally fail in service.
The only problems - the max capacitance you can get isn't too good.
One more problem with ceramics: some regulators don't like the low ESR and oscillate! One of my colleagues found this out the hard way, and had to put a series resistor on his prototype. You don't normally have to worry about components being too good...
I think that's overly harsh on electrolytics. Like everything else, what you get depends on what you buy. You can buy from respected companies that have been making good caps for 20 years, or you can buy from whatever random Chinese company was cheapest this week. You can settle for any specs you can get, or you can insist on caps that are rated for 5000 hours of operation at 105 degrees Celcius (hotter than boiling water!).
There are also system design issues. You can push the caps to the very limit of their rated ripple current, or you can use more caps and share the current around.
Good god...how many of these things could be lurking about in automotive airbags, ABS systems, or in any sort of medical device?
For the most part, none.
Medical stuff routinely uses electrolytics. It doesn't have to be perfect, it just has to fail a lot less often than doctors and nurses.
Electrolytic capacitors have a fixed lifetime and are by nature unreliable.
They do not. The lifetime depends on the grade selected by the engineer, and how hard the design pushes the cap. A good cap used properly can last for many years of continuous service. That's good enough for many applications, even in safety-critical systems.
Where reliability is critical, Tantalum capacitors are used, but they're physically larger and more expensive.
You can't be serious! Tantalums are notoriusly flaky. Not only that, the usual failure mode is that the cap vanishes in a spectacular flash of purple fire. Every capacitor failure I've ever seen in computing equipment has been a tantalum. An engineer who used to work at Motorola told me that tantalums were banned from pager designs. At the time, Motorola would rather pay the premium for ceramic caps than risk tantalums.
Any -critical- system manufacturer(automotive safety systems, medical equipment, etc) that uses electrolytic capacitors should be shot.
It depends entirely on the service life that is needed, and the degree of redundancy you can afford. Satellites and airbags have to remain in service for decades without repair, so electrolytics are probably unacceptable. Medical equipment generally doesn't need such high reliability, and frequently uses electrolytics. (Seriously. Med equipment is regularly replaced, there's no point in making it more than a couple of orders of magnitude more reliable than physicians, and the critical stuff has spares sitting on shelves.) Telecom equipment can afford redundancy in almost everything, and so it's full of electrolytics.
Slashdot Mirror
Dumbass. ;-)
This "project" is just plain dangerous.
The wonderful (not) thing about the DMCA is that anything can be considered a protection system, because protection is in the eye of the content provider. The only way you can tell if your actions are unlawful circumvention are to try them and see if you get sent to jail.
For your purposes, just make sure to tell the subjects that participation is purely voluntary, and don't publicize personally-identifying information (or record it in the first place if you can help it).
The only way to be sure is to nuke the hard drive from orbit. ;-)
Everybody knows that alien energy beams aren't for vaporizing oceans: they're for anal probing. If species loss continues at its current rate, in 30 years nobody will be able to sit down. The ironic thing is that increased vaseline use will probably just accelerate the species loss...
Even better way: bill the user $20 a pop. People magically get more careful when it's their money that's being pissed away.
Or consider the case of Diane Feinstein, a politician who aggressively supports gun control. But only for the lower castes: she herself got a gun permit because she wasn't safe without it.
Understand this: the gun control freaks don't care about the truth, they don't care about safety, and they don't care about the law. They're after power. When they say "think of the children", they mean "think about how we can crank up the law enforcement budgets when people can't defend their kids".
They think about it a great deal. If you read the NRA propaganda, you'll see that they put great emphasis on training and safety, and they don't whitewash the fact that bad things sometimes happen with guns. What they say is that, in their opinion, the good results outweigh the bad.Compare that to most of the gun control organizations. They have nothing but bad things to say about guns. Give them any scenario involving a gun, and the answer will always be that the gun makes it worse. Liquor store owner in a rough area of town? They'll say the gun will provoke a robber to even greater crimes. Gun at home? Same story, it'll never stop a home invasion, just cause accidental shootings of the kiddies.
I wonder if databases will be that hard, though. Good ones already provide on-line replication and failover, multi-version concurrency, and transactions that automatically roll-back if a collision is detected.
Did I say that all programs will be easily adaptable to that approach? No. I said that those programs that do not adapt will tend to have poor performance. Ah, I state an inarguable and easily-verified fact, you talk about how much more you know. Smooth move, Ex-Lax. Look, Mr. Smarty Pants, I don't have the time to write a frickin tutorial on things that are common knowledge, where the reader can find enlightenment at their nearest search engine nearly as fast I can write an essay on the topic.But since you can't be arsed to do it, here's a link to search Google for "Linux per-cpu". See? Tens of thousands of hits. If you add "allocator" to the search criteria, this is the first hit. It assumes background knowledge, but should make sense.
Ladies and gentlemen, we have just lost cabin pressure.The statement was "If you have a few million tasks to do, pretty much any threading system is going to suck."
The context makes it clear that "tasks" means "things that make the threads talk to each other". And it will, indeed, truly and royally suck.
As I also pointed out, the minimum time to send a round-trip signal from one CPU to another is determined by the speed of light. Suppose you have two processors that are 6 centimeters apart. The round-trip time for light is 200 picoseconds. Electrical signals are about half that fast, or 400 picoseconds. Therefore the act of merely acquiring an inter-thread lock will waste 80 clock cycles waiting for the atomic lock instruction to execute, assuming there is no contention. After that the thread will perform memory reads on shared data. Each read from a cold cache line will have an additional 80 wait states while the data is snooped from the hot cache. Complex activity can easily touch 50 cache lines, which is 4,000 clock cycles.
And that's the best case scenario where the programmer has flawlessly layed out the variables in memory to minimize cache transfers. In the real world it is appalling easy to cause cache ping-pong, where two processes try to use the same cache line, and it keeps "bouncing" back and forth between multiple CPUs.
Oh, and that's assuming a zero-overhead protocol for coherency. Realistically you should expect a few hundred picoseconds or so of additional round-trip latency.
Finally, these numbers are for one node that contains a few CPUs. Going between nodes will be vastly worse. A four nanosecond cable (i.e., a one foot cable) between nodes means about 1000 wait states to acquire a lock. A two microsecond RTT (e.g., Myrinet) means 400,000 wait states.
A shared memory space implies a coherency mechanism. A coherency mechanism implies round-trip messages. ("I need this, can I have it?"The thing is, I/O latency isn't improvable. You can only put chips so close together, and the speed of light is sort of non-negotiable. CPU speed, however, is improvable. So the ratio of I/O latency to clock period is going to keep increasing. Code that doesn't batch up data will not run any faster on the machines of tomorrow.
I wasn't bitching about it. I was correcting the misstatement that its influence on performance was zero. I was pointing out that all applications that want maximum performance will be designed that way. They will do whatever it takes to deserialize the algorithms. If several CPUs need to know the results of a simple calculation, they will each calculate it themselves, because calculation it in one place and distributing the results would take a thousand times longer.Take a look at what the Linux kernel is doing sometime. Everything is moving to per-processor implementations. Each processors gets its own memory allocator, thread/process queue, interrupt handlers, and so forth. Inter-CPU locks and shared memory are avoided like a plague. They know that the I/O-to-core clock ratio is bad, and it's going to get much, much worse.
Look at it this way: the best current transistors can switch at a rate of 200 GHz. That's a clock period of 5 picoseconds. These transistors will be in mass production within 20 years. (Possibly within a few years, but let's be pessimistic.) An electrical signal can travel only about 2 millimeters in that period of time. That means your arithmetic-logic unit cannot even fetch an operand from the L1 cache in a single clock cycle. These processors will use asynchronous message-passing logic at the very core, and farther out the system will be entirely based on messages. HyperTransport is the writing on the wall.
Also consider current-generation transactional systems. The request-producer doesn't have to block waiting for the first response: it can keep queueing requests. If the scheduler is good, this amounts to batching up a bunch of requests, processing them in one fell swoop, then sending the responses in one fell swoop. Of course whether this actually happens depends on the workload and the OS.
Incidentally, I'm typing this on a Unix machine that runs the graphics subsystem in a separate process. Every screen update requires at least one context switch. Does it suck? Not at all. The X11 protocol allows requests to be batched up and handled all at once. Whether the application draws a single character or renders a 3-D scene doesn't have much influence on the context switch overhead. Again, the appropriate solution depends on the workload, and the proper messaging abstraction can make separate processes quite practical. And if your compute jobs cannot possibly fit in a single machine, you have no choice but to use multiple processes.
Not at all. What about Monte Carlo simulations? Losing the occassional random process is irrelevant. What about artificial intelligences running on really big machines? Getting erroneous answers from subsystems, or not getting timely answers at all, will be a fact of a-life. Being able to terminate processes at-will will be critical to building reliable AIs. What about graphics systems? Losing a frame or a part therof is nothing compared to a full crash. What about speech reconition systems? A momentary interruption for one user is nothing compared to a total disruption of all users.Even in the present day, there are plenty of practical workloads that can withstand a subsystem dying, but would rather not see the whole system die hard. If the system is built on a foundation of multithreading, the only failure mode is a total crash.
It isn't zero, though. If you have a few million tasks to do, pretty much any threading system is going to suck.
So you get the best of both worlds: the common case is handled with no overhead--not even a single system call--while scheduling is handled by an omniscient 1:1 kernel scheduler.
Meta comment: Why the fuck does Slash strip out HTML non-breaking space character entities? More proof that the /. operators don't care about content, they just want to milk the site for advertising money.
Here's a link to Vishay's solid aluminum capacitors. They're apparently constructed like water-based electrolytics, but with a solid polymer instead of water. ESR is good: 10 milliohm. Reliability is good: 200,000 hours at 65 deg. C. Tempco is awesome: -5%/+10% value change from -55 to +105 deg. C. Major downside is that they hate excessive inrush current. I think they're also a bit pricey.
1. Is the proprietary part clearly separated from the GPL part? If you cannot tell where one ends and the other begins (e.g., static linking), they are a single work, and thus the result is covered by the GPL. If they are separate files in a filesystem, they can have different licenses.
2. Does the proprietary part contain any GPLed code? (E.g., kernel header files were included during compilation.) If the answer is "yes", then the GPL applies to it. On the other hand, if the proprietary module includes only original code, it can have any license you want.
So: if you want to have a binary driver, make sure every single line of it original work, and use it as a loadable module.
Now I have to upgrade to phased-array chalk for my warchalking efforts!
But the base failure rate for the standard grade is 1% max per 1000 hours, which is huge. Assuming 10 capacitors per device, the factor of 0.006 from voltage derating, and a factor of 0.4 from temperature derating, that's a failure rate of 240 ppm/1000 hours. Not exactly a six sigma quality level. For one year of operation, that's a failure rate of 0.2%. For three years, 0.63% failure rate. For ten years, 2.1%. For 50 years, 10%.
So what does 0.2% per year mean? If the device is a line card, and the telephone switch has 10,000 cards, that's a failure every 18 days. That's often enough that you'd have to have a $100k/year employee on call 24x7. That's $1 of expense per capacitor. Not so cheap. I don't even want to think about the cost for devices that are geographically deployed, like electric meters and embedded controllers.
There's also the failure-mode issue. When they fail, tantalums blast their (electrically conductive) guts all over the inside of the enclosure. That's an appalling thing to have happen in an enclosure filled with $50k processor cards.
I stand by my opinion that tantalums are ungood. If you just want to screw the consumer, electrolytics give more screwage per dollar. If you need high-rel and can afford scheduled replacements, good-quality electrolytics. Otherwise, ceramics.
Have you seen the new solid aluminum caps? Better volumetric capacity than tantalums, ESR nearly as good as ceramics. I haven't bothered to look up the data sheets, but I'd imagine that aluminum oxide has a lower failure rate than tantalum oxide.
Quality costs money, and money is limited. If you spend all your money improving one thing, you don't make it much better, but you can't afford quality anywhere else, and so the overall results are poor. Once something is "pretty good", you don't keep spending on it. You stop and ask "What's the cheapest way to improve results?" and that tells you where you should be spending.
There are also system design issues. You can push the caps to the very limit of their rated ripple current, or you can use more caps and share the current around.
Medical stuff routinely uses electrolytics. It doesn't have to be perfect, it just has to fail a lot less often than doctors and nurses. They do not. The lifetime depends on the grade selected by the engineer, and how hard the design pushes the cap. A good cap used properly can last for many years of continuous service. That's good enough for many applications, even in safety-critical systems. You can't be serious! Tantalums are notoriusly flaky. Not only that, the usual failure mode is that the cap vanishes in a spectacular flash of purple fire. Every capacitor failure I've ever seen in computing equipment has been a tantalum. An engineer who used to work at Motorola told me that tantalums were banned from pager designs. At the time, Motorola would rather pay the premium for ceramic caps than risk tantalums. It depends entirely on the service life that is needed, and the degree of redundancy you can afford. Satellites and airbags have to remain in service for decades without repair, so electrolytics are probably unacceptable. Medical equipment generally doesn't need such high reliability, and frequently uses electrolytics. (Seriously. Med equipment is regularly replaced, there's no point in making it more than a couple of orders of magnitude more reliable than physicians, and the critical stuff has spares sitting on shelves.) Telecom equipment can afford redundancy in almost everything, and so it's full of electrolytics.