There are many things involved. Like whether you call it Java. Microsoft wanted to call their VM Java and execute Java bytecode. Google differs on both points. And, well, despite its size, Google is currently not (considered to be) a monopolist.
I find it a bit suspicious that Africa has handled many Ebola outbreaks before this just fine. Sure there were deaths, it's Ebola, but they handled it. Now we have 20+ medical companies with untested human trials of Ebola vaccines/cures all rushing in to "save" the day by testing the drug on humans without a controlled environment and with no legal liability. If a survivor's next fetus grows a third eye and has an IQ of a sweet potato in a drought are they going to take responsibility? I doubt it. How about getting the right gear and help to the health workers instead of pumping them full of crap you could not test legally in your own country. Stop using Africa as a petri dish. Makes me wonder if they didn't start and help spread the epidemic in the first place. But then again maybe I have played/watched too much resident evil.
Proper help to the health workes would include vaccine. In an early phase, there won't be enough vaccine doses for the general population anyway, but currently health workers are at high risk and the number of doctors is dwindling. Not because they leave their posts, but because they die. If you have protective gear and practices that reduce the risk of infection by 99 %, that's still a high risk scenario if you are at a treatment center with multiple patient encounters a day. For any similar infection where there is some kind of vaccine or prophylaxis, health workers get it. The side effects could be quite dire and still be worth it, assuming they are going to do their job at all.
I think all first year computer science / programming / engineering students should be introduced to this and learn how to write programs for this environment first before moving on to modern systems. True power is being able to write useful stuff with only 64kb of ram and 1mhz of processor, and have it run in an acceptable time frame, and taking those skills and scaling up today's multi-core/ multi-gigahertz/multi-gigabyte address spaces.
Cheap memory accesses compared to instruction latency, over your whole memory space. Memory locality basically doesn't matter. Branching is also almost free, since you are not pipelined at all. If you would extrapolate a Z80 machine to multi-gigahertz and multi-gigabyte you would get a much simpler low-level structure than you actually have. Some of the lessons learned regarding being frugal make sense, but you will also learn a lot of tricks that are either directly counter-productive, or at the very least steal your attention from what you should be concerned with, even in those very cases where you are really focusing on performance and power efficiency (in addition to the myriad of valid cases where developer productivity is simply more important than optimality).
It used to be that you couldn't pre-calculate everything since you didn't have enough storage. These days, you shouldn't pre-calculate everything since it will actually be cheaper to do it again rather than risk hitting main memory with a tremendous amount of random accesses, or even worse, swap. Up to some quite serious size data sets a flat data structure with fully sequential accesses can turn out to be preferable to something like a binary tree with multi-level indirections. (Now, the insane amount of references even for what should be a flat array in anything from Java to Python is one reason for why even very good JITs fall short of well-written C, Fortran, or C++.)
If you clear out the various multi-platform work for OpenSSL, _of course_ it can progress more quickly and more securely. The multi-platform work is where so much of the work has been done.
As a person making their living writing software for MacOS X and iOS, do I care about this code running in MacOS 9? I don't care one bit.
They explain it very well: You don't need to be "multi-platform" if you are standard. Instead of "we have thirteen implementions of SSL_memcpy that run on a dozen completely outdated platforms that nobody cares about", they use memcpy and say "if your platform doesn't support a standard C function correctly, fuck you and your platform". Which is the correct approach.
A slightly more pragmatic approach is to keep those implementations, at least the most crucial ones, but please make sure that you use memcpy etc directly on any sane modern platform.
What is so difficult to understand, and why is everyone getting their knickers up in a bunch over it?
The OpenBSD project used to be pretty rude to a number of people (mostly you could understand why, but that doesn't justify). While some of this is just ignorance much of it is likely people wanting to get back at them and people from the various security services trying to spread dissent.
Any other bitching just shows what an idiot you are (not saying you're bitching, just pointing that out to the general peanut gallery).
He's bitching, whether he realises it or not. He didn't point to a single instance of Alpha support slowing down other platforms. His analogy doesn't apply just because they provide portability. It applies if providing portability to old platforms such as the Alpha slows down the development of OpenBSD, which it probably occasionally does and on the other hand probably keeps people interested in developing on their old Alpha machines contributing and so overall has a positive effect.
I haven't watched the full talk (yet), but previous outlines of what OpenSSL did reeked of a Javaesque approach, provide such a thick runtime library on top of the OS, that you don't really need to care about what the platform gives you. That gives you a great portability story, once the layer is in place. The bad thing is that you do not benefit from the specifics of the platform. If you let your portability/base layer rot, you are also behind everyone's game. What's happened during the last 5-10 years is a lot of work to make the C standard library (or slight variations of it), as well as base system calls, much more hardened, to some extent providing security in depth. The LibreSSL critique has been based on the fact that OpenSSL went with their home-rolled, slightly inferior, slightly unpredictable (not handling NULL values in places, at least not in the same way any sane platform did, etc) layer for far too many things, even on modern platforms. As a provider of a platform with security in mind, I can understand the frustration of having a crucial library saying "hey, we don't care about that stuff, we can implement everything we need".
The power output of a Boeing 747 is 140 MW according to a slightly unreliable Wikipedia list. Now, this is probably the total engine output, but you would certainly need a significant fraction of that in electrical power for propellers. Note the other number in that list? A full Nimitz-class destroyer is 190 MW (that seems to be electrical power). A nuclear submarine does not even come close. The cooling environment of that 20 ton reactor is probably quite different, too. You can cool off the rector coolant against the ocean. Not so at 30,000 feet.
yes, you do. in a preemptable OS, in a multi-threaded app, you need atomic operations to share data between threads, as any read-modify-write operation on shared data gets wrecked when it is preempted between the read and the write.
Furthermore, what is atomic in terms of context switching preemption is not necessarily atomic in terms of memory bus arbitration. The two can usually coincide, but they don't have to.
The one question I still have is why the flow stops at 41,000 ft. I would have expected a kind of spring effect, followed by the lower portion of the siphon slowly descending as water vaporizes off the pre-apex portion, allowing the water in the lower part to descend while maintaining the same vapor pressure. I'm sure it is my failure to understand, so if anyone can offer a better explanation please do so!
I think it does. The time scale is just staggeringly different. Watching a water surface dry, and one with low area versus the volume, at that, is a boring activity. Put some table salt in a glass and fill an identical glass with water. Put some lid over it all. The equilibrium state will be more water in the initially empty, salt-containing, glass, than in the one originally containing water. Why? Because of the change in boiling enthalpy. But that change, and the formation of a water film or drops on all other surfaces in the enclosed volume, is immensely slow anywhere near room temperature.
Nested blocks are refactorable into smaller functions.
And the program eats the function/method/message call overhead, the overhead of passing all local variables as arguments, and the overhead of constructing and destroying an object through which to return multiple values from each function call.
I think you need to be introduced to a modern optimizing compiler. It will handle the first two for you, just fine, as long as you are in the same compilation unit (or doing fancier global optimziation). Since you just refactored this from a single function, you are supposedly still in the same compilation unit. If you pack the data in something like a stack-allocated struct even the last one will be reduced or completely avoided.
The Apple library itself was open source, right (although rebuilding the OS files would be precarious in OS X and outright impossible in iOS)? The mess with libraries like this (proprietary or not) is all other code (proprietary or not) that not only link to shared objects provided with the OS, but roll their own, sometimes even modified, build of the library. Now, thanks to the fact that it's GPL it cannot be hidden in a blob without at least a license notice, but tracking it down everywhere will be a mess. And then we haven't even got started about embedded systems...
Go to the company website instead. They say lunar resources and are able to tell the difference between kms and miles. However, it's all a bit pie in the sky even there. Even with the advantage of lunar resources, I would be more optimistic about geostationary orbital solar power. Microgravity would mean that you could get away with really thin structures, even concentrated thermal solar might make sense if you can work out a reasonable cooling part of the cycle (just make an extremely thin mirror as the bulk of the concentrator).
Solar insolation on the moon is not dramatically higher than on Earth - around 1400 W/m^2 versus around 1000 W/m^2 on Earth. Granted, a Lunar solar station wouldn't be affected by weather, but Earth based receivers will suffer from efficiency loss during bad weather.
Could they achieve the same result by building a bit larger system on earth, but without the hundreds (or thousands?) of rocket launches it would take to get the materials to the moon to get the thing started?
Besides, who wants to see a big black ribbon around the moon?
They plan to use lunar materials, so no hundresds of rocket launches to get started. I guess the point is kind of that real estate and raw materials are "free", if you get the proper manufacturing equipment up there. If that equipment is automated enough, you can build up slowly, but steadily.
How about putting a filter (low-pass/high-pass - I'm not an audio engineer, so I don't know) to stop any of the "damaging" waveforms from reaching the speaker? It's probably just a capacitor or inductor in line with it and you could get away with the same shoddy speaker that wouldn't blow from the clipped signal.
And in all likelihood you would have (non-negligible) worse sound performance for any sane waveform you played.
BTW, you could easily script a mechanical hard drive to power off and power on, all the time, for days and days. I am pretty sure a lot of drives would fail in the first year and I would honestly not want the manufacturer to honor the warranty if the total power on count exceeded half a million (powering on once per minute every minute for a year), even though it was all "legal instructions given to the machine".
Plus writing software that uses 72 cores is such a walk in the park
Some stuff actually is. It depends on how trivially parallel the problem is. With some stuff there is no interaction at all between the threads - feed it the right subset of the input - process the data - dump it out.
More importantly, for some applications a limited amount of very low-latency/high-bandwidth communication is enough to give spectacular performance improvements. In those cases, the fully coherent x86 model, kept up by this kind of cache and memory architecture, will do wonders, compared to an MPI implementation with weaker individual nodes, but also possibly against (current) nVidia offerings. It's harder to say how it will stack up against Maxwell.
20 years? I would be very doubtful regarding any prediction beyond the point where current process scaling trends finally break. Note, they might break the other way. Switching to a non-silicon material might allow higher frequencies which will again shift the tradeoff between locality, energy, and production cost. But there is no reason, no reason at all, to expect the current style to last for more than ten years, while you could be quite right that it could stay much the same for the next five years or so.
Not really. For an x32 binary, you would have x32 libc and use all the fancy features. For an x86 binary running on an AMD64 processor, you are still stuck in "compatibility mode" on the processor, even when you enter libc, which means you can only use actual x86 instructions (with the smaller register file etc). It is my impression that on-the-fly switching between long and compatibility mode within the same proecss would still incur a cost that's comparable to (at the very least) a kernel mode transition, so the benefits would only exist for very few operations. Large memcpys wouldn't be among them, since the x86 vector instructions are actually quite fine for that purpose.
There's plenty of applications around still without a 64 bit binary. From what I understand this layer just allows 32 bit programs to utilize some performance enhancing features of 64 bit architecture. It seems a genuinely good idea.
It allows 32-bit programs, which are *recompiled*, to benefit from those features. You still need the source and x32 builds of all dependencies. However, sometimes I guess there could be porting issues due to pointer size assumptions (but no other hard assumptions of x86 ABI behavior). Those codebases could not be recompiled for x64, but might port to x32 more easily.
Any application that does heavy-numerical computation should not be affected by much by the ABI if at all. All function calls are inlined inside the critical loop.
The ABI here also defines the size of all pointers. All pointers are 32-bit here. Any purely compute intensive application will not be affected much, but something including some complexity in data structures, with pointers, could possibly benefit a lot. On the other hand, if all your code does is traversing trees, you should seriously consider allocating them in one bunch and using internal indices (of smaller integer type) rather than native pointers anyway.
It all depends on what timespan you have. All you need to do is to emit sounds that are quite inaudible or at least indistinguishable from high frequency noise that we have been trained to accept (PWM noise from LCD brightness control etc). If you have plenty of time, you can reduce your bitrate heavily in the handshaking step, basically looking for just a few bits of signature in a very wide span of frequencies and encodings. When you have a basic channel, you can tell your counterpart what SNR you are getting and successively tune the channel.
You would never want this for regular networking with any kind of latency demands. If you are rather just trying to get a specific updated payload across at some point, with any number of retransmissions, then I find it quite believable.
I suppose in very specific cases it could be worth it to intentionally make an encrypted channel unusable, in order to try to lure a target into using an unencrypted channel. But, as you say, doing so (and manifesting that you have that ability) comes at a rather great cost in terms of non-covertness.
It doesn't help you that individual operations are rounded deterministically, if the order of your operations is non-deterministic. You cannot expect bit-identical results if you parallelize or allow any level of operation reordering. Even a very well-written code might implement a reduce operation in different hierarchies depending on memory layout. Enforcing all these things to be done in the exactly same order, with full IEEE754 compliance is a significant performance cost. By taking numerical aspects into account, you can ensure that your result is not invalid or unreasonable. However, for a chaotic problem where a machine epsilon difference in input data might be enough for a macroscopically different end result, there is nothing you can do and still expect reasonable utilization of modern architectures.
No, it isn't, when the system itself is not well-conditioned. And I bet you don't want your compiler to run a real codebase in a IEEE754 strict interpretation, as that will disallow almost any optimization. Even if you would allow it, then "trivial" rearrangements, that don't affect the theoretical analysis of stability, correctness or condition number, will still introduce different rounding perturbations. Perturb weather or some other systems, and you will get a completely different trajectory.
That said, many applied fields, including meteorology, could benefit from more well-disciplined computational science approaches. But don't expect all that much of a difference.
Slashdot Mirror
There are many things involved. Like whether you call it Java. Microsoft wanted to call their VM Java and execute Java bytecode. Google differs on both points. And, well, despite its size, Google is currently not (considered to be) a monopolist.
I find it a bit suspicious that Africa has handled many Ebola outbreaks before this just fine. Sure there were deaths, it's Ebola, but they handled it. Now we have 20+ medical companies with untested human trials of Ebola vaccines/cures all rushing in to "save" the day by testing the drug on humans without a controlled environment and with no legal liability. If a survivor's next fetus grows a third eye and has an IQ of a sweet potato in a drought are they going to take responsibility? I doubt it. How about getting the right gear and help to the health workers instead of pumping them full of crap you could not test legally in your own country. Stop using Africa as a petri dish. Makes me wonder if they didn't start and help spread the epidemic in the first place. But then again maybe I have played/watched too much resident evil.
Proper help to the health workes would include vaccine. In an early phase, there won't be enough vaccine doses for the general population anyway, but currently health workers are at high risk and the number of doctors is dwindling. Not because they leave their posts, but because they die. If you have protective gear and practices that reduce the risk of infection by 99 %, that's still a high risk scenario if you are at a treatment center with multiple patient encounters a day. For any similar infection where there is some kind of vaccine or prophylaxis, health workers get it. The side effects could be quite dire and still be worth it, assuming they are going to do their job at all.
I think all first year computer science / programming / engineering students should be introduced to this and learn how to write programs for this environment first before moving on to modern systems. True power is being able to write useful stuff with only 64kb of ram and 1mhz of processor, and have it run in an acceptable time frame, and taking those skills and scaling up today's multi-core/ multi-gigahertz/multi-gigabyte address spaces.
Cheap memory accesses compared to instruction latency, over your whole memory space. Memory locality basically doesn't matter. Branching is also almost free, since you are not pipelined at all. If you would extrapolate a Z80 machine to multi-gigahertz and multi-gigabyte you would get a much simpler low-level structure than you actually have. Some of the lessons learned regarding being frugal make sense, but you will also learn a lot of tricks that are either directly counter-productive, or at the very least steal your attention from what you should be concerned with, even in those very cases where you are really focusing on performance and power efficiency (in addition to the myriad of valid cases where developer productivity is simply more important than optimality).
It used to be that you couldn't pre-calculate everything since you didn't have enough storage. These days, you shouldn't pre-calculate everything since it will actually be cheaper to do it again rather than risk hitting main memory with a tremendous amount of random accesses, or even worse, swap. Up to some quite serious size data sets a flat data structure with fully sequential accesses can turn out to be preferable to something like a binary tree with multi-level indirections. (Now, the insane amount of references even for what should be a flat array in anything from Java to Python is one reason for why even very good JITs fall short of well-written C, Fortran, or C++.)
If you clear out the various multi-platform work for OpenSSL, _of course_ it can progress more quickly and more securely. The multi-platform work is where so much of the work has been done.
As a person making their living writing software for MacOS X and iOS, do I care about this code running in MacOS 9? I don't care one bit. They explain it very well: You don't need to be "multi-platform" if you are standard. Instead of "we have thirteen implementions of SSL_memcpy that run on a dozen completely outdated platforms that nobody cares about", they use memcpy and say "if your platform doesn't support a standard C function correctly, fuck you and your platform". Which is the correct approach.
A slightly more pragmatic approach is to keep those implementations, at least the most crucial ones, but please make sure that you use memcpy etc directly on any sane modern platform.
What is so difficult to understand, and why is everyone getting their knickers up in a bunch over it?
The OpenBSD project used to be pretty rude to a number of people (mostly you could understand why, but that doesn't justify). While some of this is just ignorance much of it is likely people wanting to get back at them and people from the various security services trying to spread dissent.
Any other bitching just shows what an idiot you are (not saying you're bitching, just pointing that out to the general peanut gallery).
He's bitching, whether he realises it or not. He didn't point to a single instance of Alpha support slowing down other platforms. His analogy doesn't apply just because they provide portability. It applies if providing portability to old platforms such as the Alpha slows down the development of OpenBSD, which it probably occasionally does and on the other hand probably keeps people interested in developing on their old Alpha machines contributing and so overall has a positive effect.
I haven't watched the full talk (yet), but previous outlines of what OpenSSL did reeked of a Javaesque approach, provide such a thick runtime library on top of the OS, that you don't really need to care about what the platform gives you. That gives you a great portability story, once the layer is in place. The bad thing is that you do not benefit from the specifics of the platform. If you let your portability/base layer rot, you are also behind everyone's game. What's happened during the last 5-10 years is a lot of work to make the C standard library (or slight variations of it), as well as base system calls, much more hardened, to some extent providing security in depth. The LibreSSL critique has been based on the fact that OpenSSL went with their home-rolled, slightly inferior, slightly unpredictable (not handling NULL values in places, at least not in the same way any sane platform did, etc) layer for far too many things, even on modern platforms. As a provider of a platform with security in mind, I can understand the frustration of having a crucial library saying "hey, we don't care about that stuff, we can implement everything we need".
The power output of a Boeing 747 is 140 MW according to a slightly unreliable Wikipedia list. Now, this is probably the total engine output, but you would certainly need a significant fraction of that in electrical power for propellers. Note the other number in that list? A full Nimitz-class destroyer is 190 MW (that seems to be electrical power). A nuclear submarine does not even come close. The cooling environment of that 20 ton reactor is probably quite different, too. You can cool off the rector coolant against the ocean. Not so at 30,000 feet.
yes, you do. in a preemptable OS, in a multi-threaded app, you need atomic operations to share data between threads, as any read-modify-write operation on shared data gets wrecked when it is preempted between the read and the write.
Furthermore, what is atomic in terms of context switching preemption is not necessarily atomic in terms of memory bus arbitration. The two can usually coincide, but they don't have to.
I would imagine that the gradient will be much more dependent on the location of pumping and isolation, rather than gravity, though.
The one question I still have is why the flow stops at 41,000 ft. I would have expected a kind of spring effect, followed by the lower portion of the siphon slowly descending as water vaporizes off the pre-apex portion, allowing the water in the lower part to descend while maintaining the same vapor pressure. I'm sure it is my failure to understand, so if anyone can offer a better explanation please do so!
I think it does. The time scale is just staggeringly different. Watching a water surface dry, and one with low area versus the volume, at that, is a boring activity. Put some table salt in a glass and fill an identical glass with water. Put some lid over it all. The equilibrium state will be more water in the initially empty, salt-containing, glass, than in the one originally containing water. Why? Because of the change in boiling enthalpy. But that change, and the formation of a water film or drops on all other surfaces in the enclosed volume, is immensely slow anywhere near room temperature.
Nested blocks are refactorable into smaller functions.
And the program eats the function/method/message call overhead, the overhead of passing all local variables as arguments, and the overhead of constructing and destroying an object through which to return multiple values from each function call.
I think you need to be introduced to a modern optimizing compiler. It will handle the first two for you, just fine, as long as you are in the same compilation unit (or doing fancier global optimziation). Since you just refactored this from a single function, you are supposedly still in the same compilation unit. If you pack the data in something like a stack-allocated struct even the last one will be reduced or completely avoided.
The Apple library itself was open source, right (although rebuilding the OS files would be precarious in OS X and outright impossible in iOS)? The mess with libraries like this (proprietary or not) is all other code (proprietary or not) that not only link to shared objects provided with the OS, but roll their own, sometimes even modified, build of the library. Now, thanks to the fact that it's GPL it cannot be hidden in a blob without at least a license notice, but tracking it down everywhere will be a mess. And then we haven't even got started about embedded systems...
Go to the company website instead. They say lunar resources and are able to tell the difference between kms and miles. However, it's all a bit pie in the sky even there. Even with the advantage of lunar resources, I would be more optimistic about geostationary orbital solar power. Microgravity would mean that you could get away with really thin structures, even concentrated thermal solar might make sense if you can work out a reasonable cooling part of the cycle (just make an extremely thin mirror as the bulk of the concentrator).
Solar insolation on the moon is not dramatically higher than on Earth - around 1400 W/m^2 versus around 1000 W/m^2 on Earth. Granted, a Lunar solar station wouldn't be affected by weather, but Earth based receivers will suffer from efficiency loss during bad weather.
Could they achieve the same result by building a bit larger system on earth, but without the hundreds (or thousands?) of rocket launches it would take to get the materials to the moon to get the thing started?
Besides, who wants to see a big black ribbon around the moon?
They plan to use lunar materials, so no hundresds of rocket launches to get started. I guess the point is kind of that real estate and raw materials are "free", if you get the proper manufacturing equipment up there. If that equipment is automated enough, you can build up slowly, but steadily.
How about putting a filter (low-pass/high-pass - I'm not an audio engineer, so I don't know) to stop any of the "damaging" waveforms from reaching the speaker? It's probably just a capacitor or inductor in line with it and you could get away with the same shoddy speaker that wouldn't blow from the clipped signal.
And in all likelihood you would have (non-negligible) worse sound performance for any sane waveform you played. BTW, you could easily script a mechanical hard drive to power off and power on, all the time, for days and days. I am pretty sure a lot of drives would fail in the first year and I would honestly not want the manufacturer to honor the warranty if the total power on count exceeded half a million (powering on once per minute every minute for a year), even though it was all "legal instructions given to the machine".
In other words, they made very neat bags of mostly water.
Some stuff actually is. It depends on how trivially parallel the problem is. With some stuff there is no interaction at all between the threads - feed it the right subset of the input - process the data - dump it out.
More importantly, for some applications a limited amount of very low-latency/high-bandwidth communication is enough to give spectacular performance improvements. In those cases, the fully coherent x86 model, kept up by this kind of cache and memory architecture, will do wonders, compared to an MPI implementation with weaker individual nodes, but also possibly against (current) nVidia offerings. It's harder to say how it will stack up against Maxwell.
20 years? I would be very doubtful regarding any prediction beyond the point where current process scaling trends finally break. Note, they might break the other way. Switching to a non-silicon material might allow higher frequencies which will again shift the tradeoff between locality, energy, and production cost. But there is no reason, no reason at all, to expect the current style to last for more than ten years, while you could be quite right that it could stay much the same for the next five years or so.
Not really. For an x32 binary, you would have x32 libc and use all the fancy features. For an x86 binary running on an AMD64 processor, you are still stuck in "compatibility mode" on the processor, even when you enter libc, which means you can only use actual x86 instructions (with the smaller register file etc). It is my impression that on-the-fly switching between long and compatibility mode within the same proecss would still incur a cost that's comparable to (at the very least) a kernel mode transition, so the benefits would only exist for very few operations. Large memcpys wouldn't be among them, since the x86 vector instructions are actually quite fine for that purpose.
There's plenty of applications around still without a 64 bit binary. From what I understand this layer just allows 32 bit programs to utilize some performance enhancing features of 64 bit architecture. It seems a genuinely good idea.
It allows 32-bit programs, which are *recompiled*, to benefit from those features. You still need the source and x32 builds of all dependencies. However, sometimes I guess there could be porting issues due to pointer size assumptions (but no other hard assumptions of x86 ABI behavior). Those codebases could not be recompiled for x64, but might port to x32 more easily.
Any application that does heavy-numerical computation should not be affected by much by the ABI if at all. All function calls are inlined inside the critical loop.
The ABI here also defines the size of all pointers. All pointers are 32-bit here. Any purely compute intensive application will not be affected much, but something including some complexity in data structures, with pointers, could possibly benefit a lot. On the other hand, if all your code does is traversing trees, you should seriously consider allocating them in one bunch and using internal indices (of smaller integer type) rather than native pointers anyway.
It all depends on what timespan you have. All you need to do is to emit sounds that are quite inaudible or at least indistinguishable from high frequency noise that we have been trained to accept (PWM noise from LCD brightness control etc). If you have plenty of time, you can reduce your bitrate heavily in the handshaking step, basically looking for just a few bits of signature in a very wide span of frequencies and encodings. When you have a basic channel, you can tell your counterpart what SNR you are getting and successively tune the channel.
You would never want this for regular networking with any kind of latency demands. If you are rather just trying to get a specific updated payload across at some point, with any number of retransmissions, then I find it quite believable.
I suppose in very specific cases it could be worth it to intentionally make an encrypted channel unusable, in order to try to lure a target into using an unencrypted channel. But, as you say, doing so (and manifesting that you have that ability) comes at a rather great cost in terms of non-covertness.
It doesn't help you that individual operations are rounded deterministically, if the order of your operations is non-deterministic. You cannot expect bit-identical results if you parallelize or allow any level of operation reordering. Even a very well-written code might implement a reduce operation in different hierarchies depending on memory layout. Enforcing all these things to be done in the exactly same order, with full IEEE754 compliance is a significant performance cost. By taking numerical aspects into account, you can ensure that your result is not invalid or unreasonable. However, for a chaotic problem where a machine epsilon difference in input data might be enough for a macroscopically different end result, there is nothing you can do and still expect reasonable utilization of modern architectures.
That said, many applied fields, including meteorology, could benefit from more well-disciplined computational science approaches. But don't expect all that much of a difference.
Wrong. It was totally OK in XP. It was Vista that broke it for WDDM (the new driver model), but I think 7 fixed it "back".