This may change as the x86/x64 compiler writers start paying attention to the "optimize for size" bits of the compiler. For the last few decades all the attention has been paid to speed optimizations. It's possible that some of the advantage of ARM in this regard is due to the historically different focus of their compiler teams.
Five years ago would you have seriously thought they'd stick multiple cores in a phone? 64-bit will happen because phones are rapidly becoming more complex, and also because just like the first multi-core phones it will be a huge marketing advantage, because suddenly all those 32-bit phones will look weak and puny.
By that definition CISC chips have always actually been RISC chips. What did you think all that microcode in those CISC chips really was? RISC was an early win because it exposed the microcode to the compiler for improved optimization opportunities, and the simpler fetch/decode/execute logic made it easy to implement an efficient pipeline scheme which compensated for the increased memory traffic. The weakness of RISC was that by moving the microinstructions out into main memory and exposing them to the compilers they wound up exposing too many details of their implementations, and made themselves vulnerable to changes in the speed differential between CPU and memory. RISC's initial advantage in internal complexity quickly eroded as they added multiple dispatch units, and their pipelines changed from 4 to 6 to 8 stages but the instructions were still claiming they had 4. And as the performance differential between the CPU and main memory increased the functional density of CISC code became a win. Intel noticed that they could fake out more registers than the instruction set explicitly revealed, and could treat near memory off BP and SP as though they were registers, neatly mimicking the register windows of machines like SPARC (this basic trick had been used decades earlier in the TI 990 minicomputer). And Intel noticed that since their micro-instructions were similar to RISC ops, many of the basic optimizations that compilers were doing to improve the outputted code were sufficiently simple peephole-type optimizations that it could be implemented in hardware if this hardware optimizer were able to see the a wide enough window of micro-ops in flight. And since the burgeoning delta between CPU and memory speeds meant greatly increased on-die caches, it turned out that adding all this hardware didn't really change the die size much.
I call BS. You should be able to easily and productively talk to people with an IQ +/- 1SD of your own. At 140 that gives you a range of 125-155 with whom you should be able to hold a relatively interesting conversation, which comes out to about 5% of the general population. As long as you hang around the sorts of places where other smart people frequent, this will be much higher. College towns, business areas with largely college-educated workforce, etc. Hang out at the right pub and half the denizens there will have IQ's above 120. For that matter if you have an IQ of 140 and aren't working daily with lots of people with IQ's in the 120+ range then you need to find another place to work, or another line of work altogether.
Personally I think the new start screen is a huge improvement over the old start menu, the metro apps look gorgeous, and the improvements to the desktop side (speed and usability) are significant. I don't think Win 8 will flop on the desktop.
But I don't think it will succeed on tablets like Microsoft needs it to. It will be a disappointment like WP7. The apps won't materialize like Microsoft needs them to, so customers will be stuck with a gorgeous UI that runs a browser, really basic email client, and MS Office. A handful of quality apps, and a somewhat larger smattering of mediocre-to-crappy apps, just like WP7. WinRT is a really huge breaking change in the APIs, so while you can program apps in VB.NET/C# it's a huge shift to do so. Unless your app is pretty trivial you're looking at rewriting a huge chunk of your code. And if you're gonna have to switch APIs and rewrite then you may as well target the iPad/iPhone, since that's where the market is. Microsoft is claiming that devs should target Metro/WinRT because of the sure-to-be-huge customer base, but that's far from a given. There will be a huge customer base on the desktop sure, but that customer base is already served by the existing application base, there's very little incremental market improvement to be had by going with Metro, unless the Win8 tablets really take off, and unfortunately WinRT makes that a much iffier "if".
I think it's telling that 6mo after giving away ~3000 development machines at Build 11, there are something like 100 apps in the app store.
If Metro were simply a newer variant of WPF then I believe Apple would be in for a serious fight for first place in the tablet space. Win 8 is wonderful to use on a tablet. But if the apps don't materialize by the hundreds of thousands in short order, then that just doesn't matter. Microsoft should have learned this lesson with WP7, which is itself much prettier and nicer to use than iOS. That they didn't is somewhat depressing. That they doubled down on their error by making WinRT even more of a breaking change than WP7, and even more aggravating to develop for than Silverlight/WP7 is kind of breathtaking.
No. It's certainly possible for some random problem to be misclassified as NP-complete because of a botched reduction proof. This sort of mistake has happened before, and it's not a big deal for anybody but the poor student. But 3-SAT is special - it was the first NP-complete problem that was discovered; the proofs of the other members of NP-complete depends on 3-SAT being in NP-complete. So if 3-SAT is in P then either all the reduction proofs for all the other NP-complete algorithms are wrong (very unlikely), or P==NP.
Progressives gave me very bad headaches. Once I switched to trufocus (now called superfocus) glasses the headaches went away. Plus I can keep the entire screen in focus (both screens actually), with progressives only a small band was in focus, both the top of the glasses was out of focus and the lower half was out of focus because the screen isn't at the right distance for *either* prescription. I could have gotten another pair of non-progressive mid-range glasses that would have solved the problem when sitting normally at my desk, but then I would have had to switch to a far-prescription lens when I leaned back in my chair... Or a pair of trifocals, which would at least give me a 6" bar of screen in focus. But it all got pretty silly very quickly, and the trufocals seemed like they would make the whole problem go away.
The focusing mechanism sounds aggravating but in practice it just disappears. The hyperfocal distance for the glasses is about four feet, so beyond that you just set it to infinity and forget about it. The focusing mechanism only comes into play when you settle down to code and set your focus, then when you get up to move about you set it back to infinity. Also I've found that in practice I don't really use the full focusing range, there are about five positions on the slider that I actually use. But those three extra focal lengths that you get over bifocals are a major win.
I've been very happy with mine, and will be buying another pair in September (I try to get new glasses every two years). My only knock against them was that I thought the round lens look was pretty ugly, however I've gotten a *lot* of compliments on the look of my superfocus glasses, strangers are always commenting to me on how nice they look - I've been wearing glasses for 30 years and never so much as a peep about my glasses except the platitudes from family, but in the 18 months since I got the superfocals it happens two or three times a month; cashiers, tellers, random people in the mall, etc.
I also collect and shave with straight razors, and there are definitely new razors being made with ivory scales, though the manufacturers all claim to be using mammoth ivory. I always assumed there were certificates and licenses that they had to have to use any sort of ivory, but maybe I'm wrong. Anybody know what German law is on ivory (the DoVo company that makes these is in Solingen Germany)?
The bigger problem is that it can be tough to tell real ivory from ivory-looking celluloid just by visual inspection, even if you're holding it in your hands. There's no way to tell from a low-res ebay picture, and most sellers IMO don't have the foggiest idea what real ivory is like. I've had sellers claim that the genuine article was celluloid and vice versa, and I've had celluloid ivory in my hands that I had to test with a hot needle to see if it was celluloid or genuine.
Great battery life - talk time of 8 hrs or standby time of 2+ weeks. Don't know about the talk time, but I *do* get the specced standby time. Get it for $20 with the cheap ($30/mo) T-Mobile plan, or with their pre-pay plan for $40 (includes a $25 refill card).
If you read further the author does bring up the issue of peer review:
...the study cited by Proenza has undergone peer review, and is thus the only scientific study one can use to make arguments on QuikSCAT's effectiveness. The Goerss study has not been published in a journal, and has not undergone peer review. However, Proenza was making his QuikSCAT accuracy arguments in March, two months before the Zapotocny study he cited had been accepted for publication.
The fact that the Zapotocny study has been peer-reviewed doesn't make it more relevant for Proenza's argument if it's studying the wrong hurricanes or has too-high of an uncertainty factor.
Oh you wacky cityfolk with your strange grocery stores and megamarts. People in the country don't need money to buy food because they can (and do, and did) just grow it and hunt it. My great-grandparents (in rural Louisiana, not Tennessee, but same diff) knew about the Depression because they heard about it from the townspeople at church. It didn't affect them one way or the other because they had always grown all their food anyway. Rural electrification was a much bigger deal for them.
Reminds me of a funny story a friend told me (though it may not have been original). A group of them were running in a dungeon and ran into a locked room, and peeking under the door revealed that it was full of gold statues and jewels, and it was obvious that the key was going to be at the bottom of the dungeon. The DM had given them a teleport pad for running back to town for supplies and R&R, and they had left the other one back in their room in the inn. So one member teleported back to the room, then hoofed it back to the dungeon with the teleport pad. They slid one under the door and set the other one up on the wall in another room, and proceeded to toss fireballs at it while avoiding the gushing gouts of molten gold coming back at them. Waited till it cooled, then the fighters chopped it into pieces and loaded it into their packs, and everybody headed home. Halfway home they were all knocked unconscious by a passing level 18 wizard on a flying carpet who then stole their gold, because the one thing a good DM can't stand is being a Monty Hall.
The DM decided to "fix" the previous problem by enforcing PE=KE so you couldn't use the teleport pad until you were near the bottom of the dungeon so the potential energy between the two was very low. Unfortunately the next trip while crossing a lake high up in the mountains the guy carrying the teleport pad got killed and fell in. The (walled) town promptly filled up with boiling water from the lake, turning it into a very large bowl of halfling stew.
Fun stuff. Computer RPGs just don't quite compare.
Nope, I don't know which quadruples will execute in parallel on a Core Duo. And unless I compile a special version just for the core duo the compiler doesn't either. But this small assembler change sped up the *entire* program (not just that code segment) by an average of 8% across several CPU's tested. That's a pretty big win for a hundred lines of assembler.
One reason I'm so skeptical of claims of compiler efficiency by guys that have never done significant amounts of assembler is that these claims typically rest on the capabilities of a "sufficiently sophisticated compiler" that never seems to exist in reality. If you spend much time staring at the code coming out of MSVC it's difficult to be impressed. Yes they use sophisticated algorithms, and yes they optimize every single line of code relentlessly. But all those claims of the compiler producing better code than a human programmer were originally in reference to the sort of programmers that nowadays prefer VB, the claim was never made that compilers could out-perform a good programmer. Somehow this distinction has been lost in recent years, probably because of the lack of exposure to assembler in the college curriculae and the de-emphasis of low-level concerns have made the sort of competencies needed for assembler a rarity.
It sounds like "global optimization" means something different to you than it does to a compiler writer. For a compiler, this simply means optimizing across basic blocks, not optimizing across functions and files (that's usually called "whole-program optimization" or something like that). Humans optimize across basic blocks very easily, it's actually difficult to stop a programmer from doing fairly extensive optimizations at this scale -- programs just look untidy and needlessly redundant without it. Compilers still have trouble doing a decent job of this type of optimizations for non-functional languages (like C).
Even using assembler macros and prefab libraries of general-purpose assembler functions you're generally no worse off than the compiler. What the heck to you think the standard C runtime is?
The bigger danger to doing lots of code in assembler is that you're tempted to use simpler algorithms over tricky-but-fast ones, and you're tempted to optimize too early (though this is a problem in any language. Assembler just makes this trap particularly easy to fall into).
Only someone who hasn't recently replaced some critical C code with assembler and gotten substantial improvement would say that. This was MSVC 2003 which isn't the smartest C compiler out there, but not a bad one for the architecture. Still, a few hours with the assembler and a few more hours doing some timings to help fine-tune things improved the CPU performance of this particular service by about 8%.
Humans have been writing optimized assembler for decades, the compilers are still trying to catch up. Modern hand-written assembler isn't necessarily any trickier or more clever than the old stuff (it's actually a bit simpler). Yes compilers are using complicated and advanced techniques, but it's still all an attempt to approximate what humans do easily and intuitively. Artificial intelligence programs use complicated and advanced techniques too, but no one would claim that this suddenly makes philosophy any harder.
Your second point about the sophistication of the CPU's is true but orthogonal to the original claim. These sophisticated CPU's don't know who wrote the machine code, they do parallel execution and branch prediction and so forth on hand-optimized assembly just like they do on compiler-generated code. Which is one reason (along with extra registers and less segment BS) that it's easier to write and maintain assembler nowadays, even well-optimized assembler.
Except that we're not just "bumbling along". There are a lot of fields (such as the colorado oil shales and canadian oil sands) and a lot of technologies that weren't viable at $17/bbl that are viable at $50/bbl, and the oil companies are busily bringing those fields online and productizing those new technologies. But there is a lag of many years because it took awhile for the companies to decide that the risk of making a decade-long multi-billion dollar investment was likely to pay off, then another several years to finish developing the technologies and building up the oil fields. All of this started a few years ago, and won't start really coming online for another few years. Projecting future production based on current trends is therefore *really* misleading, because those current trends were based on two decades of stable oil prices at around $17/bbl. We got the same sort of misleading predictions back in the late 70's when the price of oil was spiking from $5/bbl to $15/bbl, but by the mid 80's a lot of new fields had come online, the offshore fields were producing gangbusters, and where the world had been running out of $5/bbl oil, it suddenly had plenty of $15/bbl oil. And once these new fields and new technologies come online we'll discover that we've got loads of $50/bbl oil -- I've heard estimates that the colorado oil shales and the canadian oil sands each have 3x-5x more oil than the entire middle east, it's just expensive and technologically intensive to get it out.
It's just you. The british bombe's were used on the 3-rotor enigma but couldn't handle the naval 4-rotor enigma. The american version was a bigger variant (and there were many more of them) to handle the much more difficult naval variant.
The 6809 was awfully nice, but the Intel 9600 is probably my favorite of the 16-bit processors. Three-register instructions, 128 registers (mapped to zero-page along with all the I/O addresses), nearly perfectly orthogonal architecture. The TI 9900 (used on the obscure TI99/4 microcomputer) was also pretty neat, it mapped the 16 GP registers to memory via a register base pointer so you could do ordinary stack allocation with your registers mapped into the stack, sliding window stacks, or even heap-allocated frames if you needed continuations, and since the registers were mapped to memory you didn't have to save or load them on procedure call since the hardware did it for you.
Ahhh, those were the days. Not boring x86 or RISC stuff like today.
This "one assembler statement maps to one instruction" line hasn't been true for nearly 50 years. Assembler developers use macros heavily, and assemblers typically came with large libraries of macros. They've even had if/then/else and while and for loops for decades (at least the better assemblers did).
Hand-written assembly doesn't look like compiler-generated assembly any more than hand-written C code looks like cfront-generated code.
Slashdot Mirror
This may change as the x86/x64 compiler writers start paying attention to the "optimize for size" bits of the compiler. For the last few decades all the attention has been paid to speed optimizations. It's possible that some of the advantage of ARM in this regard is due to the historically different focus of their compiler teams.
Five years ago would you have seriously thought they'd stick multiple cores in a phone? 64-bit will happen because phones are rapidly becoming more complex, and also because just like the first multi-core phones it will be a huge marketing advantage, because suddenly all those 32-bit phones will look weak and puny.
By that definition CISC chips have always actually been RISC chips. What did you think all that microcode in those CISC chips really was? RISC was an early win because it exposed the microcode to the compiler for improved optimization opportunities, and the simpler fetch/decode/execute logic made it easy to implement an efficient pipeline scheme which compensated for the increased memory traffic. The weakness of RISC was that by moving the microinstructions out into main memory and exposing them to the compilers they wound up exposing too many details of their implementations, and made themselves vulnerable to changes in the speed differential between CPU and memory. RISC's initial advantage in internal complexity quickly eroded as they added multiple dispatch units, and their pipelines changed from 4 to 6 to 8 stages but the instructions were still claiming they had 4. And as the performance differential between the CPU and main memory increased the functional density of CISC code became a win. Intel noticed that they could fake out more registers than the instruction set explicitly revealed, and could treat near memory off BP and SP as though they were registers, neatly mimicking the register windows of machines like SPARC (this basic trick had been used decades earlier in the TI 990 minicomputer). And Intel noticed that since their micro-instructions were similar to RISC ops, many of the basic optimizations that compilers were doing to improve the outputted code were sufficiently simple peephole-type optimizations that it could be implemented in hardware if this hardware optimizer were able to see the a wide enough window of micro-ops in flight. And since the burgeoning delta between CPU and memory speeds meant greatly increased on-die caches, it turned out that adding all this hardware didn't really change the die size much.
I call BS. You should be able to easily and productively talk to people with an IQ +/- 1SD of your own. At 140 that gives you a range of 125-155 with whom you should be able to hold a relatively interesting conversation, which comes out to about 5% of the general population. As long as you hang around the sorts of places where other smart people frequent, this will be much higher. College towns, business areas with largely college-educated workforce, etc. Hang out at the right pub and half the denizens there will have IQ's above 120. For that matter if you have an IQ of 140 and aren't working daily with lots of people with IQ's in the 120+ range then you need to find another place to work, or another line of work altogether.
I've never known an employer demand details, just the prescriptions demonstrating that you're taking them legally.
Personally I think the new start screen is a huge improvement over the old start menu, the metro apps look gorgeous, and the improvements to the desktop side (speed and usability) are significant. I don't think Win 8 will flop on the desktop.
But I don't think it will succeed on tablets like Microsoft needs it to. It will be a disappointment like WP7. The apps won't materialize like Microsoft needs them to, so customers will be stuck with a gorgeous UI that runs a browser, really basic email client, and MS Office. A handful of quality apps, and a somewhat larger smattering of mediocre-to-crappy apps, just like WP7. WinRT is a really huge breaking change in the APIs, so while you can program apps in VB.NET/C# it's a huge shift to do so. Unless your app is pretty trivial you're looking at rewriting a huge chunk of your code. And if you're gonna have to switch APIs and rewrite then you may as well target the iPad/iPhone, since that's where the market is. Microsoft is claiming that devs should target Metro/WinRT because of the sure-to-be-huge customer base, but that's far from a given. There will be a huge customer base on the desktop sure, but that customer base is already served by the existing application base, there's very little incremental market improvement to be had by going with Metro, unless the Win8 tablets really take off, and unfortunately WinRT makes that a much iffier "if".
If you go scrounging around looking for developer experiences with WinRT you find inspiring stories like this Microsoft MVP who finally figured out *how to read a file*: http://www.sharpgis.net/post/2012/01/12/Reading-and-Writing-text-files-in-Windows-8-Metro.aspx
I think it's telling that 6mo after giving away ~3000 development machines at Build 11, there are something like 100 apps in the app store.
If Metro were simply a newer variant of WPF then I believe Apple would be in for a serious fight for first place in the tablet space. Win 8 is wonderful to use on a tablet. But if the apps don't materialize by the hundreds of thousands in short order, then that just doesn't matter. Microsoft should have learned this lesson with WP7, which is itself much prettier and nicer to use than iOS. That they didn't is somewhat depressing. That they doubled down on their error by making WinRT even more of a breaking change than WP7, and even more aggravating to develop for than Silverlight/WP7 is kind of breathtaking.
No. It's certainly possible for some random problem to be misclassified as NP-complete because of a botched reduction proof. This sort of mistake has happened before, and it's not a big deal for anybody but the poor student. But 3-SAT is special - it was the first NP-complete problem that was discovered; the proofs of the other members of NP-complete depends on 3-SAT being in NP-complete. So if 3-SAT is in P then either all the reduction proofs for all the other NP-complete algorithms are wrong (very unlikely), or P==NP.
Progressives gave me very bad headaches. Once I switched to trufocus (now called superfocus) glasses the headaches went away. Plus I can keep the entire screen in focus (both screens actually), with progressives only a small band was in focus, both the top of the glasses was out of focus and the lower half was out of focus because the screen isn't at the right distance for *either* prescription. I could have gotten another pair of non-progressive mid-range glasses that would have solved the problem when sitting normally at my desk, but then I would have had to switch to a far-prescription lens when I leaned back in my chair... Or a pair of trifocals, which would at least give me a 6" bar of screen in focus. But it all got pretty silly very quickly, and the trufocals seemed like they would make the whole problem go away.
The focusing mechanism sounds aggravating but in practice it just disappears. The hyperfocal distance for the glasses is about four feet, so beyond that you just set it to infinity and forget about it. The focusing mechanism only comes into play when you settle down to code and set your focus, then when you get up to move about you set it back to infinity. Also I've found that in practice I don't really use the full focusing range, there are about five positions on the slider that I actually use. But those three extra focal lengths that you get over bifocals are a major win.
I've been very happy with mine, and will be buying another pair in September (I try to get new glasses every two years). My only knock against them was that I thought the round lens look was pretty ugly, however I've gotten a *lot* of compliments on the look of my superfocus glasses, strangers are always commenting to me on how nice they look - I've been wearing glasses for 30 years and never so much as a peep about my glasses except the platitudes from family, but in the 18 months since I got the superfocals it happens two or three times a month; cashiers, tellers, random people in the mall, etc.
No, that snippet compares AL and DX, leaving AX with 1's everywhere except the first different bit, which will hold a 0.
Ex:
AL= 00001101
DX= 00000010 00011001
CWD just puts a 0 in AH
AX= 00000000 00001101
DX= 00000010 00011001
XOR ax,dx computes ax ^= dx
AX=00000010 00010100
DX unchanged
SUB ax,dx computes ax -= dx
AX=1111111111111011
DX unchanged
The XOR swap algorithm to swap ax and dx is:
xor ax,dx
xor dx,ax
xor ax,dx
I also collect and shave with straight razors, and there are definitely new razors being made with ivory scales, though the manufacturers all claim to be using mammoth ivory. I always assumed there were certificates and licenses that they had to have to use any sort of ivory, but maybe I'm wrong. Anybody know what German law is on ivory (the DoVo company that makes these is in Solingen Germany)?
The bigger problem is that it can be tough to tell real ivory from ivory-looking celluloid just by visual inspection, even if you're holding it in your hands. There's no way to tell from a low-res ebay picture, and most sellers IMO don't have the foggiest idea what real ivory is like. I've had sellers claim that the genuine article was celluloid and vice versa, and I've had celluloid ivory in my hands that I had to test with a hot needle to see if it was celluloid or genuine.
Great battery life - talk time of 8 hrs or standby time of 2+ weeks. Don't know about the talk time, but I *do* get the specced standby time. Get it for $20 with the cheap ($30/mo) T-Mobile plan, or with their pre-pay plan for $40 (includes a $25 refill card).
The fact that the Zapotocny study has been peer-reviewed doesn't make it more relevant for Proenza's argument if it's studying the wrong hurricanes or has too-high of an uncertainty factor.
One of the most addictive games I've ever played.
Oh you wacky cityfolk with your strange grocery stores and megamarts. People in the country don't need money to buy food because they can (and do, and did) just grow it and hunt it. My great-grandparents (in rural Louisiana, not Tennessee, but same diff) knew about the Depression because they heard about it from the townspeople at church. It didn't affect them one way or the other because they had always grown all their food anyway. Rural electrification was a much bigger deal for them.
"A foolish consistency is the hobgoblin of simple minds" - Emerson
Reminds me of a funny story a friend told me (though it may not have been original). A group of them were running in a dungeon and ran into a locked room, and peeking under the door revealed that it was full of gold statues and jewels, and it was obvious that the key was going to be at the bottom of the dungeon. The DM had given them a teleport pad for running back to town for supplies and R&R, and they had left the other one back in their room in the inn. So one member teleported back to the room, then hoofed it back to the dungeon with the teleport pad. They slid one under the door and set the other one up on the wall in another room, and proceeded to toss fireballs at it while avoiding the gushing gouts of molten gold coming back at them. Waited till it cooled, then the fighters chopped it into pieces and loaded it into their packs, and everybody headed home. Halfway home they were all knocked unconscious by a passing level 18 wizard on a flying carpet who then stole their gold, because the one thing a good DM can't stand is being a Monty Hall.
The DM decided to "fix" the previous problem by enforcing PE=KE so you couldn't use the teleport pad until you were near the bottom of the dungeon so the potential energy between the two was very low. Unfortunately the next trip while crossing a lake high up in the mountains the guy carrying the teleport pad got killed and fell in. The (walled) town promptly filled up with boiling water from the lake, turning it into a very large bowl of halfling stew.
Fun stuff. Computer RPGs just don't quite compare.
Nope, I don't know which quadruples will execute in parallel on a Core Duo. And unless I compile a special version just for the core duo the compiler doesn't either. But this small assembler change sped up the *entire* program (not just that code segment) by an average of 8% across several CPU's tested. That's a pretty big win for a hundred lines of assembler.
One reason I'm so skeptical of claims of compiler efficiency by guys that have never done significant amounts of assembler is that these claims typically rest on the capabilities of a "sufficiently sophisticated compiler" that never seems to exist in reality. If you spend much time staring at the code coming out of MSVC it's difficult to be impressed. Yes they use sophisticated algorithms, and yes they optimize every single line of code relentlessly. But all those claims of the compiler producing better code than a human programmer were originally in reference to the sort of programmers that nowadays prefer VB, the claim was never made that compilers could out-perform a good programmer. Somehow this distinction has been lost in recent years, probably because of the lack of exposure to assembler in the college curriculae and the de-emphasis of low-level concerns have made the sort of competencies needed for assembler a rarity.
It sounds like "global optimization" means something different to you than it does to a compiler writer. For a compiler, this simply means optimizing across basic blocks, not optimizing across functions and files (that's usually called "whole-program optimization" or something like that). Humans optimize across basic blocks very easily, it's actually difficult to stop a programmer from doing fairly extensive optimizations at this scale -- programs just look untidy and needlessly redundant without it. Compilers still have trouble doing a decent job of this type of optimizations for non-functional languages (like C).
Even using assembler macros and prefab libraries of general-purpose assembler functions you're generally no worse off than the compiler. What the heck to you think the standard C runtime is?
The bigger danger to doing lots of code in assembler is that you're tempted to use simpler algorithms over tricky-but-fast ones, and you're tempted to optimize too early (though this is a problem in any language. Assembler just makes this trap particularly easy to fall into).
Only someone who hasn't recently replaced some critical C code with assembler and gotten substantial improvement would say that. This was MSVC 2003 which isn't the smartest C compiler out there, but not a bad one for the architecture. Still, a few hours with the assembler and a few more hours doing some timings to help fine-tune things improved the CPU performance of this particular service by about 8%.
Humans have been writing optimized assembler for decades, the compilers are still trying to catch up. Modern hand-written assembler isn't necessarily any trickier or more clever than the old stuff (it's actually a bit simpler). Yes compilers are using complicated and advanced techniques, but it's still all an attempt to approximate what humans do easily and intuitively. Artificial intelligence programs use complicated and advanced techniques too, but no one would claim that this suddenly makes philosophy any harder.
Your second point about the sophistication of the CPU's is true but orthogonal to the original claim. These sophisticated CPU's don't know who wrote the machine code, they do parallel execution and branch prediction and so forth on hand-optimized assembly just like they do on compiler-generated code. Which is one reason (along with extra registers and less segment BS) that it's easier to write and maintain assembler nowadays, even well-optimized assembler.
The XT keyboard had 83 keys, not 88. Even the original AT keyboard only had 84 keys.
Except that we're not just "bumbling along". There are a lot of fields (such as the colorado oil shales and canadian oil sands) and a lot of technologies that weren't viable at $17/bbl that are viable at $50/bbl, and the oil companies are busily bringing those fields online and productizing those new technologies. But there is a lag of many years because it took awhile for the companies to decide that the risk of making a decade-long multi-billion dollar investment was likely to pay off, then another several years to finish developing the technologies and building up the oil fields. All of this started a few years ago, and won't start really coming online for another few years. Projecting future production based on current trends is therefore *really* misleading, because those current trends were based on two decades of stable oil prices at around $17/bbl. We got the same sort of misleading predictions back in the late 70's when the price of oil was spiking from $5/bbl to $15/bbl, but by the mid 80's a lot of new fields had come online, the offshore fields were producing gangbusters, and where the world had been running out of $5/bbl oil, it suddenly had plenty of $15/bbl oil. And once these new fields and new technologies come online we'll discover that we've got loads of $50/bbl oil -- I've heard estimates that the colorado oil shales and the canadian oil sands each have 3x-5x more oil than the entire middle east, it's just expensive and technologically intensive to get it out.
It's just you. The british bombe's were used on the 3-rotor enigma but couldn't handle the naval 4-rotor enigma. The american version was a bigger variant (and there were many more of them) to handle the much more difficult naval variant.
The 6809 was awfully nice, but the Intel 9600 is probably my favorite of the 16-bit processors. Three-register instructions, 128 registers (mapped to zero-page along with all the I/O addresses), nearly perfectly orthogonal architecture. The TI 9900 (used on the obscure TI99/4 microcomputer) was also pretty neat, it mapped the 16 GP registers to memory via a register base pointer so you could do ordinary stack allocation with your registers mapped into the stack, sliding window stacks, or even heap-allocated frames if you needed continuations, and since the registers were mapped to memory you didn't have to save or load them on procedure call since the hardware did it for you.
Ahhh, those were the days. Not boring x86 or RISC stuff like today.
Assembly and C, just like Unix.
This "one assembler statement maps to one instruction" line hasn't been true for nearly 50 years. Assembler developers use macros heavily, and assemblers typically came with large libraries of macros. They've even had if/then/else and while and for loops for decades (at least the better assemblers did).
Hand-written assembly doesn't look like compiler-generated assembly any more than hand-written C code looks like cfront-generated code.