5. Compare the resulting binaries. They should be identical.
No they shouldn't. That's the whole point of paying good money for the Intel compiler: it's supposed to create faster binaries that are of course different from gcc's output.
In general, there are myriad ways to create functionally equivalent code with different machine code sequences. The odds of two unrelated compilers producing identical output are essentially nil.
You know, I never get tired of that one clip they always show in History Channel documentaries where that battleship explodes into a huge burst of ampersands and dollar signs.
This will inevitably discourage people from developing innovative POS systems in software, because it is far cheaper to reinvent something already known.
Give me a break. Developers will *always* innovate in every field, if for no other reason than most engineers have a strong case of "Not Invented Here" syndrome. If somebody thinks that he has a better idea, he's going to code it.
Something like a 25% efficiency is the maximum possible allowed by thermodynamics.
Not really. Combined cycle gas turbine plants can generate electricity at efficiencies close to 60% (and even higher if the waste heat is used for cogeneration). However, most electricity is still produced in older coal plants with efficiencies closer to 30%.
many of which have gone to the Valley's billionaires and centimillionaires
Usually, a centimillionaire only has enough cash to buy a used car. Making this high-end car available to these people sounds like a huge benefit to me.
the Mayan calendar merely resets at that date. similar to how computers were expected to reset at y2k
Indeed, I've heard that there's a big boom going on in Central America for stonemasons. All sorts of contractors are already down there, urgently carving updates into the hieroglyphs on all the pyramids and temples before the rollover date.
Forget uninstall. Is there even yet a way to *install* Windows without trashing the MBR w.r.t other OSes? If not, I say Windows is not ready for the desktop.
But they had a hard job getting anybody to buy into such a radical change.
That's not too surprising, due to the disappointing fact that once their product finally hit the market, it wasn't significantly more efficient than its conventional competitors.
No, it's not an ideal situation. But what would you propose?
At least transfer them to some non-critical area where they can do some productive work. I think they ought to make them wander around in the boondocks checking how many bars they have and testing if people can still hear them on test calls. For some reason, it seems Verizon needs to deploy teams comprised of hundreds of people to handle this task, so I'm sure that they always need more help in that department.
Most of the classic 8-bit CPUs have variable-length instruction coding, multiple-clock instructions controlled by state machines, and support indexed memory addressing modes and memory writes on general operations (instead of dedicated load/store instructions). All of these are hallmarks of a CISC architecture.
The 6502 may have had a few RISC like features if you pretend that the first 256 bytes of memory are registers, but it still doesn't really qualify as genuine RISC.
I've wondered if there are multiple universes with different physical laws, then maybe some of them could be so "fertile" that all of the matter in them naturally organizes into one giant living organism. (For some definition of life.) That would probably require something like much less expansion, much weaker gravity, and formation of copious carbon-like "elements" during the big bang equivalent. That kind of universe would be vastly more suited for life than this one.
Be that as it may, I used to write performance sensitive X86 code in that timeframe, and from my experience it typically *did* get about 1 instruction per clock throughput on real-world compiled code. For your assertion to hold, it would have had to get about 1/3 of 1 instruction per clock, which certainly is not the case for the Pentium-II and later. That kind of IPC would have been more typical of the 80486 family.
the Shark was more powerful (233MHz, which is roughly equivalent to a 466MHz x86 processor)
I had an iPaq PDA around that time with a 200MHz ARM CPU. I loaded Linux on it, ran some benchmarks, and I was saddened to find that its performance was not much better than a 33MHz 80486.
I'm not sure I believe your numbers since any 466MHz X86 would be a superscalar design, and AFAIK, ARM chips from that era aren't. The X86 in the Pentium-II timeframe would typically get a real-world throughput of one simple CISC operation per clock (using each of its multiple ALUs at about 50% efficiency), whereas the ARM would have at best one smaller RISC operation per clock. It's hard to see how the ARM could achieve *double* the X86 on performance per clock.
The usage here is appropriate, given that this particular usage was originally coined to refer to government abuses in Argentina and nearby states in the 1970s. As Wikipedia explains:
In the case of forced disappearance the word disappear, which is properly an intransitive verb, becomes transitive. Victims, who are those who have disappeared, or the disappeared, are said to have been disappeared, rather than the more usual have disappeared. The perpetrators have disappeared them, rather than made them disappear.
They will probably say something similar to that old Politico [yahoo.com] story that basically says, "We had to give Obama better coverage. It's not our fault that McCain sucks".
Well, you can't rally refute that.
In another survey, the Dali Lama consistently got more favorable press coverage than Kim Jong-il.
I use those all the time. It is strange how often they are useful. My only complaint with them is that if the number has leading zeros, then it assumes octal (07 -> 10), and if it's preceded by a dash, it assumes negative numbers. This can be an annoyance when tweaking dates like 2008-06-07.
Of course, one could complain similarly about Vi--having to switch to command mode is something that gets just about every single newbie.
I solved that by adding imap <M-f> <ESC> to my.vimrc file. If your keyboard has a short spacebar, hitting Alt+F can be done almost subconsciously without moving fingers off the home row. I find it much better than reaching for the ESC key.
If it's really important, I always verify the integrity no matter what
I do that even if it's not important. I have a script which creates an md5 checksum file for a directory tree and adds it to the directory, and I always run it before burning a CD or DVD. Once burned, I verify the checksum on two different computers.
There have been a few times that the computer that burned the disc successfully verified a new disc, but a different one didn't. When that has happened, I trashed that disc and made a new one.
Sometimes I wonder if a lot of the reports of "deteriorating discs" are actually cases where someone burned a coaster in the first place, and just never happened to try to read or verify the data until years later.
5. Compare the resulting binaries. They should be identical.
No they shouldn't. That's the whole point of paying good money for the Intel compiler: it's supposed to create faster binaries that are of course different from gcc's output.
In general, there are myriad ways to create functionally equivalent code with different machine code sequences. The odds of two unrelated compilers producing identical output are essentially nil.
You know, I never get tired of that one clip they always show in History Channel documentaries where that battleship explodes into a huge burst of ampersands and dollar signs.
This will inevitably discourage people from developing innovative POS systems in software, because it is far cheaper to reinvent something already known.
Give me a break. Developers will *always* innovate in every field, if for no other reason than most engineers have a strong case of "Not Invented Here" syndrome. If somebody thinks that he has a better idea, he's going to code it.
Something like a 25% efficiency is the maximum possible allowed by thermodynamics.
Not really. Combined cycle gas turbine plants can generate electricity at efficiencies close to 60% (and even higher if the waste heat is used for cogeneration). However, most electricity is still produced in older coal plants with efficiencies closer to 30%.
many of which have gone to the Valley's billionaires and centimillionaires
Usually, a centimillionaire only has enough cash to buy a used car. Making this high-end car available to these people sounds like a huge benefit to me.
If you feel that you don't have the ability to learn anything from this data point, then fine. You go on and eat nothing but junk food. Please.
the Mayan calendar merely resets at that date. similar to how computers were expected to reset at y2k
Indeed, I've heard that there's a big boom going on in Central America for stonemasons. All sorts of contractors are already down there, urgently carving updates into the hieroglyphs on all the pyramids and temples before the rollover date.
Forget uninstall. Is there even yet a way to *install* Windows without trashing the MBR w.r.t other OSes? If not, I say Windows is not ready for the desktop.
But they had a hard job getting anybody to buy into such a radical change.
That's not too surprising, due to the disappointing fact that once their product finally hit the market, it wasn't significantly more efficient than its conventional competitors.
No, it's not an ideal situation. But what would you propose?
At least transfer them to some non-critical area where they can do some productive work. I think they ought to make them wander around in the boondocks checking how many bars they have and testing if people can still hear them on test calls. For some reason, it seems Verizon needs to deploy teams comprised of hundreds of people to handle this task, so I'm sure that they always need more help in that department.
Stewardesses is still unsurpassed on my box. (But maybe it's because "GNU's not Unix", so I have a different dictionary file.)
Most of the classic 8-bit CPUs have variable-length instruction coding, multiple-clock instructions controlled by state machines, and support indexed memory addressing modes and memory writes on general operations (instead of dedicated load/store instructions). All of these are hallmarks of a CISC architecture.
The 6502 may have had a few RISC like features if you pretend that the first 256 bytes of memory are registers, but it still doesn't really qualify as genuine RISC.
Hmmm, and here I thought that old-school 8-bit computing is the future, since more than half of all CPUs sold are 8-bit processors.
I've wondered if there are multiple universes with different physical laws, then maybe some of them could be so "fertile" that all of the matter in them naturally organizes into one giant living organism. (For some definition of life.) That would probably require something like much less expansion, much weaker gravity, and formation of copious carbon-like "elements" during the big bang equivalent. That kind of universe would be vastly more suited for life than this one.
What would happen if this tool fell into the use of the wrong hands? What if Barbarians were to get a hold of this information?
Be that as it may, I used to write performance sensitive X86 code in that timeframe, and from my experience it typically *did* get about 1 instruction per clock throughput on real-world compiled code. For your assertion to hold, it would have had to get about 1/3 of 1 instruction per clock, which certainly is not the case for the Pentium-II and later. That kind of IPC would have been more typical of the 80486 family.
the Shark was more powerful (233MHz, which is roughly equivalent to a 466MHz x86 processor)
I had an iPaq PDA around that time with a 200MHz ARM CPU. I loaded Linux on it, ran some benchmarks, and I was saddened to find that its performance was not much better than a 33MHz 80486.
I'm not sure I believe your numbers since any 466MHz X86 would be a superscalar design, and AFAIK, ARM chips from that era aren't. The X86 in the Pentium-II timeframe would typically get a real-world throughput of one simple CISC operation per clock (using each of its multiple ALUs at about 50% efficiency), whereas the ARM would have at best one smaller RISC operation per clock. It's hard to see how the ARM could achieve *double* the X86 on performance per clock.
The usage in this headline is an example of irony. It doesn't have to be an exact match for the original situation.
The usage here is appropriate, given that this particular usage was originally coined to refer to government abuses in Argentina and nearby states in the 1970s. As Wikipedia explains:
In the case of forced disappearance the word disappear, which is properly an intransitive verb, becomes transitive. Victims, who are those who have disappeared, or the disappeared, are said to have been disappeared, rather than the more usual have disappeared. The perpetrators have disappeared them, rather than made them disappear.
They will probably say something similar to that old Politico [yahoo.com] story that basically says, "We had to give Obama better coverage. It's not our fault that McCain sucks".
Well, you can't rally refute that.
In another survey, the Dali Lama consistently got more favorable press coverage than Kim Jong-il.
I use those all the time. It is strange how often they are useful. My only complaint with them is that if the number has leading zeros, then it assumes octal (07 -> 10), and if it's preceded by a dash, it assumes negative numbers. This can be an annoyance when tweaking dates like 2008-06-07.
Of course, one could complain similarly about Vi--having to switch to command mode is something that gets just about every single newbie.
I solved that by adding imap <M-f> <ESC> to my .vimrc file. If your keyboard has a short spacebar, hitting Alt+F can be done almost subconsciously without moving fingers off the home row. I find it much better than reaching for the ESC key.
If it's really important, I always verify the integrity no matter what
I do that even if it's not important. I have a script which creates an md5 checksum file for a directory tree and adds it to the directory, and I always run it before burning a CD or DVD. Once burned, I verify the checksum on two different computers.
There have been a few times that the computer that burned the disc successfully verified a new disc, but a different one didn't. When that has happened, I trashed that disc and made a new one.
Sometimes I wonder if a lot of the reports of "deteriorating discs" are actually cases where someone burned a coaster in the first place, and just never happened to try to read or verify the data until years later.
No, it gives you binary derived GiB, MiB and KiB. These are a royal PITA to deal with when the output contains any mixture of the three.
The '--si' option gives you honest-to-goodness decimal GB MB and KB numbers, which is the way God intended humans to see them.
Add this to your .inpurc file:
Then you can do it either way. <Ctl-Space> works like Windows, tab works like bash. Also add these if you want a little additional sanity: