Yeah, this may as well be "Displaying the results of a relational database query".
I'm sick of every combination of existing computer technology being pattented.
It's just freaking math! It's like pattenting 2 + 3, then coming out and pattenting 3 + 2. Then 3 - (-2). It's all just permutations of the same god damn thing!
"Let's make use of the information we have stored about our customers to actually tell the customers things" is a great idea, but it hardly warrants patent protection. It's just a business finally thinking that maybe they could use their data-hording to the benefit of the customer.
Is Bezos going to get another patent for reminding customers when their birthdays are?
"Its users" are Intel customers, not AMD customers.
No, its users are software developers. Software developers who use ICC because it produces the fastest code, but who want their application to run on everything, and have no reason to expect that the code produced by ICC will fail to use an optimal codepath for no reason.
If Intel stated that the code produced by ICC would only run on Intel parts, no software developer would use it since the software developers' customers could be using any chip and it would be foolish to cut off 15-20% of your market for no reason. But Intel dosen't state this, they just make it look like AMD chips are slower.
If Intel were to guarantee the performance of their compiler on AMD platforms, then they would have to purchase and assemble a small warehouse full of platforms, and train and support a small army of specialists in those platforms.
They don't have to guarantee the performance on AMD, but they should not deliberately break performance on AMD.
Is this difference between "supporting and optimizing for competitors products" and "not deliberately breaking for competitors products" really not obvious?
Intel would not have to do any more work to make the codepath work on AMD. All they have to do is correctly determine if the processor supports SSE2 -- which is done with the same instruction as detecting that the chip is GenuineIntel -- and use SSE2 if it is supported. That's it. Estimated cost: $0.
And if Intel releases a compiler that includes a fatal bug on AMD hardware, then they could become legally culpable for any damage caused by that bug.
Highly doubtful. When has that ever happened? I doubt you could hold Intel responsible for fatal bugs when running on Intel hardware. Again, they don't have to guarantee in any way, legally binding or otherwise, that their code works on AMD chips. They just have to allow it to work. Instead they prevent it from working.
If the code failed on an AMD part because of an incompatability, that would fall on AMD's shoulders. AMD knows that, and so they make their part fully compatible. It is AMD's responsibility to make sure that if their chip claims SSE2 support that it really does support SSE2. And it does.
I just don't like this idea that Intel is responsible for everybody else's hardware platform, and that somehow Intel is supposed to provide all of these services to AMD for free.
That's not the idea. The idea is that Intel should produce code that doesn't artificially fail to support a fully compatible chip.
Is this clear? All Intel has to do is correctly -- according to their own documentation -- check whether a CPU supports a given feature when deciding whether to use a given codepath or not. That's it. They just have to make their compiler work correctly, rather than deliberately break.
Again, in case it still isn't clear. This is like Microsoft supporting DRDOS versus detecting that it is DRDOS and then deliberately breaking even though DRDOS could run Windows just fine otherwise. That is precisely the situation here -- AMD processors could perfectly run the SSE2 codepaths that ICC produces, but Intel deliberately fails to use that code path for anyone but their own parts.
There is no support issue. Nobody wants Intel to guarantee that AMD parts work. Nobody wants Intel to make special optimizations for AMD. We only want ICC to not hinder AMD parts.
Again, the obvious solution is for AMD to write their own compiler.
Again, this is obviously infeasible and obviously not relevent to Intel's behavior.
Good thing you aren't an Intel lawyer, since that argument does nothing to address Intel deliberately running slower code on AMD parts. "Write your own damn compiler" doesn't address the issue of Intel's compiler producing code that, despite the expectations of its users, avoids using extensions available on a processor because Intel doesn't like that processor. But good luck.
They are tiny (infinitesimal?) points in space where the forces on an object due to the earth and another body (the sun or moon etc) cancel each other ; allowing an object placed there to maintain its position relative to the two bodies http://en.wikipedia.org/wiki/Lagrange_point/
Technically that is true; practically it is false. The exact point of stability is infintesimally small, which is why no real object placed there can get by without having some kind of orbit correction mechanism. Once you have that mechanism, the area of space which is relatively stable is quite large.
In particular I understand that the L4 and L5 points have large areas around them where an object will stably orbit the LaGrange point itself.
So practically it is possible to have a number of stations near the L points and still allow craft to pass through them to achieve low-energy trajectories to other places in the solar system. There is no need for a monopoly.
Actually - do the chips it supports other than AMD, like the old cyrix ones, support the function that tells it whether it has SSE or not ?
Yes, they do. All x86-compatible processors back to I think the 386 or 486 support the CPUID instruction, and there's a control register that tells you whether the CPUID instruction is supported (the absence of which would clearly imply that SSE is not supported). Basically, there is a well-defined sequence of instructions for identifying processors and their features all the way back to the 8086.
You may be wondering how a processor that existed before SSE can tell you if it has SSE. The way this works on old processors is that there are bits in the CPUID feature field defined as "Reserved" or "Must Be Zero(MBZ)". So all x86-compatible processors return zero for these bits. Then someone (usually Intel) creates an instruction set extension, and chooses one of these bits to represent that. So for example the Pentium MMX took one of these MBZ bits and redefined it to be the "MMX extension" bit, and returns a 1 for that bit. If everyone follows the spec (and they do; Intel compatability has always been priority #1 for the other x86 chip makers), then all other processors will return 0. In the future when MMX support is added to those, they can return 1 as well.
So it isn't laziness. They use one CPUID call to get the processor string instead of another to check the SSE2 bit. It is a deliberate attempt to prevent non-Intel processors from running the fastest code produced by the Intel compiler.
Peace has been found between untrustworthy adversaries in the past. Your implication of naivete is misplaced. Treaties are made, and treaties are broken. The point is that at all times peace should be the goal, and abandoned only when peace is no longer feasible. Asserting that peace is impossible before it is tried and starting a war is the height of foolishness.
Practically, the best thing the U.S. and China have going for them is their economic co-dependence. It is utterly stupid for the U.S. to have outsourced its fundamental production capacity to China -- if war did break out, and China decided to stop shipping us steel, what would we make war machines with? Our Intellectual Property? Nevertheless, it becomes increasingly undesireable for the U.S. and China to escalate things. Of course this means we're forced to tolerate China's miserable human rights record (which unsurprisingly hasn't been difficult for our business sector). We may have little choice but to let Taiwan sink or swim on its own.
In the worst case, we've still got MAD. It sucks, but it works.
Who says anyone must hold absolute control of the LaGrange points?
I mean, the same argument could be said for Antarctica -- if we don't turn it into a U.S. controlled territory, the Chinese will! Well, maybe if they were trying to monopolize access to Antarctica, we would care enough to do it first. In the meantime, many countries can conduct their own business on Antarctica and there are no problems.
Why treat space differently? Why would you, in anticipation of a conflict in the future, create one now? If you treat control of LaGrange as a binary choice -- either us or the Chinese have 100% control with no access at all for the other -- then you will bring that situation about. If you say that we will fight over LaGrange and thus we must claim it now and prevent the Chinese from doing so, then you only give them an incentive to take it for themselves, whether before or after we do.
I am fully aware that with history as our guide we can predict conflicts in space. Why assume that all such conflicts are unavoidable and that the only choice is preemptive action? History doesn't bear that out at all. History does say that when one side believes war is innevitable, then it is.
We don't have to go to war with China, over the LaGrange points or anything else. We don't. And only by believing that this is the case will it ever be possible.
So I say we treat it like Antarctica. Nobody claims it, nobody prevents others from accesing it, everybody benefits. If this model of peaceful coexistence breaks down, well hopefully we're not fools and are prepared. But let's not go creating conflicts where none exist yet, okay?
Sure it does. At over 900 pages, the hardcover version of this book would serve quite well as a cornerstone for a bookshelf. It works almost as well as cinder blocks or milk crates!
Right, regardless of whether those optimizations would be suitable for the other processor, which, oh by the way, the CPUID instruction tells you. Rather than checking "Does this CPU support SSE2? If so, then use the SSE2 code path." it checks for "GenuineIntel" and only uses the SSE2 code path then.
The argument that they're only de-optimizing all competitors' chips even if they support the optimizations doesn't make it sound any better.
This is a case where a compiler can go "if it is a 'processor-type-a' use these instructions otherwise use something else". I don't see any fault here. Intel has created a compiler that uses their chip's optimal settings. An efficient instruction set of instructions for a P4 will not be the same for an Athlon anyway due to internals of both chips being different. Why would anyone believe otherwise?
Because "anyone" would know that certain code paths are going to be faster on both AMD and Intel processors than others. An SSE2 optimized code path is going to be faster on both chips than an x87 code path. Yes the chips are different but both do better with certain kinds of code.
Why would this be the case? Because AMD tried to make their SSE2 support as fast as possible so that it could run the same code as an intel compiler just as fast! AMD is not in a position to expect everyone to optimize their code for the underdog's processors. They have to make sure the code that exists runs fast.
Yes, they are going to be differences in the most optimal sequence of instructions depending on the microarchitecture of the chips. This does not mean that the optimal code path for Intel is automatically sub-optimal for AMD. Why would you assume that?
You don't see any fault because you aren't comprehending the situation. The CPUID instruction returns, among other things, a bit field detailing all of the instruction set extensions supported by the chip. AMD processors have supported SSE2 for years, and have this bit set. These instructions are quite fast on AMD processors, because they have to be. The Intel compiler produces code that uses SSE2, and other instructions if the compiler doesn't support it. However to determine which code path to use, the Intel-generated code uses the processor name returned by CPUID rather than the feature bits. It checks for "GeniuneIntel" or "AuthenticAMD", and uses either the fast code path or the slow one.
It has nothing to do with compatability, and everything to do with detecting and crippling a competitor's chip.
That's just not feasible. Unlike Intel, AMD isn't huge and they don't have a massive software team. However, they aren't stupid and have funded and helped develop compilers. In particular gcc received a lot of help from AMD, especially in developing the AMD64 target.
Yes, and please don't consider the jobs of those working at companies that buy Intel parts. It's okay for an American company to gouge people because it's good for Americans, even if Americans are the one being gouged. That makes tons of sense.
Yeah, I agree. Breaking Intel's stranglehold on OEMs and suppliers would be all the benefit AMD needs. They're positive on the balance sheet, they have good parts, and they're preparing another fab. Sending them loads of cash would of course make them happy, but giving computer makers free reign to use AMD parts is all they need.
Consumers have suffered a lot from Intel's monopoly, and they should be the ones directly compensated.
c++'s merit is, that it allows a seemless transition from the bare-metal-programming of C to the more abstract realms of genericity (via templates *argh*) and OO
The beauty of templates (yes, it is a beauty, even if they do make you scream "argh" whenever you have to parse an error message) is that the source code you write is generic, but the object code produced by the compiler is not. This gives you the flexibility of generic programming with the speed of static typing. Templates can be really fast, as fast as code designed for a single type, a claim the other generic programming methods I know of (all of those which use base classes/virtual functions, including how generic programming was done in C) cannot make.
C++ really is a bare-metal language with syntactic sugar thrown on top to make OOP easier*. It is not a transition from C to higher level languages -- that transition is easy. It is designed instead to facilitate the use of higher-level concepts in a language that is still C-like. It is meant to occupy that middle ground, not provide transitions between the extremes.
I won't argue that it isn't full of arcane stuff that can give you headaches, though.
* Exceptions being the, uh, exception. But then again I don't like exceptions.
He's talking about "placement" delete which does not call the destructor, but he's still on crack because the whole point of placement new/delete is to separate the allocation/deallocation of memory for an object with the construction/destruction of the object. If you want to both deallocate the memory and call the destructor, you use normal delete. Placement new is similarly used only in cases when you want to separate memory allocation from constructing the object, like in pool classes.
The template closing thing is an obvious, minor change.
I'm not so sure about 'auto'. Just from the article, which admittedly is not supposed to be a list of features going into the new standard, I can't help but see problems. e.g.:
auto my_thing = [complex stl expression];
[some other complex expression](my_thing);
and getting some horrible STL error on the second expression because the type of the first expression wasn't what you expected and now you have to figure out what it actually was and how to force it to be what you thought it was going to be. In other words, it's the same nasty STL template debugging you have to do today, only with another level of hidden indirection in the type of a variable, which is at least something I don't really have to worry about today.
On the other hand, I do really like the idea of "concepts" where you specify what "concept" a template expects and the type you give can be verified to be the correct concept. As it stands right now, you don't know that a given type won't work in a given template until the compiler compiles a template function that requires a method your class doesn't support which may not even happen until after you've been using the template and class combination for a while. This sounds a bit like Java interfaces, but without the requirement that your class derive from the interface. You just have to provide what the concept expects.
This beats the hell out of the current situation where the "concept" a template requires is implied by its implementation. The implication that this might simplify template error messages would be icing on the cake.
Energy isn't exactly relevent since what we need to do is transfer momentum. I don't think a nuclear weapon is the best way to do that. If you're going to send a fission device out there, I say use an engine. This probably requires a delicate rendevous with the comet, rather than a simple ballistic interception, though.
They were knowingly harboring and protecting a large and dangerous terrorist organization, and pretty much the whole world was in agreement that that was not right.
Pretty much the whole world agreed that invading Afghanistan was a reasonable response. We even brought most of them along -- hell, even Canada and France are there!
My only beef with the Afghanistan situation is that we're dropping the ball now.
And why are we dropping the ball? Because the Hunt for bin Laden got sidelined so that our government could focus on what they really vanted to do: invade Iraq. Now our troops are spread thin, and we're dependent on warlords to keep order, such as it is, in the areas we don't have the manpower to hold ourselves.
The US acquired a reputation during the Cold War for going into small countries, screwing them up badly, and then leaving. That sort of ham-handed meddling is exactly what makes a big chunk of the world mad at us.
Yes, but you'd have to read a history book to know that. Guess what Bush doesn't like doing? But I digress, because the part that pisses me off is that it didn't have to happen that way. Afghanistan was, against all odds, going pretty well. In a way it isn't surprising when you look at everything it had going for it.
First, we had a clear mandate to be there, which already made Afghanistan better than most of our foreign adventures of the previous thirty years. Second, the people there didn't already hate us, since we helped them against the USSR -- as opposed to Iraq, whose people remember the last time we promised to bring them freedom. Third, we actually took the conflict and our enemies seriously and thus the actual experts were allowed to make the decisions. Compare again with Iraq, where we (correctly) assumed the invasion would be a cakewalk and (incorrectly) assumed that the people would welcome invaders with open arms. We never thought Afghanistan would be easy, or that once our army was there it would be all roses and parades, and thus we were prepared. In Iraq we were not prepared at all, and the reason is entirely due to our civilian command and their ignorance and self-serving bullshit.
A lot of Americans may not want to admit it, but we have a lot to do to prove that we really are capable of bringing freedom and democracy. Afghanistan was the perfect opportunity, and it was actually going well.
Imagine a world in which we haven't invaded Iraq. All our resources are dedicated to Afghanistan. We are, despite all our critics expectations based on history, actually succeeding in our stated mission. Finally, the troops leave. Then Bush starts talking about the evils of Saddam Hussein, and how having already proven ourselves in Afghanistan we were ready to bring freedom to Iraq. Maybe the people would actually believe us then? Yes, it's a fantasy, but it's no more a fantasy than the official line we're given today. All because of bullshit. All because we can't be real about why the world is the way it is and why people do the things they do.
Since I seem to remember from a discussion you had on k5 that the human brain having a seven-dimensional structure is an unproven hypothesis of your own invention, I would find it unlikely that this test would verify that Neanderthal had an eighth layer, what with not showing that humans have seven while we've had much longer to study their DNA.
Still, neat hypothesis. The neanderthal brain is bigger but sub-optimally designed.
We could argue about the merits of income tax versus sales tax; I worry about the implementation of a saes tax.
But if you insist on an income tax, it must be a progressive one. And no, a flat tax is not progressive. By definition a tax is only progressive if the rate increases as your income increases. A flat tax is not progressive.
Now the reason why a progressive income tax is essential to "fairness" is the very obvious fact that 25% of the income of a person barely making ends meat is much more significant -- read financially damaging -- than 25% of the income of a person who's biggest financial worry is whether they will be able to send all of their kids to Ivy League schools if they don't get scholarships. It is not "fair" at all to expect someone who can't afford medical care for their children to support society with the same contribution as a wealthy person.
Flat tax sounds good on paper, so long as that paper has no figures representing reality and the difficulties faced by the poor. But the fact is that a flat tax necessarily means that the burden of supporting society is placed more heavily on the poor. A progressive tax attempts to alleviate this by taking more from those who can afford more. I pay a greater percentage in taxes than a lot of people, yet I consider this to be imminently fair. That's just my opinion. It isn't my opinion that flat taxes place a greater burden on lower income families though.
Slashdot Mirror
Ebay make Amazon look like Jesus and his disciples.
Which disciples? I hear some of them turned out not to be so great.
Also, the thought of Jeff Bezos in sack cloth is amusing.
Yeah, this may as well be "Displaying the results of a relational database query".
I'm sick of every combination of existing computer technology being pattented.
It's just freaking math! It's like pattenting 2 + 3, then coming out and pattenting 3 + 2. Then 3 - (-2). It's all just permutations of the same god damn thing!
"Let's make use of the information we have stored about our customers to actually tell the customers things" is a great idea, but it hardly warrants patent protection. It's just a business finally thinking that maybe they could use their data-hording to the benefit of the customer.
Is Bezos going to get another patent for reminding customers when their birthdays are?
"Its users" are Intel customers, not AMD customers.
No, its users are software developers. Software developers who use ICC because it produces the fastest code, but who want their application to run on everything, and have no reason to expect that the code produced by ICC will fail to use an optimal codepath for no reason.
If Intel stated that the code produced by ICC would only run on Intel parts, no software developer would use it since the software developers' customers could be using any chip and it would be foolish to cut off 15-20% of your market for no reason. But Intel dosen't state this, they just make it look like AMD chips are slower.
If Intel were to guarantee the performance of their compiler on AMD platforms, then they would have to purchase and assemble a small warehouse full of platforms, and train and support a small army of specialists in those platforms.
They don't have to guarantee the performance on AMD, but they should not deliberately break performance on AMD.
Is this difference between "supporting and optimizing for competitors products" and "not deliberately breaking for competitors products" really not obvious?
Intel would not have to do any more work to make the codepath work on AMD. All they have to do is correctly determine if the processor supports SSE2 -- which is done with the same instruction as detecting that the chip is GenuineIntel -- and use SSE2 if it is supported. That's it. Estimated cost: $0.
And if Intel releases a compiler that includes a fatal bug on AMD hardware, then they could become legally culpable for any damage caused by that bug.
Highly doubtful. When has that ever happened? I doubt you could hold Intel responsible for fatal bugs when running on Intel hardware. Again, they don't have to guarantee in any way, legally binding or otherwise, that their code works on AMD chips. They just have to allow it to work. Instead they prevent it from working.
If the code failed on an AMD part because of an incompatability, that would fall on AMD's shoulders. AMD knows that, and so they make their part fully compatible. It is AMD's responsibility to make sure that if their chip claims SSE2 support that it really does support SSE2. And it does.
I just don't like this idea that Intel is responsible for everybody else's hardware platform, and that somehow Intel is supposed to provide all of these services to AMD for free.
That's not the idea. The idea is that Intel should produce code that doesn't artificially fail to support a fully compatible chip.
Is this clear? All Intel has to do is correctly -- according to their own documentation -- check whether a CPU supports a given feature when deciding whether to use a given codepath or not. That's it. They just have to make their compiler work correctly, rather than deliberately break.
Again, in case it still isn't clear. This is like Microsoft supporting DRDOS versus detecting that it is DRDOS and then deliberately breaking even though DRDOS could run Windows just fine otherwise. That is precisely the situation here -- AMD processors could perfectly run the SSE2 codepaths that ICC produces, but Intel deliberately fails to use that code path for anyone but their own parts.
There is no support issue. Nobody wants Intel to guarantee that AMD parts work. Nobody wants Intel to make special optimizations for AMD. We only want ICC to not hinder AMD parts.
Again, the obvious solution is for AMD to write their own compiler.
Again, this is obviously infeasible and obviously not relevent to Intel's behavior.
Good thing you aren't an Intel lawyer, since that argument does nothing to address Intel deliberately running slower code on AMD parts. "Write your own damn compiler" doesn't address the issue of Intel's compiler producing code that, despite the expectations of its users, avoids using extensions available on a processor because Intel doesn't like that processor. But good luck.
They are tiny (infinitesimal?) points in space where the forces on an object due to the earth and another body (the sun or moon etc) cancel each other ; allowing an object placed there to maintain its position relative to the two bodies http://en.wikipedia.org/wiki/Lagrange_point/
Technically that is true; practically it is false. The exact point of stability is infintesimally small, which is why no real object placed there can get by without having some kind of orbit correction mechanism. Once you have that mechanism, the area of space which is relatively stable is quite large.
In particular I understand that the L4 and L5 points have large areas around them where an object will stably orbit the LaGrange point itself.
So practically it is possible to have a number of stations near the L points and still allow craft to pass through them to achieve low-energy trajectories to other places in the solar system. There is no need for a monopoly.
Actually - do the chips it supports other than AMD, like the old cyrix ones, support the function that tells it whether it has SSE or not ?
Yes, they do. All x86-compatible processors back to I think the 386 or 486 support the CPUID instruction, and there's a control register that tells you whether the CPUID instruction is supported (the absence of which would clearly imply that SSE is not supported). Basically, there is a well-defined sequence of instructions for identifying processors and their features all the way back to the 8086.
You may be wondering how a processor that existed before SSE can tell you if it has SSE. The way this works on old processors is that there are bits in the CPUID feature field defined as "Reserved" or "Must Be Zero(MBZ)". So all x86-compatible processors return zero for these bits. Then someone (usually Intel) creates an instruction set extension, and chooses one of these bits to represent that. So for example the Pentium MMX took one of these MBZ bits and redefined it to be the "MMX extension" bit, and returns a 1 for that bit. If everyone follows the spec (and they do; Intel compatability has always been priority #1 for the other x86 chip makers), then all other processors will return 0. In the future when MMX support is added to those, they can return 1 as well.
So it isn't laziness. They use one CPUID call to get the processor string instead of another to check the SSE2 bit. It is a deliberate attempt to prevent non-Intel processors from running the fastest code produced by the Intel compiler.
Peace has been found between untrustworthy adversaries in the past. Your implication of naivete is misplaced. Treaties are made, and treaties are broken. The point is that at all times peace should be the goal, and abandoned only when peace is no longer feasible. Asserting that peace is impossible before it is tried and starting a war is the height of foolishness.
Practically, the best thing the U.S. and China have going for them is their economic co-dependence. It is utterly stupid for the U.S. to have outsourced its fundamental production capacity to China -- if war did break out, and China decided to stop shipping us steel, what would we make war machines with? Our Intellectual Property? Nevertheless, it becomes increasingly undesireable for the U.S. and China to escalate things. Of course this means we're forced to tolerate China's miserable human rights record (which unsurprisingly hasn't been difficult for our business sector). We may have little choice but to let Taiwan sink or swim on its own.
In the worst case, we've still got MAD. It sucks, but it works.
Who says anyone must hold absolute control of the LaGrange points?
I mean, the same argument could be said for Antarctica -- if we don't turn it into a U.S. controlled territory, the Chinese will! Well, maybe if they were trying to monopolize access to Antarctica, we would care enough to do it first. In the meantime, many countries can conduct their own business on Antarctica and there are no problems.
Why treat space differently? Why would you, in anticipation of a conflict in the future, create one now? If you treat control of LaGrange as a binary choice -- either us or the Chinese have 100% control with no access at all for the other -- then you will bring that situation about. If you say that we will fight over LaGrange and thus we must claim it now and prevent the Chinese from doing so, then you only give them an incentive to take it for themselves, whether before or after we do.
I am fully aware that with history as our guide we can predict conflicts in space. Why assume that all such conflicts are unavoidable and that the only choice is preemptive action? History doesn't bear that out at all. History does say that when one side believes war is innevitable, then it is.
We don't have to go to war with China, over the LaGrange points or anything else. We don't. And only by believing that this is the case will it ever be possible.
So I say we treat it like Antarctica. Nobody claims it, nobody prevents others from accesing it, everybody benefits. If this model of peaceful coexistence breaks down, well hopefully we're not fools and are prepared. But let's not go creating conflicts where none exist yet, okay?
Sure it does. At over 900 pages, the hardcover version of this book would serve quite well as a cornerstone for a bookshelf. It works almost as well as cinder blocks or milk crates!
They're ARE optimizing only for intel. Period.
Right, regardless of whether those optimizations would be suitable for the other processor, which, oh by the way, the CPUID instruction tells you. Rather than checking "Does this CPU support SSE2? If so, then use the SSE2 code path." it checks for "GenuineIntel" and only uses the SSE2 code path then.
The argument that they're only de-optimizing all competitors' chips even if they support the optimizations doesn't make it sound any better.
This is a case where a compiler can go "if it is a 'processor-type-a' use these instructions otherwise use something else". I don't see any fault here. Intel has created a compiler that uses their chip's optimal settings. An efficient instruction set of instructions for a P4 will not be the same for an Athlon anyway due to internals of both chips being different. Why would anyone believe otherwise?
Because "anyone" would know that certain code paths are going to be faster on both AMD and Intel processors than others. An SSE2 optimized code path is going to be faster on both chips than an x87 code path. Yes the chips are different but both do better with certain kinds of code.
Why would this be the case? Because AMD tried to make their SSE2 support as fast as possible so that it could run the same code as an intel compiler just as fast! AMD is not in a position to expect everyone to optimize their code for the underdog's processors. They have to make sure the code that exists runs fast.
Yes, they are going to be differences in the most optimal sequence of instructions depending on the microarchitecture of the chips. This does not mean that the optimal code path for Intel is automatically sub-optimal for AMD. Why would you assume that?
You don't see any fault because you aren't comprehending the situation. The CPUID instruction returns, among other things, a bit field detailing all of the instruction set extensions supported by the chip. AMD processors have supported SSE2 for years, and have this bit set. These instructions are quite fast on AMD processors, because they have to be. The Intel compiler produces code that uses SSE2, and other instructions if the compiler doesn't support it. However to determine which code path to use, the Intel-generated code uses the processor name returned by CPUID rather than the feature bits. It checks for "GeniuneIntel" or "AuthenticAMD", and uses either the fast code path or the slow one.
It has nothing to do with compatability, and everything to do with detecting and crippling a competitor's chip.
That's just not feasible. Unlike Intel, AMD isn't huge and they don't have a massive software team. However, they aren't stupid and have funded and helped develop compilers. In particular gcc received a lot of help from AMD, especially in developing the AMD64 target.
Yes, and please don't consider the jobs of those working at companies that buy Intel parts. It's okay for an American company to gouge people because it's good for Americans, even if Americans are the one being gouged. That makes tons of sense.
Yeah, I agree. Breaking Intel's stranglehold on OEMs and suppliers would be all the benefit AMD needs. They're positive on the balance sheet, they have good parts, and they're preparing another fab. Sending them loads of cash would of course make them happy, but giving computer makers free reign to use AMD parts is all they need.
Consumers have suffered a lot from Intel's monopoly, and they should be the ones directly compensated.
c++'s merit is, that it allows a seemless transition from the bare-metal-programming of C to the more abstract realms of genericity (via templates *argh*) and OO
The beauty of templates (yes, it is a beauty, even if they do make you scream "argh" whenever you have to parse an error message) is that the source code you write is generic, but the object code produced by the compiler is not. This gives you the flexibility of generic programming with the speed of static typing. Templates can be really fast, as fast as code designed for a single type, a claim the other generic programming methods I know of (all of those which use base classes/virtual functions, including how generic programming was done in C) cannot make.
C++ really is a bare-metal language with syntactic sugar thrown on top to make OOP easier*. It is not a transition from C to higher level languages -- that transition is easy. It is designed instead to facilitate the use of higher-level concepts in a language that is still C-like. It is meant to occupy that middle ground, not provide transitions between the extremes.
I won't argue that it isn't full of arcane stuff that can give you headaches, though.
* Exceptions being the, uh, exception. But then again I don't like exceptions.
He's talking about "placement" delete which does not call the destructor, but he's still on crack because the whole point of placement new/delete is to separate the allocation/deallocation of memory for an object with the construction/destruction of the object. If you want to both deallocate the memory and call the destructor, you use normal delete. Placement new is similarly used only in cases when you want to separate memory allocation from constructing the object, like in pool classes.
No, he means it's whatever year it ends up actually being. 2005 was just an example, as was 06 which he also listed.
Somebody throw that a +1, Funny because it was.
The template closing thing is an obvious, minor change.
I'm not so sure about 'auto'. Just from the article, which admittedly is not supposed to be a list of features going into the new standard, I can't help but see problems. e.g.:
auto my_thing = [complex stl expression];
[some other complex expression](my_thing);
and getting some horrible STL error on the second expression because the type of the first expression wasn't what you expected and now you have to figure out what it actually was and how to force it to be what you thought it was going to be. In other words, it's the same nasty STL template debugging you have to do today, only with another level of hidden indirection in the type of a variable, which is at least something I don't really have to worry about today.
On the other hand, I do really like the idea of "concepts" where you specify what "concept" a template expects and the type you give can be verified to be the correct concept. As it stands right now, you don't know that a given type won't work in a given template until the compiler compiles a template function that requires a method your class doesn't support which may not even happen until after you've been using the template and class combination for a while. This sounds a bit like Java interfaces, but without the requirement that your class derive from the interface. You just have to provide what the concept expects.
This beats the hell out of the current situation where the "concept" a template requires is implied by its implementation. The implication that this might simplify template error messages would be icing on the cake.
Energy isn't exactly relevent since what we need to do is transfer momentum. I don't think a nuclear weapon is the best way to do that. If you're going to send a fission device out there, I say use an engine. This probably requires a delicate rendevous with the comet, rather than a simple ballistic interception, though.
They were knowingly harboring and protecting a large and dangerous terrorist organization, and pretty much the whole world was in agreement that that was not right.
Pretty much the whole world agreed that invading Afghanistan was a reasonable response. We even brought most of them along -- hell, even Canada and France are there!
My only beef with the Afghanistan situation is that we're dropping the ball now.
And why are we dropping the ball? Because the Hunt for bin Laden got sidelined so that our government could focus on what they really vanted to do: invade Iraq. Now our troops are spread thin, and we're dependent on warlords to keep order, such as it is, in the areas we don't have the manpower to hold ourselves.
The US acquired a reputation during the Cold War for going into small countries, screwing them up badly, and then leaving. That sort of ham-handed meddling is exactly what makes a big chunk of the world mad at us.
Yes, but you'd have to read a history book to know that. Guess what Bush doesn't like doing? But I digress, because the part that pisses me off is that it didn't have to happen that way. Afghanistan was, against all odds, going pretty well. In a way it isn't surprising when you look at everything it had going for it.
First, we had a clear mandate to be there, which already made Afghanistan better than most of our foreign adventures of the previous thirty years. Second, the people there didn't already hate us, since we helped them against the USSR -- as opposed to Iraq, whose people remember the last time we promised to bring them freedom. Third, we actually took the conflict and our enemies seriously and thus the actual experts were allowed to make the decisions. Compare again with Iraq, where we (correctly) assumed the invasion would be a cakewalk and (incorrectly) assumed that the people would welcome invaders with open arms. We never thought Afghanistan would be easy, or that once our army was there it would be all roses and parades, and thus we were prepared. In Iraq we were not prepared at all, and the reason is entirely due to our civilian command and their ignorance and self-serving bullshit.
A lot of Americans may not want to admit it, but we have a lot to do to prove that we really are capable of bringing freedom and democracy. Afghanistan was the perfect opportunity, and it was actually going well.
Imagine a world in which we haven't invaded Iraq. All our resources are dedicated to Afghanistan. We are, despite all our critics expectations based on history, actually succeeding in our stated mission. Finally, the troops leave. Then Bush starts talking about the evils of Saddam Hussein, and how having already proven ourselves in Afghanistan we were ready to bring freedom to Iraq. Maybe the people would actually believe us then? Yes, it's a fantasy, but it's no more a fantasy than the official line we're given today. All because of bullshit. All because we can't be real about why the world is the way it is and why people do the things they do.
Since I seem to remember from a discussion you had on k5 that the human brain having a seven-dimensional structure is an unproven hypothesis of your own invention, I would find it unlikely that this test would verify that Neanderthal had an eighth layer, what with not showing that humans have seven while we've had much longer to study their DNA.
Still, neat hypothesis. The neanderthal brain is bigger but sub-optimally designed.
Yes! Now you're catching on.
We could argue about the merits of income tax versus sales tax; I worry about the implementation of a saes tax.
But if you insist on an income tax, it must be a progressive one. And no, a flat tax is not progressive. By definition a tax is only progressive if the rate increases as your income increases. A flat tax is not progressive.
Now the reason why a progressive income tax is essential to "fairness" is the very obvious fact that 25% of the income of a person barely making ends meat is much more significant -- read financially damaging -- than 25% of the income of a person who's biggest financial worry is whether they will be able to send all of their kids to Ivy League schools if they don't get scholarships. It is not "fair" at all to expect someone who can't afford medical care for their children to support society with the same contribution as a wealthy person.
Flat tax sounds good on paper, so long as that paper has no figures representing reality and the difficulties faced by the poor. But the fact is that a flat tax necessarily means that the burden of supporting society is placed more heavily on the poor. A progressive tax attempts to alleviate this by taking more from those who can afford more. I pay a greater percentage in taxes than a lot of people, yet I consider this to be imminently fair. That's just my opinion. It isn't my opinion that flat taxes place a greater burden on lower income families though.
You know how expensive it is to keep your kind of class war masked,
The greatest accomplishment by the rich in the class war was to convince the lower classes that the class war doesn't exist.