You cannot parallelize a serial task, any more than you can have 60 people dig one posthole in one second. On the other hand, there are MANY tasks that are inherently parallel but which are serialized because either the programmers aren't up to the task, the OS isn't up to the task or the CPU isn't up to the task.
(I don't know if kernel threads under Linux will be divided between CPUs in an SMP system, they certainly can't migrate across motherboards in any MOSIX-type project. That limits how parallel the bottlenecks in the program can ever become. And it's one of the best OS' out there.)
I've left out links to some projects, by request, but everything can be found on their homepage anyway. Anyways, it is this combination that is important, NOT one component alone.
There's probably further skew in the statistics for children born close to the same time, since there are two possible paths by which you can get both children to be the same gender and only one path for a different gender. (You can't just tally up the paths, as they're not of equal probability.) There may be all kinds of other factors which could be included. Since we've only just discovered that chimera are more common than previously thought, it seems reasonable to suggest that we don't know all the factors involved. In consequence, although there is an exact answer, it is not currently knowable beyond a certain point. Every answer given is going to be based on a model that is simplified to the point of being inexact (probably good enough, but inexact nonetheless).
I dunno. A lot of sites I visit (like the RTAI real-time Linux site) use mis-configured SSL certs. In the RTAI case, it's bothersome because I don't need encryption but I do like knowing that the file I'm getting is the file I think I'm getting.
Yes, and the French Imperialist Period, the Spanish Imperialist Period and the Portuguese Imperialist Period. The English grabbed much of North America -- eventually -- but for a long time, many places in the US were under the control of other countries - France and Spain in particular. (Which is one reason this whole immigration debate has always puzzled me, but that's another issue.)
But, yes, when using a dictionary attack, it is helpful to use the correct dictionary. US-centric excuses don't fly, for the simple reason that the FBI are there to complete a task, not merely look as if they're trying. And, frankly, given the computing power at the disposal of the FBI and the shortness of the US dictionary, how the hell did it take a whole year to try?
This does go back to the question of where the divide should be between personal safeguards and collective safeguards. These two will ALWAYS be in opposition, so you have to compromise somewhere. All of society is a compromise between these two. Should the Brazilian authorities even have the right to see what's on the hard drive? Yes/No/Maybe? All depends on where you draw that line. Should an individual have to encrypt data to be safe? Or should the authorities have the right to break any such safeguards? This is not a trivial issue.
It has happened in computing. The advent of multi-tasking on single-processor machines, the advent of machine-independent source code, etc - these all showed how to overcome the limitations of the models of computing, the paradigms if you will, of the past. Plan9, BeOS, Java, Erlang, Occam - these all made exceptionally good attempts at producing comparable revolutions in the industry. In practice, in the niches they are ideally suited to they have become the preferred model, but not so much outside of those constraints. They are the Ideal Gas Laws or the Newtonian Mechanics of computing. Correct, within constraints.
(This tells me that there is no all-encompassing model that is "correct", that the more generic practices have enough exceptions for these niches to develop.)
Specific programs are like specific cases in physics. A program that appears 100% sound but is verifiably flawed is comparable to watching liquid helium appear to defy the laws of gravity by climbing up over surfaces. It may help you discover how/why/where the model you are working on is flawed, but it is not the model itself.
Now we do have some very good models for computing - Z and Object Z are extremely powerful. Unfortunately, they are about as useful (in practical terms) as using Quantum Mechanics to forecast the weather. Nobody has found a way to utilize them effectively on any program of any significant scale, although I personally am utterly convinced this would be possible if we had some additional tools. If Z is QM, then there may be a parallel to GR, something functionally close - or identical to - Z, but on the macro scale not the micro scale.
You only have to glance at arXiv to realize that theory in computing is evolving at a rapid rate, BUT = and this is the key part I cannot emphasize enough = theory is so so horribly backwards at this point. It is only in the last year or so that standards bodies even started drawing up how to write safe programs! This is, what, 62 years since the first stored-program digital computer. It has taken 62 years to figure out we need some standards documents on how to avoid the problems that have bedeviled computing for pretty much all of those 62 years. Note that we don't currently have a unified theory on any of this - the document was written by a standards body with assistance from outside comments. If we had solid, practical theory on any of the specifics, the standards body wouldn't have needed outside assistance. In fact, if we'd had solid, practical theory, then aside from writing up that theory as a single corpus of text, we wouldn't have even needed a standards body at all.
Conclusion: The field is a mess. The saying that "if builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization" is pithy but has a point. All programmers =are= wrong in some sense, in the way they write code, but until someone discovers what "right" actually means, let alone what it is, programmers will continue to write programs the way that they are.
If you can discover the GR of Good Programming, or even discover as-yet unknown non-trivial constraints on it, you will truly have learned. You'd also be the computing world's Einstein compared to Alan Turing's Newton. If you can discover the Grand Unified Theory of computing - assuming that the Halting Problem doesn't prohibit us from having one - then you will transform the field outside of anything we can currently imagine. THAT is the kind of learning that happens but once in a hundred years, if that. (If we use the ABC as the benchmark for this, I wouldn't expect a transformation on that scale for another 25 years going from the ABC, 38 from the Manchester Mk. 1.)
Fixing X, on the other hand, is not really any more exciting than finding how to modify the ideal gas laws to handle some specific non-ideal gas. Useful if that's what you're working with, but not really a learning experience.
Since every theory is a simplified model, every theory has problems. Sometimes the model works just fine at the resolution and scope for which it is intended (eg: Hooke's Law). It's the cases where you know it's broken within the bounds it should be working for, but you don't know where or why, that are the exciting ones. In the case of relativity, we know it's incompatible with QM at some level that includes gravity but may extend beyond that. We now know that it also has problems with neutrino mass. It may be that relativity can be fixed - at least for neutrinos - but either relativity or QM (or maybe both) =must= break down entirely within their intended scope in a way that is irretrievable. But nobody knows which, when, why or how.
But this is the fun of science! Science would have no purpose if it weren't for the ferreting out of the glitches and flaws in theories, fixing them and testing them to destruction all over again. We learn so little by being right in comparison to what we learn when we're wrong.
As RAM gets ever-larger, densities get ever-greater, and the energy requirements for corruption get ever-smaller, the amount of error-correction needed is going to increase. That seems obvious. Well, to an extent. There are space-rated chips that use lead-lined casing to make them radiation-resistant. Having the motherboard run cooler will decrease the thermally-generated random noise in the system. If you're using a full-immersion system, the coolant might easily absorb some of the cosmic rays not otherwise blocked. So you have plenty of options in that direction.
If you are a member of a professional society (I'm a member of the Institute of Mathematics and its Applications), then see if it is something they will publish. The benefit of this is that professional societies have their own criteria when it comes to deciding who is a reputable source - and that criteria is usually built into the membership in the first place. They are the scientific/academic equivalent of guilds and membership of one is often highly desirable. If you're good enough to write publishable papers of interest, you really should belong to one.
If you belong to any professional organizations with standing in the academic community, then getting the stamp of approval from that organization can make a huge difference in how a paper is received.
If you know someone with standing in the academic community, then have them edit the paper and submit it as a joint paper. Their credibility will help carry the day, but you get the credit.
You can't really do that. The Government outsources to the private sector, and that means you have to have Internet connectivity to access a lot of the facilities that Government centres use. Even when resources are Government-owned, they're scattered across the country. With the Internet itself outsourced, there isn't a Government-owned network to connect these resources together.
Unplugging a NASA centre would do more than just stop you getting Hubble pictures - it would essentially shut down all work there indefinitely.
Installing intrusion detection and countermeasures software, IPSec, IPv6, mandatory access controls on network connections, etc, is much more productive. It provides all of the security you need and all of the access you need. And it really isn't that hard to set up.
You just need a few quadrillion tonnes of hydrogen.
Ok, if you want something a little smaller, then let's look at the problem. Ignition can now be done. Lots of ways to ignite fusion. A sustained reaction is harder. However, as a general rule, in other domains when instabilities have appeared to be a problem, it is the instabilities that proved to be the solution. Instead of working to eliminate them, perhaps they could be used as a pump mechanism to draw in new fuel and expel the helium produced.
I actually read the bill, rather than some blogger's take on some paranoid's interpretation of the bill. It makes no mention of a kill switch. Rather, it states that sensitive sites aught to have adequate protection against attack. That is so very, very different. Less news-ish, less sensational, but actually far more interesting.
Besides, the Government has had a position for an Internet Czar for about a decade now. Last one quit a while back, but the position exists. Why should it matter if they actually fill the position?
Yes, they are, but that doesn't make them correct and it doesn't mean anyone can be certain of their correctness, unless they spend time analyzing all the code arcs and constructing the model they actually use (versus the model intended by the author(s)) and =then= comparing that model against the formulation of the Navier-Stokes equation within the specific parameters concerned. (Almost nobody implements the generic equations, any CFD you find is going to be a simplified special-case version.)
Now, if you were using CFDs to model how air flowed through a computer case, you probably aren't going to be worried if the numbers are a bit off. What matters is that there's no dead air and that there's a fairly high air-flow over the hotter components. In those cases, you don't give a damn about mathematically perfect models. If you want to model canal erosion, you don't really care that much if the actual erosion is going to be three feet further downstream, just so long as you get the general vicinity. Good enough works for these cases.
Airfoils - that's another matter. You need a much higher level of correctness, because you're dealing with a much more compact and much more complex surface. (You can download 1,500+ standard airfoils with specific characteristics - hardly necessary if this stuff was easy.)
NASA has several Open Source CFD packages. Unlike the ones developed by the regular OSS community (which may technically be superior), NASA Langley's CFDs are used by engineers there in real aircraft design. No matter what problems there may be (and there are sure to be some), they have to be "good enough" for real-world commercial aviation. That is certainly good enough for a physics lab.
The problem with other CFD packages is that even if they produce good results, unless you analyze the code, you can't be certain if the results are scientifically correct. Personally, I like programs like Gerris and some of the other packages out there, but I can't be certain of their correctness.
As a complete aside, there's a fascinating story emerging over amateur fusion scientists. Apparently, ITER expects amateurs to make some useful discoveries, and several amateurs have made claims of achieving some nuclear fusion events. This would put fusion technology in the same state as garage computing was in the early 1970s.
None of those are real data from the computer's standpoint. That is merely presentation information. To a computer, the only thing that is "real" is that facet of the data that the computer can directly understand. A value is a value, but to a computer a name is also a value, just a badly-stored one.
From a computer's standpoint, you have discrete objects, the need to ensure a new object is also discrete, and the ability to select/update/delete the object(s) you want and no others. Also from a computer's standpoint, fixed-size objects are faster to handle than variable-sized objects - no garbage-collection, no fragmentation, you can hash directly to the start of a record, etc.
If you want to compare two names - say, "Fred Blogg" and "Fred Bloggs", you could go through sequentially until you reach the last byte and see the difference. Or you could load two unsigned integers and compare those. One uses a lot more compute cycles, a lot more I/O and a lot more buffer space. The other is a single opcode on the CPU.
How would you actually implement this? Well, the simplest method is your basic data dictionary. Two columns - a unique ID and a string object that represents a discrete object. A table of people's names and addresses would then have your key field as normal, a unique ID pointing to the name in a standardized format, a unique ID pointing to the first line of the address, etc. This is how some compilers work - tokenizing by discrete object, storing the object itself in a dictionary and then just using the token thereafter. It's only inefficient when you are doing a lot of I/O with the user, because you've so many tokens to translate. If most of the crunching is internal, it's very very fast.
A slightly improved version would have an additional table which allows you to specify a binding between tokens. Since a street is unlikely to move very often, comparing a series of tokens for each line - whilst a HELL of a lot better than comparing each character - is still more than you need. So you now have two dictionary tables - one for atomic data and one for composite data. This allows you to improve the granularity on the atomic dictionary some (though you don't want it so fine-grained that the expense of the searches overwhelms the benefits of the tokenizing).
There MAY be some benefits in splitting the atomic dictionary up by types of data, but probably not a whole lot. If related objects are close in the dictionary, then you can exploit that relationship by performing relatively simple SELECTs - it'll be cheaper to get back more than you want than to get each item individually. You can also reduce seek times, which have always been database killers. The only time you'd really get a benefit is if there are multiple groups of object types between which there is no relationship whatsoever. If you've totally unrelated data, then splitting the data up makes some sense. Entities and their relationships in a database should reflect -something-. If an atomic dictionary tries to pack utterly unrelated things together, then it is not representing a "something" but rather a mashed-up view of several somethings.
Now, you'll find some of what I've written in any standard DB text. The rest you'll find scattered between programming manuals (especially when considering when to use stack vs. heap), compiler manuals and rule-of-thumb guides on how to squeeze out every last drop from the CPU and data bus.
Slashdot Mirror
You cannot parallelize a serial task, any more than you can have 60 people dig one posthole in one second. On the other hand, there are MANY tasks that are inherently parallel but which are serialized because either the programmers aren't up to the task, the OS isn't up to the task or the CPU isn't up to the task.
(I don't know if kernel threads under Linux will be divided between CPUs in an SMP system, they certainly can't migrate across motherboards in any MOSIX-type project. That limits how parallel the bottlenecks in the program can ever become. And it's one of the best OS' out there.)
I've left out links to some projects, by request, but everything can be found on their homepage anyway. Anyways, it is this combination that is important, NOT one component alone.
There's probably further skew in the statistics for children born close to the same time, since there are two possible paths by which you can get both children to be the same gender and only one path for a different gender. (You can't just tally up the paths, as they're not of equal probability.) There may be all kinds of other factors which could be included. Since we've only just discovered that chimera are more common than previously thought, it seems reasonable to suggest that we don't know all the factors involved. In consequence, although there is an exact answer, it is not currently knowable beyond a certain point. Every answer given is going to be based on a model that is simplified to the point of being inexact (probably good enough, but inexact nonetheless).
I dunno. A lot of sites I visit (like the RTAI real-time Linux site) use mis-configured SSL certs. In the RTAI case, it's bothersome because I don't need encryption but I do like knowing that the file I'm getting is the file I think I'm getting.
Yes, and the French Imperialist Period, the Spanish Imperialist Period and the Portuguese Imperialist Period. The English grabbed much of North America -- eventually -- but for a long time, many places in the US were under the control of other countries - France and Spain in particular. (Which is one reason this whole immigration debate has always puzzled me, but that's another issue.)
But, yes, when using a dictionary attack, it is helpful to use the correct dictionary. US-centric excuses don't fly, for the simple reason that the FBI are there to complete a task, not merely look as if they're trying. And, frankly, given the computing power at the disposal of the FBI and the shortness of the US dictionary, how the hell did it take a whole year to try?
This does go back to the question of where the divide should be between personal safeguards and collective safeguards. These two will ALWAYS be in opposition, so you have to compromise somewhere. All of society is a compromise between these two. Should the Brazilian authorities even have the right to see what's on the hard drive? Yes/No/Maybe? All depends on where you draw that line. Should an individual have to encrypt data to be safe? Or should the authorities have the right to break any such safeguards? This is not a trivial issue.
Oh, well, in that case the lack of balanced parentheses is a business model and it's doubtful that could be patented.
Because much singing and dancing was involved around the issues.
Given the stuff geeks drink, I think "consciousness" may be incorrect word usage.
Nonono. It was actually a mistype. The Supremes have patented the Bikini.
Since LISP is based on a stack machine, and since being tied to a machine is one of the tests, it would follow LISP programs are always patentable.
It has happened in computing. The advent of multi-tasking on single-processor machines, the advent of machine-independent source code, etc - these all showed how to overcome the limitations of the models of computing, the paradigms if you will, of the past. Plan9, BeOS, Java, Erlang, Occam - these all made exceptionally good attempts at producing comparable revolutions in the industry. In practice, in the niches they are ideally suited to they have become the preferred model, but not so much outside of those constraints. They are the Ideal Gas Laws or the Newtonian Mechanics of computing. Correct, within constraints.
(This tells me that there is no all-encompassing model that is "correct", that the more generic practices have enough exceptions for these niches to develop.)
Specific programs are like specific cases in physics. A program that appears 100% sound but is verifiably flawed is comparable to watching liquid helium appear to defy the laws of gravity by climbing up over surfaces. It may help you discover how/why/where the model you are working on is flawed, but it is not the model itself.
Now we do have some very good models for computing - Z and Object Z are extremely powerful. Unfortunately, they are about as useful (in practical terms) as using Quantum Mechanics to forecast the weather. Nobody has found a way to utilize them effectively on any program of any significant scale, although I personally am utterly convinced this would be possible if we had some additional tools. If Z is QM, then there may be a parallel to GR, something functionally close - or identical to - Z, but on the macro scale not the micro scale.
You only have to glance at arXiv to realize that theory in computing is evolving at a rapid rate, BUT = and this is the key part I cannot emphasize enough = theory is so so horribly backwards at this point. It is only in the last year or so that standards bodies even started drawing up how to write safe programs! This is, what, 62 years since the first stored-program digital computer. It has taken 62 years to figure out we need some standards documents on how to avoid the problems that have bedeviled computing for pretty much all of those 62 years. Note that we don't currently have a unified theory on any of this - the document was written by a standards body with assistance from outside comments. If we had solid, practical theory on any of the specifics, the standards body wouldn't have needed outside assistance. In fact, if we'd had solid, practical theory, then aside from writing up that theory as a single corpus of text, we wouldn't have even needed a standards body at all.
Conclusion: The field is a mess. The saying that "if builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization" is pithy but has a point. All programmers =are= wrong in some sense, in the way they write code, but until someone discovers what "right" actually means, let alone what it is, programmers will continue to write programs the way that they are.
If you can discover the GR of Good Programming, or even discover as-yet unknown non-trivial constraints on it, you will truly have learned. You'd also be the computing world's Einstein compared to Alan Turing's Newton. If you can discover the Grand Unified Theory of computing - assuming that the Halting Problem doesn't prohibit us from having one - then you will transform the field outside of anything we can currently imagine. THAT is the kind of learning that happens but once in a hundred years, if that. (If we use the ABC as the benchmark for this, I wouldn't expect a transformation on that scale for another 25 years going from the ABC, 38 from the Manchester Mk. 1.)
Fixing X, on the other hand, is not really any more exciting than finding how to modify the ideal gas laws to handle some specific non-ideal gas. Useful if that's what you're working with, but not really a learning experience.
Since every theory is a simplified model, every theory has problems. Sometimes the model works just fine at the resolution and scope for which it is intended (eg: Hooke's Law). It's the cases where you know it's broken within the bounds it should be working for, but you don't know where or why, that are the exciting ones. In the case of relativity, we know it's incompatible with QM at some level that includes gravity but may extend beyond that. We now know that it also has problems with neutrino mass. It may be that relativity can be fixed - at least for neutrinos - but either relativity or QM (or maybe both) =must= break down entirely within their intended scope in a way that is irretrievable. But nobody knows which, when, why or how.
But this is the fun of science! Science would have no purpose if it weren't for the ferreting out of the glitches and flaws in theories, fixing them and testing them to destruction all over again. We learn so little by being right in comparison to what we learn when we're wrong.
As RAM gets ever-larger, densities get ever-greater, and the energy requirements for corruption get ever-smaller, the amount of error-correction needed is going to increase. That seems obvious. Well, to an extent. There are space-rated chips that use lead-lined casing to make them radiation-resistant. Having the motherboard run cooler will decrease the thermally-generated random noise in the system. If you're using a full-immersion system, the coolant might easily absorb some of the cosmic rays not otherwise blocked. So you have plenty of options in that direction.
Well, yeah, that is perfectly true. Which is why the bill has nothing in it about screwing up the rest of the country.
If you are a member of a professional society (I'm a member of the Institute of Mathematics and its Applications), then see if it is something they will publish. The benefit of this is that professional societies have their own criteria when it comes to deciding who is a reputable source - and that criteria is usually built into the membership in the first place. They are the scientific/academic equivalent of guilds and membership of one is often highly desirable. If you're good enough to write publishable papers of interest, you really should belong to one.
If you belong to any professional organizations with standing in the academic community, then getting the stamp of approval from that organization can make a huge difference in how a paper is received.
If you know someone with standing in the academic community, then have them edit the paper and submit it as a joint paper. Their credibility will help carry the day, but you get the credit.
You can't really do that. The Government outsources to the private sector, and that means you have to have Internet connectivity to access a lot of the facilities that Government centres use. Even when resources are Government-owned, they're scattered across the country. With the Internet itself outsourced, there isn't a Government-owned network to connect these resources together.
Unplugging a NASA centre would do more than just stop you getting Hubble pictures - it would essentially shut down all work there indefinitely.
Installing intrusion detection and countermeasures software, IPSec, IPv6, mandatory access controls on network connections, etc, is much more productive. It provides all of the security you need and all of the access you need. And it really isn't that hard to set up.
You just need a few quadrillion tonnes of hydrogen.
Ok, if you want something a little smaller, then let's look at the problem. Ignition can now be done. Lots of ways to ignite fusion. A sustained reaction is harder. However, as a general rule, in other domains when instabilities have appeared to be a problem, it is the instabilities that proved to be the solution. Instead of working to eliminate them, perhaps they could be used as a pump mechanism to draw in new fuel and expel the helium produced.
I actually read the bill, rather than some blogger's take on some paranoid's interpretation of the bill. It makes no mention of a kill switch. Rather, it states that sensitive sites aught to have adequate protection against attack. That is so very, very different. Less news-ish, less sensational, but actually far more interesting.
Besides, the Government has had a position for an Internet Czar for about a decade now. Last one quit a while back, but the position exists. Why should it matter if they actually fill the position?
Of course, simulation is only one solution.
For visuals, UIUC's Airfoil Data Site is a good place to start.
Yes, they are, but that doesn't make them correct and it doesn't mean anyone can be certain of their correctness, unless they spend time analyzing all the code arcs and constructing the model they actually use (versus the model intended by the author(s)) and =then= comparing that model against the formulation of the Navier-Stokes equation within the specific parameters concerned. (Almost nobody implements the generic equations, any CFD you find is going to be a simplified special-case version.)
Now, if you were using CFDs to model how air flowed through a computer case, you probably aren't going to be worried if the numbers are a bit off. What matters is that there's no dead air and that there's a fairly high air-flow over the hotter components. In those cases, you don't give a damn about mathematically perfect models. If you want to model canal erosion, you don't really care that much if the actual erosion is going to be three feet further downstream, just so long as you get the general vicinity. Good enough works for these cases.
Airfoils - that's another matter. You need a much higher level of correctness, because you're dealing with a much more compact and much more complex surface. (You can download 1,500+ standard airfoils with specific characteristics - hardly necessary if this stuff was easy.)
NASA has several Open Source CFD packages. Unlike the ones developed by the regular OSS community (which may technically be superior), NASA Langley's CFDs are used by engineers there in real aircraft design. No matter what problems there may be (and there are sure to be some), they have to be "good enough" for real-world commercial aviation. That is certainly good enough for a physics lab.
The problem with other CFD packages is that even if they produce good results, unless you analyze the code, you can't be certain if the results are scientifically correct. Personally, I like programs like Gerris and some of the other packages out there, but I can't be certain of their correctness.
As a complete aside, there's a fascinating story emerging over amateur fusion scientists. Apparently, ITER expects amateurs to make some useful discoveries, and several amateurs have made claims of achieving some nuclear fusion events. This would put fusion technology in the same state as garage computing was in the early 1970s.
I use XV. The fish is cool.
Duh. That should be obvious. Geeks don't get laid.
None of those are real data from the computer's standpoint. That is merely presentation information. To a computer, the only thing that is "real" is that facet of the data that the computer can directly understand. A value is a value, but to a computer a name is also a value, just a badly-stored one.
From a computer's standpoint, you have discrete objects, the need to ensure a new object is also discrete, and the ability to select/update/delete the object(s) you want and no others. Also from a computer's standpoint, fixed-size objects are faster to handle than variable-sized objects - no garbage-collection, no fragmentation, you can hash directly to the start of a record, etc.
If you want to compare two names - say, "Fred Blogg" and "Fred Bloggs", you could go through sequentially until you reach the last byte and see the difference. Or you could load two unsigned integers and compare those. One uses a lot more compute cycles, a lot more I/O and a lot more buffer space. The other is a single opcode on the CPU.
How would you actually implement this? Well, the simplest method is your basic data dictionary. Two columns - a unique ID and a string object that represents a discrete object. A table of people's names and addresses would then have your key field as normal, a unique ID pointing to the name in a standardized format, a unique ID pointing to the first line of the address, etc. This is how some compilers work - tokenizing by discrete object, storing the object itself in a dictionary and then just using the token thereafter. It's only inefficient when you are doing a lot of I/O with the user, because you've so many tokens to translate. If most of the crunching is internal, it's very very fast.
A slightly improved version would have an additional table which allows you to specify a binding between tokens. Since a street is unlikely to move very often, comparing a series of tokens for each line - whilst a HELL of a lot better than comparing each character - is still more than you need. So you now have two dictionary tables - one for atomic data and one for composite data. This allows you to improve the granularity on the atomic dictionary some (though you don't want it so fine-grained that the expense of the searches overwhelms the benefits of the tokenizing).
There MAY be some benefits in splitting the atomic dictionary up by types of data, but probably not a whole lot. If related objects are close in the dictionary, then you can exploit that relationship by performing relatively simple SELECTs - it'll be cheaper to get back more than you want than to get each item individually. You can also reduce seek times, which have always been database killers. The only time you'd really get a benefit is if there are multiple groups of object types between which there is no relationship whatsoever. If you've totally unrelated data, then splitting the data up makes some sense. Entities and their relationships in a database should reflect -something-. If an atomic dictionary tries to pack utterly unrelated things together, then it is not representing a "something" but rather a mashed-up view of several somethings.
Now, you'll find some of what I've written in any standard DB text. The rest you'll find scattered between programming manuals (especially when considering when to use stack vs. heap), compiler manuals and rule-of-thumb guides on how to squeeze out every last drop from the CPU and data bus.