You snipped "running a database server" from the original post. Yes, UltraSPARC III is poor for numeric computing, and Power4 is also crippled because the dual-core CPUs share cache. But running databases, the top HP Itanium 2 system just nudges out the top IBM Power4 system (I can't find the reference, sorry - both were 32 CPU systems I think).
Sun declines to participate in those benchmarks because a) officially they don't think they reflect expected workload, or b) they do too badly. On the other hand, the 128 CPU Fujitsu SPARC-64 still beats them both.
The point being, running databases as the original poster was talking about, the Itanium 2 is nothing special.
Most home users are going to see a performance drop from 64 bits. 64-bit code needs 8 bytes to hold every pointer.
Not quite - the registers hold the pointer, the code usually only holds an offset which is added to a base register. The offset is often smaller (most RISC processors only load 16 bits of a constant at a time), but this depends on the execution model that's used - memory segments can be limited to 4GB for user programs, so offsets don't need to be larger than 32 bits, even on a 64 bit CPU.
Also, some CPUs have 32 bit modes - AMD's x86-64 actually lets 32-bit and 64-bit code segments share the CPU (the OS must be 64 bits for this to work).
How is anything Transmeta done even remotely close to something of this level?
It has the potential. Revolutions aren't always noticed right away, but the idea of translating the instruction from one CPU to another, and running almost the same speed as the original, is something that has never been done both commercially and successfully before.
The implications of this are more profound than it first seems. First, this removes the requirement that CPUs be particularly compatible with anything. In fact, the some of the Transmeta CPUs aren't compatible with each other - yet they all run the same programs.
This frees up the design incredibly. For comparison, the Transmeta CPUs (which Linus writes code morphing software for) and the IA-64 (which he thinks is crap) are both VLIW architectures, with about the same issue width and number of registers, and so on. They are more similar to each other than either is to the x86.
However, the Transmeta CPUs leave a lot of things like the ordering of instructions and handing of exceptions exposed to software. The code morpher takes care of those jagged edges, making them disappear - as a result, the CPU implementation is very simple but very effective.
In comparison, the IA-64 needs to explicitly specify what instruction combinations are allowable in the input packets, needs to store exception information (there are at least 128 bits that do nothing but remember if an exception happened when using a register), and so on. The result is that the sharp jaggie bits now look like soft jaggie bits, yet the machanisms needed to keep the whole thing consistant bogs it down. I don't think an IA-64 could be implemented at all in a CPU as simple as Transmeta's.
The second important thing is that the CPU is not tied to a single instruction set. I think Transmeta has made a mistake in not including support for other instruction sets, but it has demonstrated that it can. I remember reading that the first demo showing a Transmeta CPU running Doom was written in x86 machine language, except for the inner loop which was written in Java bytecode. Every iteration the CPU+software switched instruction sets without missing a frame.
If Transmeta is aiming for the low power, embedded marketplace, the dominant player there is ARM, not x86. If they could offer the ability to mix popular embedded ARM code with popular desktop x86 code, they might have a real winner there.
But as yet, the revolutionary aspects of the Transmeta designs are unexploited, and mostly even unnoticed. But I'm convinced that even if they don't do it, it will get done another way, whether it's Java,.NET, some Open Source project (Parrot?), or something that's not even noticed yet (Tao Group Elate?). But I think they are revolutionary.
Optimizations done at compile time are far better than optimizations done at runtime.
Er, you're aware that one does not exclude the other?
Compile time optimizations can take more of the program structure into account, so can be really big wins when they're done well. But they can't take into account program behaviour. For example, the compiler can only tell that there's an if statement in the middle of a loop. The CPU can tell that 99% of the time it is false, so it can skip it and only go back if needed (profiling optimizers can do something similar, as can recompilers and translators - like Java HotSpot JVM and the Transmeta CodeMorpher (Linus works on that), which will both stop and optimize if a block of code is executed a lot).
The compiler is also nearly clueless about the structure of the CPU. Although the compiler can assume a CPU has a floating point unit, it has no idea if it has two that can execute in parallel, or how long the pipelines are. Modern CPUs can re-order instructions to match the actual hardware. The hardware can even add registers by "renaming" them - the x86 instruction set has eight general purpose registers, but the CPUs usually have dozens, so if a group of instructions share a register but don't share data, the CPU can give two independent registers the same "name" as far as the instructions are concerned, and execute both groups at the same time.
Yes, a compiler might assign registers more effectively, but only if you knew before hand what CPU was going to be used.
Compilers can group instructions together in such a way that the CPU is more likely to detect the right patterns. In this case, the optimizations are "implied", and a smart CPU will pick up on them and run faster, a dumb CPU won't, but it normally won't hurt performance. This means that you can have both high level, compiler optimizations as well as low level, CPU optimizations that the compiler could not perform.
Doesn't have what you'd call facts or information. And even its facts aren't that good (e.g. Buran wasn't an "exact replica" of the STS - though it looked similar, Buran didn't even have main engines, it was strapped to a rocket).
Governments didn't build the first airplane, but they did contribute a lot of the important research to development of them, especially when commercial development was satisfied but government interests were not - the reasons for the initial X-planes were entirely because the Air Force needed to learn how to make things do things that aerospace companies couldn't, like break the sound barrier, or fly without wings.
The technology sometimes got developed into real products, sometimes just sat on a shelf waiting until someone could use it.
The real reason for the Space Shuttle was to learn how to build and operate a Space Shuttle, because there had never been anything like it before. I'll grant, it wasn't the most efficient way of doing it, or the best possible vehicle, but it does remain the only one - even as it is, the only Space Shuttle is the best Space Shuttle.
We know - now - that it can be done better. Great, build upon that. There are many ways, from government doing it itself (probably not the best way, but would get it done), to joint ventures or assistance (often break down from disagreements ovr design or funding, like the Lockheed VentuStar), to just throwing the technology out and letting the free market do something with it (there's no market at the moment, so that's not going to happen).
The government building the Space Shuttle was one way of doing it, and probably the only viable one when it was proposed, because the idea of a reusable space vehicle was merely speculation - nobody knew if it would work, how expensive it would be, how reliable, and so on. After it was done, you learn the lessons, and you can try again - if you have the money. The Soviet Union did, for a while, but the Buran only flew once - it would have given a lot more information on what works and what doesn't if it had kept flying, but since it didn't, there's a new mindset that the Space Shuttle is the "only way" to do it. Government involvement will be necessary to get beyond that now, but at least now there is more than the government-only option.
And now that the Space Shuttle exists, there's also a benchmark to measure against, as a target to exceed. Before, the goal was basically just to get it to fly, and not much more. Now there are targets we know are more reasonable based on this experience.
As an aside, the Lockheed "VentuStar" program looked promising, but what would have been better is to fund prototypes for all three proposals (low-tech DC-X, medium tech Shuttle II, high tech VentuStar), and then let them compete. It would also have taken immense amounts of money though, but that might be what's needed to get the market for reusable vehicles started...
Have we invented the last invention, because machines are so smart they do the inventing for us? No, we have not.
I think this might not be the real point. The point is that at some point, a spiral will start in which the capabilities for invention, either done by machine or augmented by them, will surpass what can be done by humans without them. And in some areas it has - for example it would just not be possible to design a Pentium 4 processor without the computing power of Pentium III processors to automate and test such an immense design.
This capability lets each new increment in technology be created faster than the previous increment of the same size. Or to put it another way, each new generation has a greater increase in complexity over the generation before than that generation had over the one even earlier, even if the time required per generation is the same. Either way, the rate of new technological complexity is increasing as a result of technological complexity.
Whether it's computer-assisted humans, or computers doing it independently, change is happening so fast that sometimes it's almost finished before anyone knows what's happened - look at the Internet explosion over the past five years for something that has literally replaced entire social infrastructures (e.g. know anyone who's bought an encyclopaedia set lately?).
The dust han't even settled and now people are developing an entire layer of technology that works on top of that.
I don't know how fast technological progress is going to get, but frankly the potential scares me a little - I don't think we've done a good job of keeping up with and wisely using new technology so far. But then, new technology is being developed to help us all solve that problem too - which is the point here.
Still, it is just starting, so you can still look for decade-long periods for the development of things for quite a while yet. The point is that the trend is accelerating.
I wrote a silly story in the early 90's where this happened - an AI rewrote eventually itself to work better, despite the protests of the programmer, who was emotionally a bit unstable. He had fallen in love with the program, and had deep feelings of guilt over his attraction to a real woman.
There was a bunch of slapstick as the AI was "killed" by someone burying an axe into the IBM DASD the program was stored on - luckily it was friends with a Cray who had extra storage and processing capacity...
The Yugoslavian Mafia got involved too. Fun story.
I think they're primarily useful as an equivalent to try {} finally {} in languages that support exceptions (obviously C doesn't). If a condition fails just goto the end, where the cleanup code is guaranteed to run.
In those cases, gotos can almost always be replaced by returns, kind of like this - original code:
procedure process_file...
open file
if failed, return ...
read something
if failed goto cleanup ...
write something
if failed goto cleanup ...
cleanup:
close file
This becomes:
procedure process_file...
open file
if failed, return
call process_file_data
close file
procedure process_file_data...
...
read something
if failed return ...
write something
if failed return ...
I think it makes for a much cleaner version.
Gotos can also be mostly eliminated using labeled breaks (which C doesn't have), or redesigning things - I find that excessive use of gotos means that you're really trying to design a state machine. You can do that with gotos, or you can use a loop containing a state variable, and a switch() statement listing the states.
So far I've never found a situation where a goto couldn't be avoided while still writing clear, efficient code. Maybe I will, but those three techniques (returns, breaks, and state machines) have held up so far.
So, instead of being asked to sign up with a mortgage or buy siding on the phone, they just want me to set up an appointment with a friendly sales representative to discuss the matter in person.
So set up an appointment. And don't show up.
Or be elsewhere if it's at your home.
It's their money - if they want to waste it on you, let them.
There is no magic formula for producing quality software in a reasonable amount of time yet, but XP is another step in the right direction.
Programming methodologies are like diets. The fundamentals are always the same - eat better, exercize more. Diet/fitness plans are just methodologies for keeping track of that, and making sure you get around to doing what you know you should anyway - using food points, tracking calories burned, whatever. All have trade-offs and different emphasis, and some are more suitable for some people than others. Of course, if you have enough self-discipline and aren't distracted by other things in your life, you don't need a diet plan, you can simply keep yourself healthy on your own.
Programming methodologies are the same thing. I haven't seen anything in XP that I haven't seen elsewhere, using different words (for example, Steve McConnel's excellent Code Complete). Again, all methodologies have trade-offs and different emphasis, and some are more suitable for some projects than others, and again if your developers have enough self discipline they know how to do a project properly and don't need a set of rules to follow.
For years Motorolla talked about another generation of chip. They had serious problems and then cut off development until very recently. That was the problem with the "G5".
As far as I know, the "problem" with the G5 wasn't the core, it was the bus. Motorola makes almost all its money selling CPUs for embedded systems, where system cost is more important than for desktops, and a large part of system cost can be the bus complexity. Motorola did get the G5s working, and as fast as promised, but with the existing cheap bus that wouldn't have done Apple much good.
Apple had specifications for a CPU bus that would meet its needs, but Motorola couldn't justify the expense of making a special version of the G5 in relatively small numbers, for one customer (who, face it, would just keep asking for special versions of any good future PowerPC model - not just a one time cost).
So Motorola kept its G5 design until the embedded market is ready for it, and Apple took its bus elsewhere.
IBM is developing the PowerPC 970 for its own use - specifically in "blade" servers, which need a lower power, cheaper and cooler CPU, while keeping
up performance, which is exactly the same needs that Apple has. I don't know if Apple is going to get its bus in the 970, but it would be a simpler design than the POWER4 which actually uses two busses, one in and one out, allowing the CPU to keep sending addresses out even before it gets the data back in.
Either bus would be very fast. Motorola will ba happy it doesn't have to make custom CPUs, IBM will be happy it can sell more 970s, and Apple will be pissed at Motorola but will at least be back in the performance race again so it'll end up happy. Finally.
I visited the Canadian Currency Museum in Ottawa recently. The history of money is pretty fascinating.
On the question of printing your own money, this used to be standard practice in Canada. Since the only "real" currency was coins, banks would print paper bills representing a given amount of coins (always promising to be "redeemable" until sometime in the 20th century). The Bank of Canada was set up to provide a central source of paper currenty, and to provide confidence in the currency after some issuers went bankrupt - and obviously when anyone can print their own money, counterfitting is pretty easy - you don't even need to copy a real bill, just make up a real-sounding bank name. For legitimate banks, it was fairly profitable (due to complex economics I don't fully understand), and there's nothing stopping banks from issuing their own currency if they want to, except that likely nobody will want it.
In French Canada during shortages (such as war), playing cards were used as money (signed by an appropriate authority, such as a colonial governor).
Currently in Canada there are only two widely accepted forms of paper currency - bills from the Bank of Canada (which have iridescent patterns on the surface that can't be recreated from a printer), and Canadian Tire Money, which are really coupons that can be spent at Canadian Tire stores, but can sometimes be spent elsewhere, depending on the retailer. Canadian Tire denominations are limited to something like 50 cents.
No doubt we're going to invade Iraq to free their people and bring them democracy, right?
Actually, I think so. Sure, it may only be a side effect, but I think it will happen,
Sure - and the United State's intervention in Iran turned out so well.
The U.S govermnent is not interested in nation building (witness the total abdecation of responsibility for post-Taiban Afghanistan). The only conquered nations that produced democratic replacement governments did the work themselves.
and I think that it is actually in the West's long-term strategic interest to do so. The whole Middle East is full of disenfranchised people held in line by a combination of propaganda blaming infidels (the carrot) and secret police (the stick). It's a powder keg waiting to go off.
I'd say it's already gone off. A few times.
Just because stability in the region is in the best interests of the U.S and the world doesn't mean those in charge agree on how to accomplish it - and the current U.S administration seems to be particularly thick-headed about the value of militery intervention - ignoring things like a) terrorism was invented to get around military power - effectively, and b) large scale war hasn't been economically viable since after WW I (for example, the U.S could overwhelm China's military quickly, but the U.S economy would quickly collapse due to the dependence on imports - it would do more damage to the attacker than the victim).
I doubt Iraq will be any more democratic than Afghanistan is, or Iran or Chile or Cuba were after U.S intervention. Economic, social, political forces are far more powerful - remember, it was not U.S bombs that dismantled the Soviet Union, it was economic and political pressures from within that were responsible.
A truly democratic regime in the region will bleed off a lot of the pressure.
Like Israel? Wrong religion? How about Turkey?
Nah, it needs more than that. If you want to know what I think it needs - a free trade region. That would be the best, fastest, and surest way to promote freedom, communication, political and economic reform, and reduce historical animosities (usually people hold grudges because they don't have anything better to do - if they have the opportunity to get rich by putting aside those differences, they'll do that instead - consider Quebec separatism in Canada has been highest during economic problems, but has lately all but disappeared).
Unfortunately, even that is a long term (decades) process. The popular American "But I want it now" mindset doesn't lend itself well to this sort of foreign policy.
I'd also like to point out that metric units can also be intuitive. Celsius temperatures make a lot more sense. Freezing and boiling points at 0 and 100 make a lot more intuitive sense than 32 and 212.
I expect Farenheit was originally supposed to be based on the freezing point of pure water, rather than salt (ocean) water as it is. The difference between freezing and boiling points in Farenheit is 180 degrees - hence the name "degree" for the units.
Degrees were chosen for angles becaue it approximates the movement of the constelations (about 1 degree per night), but it's also very convenien for splitting into fractions - halfs, thirds, quarters, etc.
As for those who argue that Farenheit is superior because it's more accurate, I doubt most people could feel a difference of 1 degree C, let along 1 degree F. It only matters in situations close to freezing, such as if you're worried if ice is going to start building up on the wings of your airplane, but in that case, you could just go by half degrees C and get about the same accuracy (e.g. "one and half" vs. "thirty five" - it's also easier to visualize distance from freezing with a centigrade based scale).
The design itself came from designers at HP who estimated in 1992 that complexity would prohibit more than
4-way issue PA-RISC designs. Also, HP had just bought Cydrome which had experience in designing VLIW
systems, and engineers from VLIW producer Multiflow,. The decision was made that the PA-RISC would be
replaced with a VLIW initially called SP-PA (Super Parallel Precision Architecture) or PA-WW (Precision
Architecture-Wide Word). Intel, which had started fabricating PA-RISC CPUs for HP, was approached as a
development partner to share the cost and increase its popularity.
I got one of those lists once, and included the city where I live, saying it was "illegal to catch fish with your bare hands". Knowing someone who works at city hall, I asked - no such law.
I've seen other lists with the same law attributed to different cities.
They're a lot less funny when you know they really are too stupid to be real.
I don't think the problem is the copying of copyright material - the artists lost control of that when recording was invented. In return, they got royalty fees. The companies that turn an artist's or performer's work into a salable item also want a cut (right now, that cut is almost all of it, and you can rant about how unfair it is, but for now just say a reasonable percent is fair).
I see nothing wrong with allowing copies to be made at will, as long as there's something that administers things like royalties. Say, every time you make a copy to a networked device, that costs you a few cents, and the software works that out automatically and charges your credit card at the end of the month. If you copy to a non-networked device from a networked device, it'll only be able to play on that device, and you get charged less.
As long as you are aware of how much it costs, there is no restriction on what software you use as long as it complies. It can be something as simple as obtaining a decryption key from some service provider - the software doesn't need to keep track of anything, free/open source will work, you'd just have an account with the service company like you have with the phone company (roughly equivalent to going to some random phone and using a calling card to charge to your home number).
There would have to be something regulating this. For example, the fees should probably be only for copying, not per play. No provider should be allowed to "lock in" customers with a proprietary format, or it should be legal to convert it to another format that might charge lower fees. Regulation might be from laws, but might be from standards groups - I don't know which would be better, but there must be limits on potentially abusive behaviour. I doubt something like this could be done very quickly.
I think such a system can be alowed to be leaky, as long as it's convenient and cheap enough to use the system that it makes no real difference to the end user. Maybe your playback software could save the decryption keys, but it's just easier to have the service company manage them rather than doing it yourself, copying them between your TV, stereo, PC, Ogg player, etc. People are honest enough that they realise if they don't support the system (if it's reasonable) then they won't get the product.
I'm guessing you are an idiot who calls someone stupid because you don't immediately understand their point.
Defensive? I'll ignore the irony here and continue.
My point was that the semantic gap between the data model used in databases and the data model used in all modern programming languages - C#, Java etc. is completely unnecessary.
That's more due to the fact that most programming languages haven't advanced very much as far as being able to define how data relates to each other. Variable typing and classes are one attempt to define data integrity, but don't do much for making it simpler to manipulate it. Prolog can be thought of as a data-oriented language that addresses this problem, but I don't find it much fun - you shouldn't have to rely on side-effects to do something.
I think part of the problem is that there are two opposite forces at work - relational theory is aimed at regularizing data, while object orientation is aimed at encapsulating data with routines, and forming ad-hoc connections.
I think a better strategy than trying to slap transaction-oriented features onto ad-hoc data is to find a way to make it easier to express to compilers what you are really trying to do with data in the first place (within a relational model). As you say, "There is no reason I should need to encode my data in tables just to get atomic transactions" - you should be able to express it in your prgramming language.
The problem is when most people think "relational", they think "databases", not "data".
One more thing:
[...] don't go arround telling people they are stupid.
Why do you have this feeling that people are calling you stupid? I certainly didn't.
[...] the relational model is long overdue for the garbage pail. Modern programming languages since C have used pointers or object references. If JOIN and messing arround with tables is so good why don't we all use COBOL?"
I'm guessing you don't really know what "relational" means anyway. Lots of people don't seem to.
Basically, it means relating sets of things to other sets of things - a mathematical model. As you remember from math, a set is a collection of elements in no particular order, and in this case, the elements are tuples - an ordered list of elements (e.g. (1, "purple", squirrel) ). All the tuples a set are defined to have the same number of elements and the same semantic meaning for the positions - also known as attributes, so that you can refer to the element by the tuple attribute identifier (e.g. x.name, x.density).
Usually in databases you call the sets "tables", call the tuples "records", and call the identity of the tuple elements "columns".
There are a variety of ways of describing the relation between tuples in various sets, and you can define a set of new tuples (a result set) from the elements of tuples from related sets, perform set unions and intersections (equivalent of insert and delete records).
The elegance of this is you can define what you want, without needing to explicitly describe how to get those results. But then, without smart software, the process can be painfully slow (query optimization is the most important part of database implementation).
You can use set definitions to describe what you want to do, such as:
R = {a, b, c where a = X.a, b = X.b, c = Y.a such that X.b = Y.b}.
You can use relational algebra:
R = join(X, Y, (X.b = Y.b))[X.a, X.b, X.c]
You can use relational calculus which is what SQL looks kind of like.
Here's a suprise for you - you can represent hierarchical relationships in a relational domain. As an example, simply define the attributes of something like address:
(region description, name, parent region description, parent name)
You have a nice hierarchy of address elements. A particularly nice thing about this is that you can have different identifiers for sub-elements where appropriate - states and ZIP codes for the U.S, provinces and postal codes for Canada.
When you can add attributes like this, it helps organize things that aren't only hierarchical, or have two hierarchies. For example, armed forces personnel each have an address (one hierarchy), and a rank (another hierarchy). They've also got a service history, which is not at all hierarchical - what if you want to list everyone in Florida who served in Boznia? A hierarchy is absolutely useless for that.
This is why relational databases are so powerful (note - almost no relational databases exist, most are fairly simple approximations. Don't judge relational theory based on what Oracle or Microsoft provide).
Alternate quantum interpretation
on
E ~ mc^2
·
· Score: 1
To follow up, quantum theory usually refers to the "Copenhagen interpretation", in which particles "act like waves" in the sense that the location is tied to a probability which propogates like a wave. Strange things happen when the wave is split into two peaks - the particle ultimately ("when observed" is the term used, but you can also use the phrase "when it matters") can only exist at a point. This means when you measure one probability peak, if you don't find the particle that means you've just changed one peak to zero, and the other peak spontaneously increases - an interaction that happens instantly (faster than light).
This is the type of thing that Einstein didn't like.
An alternate is known as the "pilot wave" (pdf) interpretation. It suggests that the wave and the particle are separate - the wave is actually a force, and the particle remains a discrete thing that's pulled by that force. When that force is split, the particle follows one force wave, and the other is empty - when you eventually measure it, you've really changed nothing.
What the nature of this force is, is left unclear, but it goes get rid of the dice-throwing god. Einstein didn't like this much either.
Re:Einstein knew he was wrong
on
E ~ mc^2
·
· Score: 1
Einstein trusted relativity, because he understood it, and it was straightforward. He distrusted quantum theory (famous "God does not play dice with the universe" quote), considering it an approximation that would do until the underlying physics could be worked out. Most of his contribution to the development of quantum theory was coming up with situations where its predictions seemed wrong - "wrong" or not, quantum theory turned out to be consistant, which is what counted in the end.
As I understand it, Boeing stopped taking corporate risks when a profiteer named T Boone Pickens wanted to buy the company, and liquidate it at a profit as he had done to others. A copy of the Guardian article is here:
Since about that point, there have been two types of companies - those run by people who are genuinely dedicated to their products and customers, and will make long term investments in R&D and operations, even if the share price doesn't reflect the company's true value, and those which buy up companies with low share values, thus inflating their own shares and dismantling the long-term planning of companies they buy in exchange for short-term profit.
Incidentally, this also explains the sudden appearance of fraudelent accounting - honest companies which accurately reflected their revenue and profits had poor share performance compared to those that were dodgier, so they were bought up (and reduced to the same questionable level of accounting practices).
Boeing couldn't continue with its R&D-heavy, long range operation without becoming vulnerable to a takeover. So it reversed, and instead it began buying companies to boost its stock. Meanwhile, Airbus operated in a different financial environment, and was able to act like Boeing used to (despite being less efficient).
Slashdot Mirror
Sun declines to participate in those benchmarks because a) officially they don't think they reflect expected workload, or b) they do too badly. On the other hand, the 128 CPU Fujitsu SPARC-64 still beats them both.
The point being, running databases as the original poster was talking about, the Itanium 2 is nothing special.
Also, some CPUs have 32 bit modes - AMD's x86-64 actually lets 32-bit and 64-bit code segments share the CPU (the OS must be 64 bits for this to work).
The implications of this are more profound than it first seems. First, this removes the requirement that CPUs be particularly compatible with anything. In fact, the some of the Transmeta CPUs aren't compatible with each other - yet they all run the same programs.
This frees up the design incredibly. For comparison, the Transmeta CPUs (which Linus writes code morphing software for) and the IA-64 (which he thinks is crap) are both VLIW architectures, with about the same issue width and number of registers, and so on. They are more similar to each other than either is to the x86.
However, the Transmeta CPUs leave a lot of things like the ordering of instructions and handing of exceptions exposed to software. The code morpher takes care of those jagged edges, making them disappear - as a result, the CPU implementation is very simple but very effective.
In comparison, the IA-64 needs to explicitly specify what instruction combinations are allowable in the input packets, needs to store exception information (there are at least 128 bits that do nothing but remember if an exception happened when using a register), and so on. The result is that the sharp jaggie bits now look like soft jaggie bits, yet the machanisms needed to keep the whole thing consistant bogs it down. I don't think an IA-64 could be implemented at all in a CPU as simple as Transmeta's.
The second important thing is that the CPU is not tied to a single instruction set. I think Transmeta has made a mistake in not including support for other instruction sets, but it has demonstrated that it can. I remember reading that the first demo showing a Transmeta CPU running Doom was written in x86 machine language, except for the inner loop which was written in Java bytecode. Every iteration the CPU+software switched instruction sets without missing a frame.
If Transmeta is aiming for the low power, embedded marketplace, the dominant player there is ARM, not x86. If they could offer the ability to mix popular embedded ARM code with popular desktop x86 code, they might have a real winner there.
But as yet, the revolutionary aspects of the Transmeta designs are unexploited, and mostly even unnoticed. But I'm convinced that even if they don't do it, it will get done another way, whether it's Java, .NET, some Open Source project (Parrot?), or something that's not even noticed yet (Tao Group Elate?). But I think they are revolutionary.
Compile time optimizations can take more of the program structure into account, so can be really big wins when they're done well. But they can't take into account program behaviour. For example, the compiler can only tell that there's an if statement in the middle of a loop. The CPU can tell that 99% of the time it is false, so it can skip it and only go back if needed (profiling optimizers can do something similar, as can recompilers and translators - like Java HotSpot JVM and the Transmeta CodeMorpher (Linus works on that), which will both stop and optimize if a block of code is executed a lot).
The compiler is also nearly clueless about the structure of the CPU. Although the compiler can assume a CPU has a floating point unit, it has no idea if it has two that can execute in parallel, or how long the pipelines are. Modern CPUs can re-order instructions to match the actual hardware. The hardware can even add registers by "renaming" them - the x86 instruction set has eight general purpose registers, but the CPUs usually have dozens, so if a group of instructions share a register but don't share data, the CPU can give two independent registers the same "name" as far as the instructions are concerned, and execute both groups at the same time.
Yes, a compiler might assign registers more effectively, but only if you knew before hand what CPU was going to be used.
Compilers can group instructions together in such a way that the CPU is more likely to detect the right patterns. In this case, the optimizations are "implied", and a smart CPU will pick up on them and run faster, a dumb CPU won't, but it normally won't hurt performance. This means that you can have both high level, compiler optimizations as well as low level, CPU optimizations that the compiler could not perform.
Doesn't have what you'd call facts or information. And even its facts aren't that good (e.g. Buran wasn't an "exact replica" of the STS - though it looked similar, Buran didn't even have main engines, it was strapped to a rocket).
The technology sometimes got developed into real products, sometimes just sat on a shelf waiting until someone could use it.
The real reason for the Space Shuttle was to learn how to build and operate a Space Shuttle, because there had never been anything like it before. I'll grant, it wasn't the most efficient way of doing it, or the best possible vehicle, but it does remain the only one - even as it is, the only Space Shuttle is the best Space Shuttle.
We know - now - that it can be done better. Great, build upon that. There are many ways, from government doing it itself (probably not the best way, but would get it done), to joint ventures or assistance (often break down from disagreements ovr design or funding, like the Lockheed VentuStar), to just throwing the technology out and letting the free market do something with it (there's no market at the moment, so that's not going to happen).
The government building the Space Shuttle was one way of doing it, and probably the only viable one when it was proposed, because the idea of a reusable space vehicle was merely speculation - nobody knew if it would work, how expensive it would be, how reliable, and so on. After it was done, you learn the lessons, and you can try again - if you have the money. The Soviet Union did, for a while, but the Buran only flew once - it would have given a lot more information on what works and what doesn't if it had kept flying, but since it didn't, there's a new mindset that the Space Shuttle is the "only way" to do it. Government involvement will be necessary to get beyond that now, but at least now there is more than the government-only option.
And now that the Space Shuttle exists, there's also a benchmark to measure against, as a target to exceed. Before, the goal was basically just to get it to fly, and not much more. Now there are targets we know are more reasonable based on this experience.
As an aside, the Lockheed "VentuStar" program looked promising, but what would have been better is to fund prototypes for all three proposals (low-tech DC-X, medium tech Shuttle II, high tech VentuStar), and then let them compete. It would also have taken immense amounts of money though, but that might be what's needed to get the market for reusable vehicles started...
"Sounds interesting. Where is this story now?" http://www3.sk.sympatico.ca/jbayko/text/stories/ma rk/
Seventy chapters (short), in groups of ten.
This capability lets each new increment in technology be created faster than the previous increment of the same size. Or to put it another way, each new generation has a greater increase in complexity over the generation before than that generation had over the one even earlier, even if the time required per generation is the same. Either way, the rate of new technological complexity is increasing as a result of technological complexity.
Whether it's computer-assisted humans, or computers doing it independently, change is happening so fast that sometimes it's almost finished before anyone knows what's happened - look at the Internet explosion over the past five years for something that has literally replaced entire social infrastructures (e.g. know anyone who's bought an encyclopaedia set lately?).
The dust han't even settled and now people are developing an entire layer of technology that works on top of that.
I don't know how fast technological progress is going to get, but frankly the potential scares me a little - I don't think we've done a good job of keeping up with and wisely using new technology so far. But then, new technology is being developed to help us all solve that problem too - which is the point here.
Still, it is just starting, so you can still look for decade-long periods for the development of things for quite a while yet. The point is that the trend is accelerating.
There was a bunch of slapstick as the AI was "killed" by someone burying an axe into the IBM DASD the program was stored on - luckily it was friends with a Cray who had extra storage and processing capacity...
The Yugoslavian Mafia got involved too. Fun story.
procedure process_file...
cleanup:This becomes:
procedure process_file...
procedure process_file_data...
I think it makes for a much cleaner version.
Gotos can also be mostly eliminated using labeled breaks (which C doesn't have), or redesigning things - I find that excessive use of gotos means that you're really trying to design a state machine. You can do that with gotos, or you can use a loop containing a state variable, and a switch() statement listing the states.
So far I've never found a situation where a goto couldn't be avoided while still writing clear, efficient code. Maybe I will, but those three techniques (returns, breaks, and state machines) have held up so far.
It's their money - if they want to waste it on you, let them.
Programming methodologies are the same thing. I haven't seen anything in XP that I haven't seen elsewhere, using different words (for example, Steve McConnel's excellent Code Complete). Again, all methodologies have trade-offs and different emphasis, and some are more suitable for some projects than others, and again if your developers have enough self discipline they know how to do a project properly and don't need a set of rules to follow.
Apple had specifications for a CPU bus that would meet its needs, but Motorola couldn't justify the expense of making a special version of the G5 in relatively small numbers, for one customer (who, face it, would just keep asking for special versions of any good future PowerPC model - not just a one time cost).
So Motorola kept its G5 design until the embedded market is ready for it, and Apple took its bus elsewhere.
IBM is developing the PowerPC 970 for its own use - specifically in "blade" servers, which need a lower power, cheaper and cooler CPU, while keeping up performance, which is exactly the same needs that Apple has. I don't know if Apple is going to get its bus in the 970, but it would be a simpler design than the POWER4 which actually uses two busses, one in and one out, allowing the CPU to keep sending addresses out even before it gets the data back in.
Either bus would be very fast. Motorola will ba happy it doesn't have to make custom CPUs, IBM will be happy it can sell more 970s, and Apple will be pissed at Motorola but will at least be back in the performance race again so it'll end up happy. Finally.
On the question of printing your own money, this used to be standard practice in Canada. Since the only "real" currency was coins, banks would print paper bills representing a given amount of coins (always promising to be "redeemable" until sometime in the 20th century). The Bank of Canada was set up to provide a central source of paper currenty, and to provide confidence in the currency after some issuers went bankrupt - and obviously when anyone can print their own money, counterfitting is pretty easy - you don't even need to copy a real bill, just make up a real-sounding bank name. For legitimate banks, it was fairly profitable (due to complex economics I don't fully understand), and there's nothing stopping banks from issuing their own currency if they want to, except that likely nobody will want it.
In French Canada during shortages (such as war), playing cards were used as money (signed by an appropriate authority, such as a colonial governor).
Currently in Canada there are only two widely accepted forms of paper currency - bills from the Bank of Canada (which have iridescent patterns on the surface that can't be recreated from a printer), and Canadian Tire Money, which are really coupons that can be spent at Canadian Tire stores, but can sometimes be spent elsewhere, depending on the retailer. Canadian Tire denominations are limited to something like 50 cents.
The U.S govermnent is not interested in nation building (witness the total abdecation of responsibility for post-Taiban Afghanistan). The only conquered nations that produced democratic replacement governments did the work themselves.
I'd say it's already gone off. A few times.Just because stability in the region is in the best interests of the U.S and the world doesn't mean those in charge agree on how to accomplish it - and the current U.S administration seems to be particularly thick-headed about the value of militery intervention - ignoring things like a) terrorism was invented to get around military power - effectively, and b) large scale war hasn't been economically viable since after WW I (for example, the U.S could overwhelm China's military quickly, but the U.S economy would quickly collapse due to the dependence on imports - it would do more damage to the attacker than the victim).
I doubt Iraq will be any more democratic than Afghanistan is, or Iran or Chile or Cuba were after U.S intervention. Economic, social, political forces are far more powerful - remember, it was not U.S bombs that dismantled the Soviet Union, it was economic and political pressures from within that were responsible.
Like Israel? Wrong religion? How about Turkey?Nah, it needs more than that. If you want to know what I think it needs - a free trade region. That would be the best, fastest, and surest way to promote freedom, communication, political and economic reform, and reduce historical animosities (usually people hold grudges because they don't have anything better to do - if they have the opportunity to get rich by putting aside those differences, they'll do that instead - consider Quebec separatism in Canada has been highest during economic problems, but has lately all but disappeared).
Unfortunately, even that is a long term (decades) process. The popular American "But I want it now" mindset doesn't lend itself well to this sort of foreign policy.
Degrees were chosen for angles becaue it approximates the movement of the constelations (about 1 degree per night), but it's also very convenien for splitting into fractions - halfs, thirds, quarters, etc.
As for those who argue that Farenheit is superior because it's more accurate, I doubt most people could feel a difference of 1 degree C, let along 1 degree F. It only matters in situations close to freezing, such as if you're worried if ice is going to start building up on the wings of your airplane, but in that case, you could just go by half degrees C and get about the same accuracy (e.g. "one and half" vs. "thirty five" - it's also easier to visualize distance from freezing with a centigrade based scale).
I've seen other lists with the same law attributed to different cities.
They're a lot less funny when you know they really are too stupid to be real.
I see nothing wrong with allowing copies to be made at will, as long as there's something that administers things like royalties. Say, every time you make a copy to a networked device, that costs you a few cents, and the software works that out automatically and charges your credit card at the end of the month. If you copy to a non-networked device from a networked device, it'll only be able to play on that device, and you get charged less.
As long as you are aware of how much it costs, there is no restriction on what software you use as long as it complies. It can be something as simple as obtaining a decryption key from some service provider - the software doesn't need to keep track of anything, free/open source will work, you'd just have an account with the service company like you have with the phone company (roughly equivalent to going to some random phone and using a calling card to charge to your home number).
There would have to be something regulating this. For example, the fees should probably be only for copying, not per play. No provider should be allowed to "lock in" customers with a proprietary format, or it should be legal to convert it to another format that might charge lower fees. Regulation might be from laws, but might be from standards groups - I don't know which would be better, but there must be limits on potentially abusive behaviour. I doubt something like this could be done very quickly.
I think such a system can be alowed to be leaky, as long as it's convenient and cheap enough to use the system that it makes no real difference to the end user. Maybe your playback software could save the decryption keys, but it's just easier to have the service company manage them rather than doing it yourself, copying them between your TV, stereo, PC, Ogg player, etc. People are honest enough that they realise if they don't support the system (if it's reasonable) then they won't get the product.
I think part of the problem is that there are two opposite forces at work - relational theory is aimed at regularizing data, while object orientation is aimed at encapsulating data with routines, and forming ad-hoc connections. I think a better strategy than trying to slap transaction-oriented features onto ad-hoc data is to find a way to make it easier to express to compilers what you are really trying to do with data in the first place (within a relational model). As you say, "There is no reason I should need to encode my data in tables just to get atomic transactions" - you should be able to express it in your prgramming language.
The problem is when most people think "relational", they think "databases", not "data".
One more thing:
Why do you have this feeling that people are calling you stupid? I certainly didn't.Basically, it means relating sets of things to other sets of things - a mathematical model. As you remember from math, a set is a collection of elements in no particular order, and in this case, the elements are tuples - an ordered list of elements (e.g. (1, "purple", squirrel) ). All the tuples a set are defined to have the same number of elements and the same semantic meaning for the positions - also known as attributes, so that you can refer to the element by the tuple attribute identifier (e.g. x.name, x.density).
Usually in databases you call the sets "tables", call the tuples "records", and call the identity of the tuple elements "columns".
There are a variety of ways of describing the relation between tuples in various sets, and you can define a set of new tuples (a result set) from the elements of tuples from related sets, perform set unions and intersections (equivalent of insert and delete records).
The elegance of this is you can define what you want, without needing to explicitly describe how to get those results. But then, without smart software, the process can be painfully slow (query optimization is the most important part of database implementation).
You can use set definitions to describe what you want to do, such as:
You can use relational algebra: You can use relational calculus which is what SQL looks kind of like.Here's a suprise for you - you can represent hierarchical relationships in a relational domain. As an example, simply define the attributes of something like address:
You can create tuples with attributes like this: You have a nice hierarchy of address elements. A particularly nice thing about this is that you can have different identifiers for sub-elements where appropriate - states and ZIP codes for the U.S, provinces and postal codes for Canada.When you can add attributes like this, it helps organize things that aren't only hierarchical, or have two hierarchies. For example, armed forces personnel each have an address (one hierarchy), and a rank (another hierarchy). They've also got a service history, which is not at all hierarchical - what if you want to list everyone in Florida who served in Boznia? A hierarchy is absolutely useless for that.
This is why relational databases are so powerful (note - almost no relational databases exist, most are fairly simple approximations. Don't judge relational theory based on what Oracle or Microsoft provide).
This is the type of thing that Einstein didn't like.
An alternate is known as the "pilot wave" (pdf) interpretation. It suggests that the wave and the particle are separate - the wave is actually a force, and the particle remains a discrete thing that's pulled by that force. When that force is split, the particle follows one force wave, and the other is empty - when you eventually measure it, you've really changed nothing.
What the nature of this force is, is left unclear, but it goes get rid of the dice-throwing god. Einstein didn't like this much either.
Einstein trusted relativity, because he understood it, and it was straightforward. He distrusted quantum theory (famous "God does not play dice with the universe" quote), considering it an approximation that would do until the underlying physics could be worked out. Most of his contribution to the development of quantum theory was coming up with situations where its predictions seemed wrong - "wrong" or not, quantum theory turned out to be consistant, which is what counted in the end.
http://lists.freelives.ca/pipermail/info4/2002-Aug ust/000199.html
Since about that point, there have been two types of companies - those run by people who are genuinely dedicated to their products and customers, and will make long term investments in R&D and operations, even if the share price doesn't reflect the company's true value, and those which buy up companies with low share values, thus inflating their own shares and dismantling the long-term planning of companies they buy in exchange for short-term profit.
Incidentally, this also explains the sudden appearance of fraudelent accounting - honest companies which accurately reflected their revenue and profits had poor share performance compared to those that were dodgier, so they were bought up (and reduced to the same questionable level of accounting practices).
Boeing couldn't continue with its R&D-heavy, long range operation without becoming vulnerable to a takeover. So it reversed, and instead it began buying companies to boost its stock. Meanwhile, Airbus operated in a different financial environment, and was able to act like Boeing used to (despite being less efficient).