Mathematically modelling the brain would seem to be a very trivial problem. The problem is that there's a lot of brain to model. I've posted (admittedly non-rigorous) mathematical models of the brain on Slashdot before, but narry a grant check from it. Bah.
Computational fluid dynamics for foams, liquid crystals, et al, isn't any harder than for anything else. The equations are chaotic by nature, but chaotic systems can be well-behaved on aggregate under certain conditions. CFD as generally done relies on some specifically hand-picked special case or cases being universally true. They never are, which is why most CFD differs from how systems actually behave in practice.
If you were to treat CFD as a problem in chaos theory, rather than as isolated collections of imperfect examples of special cases, there would be no problem. It is always when engineers try to take shortcuts and oversimplify the maths to make it easy on themselves that they run into problems. They should be locked up for their own safety. If you want to really annoy them, lock them up with some airgel foam.
The problem with chaotic systems is that the system is sensitive to initial conditions, which means the only way to get "correct" results is to use infinite precision and zero step sizes. This isn't useful, but is a good way to annoy experts in CFD.
This leaves two options - use very very big, very very fast computers (the option used by F1 teams), or find an equivalent problem you CAN solve (the idea behind transforms).
Ok, does chaos look like a good place to use transforms? If you could identify and classify the Strange Attractors in the system, can you do anything useful? Probably not, at least not in the "solving the problem" sense. Chaos is fully deterministic, but it is utterly unpredictable. The only solution is the whole solution.
What knowing the Strange Attractors might tell you is how to vary the precision and step-size to get the best results for a given level of compute power. But it's going to be all raw horsepower from thereon out.
The best way to invest money on such work is to design a co-processor that performs a handful of fairly high-level maths functions directly (optimized purely for speed, not physical or logical space) so that you can do Navier-Stokes almost at the level of raw hardware rather than through clunky software. Then cluster the living daylights out of the co-processor.
It's necessary to optimize commodity hardware for space, because chip real-estate is expensive. However, if you're building what is basically a SOP (single-operation processor) for a dedicated market that can afford things like Earth Simulator, the only time you care about space is when it impacts speed.
Ideally, if the speed of light wasn't an issue, you'd want each bit in the output to be produced by wholly independent logic, duplicating the input bits as necessary to accomplish this. In practice, you'd probably want to start with that conceptually but in reality have something that was somewhere between that and a highly compressed form. Too parallel and the delays in communication exceed the benefits from the parallelization.
But this is all obvious. Anyone here who has done multi-threading or any other form of parallelization knows about synchronization issues and communication overheads. It's even one of the biggest chunks of any course on the subject of parallel design. There's nothing new there, certainly nothing "unsolved".
But, yeah, a well-designed Navier-Stokes co-processor would likely give you greater accuracy and greater performance than the modern pure software solutions. Especially those using ugly protocols to do the communications.
If Intel can conceptulalize 80 Pentium 4 cores on a wafer, it would seem reasonable enough to imagine modern fabrication methods being able to put at least a couple of hundred dedicated Navier-Stokes processors into the same space. Since the input for an iteration would be based on output from that and other processors, there's no
I would claim that the ratio of a circle to its diameter is independent of being observed, or indeed there being an observer. I would also claim that the laws of geometry, probability and topology are universal and also do not depend on the existence of observers, let alone their ability to perform maths.
Radioactive decay follows an exponential decay curve. It will have done so long before anyone could add, let alone handle irrational numbers like e.
This puts me firmly in the category of maths being discovered, not invented. Mathematical tools, however, are invented and not discovered. I consider these to be quite different. If you were to imagine an alien lifeform on some distant world, they'll have an identical math but their experience of it, the way they treat it, the systems they use, those will all be unique to them because those are inventions and not anything fundamental to maths itself.
In a simpler example of the same concept, we can use ancient Greek maths today even though they didn't have a concept of zero and had (to modern eyes) very alien views on the way maths worked. We can use ancient Greek maths because the results don't depend on any of that.
We can use Roman results, too, despite the fact that their numbering system doesn't really follow a number base in any way we'd understand. It doesn't matter, though, because the important stuff all takes place below such superficial details. Even more remarkable, we can read many of the numbers written in Linear A, even though we can't read the language itself and know very little about the culture or people.
None of this would be possible if what lay under maths was invented. It's very hard to rediscover lost inventions, as there's many ways of producing similar results. But when you can rediscover lost number systems with comparative ease - well, doesn't that tell you there has to be something a bit more universal to it?
(I won't get into parrots being able to discover the notion of zero, but it's again pertinent as it's an example of a universality that transcends the invented language it's described in.)
Designing nuke reactors, designing aircraft (transsonic flows are nasty, hypersonic is a nightmare), designing bombs, weather simulations (or so they say), designing racing cars (almost all Formula 1 teams own or rent supercomputer time and Bloodhound - the 1000 MPH car - can't be designed any other way), processing data from particle accelerators (just collecting terabits of data per second isn't easy), designing new generations of microprocessors and pattern analysis in genetics.
Of these, I'm most familiar with processing data from accelerators. The work I did at Daresbury (20 years ago, back when there was still an SERC) involved collecting data from a very tiny accelerator. A mere 20 MeV. The design was over-specced by a bit (they wanted to be able to handle 2^65536 32-bit words of data) but the system really did max out both the processing and networking capabilities that existed at the time. And Eurogam was a small, small project by nuclear physics standards. The LHC, if they can ever keep it running, will be logging terabits of data per second. The European high-performance grid exists because the alternative would be convoys of 40' trucks hauling SANs. And you know how the French drive.
No. It's the new processor requirement for Windows 8. Running the web browser requires an additional 10 million cores. If you want Flash as well, better make it 25 million extra.
It was the first mass-market ix86-clone CPU to include an on-board memory controller. The Transputer had a perfectly good on-board memory controller 25 years ago. It was 64-bit, too.
MPI is indeed clunky. Most parallel libraries out there are. (MPI and PVM are built on the idea that every node has a shell and that you can run programs by rsh-ing onto that node and running the program.)
There are more elegant ways of running things. For example, rsh and a remote shell implies that the node has a fairly good-sized OS running, which means you're eating up system resources before you do anything.
MOSIX seems a better starting point. If you can shunt already-active processes over a network, you don't need a shell, you don't need userspace stuff that's going to be stagnant most of the time. (The active process needn't be a full program, it can be something that pulls in a dynamically-loaded object that has the real program in it when it gets to the destination. In fact, it's better if it ISN'T the program, since then you don't run into the issue of whether kernel threads should migrate or not.)
For collective operations, you really want to use multicasting (as then you don't waste bandwidth or create excessive latency). Scalable Reliable Multicasting of some sort - NACK-Oriented Reliable Multicasting being the popular form - would be a good starting point. The destination nodes can calculate any node-specific details faster than a master node can, since the master node would have to do so sequentially using no information not present in the collective message.
Message passing itself is so-so as an approach. You can see from the popularity of the original MACH-based HURD that there are definite limitations to the approach. In the end, whether you're talking about remote I/O, remote procedure calls or other remote operation, you're ultimately talking about sending and receiving data, where that data can be delivered to an active thread, trigger the start of a new thread, change the state of a mutex/futex/semaphore or perform some other very basic task.
Now, different approaches to parallelism work on different assumptions. MPI assumes you've a well-defined master node and well-defined slaves in almost the reverse of the traditional client-server model. Pi-Occam assumes you've well-defined channels, where channels can be fixed or mobile. I =think= channels are all point-to-point, as Occam was originally developed with the Transputer's mesh topology in mind and still carries some of the assumptions.
There are "metaschedulers", which seek to schedule operations over a whole cluster as though it was a single virtual machine. It's a good concept, there is no real distinction between N physical machines being one logical server, or one physical server being N logical machines.
However, "metaschedulers" tend to be run on a master node. If we're running on a MOSIX-type cluster, there isn't any need for a master node. Indeed, there isn't a vast need for a single metascheduler. Rather, you'd want many mini metaschedulers, each concerned with their local area, which interacted with the local scheduler and each other.
Average human lifespan is 80 years. Assuming the author is roughly 30, then the author need only fear being ridiculed for underestimating the future for the next 50 years. Assume Moore's Law continues to hold and assume that scheduling problems constrain individual motherboards to 16x16 cores (16-way SMP is your limit, it's hard to imagine hardware inside the CPU is going to be any easier than hardware outside the CPU).
This means a desktop system in 50 years time can realistically expect to be limited to the equivalent of 256 cores that are each running at 100 terahertz. It won't be quite that architecture, but it should have that level of power.
It seems very wise to be scoffed at by a few people now and then hailed as a Visionary in his old age. It's not like anyone would give him anything now for being accurate, but Visionaries get their own TV shows, awards, endorsements - serious cash!
It depends on what sort of cores are used. Most real problems are not SIMD but MIMD. You can turn a MIMD problem into a very large set of SIMD problems, though, where each one of those SIMD problems is actually extremely narrow and does not require a completely general-purpose core.
What you end up with is a hybrid of highly specialized cores, each very tightly tuned to some specific sub-category of problem. Since it's tuned, it can be ultra-RISC (it might not even need to be Turing Complete in some cases).
Since the critical path determines deadlines, and most processes will be OFF the critical path, you can also have asynchronous cores. The University of Manchester's AMULET group has been working on asynchronous computing for a while and has some nice technology, including open-source tools for making asynchronous chips.
Switching is another big heat-generator, since extreme computing like this really needs either a butterfly topology or a hypercube topology. In either case, IIRC, the number of switches goes up with the power of the number of nodes. At 100 million nodes, you'd be looking at tens of quadrillions of switches. Even if each switch is relatively lightweight on power, the sheer number makes the total consumption significant.
However, it's not all bad. Any collective operation can be delivered via NACK-oriented reliable multicast, so it's a single-shot delivery to as many nodes as you like.
Since supercomputing IS all about critical paths and deadlines, it should be possible to use delay tolerant networking protocols and have switches deliver as much in bulk as possible to minimize processing needed except on the periphery of the network. So long as packets get to their destinations by the deadlines, it makes no difference to the nodes whether they get the data then block on a barrier operation or whether they get the data just as the barrier operation is due to finish.
So there's lots of ways to cut down on the heat on the hardware side. What about the software side? Well, competent programmers are often a good start. A million cores doesn't mean it's ok to be a million times less efficient.
Code should be tightly written and customized for the specific hardware (including network) characteristics. It should then be profiled, baked, broiled and fried until light and crispy. The programmers should then refactor the code until it's done right.
The theoretical minimum heat output from a hybrid asynchronous computer is the heat you'd generate if one core is one processing element with enough memory to perform its task. You can't get any more RISC than a single instruction. The theoretical minimum heat output from a deliberately delaying network is the heat you'd generate in queueing and bulk-delivering data such that nodes are either off or busy, they're never idle on the offchance of data coming soon.
Idle nodes are the really bad nodes. If a node cannot be used right then and is off, it consumes nothing. A node is most likely to be idle if there is simply no way of telling if it'll be assigned work or not.
The next-worst are nodes that do things too fast. Doing things too fast means the memory has to stay powered to preserve the results but nothing can consume the results any time soon. Power consumed is not directly proportional to processor speed. It's not linear. If you detune the processor such that it always has the data ready just in time to be consumed, you will always use less power than storing.
The upshot of this is your input buffer wants to be very large (so you can bulk-receive) but the output buffer wants to be comparatively small (because you are generating results when they're needed and no sooner).
If you're really smart, you'd make the input buffer high-bandwidth and the output buffer high-speed. If you're generating just-in-time, the last thing you want is for the output to be slow in being forwarded on. On the other hand, data will be dropped into the input far faster than it can be consumed (since it's a bulk delive
Do you often write at mach 8 in pencil on the sides of armoured vehicles? And would this have anything to do with the huge gouge marks on the sides of vehicles going to Iraq and Afghanistan?
(Seriously, nobody would build a net for such things. We already have excellent experience with micrometeorite shielding, where micrometeorites are likely iron/nickel alloys - the stuff traditionally used in weapons where steel is inadequate.)
Aim it at a space museum and tell them that it's a donation. That way, they have to pick up the bill if one of their newly-acquired artefacts blows up someone important.
Seriously, though, a net idea makes no sense whatsoever. Would would make a lot more sense, since the real problem isn't the big chunks but the tiny fragments (pea-sized or smaller) is to re-use the shielding idea used on the Giotto probe when it went for Halley's comet.
Giotto's shielding was alternating layers of aluminium foil and kevlar. The foil would destroy smaller fragments, the kevlar would stop larger pieces. If it was too large for the kevlar, it had probably splintered up by that time and the second round would finish off most of the rest.
Giotto survived hellish conditions, flying directly towards a jet on Halley's Comet. It survived the encounter, though got a few hearts fluttering when it lost contact at point zero (right next to the cometary nucleus). When it restabilized and found Earth again, astronomers discovered a very large chunk had mashed into the probe and sent it spinning uncontrollably for a while, a-la Darth's Tie Fighter.
These days, we can even improve on the design, since we can add airgel and other more modern materials and we don't need a whole range of highly delicate sensors for sweeping duties.
So we pack up a cleaning robot, launch it into space, and get rid of junk that's highly deadly for spacecraft but too small to track reliably (if at all). This satellite's sole mission would be to point at where debris belts are expected to be and slam through them.
Stuff we can track just isn't an issue, but a fleck of paint a millimeter in diameter would be enough to punch a hole in a communications satellite. If we can get rid of the small junk, we'll massively improve the life-expectancy of everything up there and buy time to develop a means of eliminating the big junk (dead satellites, rocket stages, etc) which we can simply avoid for right now.
Some of the big junk we might even want to recover in some way. Not only would they be priceless museum exhibits, they're priceless scientific devices for examining the long-term effects of the solar wind, the actual density of natural space debris, long-term effects of exposure to the hard radiation and cosmic rays of space (vital to know for a Mars mission or for any permanent presence in space or another planet).
The smaller junk will really not tell us anything, so burning it up on strikes and globbing the rest into airgel and kevlar would make sense. A probe like that, once "full", could be crashed almost anywhere as what's captured is non-hazardous waste. Probably not enough to be worth recycling. Chucking it at where the plates are sliding would seem fair enough. It won't cause problems and the magma will be much more effective at natural recycling than anything we can do.
The big pieces are what most people worry about, despite the fact that we know where they all are and they're all relatively harmless. At the moment, there's not much that anyone could do, anyways. Besides micrometeorite strikes swiss-cheezing anything of size, the radiation will have made many materials extremely brittle. The Saturn V rocket pieces weren't built to last this long under such rough conditions. They might still be solid enough to move, or might break into deadly, untrackable fragments if they're even touched. Deep space is no better for cheap alloys than the deep oceans are for ships like the Titanic (made from another cheap alloy rather than high-quality iron).
What you'd ideally want to do is enclose those pieces you didn't want to preserve, then create a series of shockwaves such that each adds to the next. The whole structure will shred itself and can be cleaned up safely with the original cleaner robot I outlined.
Structures you DO want to keep are tougher. You'd need to bind them together very gently to avoid destroying anything preservable. There are resins that could be used. Once it's encased in resin, glue a heat s
If a rogue Russian communications satellite "accidentally" hit a Japanese whaler or three, who exactly is going to complain? The whalers would be dead, anyone who goes to Russia to complain ends up dead, and those with evidence of such a plot would likely go on the CIA's list of "people to be dead".
Besides, the Japanese can then kick up a fuss and gouge the whale-meat eaters for more cash whilst the Japanese insurance companies can claim an act of God and keep the money for the ship and the crew. Everyone wins.
Bear in mind that politicos can get voted out very easily, so tend to be nervous types when accused of something that smacks of scandal. (Widespread fraud is one thing, but accusations in the press of sponsoring pirates or spending tax dollars in bringing down Hollywood... No sane politician would take that kind of risk.)
Also bear in mind that most politicians are technically ignorant and are unlikely to know the difference between aiding and abetting in an electronic crime versus being a common carrier.
Finally, you need to also consider that these places are full of backstabbers, some likely in the pay of ISPs that would be competing with the municipal system. (If the public sector is corrupt, it's the private sector that is corrupting it.)
The French keep the best of their wine to themselves. Greece wouldn't be bad, but they keep whining about wanting their marbles back. Serbia's not a bad place, per se, but their architecture is UGLY! These are all clearly crimes against geekdom.
I wouldn't say it's meaningless. Take the known position and velocity of the asteroid, and the position and velocity of the Earth at the time of discovery.
Now, there are only two meaningful scenarios - the asteroid reached the same point at a slightly different time (resulting in an impact) OR the asteroid had a slightly different displacement but essentially the same vector (resulting in an impact).
It is NOT meaningful to give the asteroid a significantly different vector, unless you can prove it passed close to one of the gas giants and underwent a gravitational slingshot. This is because if it were on a totally different path for no obvious reason, it wouldn't be the same asteroid. Duh.
On the other hand, if this rock has been orbiting the sun for any length of time, the difference in mass and/or velocity required to have put it onto an almost identical track that did intersect the Earth would be insignificant. Well below anything we could meaningfully consider.
Ideally what you'd do is look at the time window and displacement range that would have resulted in a collision, then using the known mechanics of planetary movement, "rewind" the system as far as you can and still maintain a reasonably low margin of error. Then do the same using the actual observed values.
Anything in that range that would result in the asteroid colliding with something else before the Earth OR slingshotting off in another direction altogether OR not tracking back to (close enough) the right origin can be ignored.
Any possibility not discarded will give you a possible angle for a strike. It could have happened that way and, as far as our ability to distinguish events is concerned, what actually happened cannot be usefully distinguished. (There may well have been fragments from it that DID strike the Earth, so to call it a miss is not a given.)
This is important, why? Because it tells us a lot about how well we can predict where an asteroid will be. The more possibilities that are computationally indistinguishable, the less useful it is to claim to be able to make such a prediction.
They really needed it 250-300 million years ago though. Tweaking the impact velocity to get roughly the right values according to the article, the calculator reveals anyone on the edge of the crater would be vaporized, ripped to shreds from the pressure wave, then pulverized by the earthquake and drowned by a subsequent tsunami.
Would you really be that upset if an asteroid flattened just about any city you cared to name in the Bible Belt, Middle East, Vichy France, Greece, Serbia, Microsoft HQ,...
Asteroid Impact Calculator. Handy thing to have bookmarked, in the event that the astronomers see the next one from far enough off.
It's impossible to be sure what the density and angle of incidence would have been in this case, as this sort of data isn't usually published. It's also impossible to be sure of composition, as that depends on where the asteroid was from. Thus, any results you DO get from the calculator are either meaningless (too much garbage in) or extreme values only.
Having said that, such calculators are fun when they find truly massive craters. The crater under the antarctic ice, for example, is so large that the Earth was unlikely to have ever been hit by something that big in the past 4 billion years. Antarctica is very modern, in comparison.
You've not taken into consideration the fact that most humans aren't sentient enough to notice or care being hit by an asteroid. And even if they did, they have enough plastic surgery, botox and fat tissue that the asteroid would bounce off.
Slashdot Mirror
Mathematically modelling the brain would seem to be a very trivial problem. The problem is that there's a lot of brain to model. I've posted (admittedly non-rigorous) mathematical models of the brain on Slashdot before, but narry a grant check from it. Bah.
Computational fluid dynamics for foams, liquid crystals, et al, isn't any harder than for anything else. The equations are chaotic by nature, but chaotic systems can be well-behaved on aggregate under certain conditions. CFD as generally done relies on some specifically hand-picked special case or cases being universally true. They never are, which is why most CFD differs from how systems actually behave in practice.
If you were to treat CFD as a problem in chaos theory, rather than as isolated collections of imperfect examples of special cases, there would be no problem. It is always when engineers try to take shortcuts and oversimplify the maths to make it easy on themselves that they run into problems. They should be locked up for their own safety. If you want to really annoy them, lock them up with some airgel foam.
The problem with chaotic systems is that the system is sensitive to initial conditions, which means the only way to get "correct" results is to use infinite precision and zero step sizes. This isn't useful, but is a good way to annoy experts in CFD.
This leaves two options - use very very big, very very fast computers (the option used by F1 teams), or find an equivalent problem you CAN solve (the idea behind transforms).
Ok, does chaos look like a good place to use transforms? If you could identify and classify the Strange Attractors in the system, can you do anything useful? Probably not, at least not in the "solving the problem" sense. Chaos is fully deterministic, but it is utterly unpredictable. The only solution is the whole solution.
What knowing the Strange Attractors might tell you is how to vary the precision and step-size to get the best results for a given level of compute power. But it's going to be all raw horsepower from thereon out.
The best way to invest money on such work is to design a co-processor that performs a handful of fairly high-level maths functions directly (optimized purely for speed, not physical or logical space) so that you can do Navier-Stokes almost at the level of raw hardware rather than through clunky software. Then cluster the living daylights out of the co-processor.
It's necessary to optimize commodity hardware for space, because chip real-estate is expensive. However, if you're building what is basically a SOP (single-operation processor) for a dedicated market that can afford things like Earth Simulator, the only time you care about space is when it impacts speed.
Ideally, if the speed of light wasn't an issue, you'd want each bit in the output to be produced by wholly independent logic, duplicating the input bits as necessary to accomplish this. In practice, you'd probably want to start with that conceptually but in reality have something that was somewhere between that and a highly compressed form. Too parallel and the delays in communication exceed the benefits from the parallelization.
But this is all obvious. Anyone here who has done multi-threading or any other form of parallelization knows about synchronization issues and communication overheads. It's even one of the biggest chunks of any course on the subject of parallel design. There's nothing new there, certainly nothing "unsolved".
But, yeah, a well-designed Navier-Stokes co-processor would likely give you greater accuracy and greater performance than the modern pure software solutions. Especially those using ugly protocols to do the communications.
If Intel can conceptulalize 80 Pentium 4 cores on a wafer, it would seem reasonable enough to imagine modern fabrication methods being able to put at least a couple of hundred dedicated Navier-Stokes processors into the same space. Since the input for an iteration would be based on output from that and other processors, there's no
I would claim that the ratio of a circle to its diameter is independent of being observed, or indeed there being an observer. I would also claim that the laws of geometry, probability and topology are universal and also do not depend on the existence of observers, let alone their ability to perform maths.
Radioactive decay follows an exponential decay curve. It will have done so long before anyone could add, let alone handle irrational numbers like e.
This puts me firmly in the category of maths being discovered, not invented. Mathematical tools, however, are invented and not discovered. I consider these to be quite different. If you were to imagine an alien lifeform on some distant world, they'll have an identical math but their experience of it, the way they treat it, the systems they use, those will all be unique to them because those are inventions and not anything fundamental to maths itself.
In a simpler example of the same concept, we can use ancient Greek maths today even though they didn't have a concept of zero and had (to modern eyes) very alien views on the way maths worked. We can use ancient Greek maths because the results don't depend on any of that.
We can use Roman results, too, despite the fact that their numbering system doesn't really follow a number base in any way we'd understand. It doesn't matter, though, because the important stuff all takes place below such superficial details. Even more remarkable, we can read many of the numbers written in Linear A, even though we can't read the language itself and know very little about the culture or people.
None of this would be possible if what lay under maths was invented. It's very hard to rediscover lost inventions, as there's many ways of producing similar results. But when you can rediscover lost number systems with comparative ease - well, doesn't that tell you there has to be something a bit more universal to it?
(I won't get into parrots being able to discover the notion of zero, but it's again pertinent as it's an example of a universality that transcends the invented language it's described in.)
Well, not exactly. They're using a modpack for The Sims to develop virtual programmers who can write parallel game code.
Designing nuke reactors, designing aircraft (transsonic flows are nasty, hypersonic is a nightmare), designing bombs, weather simulations (or so they say), designing racing cars (almost all Formula 1 teams own or rent supercomputer time and Bloodhound - the 1000 MPH car - can't be designed any other way), processing data from particle accelerators (just collecting terabits of data per second isn't easy), designing new generations of microprocessors and pattern analysis in genetics.
Of these, I'm most familiar with processing data from accelerators. The work I did at Daresbury (20 years ago, back when there was still an SERC) involved collecting data from a very tiny accelerator. A mere 20 MeV. The design was over-specced by a bit (they wanted to be able to handle 2^65536 32-bit words of data) but the system really did max out both the processing and networking capabilities that existed at the time. And Eurogam was a small, small project by nuclear physics standards. The LHC, if they can ever keep it running, will be logging terabits of data per second. The European high-performance grid exists because the alternative would be convoys of 40' trucks hauling SANs. And you know how the French drive.
Depends on how many turn up to the LAN party. C'mon, have you SEEN the new Quake 8 graphics?
No. It's the new processor requirement for Windows 8. Running the web browser requires an additional 10 million cores. If you want Flash as well, better make it 25 million extra.
It's doubtful this is a factor, but AMD's HyperTransport 3 has higher bandwidth than Intel's PCI Express 2.1.
It was the first mass-market ix86-clone CPU to include an on-board memory controller. The Transputer had a perfectly good on-board memory controller 25 years ago. It was 64-bit, too.
Easy solutions =have= been found, but then Inmos was sold off. The mice were furious.
MPI is indeed clunky. Most parallel libraries out there are. (MPI and PVM are built on the idea that every node has a shell and that you can run programs by rsh-ing onto that node and running the program.)
There are more elegant ways of running things. For example, rsh and a remote shell implies that the node has a fairly good-sized OS running, which means you're eating up system resources before you do anything.
MOSIX seems a better starting point. If you can shunt already-active processes over a network, you don't need a shell, you don't need userspace stuff that's going to be stagnant most of the time. (The active process needn't be a full program, it can be something that pulls in a dynamically-loaded object that has the real program in it when it gets to the destination. In fact, it's better if it ISN'T the program, since then you don't run into the issue of whether kernel threads should migrate or not.)
For collective operations, you really want to use multicasting (as then you don't waste bandwidth or create excessive latency). Scalable Reliable Multicasting of some sort - NACK-Oriented Reliable Multicasting being the popular form - would be a good starting point. The destination nodes can calculate any node-specific details faster than a master node can, since the master node would have to do so sequentially using no information not present in the collective message.
Message passing itself is so-so as an approach. You can see from the popularity of the original MACH-based HURD that there are definite limitations to the approach. In the end, whether you're talking about remote I/O, remote procedure calls or other remote operation, you're ultimately talking about sending and receiving data, where that data can be delivered to an active thread, trigger the start of a new thread, change the state of a mutex/futex/semaphore or perform some other very basic task.
Now, different approaches to parallelism work on different assumptions. MPI assumes you've a well-defined master node and well-defined slaves in almost the reverse of the traditional client-server model. Pi-Occam assumes you've well-defined channels, where channels can be fixed or mobile. I =think= channels are all point-to-point, as Occam was originally developed with the Transputer's mesh topology in mind and still carries some of the assumptions.
There are "metaschedulers", which seek to schedule operations over a whole cluster as though it was a single virtual machine. It's a good concept, there is no real distinction between N physical machines being one logical server, or one physical server being N logical machines.
However, "metaschedulers" tend to be run on a master node. If we're running on a MOSIX-type cluster, there isn't any need for a master node. Indeed, there isn't a vast need for a single metascheduler. Rather, you'd want many mini metaschedulers, each concerned with their local area, which interacted with the local scheduler and each other.
Average human lifespan is 80 years. Assuming the author is roughly 30, then the author need only fear being ridiculed for underestimating the future for the next 50 years. Assume Moore's Law continues to hold and assume that scheduling problems constrain individual motherboards to 16x16 cores (16-way SMP is your limit, it's hard to imagine hardware inside the CPU is going to be any easier than hardware outside the CPU).
This means a desktop system in 50 years time can realistically expect to be limited to the equivalent of 256 cores that are each running at 100 terahertz. It won't be quite that architecture, but it should have that level of power.
It seems very wise to be scoffed at by a few people now and then hailed as a Visionary in his old age. It's not like anyone would give him anything now for being accurate, but Visionaries get their own TV shows, awards, endorsements - serious cash!
Far, far better to be a Visionary.
It depends on what sort of cores are used. Most real problems are not SIMD but MIMD. You can turn a MIMD problem into a very large set of SIMD problems, though, where each one of those SIMD problems is actually extremely narrow and does not require a completely general-purpose core.
What you end up with is a hybrid of highly specialized cores, each very tightly tuned to some specific sub-category of problem. Since it's tuned, it can be ultra-RISC (it might not even need to be Turing Complete in some cases).
Since the critical path determines deadlines, and most processes will be OFF the critical path, you can also have asynchronous cores. The University of Manchester's AMULET group has been working on asynchronous computing for a while and has some nice technology, including open-source tools for making asynchronous chips.
Switching is another big heat-generator, since extreme computing like this really needs either a butterfly topology or a hypercube topology. In either case, IIRC, the number of switches goes up with the power of the number of nodes. At 100 million nodes, you'd be looking at tens of quadrillions of switches. Even if each switch is relatively lightweight on power, the sheer number makes the total consumption significant.
However, it's not all bad. Any collective operation can be delivered via NACK-oriented reliable multicast, so it's a single-shot delivery to as many nodes as you like.
Since supercomputing IS all about critical paths and deadlines, it should be possible to use delay tolerant networking protocols and have switches deliver as much in bulk as possible to minimize processing needed except on the periphery of the network. So long as packets get to their destinations by the deadlines, it makes no difference to the nodes whether they get the data then block on a barrier operation or whether they get the data just as the barrier operation is due to finish.
So there's lots of ways to cut down on the heat on the hardware side. What about the software side? Well, competent programmers are often a good start. A million cores doesn't mean it's ok to be a million times less efficient.
Code should be tightly written and customized for the specific hardware (including network) characteristics. It should then be profiled, baked, broiled and fried until light and crispy. The programmers should then refactor the code until it's done right.
The theoretical minimum heat output from a hybrid asynchronous computer is the heat you'd generate if one core is one processing element with enough memory to perform its task. You can't get any more RISC than a single instruction. The theoretical minimum heat output from a deliberately delaying network is the heat you'd generate in queueing and bulk-delivering data such that nodes are either off or busy, they're never idle on the offchance of data coming soon.
Idle nodes are the really bad nodes. If a node cannot be used right then and is off, it consumes nothing. A node is most likely to be idle if there is simply no way of telling if it'll be assigned work or not.
The next-worst are nodes that do things too fast. Doing things too fast means the memory has to stay powered to preserve the results but nothing can consume the results any time soon. Power consumed is not directly proportional to processor speed. It's not linear. If you detune the processor such that it always has the data ready just in time to be consumed, you will always use less power than storing.
The upshot of this is your input buffer wants to be very large (so you can bulk-receive) but the output buffer wants to be comparatively small (because you are generating results when they're needed and no sooner).
If you're really smart, you'd make the input buffer high-bandwidth and the output buffer high-speed. If you're generating just-in-time, the last thing you want is for the output to be slow in being forwarded on. On the other hand, data will be dropped into the input far faster than it can be consumed (since it's a bulk delive
I thought the tea party folk only bothered the dormice with wings and the occasional mad hatter.
Do you often write at mach 8 in pencil on the sides of armoured vehicles? And would this have anything to do with the huge gouge marks on the sides of vehicles going to Iraq and Afghanistan?
(Seriously, nobody would build a net for such things. We already have excellent experience with micrometeorite shielding, where micrometeorites are likely iron/nickel alloys - the stuff traditionally used in weapons where steel is inadequate.)
Aim it at a space museum and tell them that it's a donation. That way, they have to pick up the bill if one of their newly-acquired artefacts blows up someone important.
Seriously, though, a net idea makes no sense whatsoever. Would would make a lot more sense, since the real problem isn't the big chunks but the tiny fragments (pea-sized or smaller) is to re-use the shielding idea used on the Giotto probe when it went for Halley's comet.
Giotto's shielding was alternating layers of aluminium foil and kevlar. The foil would destroy smaller fragments, the kevlar would stop larger pieces. If it was too large for the kevlar, it had probably splintered up by that time and the second round would finish off most of the rest.
Giotto survived hellish conditions, flying directly towards a jet on Halley's Comet. It survived the encounter, though got a few hearts fluttering when it lost contact at point zero (right next to the cometary nucleus). When it restabilized and found Earth again, astronomers discovered a very large chunk had mashed into the probe and sent it spinning uncontrollably for a while, a-la Darth's Tie Fighter.
These days, we can even improve on the design, since we can add airgel and other more modern materials and we don't need a whole range of highly delicate sensors for sweeping duties.
So we pack up a cleaning robot, launch it into space, and get rid of junk that's highly deadly for spacecraft but too small to track reliably (if at all). This satellite's sole mission would be to point at where debris belts are expected to be and slam through them.
Stuff we can track just isn't an issue, but a fleck of paint a millimeter in diameter would be enough to punch a hole in a communications satellite. If we can get rid of the small junk, we'll massively improve the life-expectancy of everything up there and buy time to develop a means of eliminating the big junk (dead satellites, rocket stages, etc) which we can simply avoid for right now.
Some of the big junk we might even want to recover in some way. Not only would they be priceless museum exhibits, they're priceless scientific devices for examining the long-term effects of the solar wind, the actual density of natural space debris, long-term effects of exposure to the hard radiation and cosmic rays of space (vital to know for a Mars mission or for any permanent presence in space or another planet).
The smaller junk will really not tell us anything, so burning it up on strikes and globbing the rest into airgel and kevlar would make sense. A probe like that, once "full", could be crashed almost anywhere as what's captured is non-hazardous waste. Probably not enough to be worth recycling. Chucking it at where the plates are sliding would seem fair enough. It won't cause problems and the magma will be much more effective at natural recycling than anything we can do.
The big pieces are what most people worry about, despite the fact that we know where they all are and they're all relatively harmless. At the moment, there's not much that anyone could do, anyways. Besides micrometeorite strikes swiss-cheezing anything of size, the radiation will have made many materials extremely brittle. The Saturn V rocket pieces weren't built to last this long under such rough conditions. They might still be solid enough to move, or might break into deadly, untrackable fragments if they're even touched. Deep space is no better for cheap alloys than the deep oceans are for ships like the Titanic (made from another cheap alloy rather than high-quality iron).
What you'd ideally want to do is enclose those pieces you didn't want to preserve, then create a series of shockwaves such that each adds to the next. The whole structure will shred itself and can be cleaned up safely with the original cleaner robot I outlined.
Structures you DO want to keep are tougher. You'd need to bind them together very gently to avoid destroying anything preservable. There are resins that could be used. Once it's encased in resin, glue a heat s
Not an impossible idea.
If a rogue Russian communications satellite "accidentally" hit a Japanese whaler or three, who exactly is going to complain? The whalers would be dead, anyone who goes to Russia to complain ends up dead, and those with evidence of such a plot would likely go on the CIA's list of "people to be dead".
Besides, the Japanese can then kick up a fuss and gouge the whale-meat eaters for more cash whilst the Japanese insurance companies can claim an act of God and keep the money for the ship and the crew. Everyone wins.
You mean, if you fail to get a joke, an angel gets its wings? God, they must be a depressing lot.
Sorry, prior rock art.
Bear in mind that politicos can get voted out very easily, so tend to be nervous types when accused of something that smacks of scandal. (Widespread fraud is one thing, but accusations in the press of sponsoring pirates or spending tax dollars in bringing down Hollywood... No sane politician would take that kind of risk.)
Also bear in mind that most politicians are technically ignorant and are unlikely to know the difference between aiding and abetting in an electronic crime versus being a common carrier.
Finally, you need to also consider that these places are full of backstabbers, some likely in the pay of ISPs that would be competing with the municipal system. (If the public sector is corrupt, it's the private sector that is corrupting it.)
The French keep the best of their wine to themselves. Greece wouldn't be bad, but they keep whining about wanting their marbles back. Serbia's not a bad place, per se, but their architecture is UGLY! These are all clearly crimes against geekdom.
I wouldn't say it's meaningless. Take the known position and velocity of the asteroid, and the position and velocity of the Earth at the time of discovery.
Now, there are only two meaningful scenarios - the asteroid reached the same point at a slightly different time (resulting in an impact) OR the asteroid had a slightly different displacement but essentially the same vector (resulting in an impact).
It is NOT meaningful to give the asteroid a significantly different vector, unless you can prove it passed close to one of the gas giants and underwent a gravitational slingshot. This is because if it were on a totally different path for no obvious reason, it wouldn't be the same asteroid. Duh.
On the other hand, if this rock has been orbiting the sun for any length of time, the difference in mass and/or velocity required to have put it onto an almost identical track that did intersect the Earth would be insignificant. Well below anything we could meaningfully consider.
Ideally what you'd do is look at the time window and displacement range that would have resulted in a collision, then using the known mechanics of planetary movement, "rewind" the system as far as you can and still maintain a reasonably low margin of error. Then do the same using the actual observed values.
Anything in that range that would result in the asteroid colliding with something else before the Earth OR slingshotting off in another direction altogether OR not tracking back to (close enough) the right origin can be ignored.
Any possibility not discarded will give you a possible angle for a strike. It could have happened that way and, as far as our ability to distinguish events is concerned, what actually happened cannot be usefully distinguished. (There may well have been fragments from it that DID strike the Earth, so to call it a miss is not a given.)
This is important, why? Because it tells us a lot about how well we can predict where an asteroid will be. The more possibilities that are computationally indistinguishable, the less useful it is to claim to be able to make such a prediction.
They really needed it 250-300 million years ago though. Tweaking the impact velocity to get roughly the right values according to the article, the calculator reveals anyone on the edge of the crater would be vaporized, ripped to shreds from the pressure wave, then pulverized by the earthquake and drowned by a subsequent tsunami.
Now, THAT is what I call having a bad day.
Would you really be that upset if an asteroid flattened just about any city you cared to name in the Bible Belt, Middle East, Vichy France, Greece, Serbia, Microsoft HQ, ...
Asteroid Impact Calculator. Handy thing to have bookmarked, in the event that the astronomers see the next one from far enough off.
It's impossible to be sure what the density and angle of incidence would have been in this case, as this sort of data isn't usually published. It's also impossible to be sure of composition, as that depends on where the asteroid was from. Thus, any results you DO get from the calculator are either meaningless (too much garbage in) or extreme values only.
Having said that, such calculators are fun when they find truly massive craters. The crater under the antarctic ice, for example, is so large that the Earth was unlikely to have ever been hit by something that big in the past 4 billion years. Antarctica is very modern, in comparison.
You've not taken into consideration the fact that most humans aren't sentient enough to notice or care being hit by an asteroid. And even if they did, they have enough plastic surgery, botox and fat tissue that the asteroid would bounce off.