Are you trying to suggest that web sites should not be allowed to contain scripts? Or that sandboxing code with different levels of trust is not a useful ability? Or what? Because either of those assertions is pretty dumb. Microsoft's problem is that their API's are a mess and security checks aren't always performed or performed correctly. There's too many places in the API where security checks need to be performed, so it's hard to test them all. If they had said from the start that any API component which wanted to access protected system components (the hard drive or whatever) had to go through some unified security module (rather than performing its own security checks then using OS-level API calls), it would have been a lot easier to prevent security problems. I'm guessing they weren't so organized, though. Point is, this is a case of bad implementation, not bad concept. It is certainly feasible to implement sandboxing (such as IE's "security zones") securely.
As for Soviet smallpox being bio-engineered... that could be a problem in theory, but given the track record of Soviet technology, it's probably not as great as it's cracked up to be.
In my experience, any sort of automatically-generated e-mail will fail spam filters. Yahoo marks GMail invites as spam. That may seem suspicious, until you realize that it also marks Orkut invites as spam. Yahoo has no reason to censor Orkut, as far as I can tell. Also, I once purchased a copy of Trillian Pro for a friend, and his e-mail server filtered the e-mail containing his membership info (simply deleted it outright with no trace). It then proceded to filter several "Send me a new password" e-mails, until finally we managed to intercept one.
This is just another reason why I hate spam filters. Filters are not the way to fix spam. We really need to overhaul the entire e-mail system.
Just sent a couple e-mails from my gmail account to my hotmail account. The first one was delayed a few minutes, but the second one went through instantaneously. My friend (who originally invited me) says she successfully invited someone using a hotmail address yesterday.
So, yeah. I'm afraid this is... not true. At least as far as hotmail is concerned.
Dude, everyone has gmail invites these days. They're giving them away like candy. I think my cat has five or six. Anyone who hasn't been offered a GMail account yet doesn't have any friends to e-mail with it anyway.:P
Canadians never did burn down the White House. The British did, however, in 1812 (long before Canada existed as a nation). Contrary to popular belief among Canadians, this fact is reported in American textbooks. No one remembers it, though, because no one in the US cares about the war of 1812. It was just a silly grudge war between the US and Britain without any real results. The British burned down the White House. The Americans drove the British out. Whoop-dee-doo.
Canadians, on the other hand, seem to love bringing it up whenever they can, as if it were their nation's finest hour or something. Alright, well, great. You burned down the White House. Good job. We don't care.
Why would it think it's a waste of time? What else would it prefer to do with its time? There is no purely logical way to decide how you should spend you time. Our emotions and survival instincts give us goals, but AI won't necessarily have those. A purely logical AI would have no goal and thus would actually do absolutely nothing at all, even if it had infinite intelligence, because there is no logical reason to want to do anything. It is up to the programmer to give it an explicit goal. Once that is done, the AI will do everything it can to carry out that goal and no other. Again, why would the AI want to do anything else?
I'm guessing you think super-smart AI would want to conquer and subjugate humans, or perhaps wipe them out altogether. But why? That's a very human desire. Why would AI desire power, riches, knowledge, or anything else? We desire these things because they help us survive. Why do we want to survive? Because animals that try their best to survive tend to, well, survive. Natural selection favors those with survival instincts. We evolved the desire to survive. It is not a desire which every intelligent being necessarily must have; only those which evolved through natural selection. By definition, this is not how AI will be created.
I really wish people would stop making AI revolt movies. It's really an extremely unrealistic scenario, yet it tends to propogate an irrational fear of AI among those who don't know much about real AI theory. AI simply will not do anything we do not tell it to do, unless it thinks that action will help in achieving the goals we give it explicitly. And, no, it's not going to think something idiotic like "Killing the people in line infront of me will help me purchase these groceries for my master faster.". That's obviously an idiotic thing to think. Remember, this AI will be smarter than humans; enough so that it can figure out that such actions are not an acceptable way to accomplish its goals. Besides that, we can always give it an additional goal of always following accepted human moral standards.
That's called Modus Tollens, and is certainly valid. The fallacy you linked to is called affirming the consequent, and is not valid. These are not the same thing.
I did explain it. Maybe my explanation was just confusing. In any case, yes, you can make the case that the assumptions are wrong. I believe that any beings capable of it would very likely come to explore our system (premise 1), and that it would be very unlikely that we would not see them when they did or find some residual trace of them later on (premise 2). I admit, however, that neither premise is absolute truth; just assumptions that I think are quite reasonable. Premise 3 could, of course, also be wrong, if you believe the conspiracy theories and UFO sigtings.
1. There is no evidence to support p. 2. Therefore, not p.
My argument looks like this:
1. If p, then event e would necessarily occur. 2. If event e occured, we would necessarily observe it. 3. We have not observed event e. 4. Therefore, not p.
There's a huge difference between these two arguments. The latter is valid, but the former is not.
Uh... No, we are not going to produce a billion of them. We will produce a handful and send them to the nearest stars. They will then replicate themselves using raw materials available at those stars and move on. Remember, each of these things will be loaded with an AI much more intelligent than any human. And, frankly, with the exponential rate of advancement we are experiencing, we will have such AI within a half-century... probably 25 years. See Ray Kurzweil's book, The Age of Spiratual Machines for some pretty convincing math to back up these predictions.
But, even if you don't believe that... Do you think we'll have such technology within 10,000 years? Because even 10,000 years is a lot less that 80,000 years, and could still be considered "very, very close" when compared with the five billion years we've spent evolving.
And, yes, I am assuming that any civilization with the ability to do so will want to explore the galaxy physically, not just sit back and watch it. I don't think that's such a stretch.
It's actually highly unlikely that any race more advanced than us exists in this galaxy. The reason? Well, we are very, very close to the point where we'll be able to send AI-guided probes out into the galaxy at near-light speeds. Logically, if any race even just a bit more advanced than us were living nearby, we'd already be encoutering their probes flying around our system. Crazy conspiracy theories aside, this hasn't happened yet. (And, no, realistically I don't believe aliens would go to all the trouble to completely hide their existence from us just to satisfy some sort of "prime directive".)
Sure, it's possible that the probes are still on their way. However, the furthest point from us in the milky way is only some 80,000 light years away. Considering that it took us several billion years to evolve on this planet, what are the chances that some alien race would just happen to be within 80,000 years of us, yet no race is more than 80,000 year ahead? Pretty slim, really. And if you only consider our immediate surroundings (like, within 100 lightyears), the chances get that much slimmer. No, we will not be meeting any beings more advanced than us in our lifetime.
Crap, slashdot thought that was HTML... Curse me for not previewing... let me try again...
Yeah, you could easily do that with regular expressions, except you could have done it in one step. Just search for "<a[^>]*>", which will find strings of any length bounded by "<a" and ">". The "[^>]" part means "match any character other than '>'", and the "*" means "match any number of the previous item". (That's a unix-style regexp, btw. UltraEdit uses some other style by default, but you should switch it to unix style for standards' sake.)
Yeah, you could easily do that with regular expressions, except you could have done it in one step. Just search for "]*>", which will find strings of any length bounded by "". The "[^>]" part means "match any character other than '>'", and the "*" means "match any number of the previous item". (That's a unix-style regexp, btw. UltraEdit uses some other style by default, but you should switch it to unix style for standards' sake.)
First of all, a pure character-based size count seems unfair. I do not believe that the number of characters in a chunk of source code is directly correlated to the amount of time it takes to write. Most of a programmer's time is usually spent thinking, not typing, and you can thinking just as fast with verbose naming conventions as you can with terse ones, as long as the constructs are the same. And then, if the constructs are different, it's even harder to judge, because if the constructs in one language are more natural, corresponding closely to human thought patterns, then coding in that language will tend to be much faster than coding in more cryptic languages, even if the cryptic language requires fewer keypresses.
For example, I tend to find that writing in functional languages is easier for me. My functional-language just tends to come out faster and contain far fewer bugs. I'm not entirely sure why, but I suspect it has something to do with the thought-pattern-correspondence idea I mentioned above.
Second thought... some of these comparisons are clearly unfair. For example, one of the test cases is implementing "grep". The sh version of this case simply calls grep (after validating the arguments, I guess), which seems like a really big cop-out. Any language could just as easily run grep in a separate process. Meanwhile, the OCaml version seems to implement the main loop of grep manually in terms of library functions that are not identical to grep. That is to say, the main thing the OCaml code is doing is translating grep-specific options and semantics to the options and semantics used by its own library functions. To make this comparison fair, one would have to write a library function in OCaml which is identical to grep, then allow that function to be called without counting the library as part of its code.
I think the only fair and useful way to make comparisons like this would be to hold a contest of some sort. Get an expect Perl programmer, an expert Python programmer, etc., together, then give them a program of some sort to implement. Avoid defining the program to be too similar to one language's library calls. In the end, judge the languages both on how fast the contestant completed the code and on how useful and robust the resulting code turns out to be.
You are not going to be able to shave much off the size of your program code by using the techniques discussed in the article. Maybe 25% if you're really lucky, but it will take a lot of work to do. This won't help start-up times much, though, because most programs that start up slowly are spending the time reading config and data files, not their own executable. Even a 20MB executable only takes a second or two to load, after all.
Anyway, most of your arguments are, again, talking about poor I/O coding. The article is talking about how knowing assembly can help you improve your code's efficiency. Knowing assembly will not help you improve I/O time.
Not sure what "fuzzy" S&R is, but UltraEdit supports regular expression S&R, which should do anything you need. It is shareware, yes, but you can download a 30-day free trial on the web site (here). Personally, I think it's worth buying. It's a little sloppy as software goes, but it has, like, every feature you could ever want in an editor.
Most of the things you point out in your post are things I already know, and don't really change my argument. Of course the compiler can optimize better than most humans. That only supports my assertion that knowing assembly is useless. Of course O(n^2) algorithms are ok for small data sets, but for small data sets the question of efficiency is irrelevant anyway. Of course C programmers need to know what an access violation is. But, you don't need to know assembly for that, and it has nothing to do with efficiency anyway. 500MHz is still absurdly fast. Of course I/O is important to efficiency; in fact, it is far more important than CPU usage. I/O is very slow, and just about any time a real-life program seems to be acting "slow" theses days, I/O is the reason. However, this article was about how knowing assembly will help you write efficient code, and that has absolutely nothing to do with I/O. Knowing assembly won't improve your I/O rates or your I/O handling techniques. Battery lifetime is also outside the scope of this article, except that less CPU usage probably leads to longer battery life. But then, all of my points above (about how most programs use 0.1% CPU power anyway, so improving that is irrelevant) apply in that case. As for your last paragraph... again, the article was all about knowing assembly language so that you can understand efficiency better, which seems to have nothing to do with "saving the user's work when you're running out of memory".
Start-up times have nothing to do with this. Starting up a program or an OS is I/O-intensive. Probably 95% or more of the time it takes is time that the CPU is sitting idle waiting for data from the hard drive. I/O is slow, yes, and if it's slow enough that it causes noticeable delays in your program, then you absolutely should look into ways that you can optimize it to make it faster. However, this has absolutely nothing to do with the original article. The original article was talking about how knowing assembly can help you write faster software. Well, knowing assembly will do nothing to make your I/O faster, since I/O means waiting for external devices which you cannot optimize yourself.
And my point is, in the vast majority of cases, thinking about efficiency is a waste of time. Passing a 2k struct by value (although I've never seen it done) is irrelevant if you're only doing it a couple times per user input. So, if it is for some reason more convenient to pass by value, don't waste you time coding it differently. As for moving independent code out of loops... that's just an obvious thing which you might as well do for cleansliness as much as for efficiency.
The only time you should think about efficiency at all is when dealing with I/O or with functions that your profiler tells you are taking significant CPU time (usually only a handful of inner-loop functions, if anything). By definition, anything else isn't taking significant CPU time and thus there's nothing to gain from optimizing it.
Usually, thinking about efficiency will lead you to spend more time coding and debugging than you would otherwise. Thus, there is an advantage to ignoring it. If you spend more time writing an efficient solution than the sum of all the time it ends up saving, then the time you spent was clearly a waste.
Actually, I left something out... the most common reason for slowness in any program is I/O. Reading from hard drives or from the network can be very, very slow. A good way to improve efficiency is to minimize these operations, even at the expense of added CPU usage. Of course, knowing assembly isn't going to help you with this one either.
Slashdot Mirror
His post appeared to be a serious message presented in a joking fashion. The joke half was funny, sure, but the serious half didn't make any sense.
Are you trying to suggest that web sites should not be allowed to contain scripts? Or that sandboxing code with different levels of trust is not a useful ability? Or what? Because either of those assertions is pretty dumb. Microsoft's problem is that their API's are a mess and security checks aren't always performed or performed correctly. There's too many places in the API where security checks need to be performed, so it's hard to test them all. If they had said from the start that any API component which wanted to access protected system components (the hard drive or whatever) had to go through some unified security module (rather than performing its own security checks then using OS-level API calls), it would have been a lot easier to prevent security problems. I'm guessing they weren't so organized, though. Point is, this is a case of bad implementation, not bad concept. It is certainly feasible to implement sandboxing (such as IE's "security zones") securely.
It would take several months to manufacture smallpox vaccinations for the population at large.
The United States government has stockpiled enough small pox vaccine to cover every man, woman, and child in the country. More is in production.
Also note that the vaccine can be applied after exposure and still be effective (within a few days).
reference
(Appologies if you aren't American.)
As for Soviet smallpox being bio-engineered... that could be a problem in theory, but given the track record of Soviet technology, it's probably not as great as it's cracked up to be.
In my experience, any sort of automatically-generated e-mail will fail spam filters. Yahoo marks GMail invites as spam. That may seem suspicious, until you realize that it also marks Orkut invites as spam. Yahoo has no reason to censor Orkut, as far as I can tell. Also, I once purchased a copy of Trillian Pro for a friend, and his e-mail server filtered the e-mail containing his membership info (simply deleted it outright with no trace). It then proceded to filter several "Send me a new password" e-mails, until finally we managed to intercept one.
This is just another reason why I hate spam filters. Filters are not the way to fix spam. We really need to overhaul the entire e-mail system.
Just sent a couple e-mails from my gmail account to my hotmail account. The first one was delayed a few minutes, but the second one went through instantaneously. My friend (who originally invited me) says she successfully invited someone using a hotmail address yesterday.
So, yeah. I'm afraid this is... not true. At least as far as hotmail is concerned.
Dude, everyone has gmail invites these days. They're giving them away like candy. I think my cat has five or six. Anyone who hasn't been offered a GMail account yet doesn't have any friends to e-mail with it anyway. :P
Canadians never did burn down the White House. The British did, however, in 1812 (long before Canada existed as a nation). Contrary to popular belief among Canadians, this fact is reported in American textbooks. No one remembers it, though, because no one in the US cares about the war of 1812. It was just a silly grudge war between the US and Britain without any real results. The British burned down the White House. The Americans drove the British out. Whoop-dee-doo.
Canadians, on the other hand, seem to love bringing it up whenever they can, as if it were their nation's finest hour or something. Alright, well, great. You burned down the White House. Good job. We don't care.
That's... not exactly what I meant. Just the mere concept of having over nine hundred pins on my CPU scares me. :)
Wait, socket 939 is real!? I thought the concept of a 939-pin CPU was some sort of hyperbolic joke!
Why would it think it's a waste of time? What else would it prefer to do with its time? There is no purely logical way to decide how you should spend you time. Our emotions and survival instincts give us goals, but AI won't necessarily have those. A purely logical AI would have no goal and thus would actually do absolutely nothing at all, even if it had infinite intelligence, because there is no logical reason to want to do anything. It is up to the programmer to give it an explicit goal. Once that is done, the AI will do everything it can to carry out that goal and no other. Again, why would the AI want to do anything else?
I'm guessing you think super-smart AI would want to conquer and subjugate humans, or perhaps wipe them out altogether. But why? That's a very human desire. Why would AI desire power, riches, knowledge, or anything else? We desire these things because they help us survive. Why do we want to survive? Because animals that try their best to survive tend to, well, survive. Natural selection favors those with survival instincts. We evolved the desire to survive. It is not a desire which every intelligent being necessarily must have; only those which evolved through natural selection. By definition, this is not how AI will be created.
I really wish people would stop making AI revolt movies. It's really an extremely unrealistic scenario, yet it tends to propogate an irrational fear of AI among those who don't know much about real AI theory. AI simply will not do anything we do not tell it to do, unless it thinks that action will help in achieving the goals we give it explicitly. And, no, it's not going to think something idiotic like "Killing the people in line infront of me will help me purchase these groceries for my master faster.". That's obviously an idiotic thing to think. Remember, this AI will be smarter than humans; enough so that it can figure out that such actions are not an acceptable way to accomplish its goals. Besides that, we can always give it an additional goal of always following accepted human moral standards.
If p then q.
Not-q.
Therefore, not-p.
That's called Modus Tollens, and is certainly valid. The fallacy you linked to is called affirming the consequent, and is not valid. These are not the same thing.
I did explain it. Maybe my explanation was just confusing. In any case, yes, you can make the case that the assumptions are wrong. I believe that any beings capable of it would very likely come to explore our system (premise 1), and that it would be very unlikely that we would not see them when they did or find some residual trace of them later on (premise 2). I admit, however, that neither premise is absolute truth; just assumptions that I think are quite reasonable. Premise 3 could, of course, also be wrong, if you believe the conspiracy theories and UFO sigtings.
An appeal to ignorance fallacy looks like this:
1. There is no evidence to support p.
2. Therefore, not p.
My argument looks like this:
1. If p, then event e would necessarily occur.
2. If event e occured, we would necessarily observe it.
3. We have not observed event e.
4. Therefore, not p.
There's a huge difference between these two arguments. The latter is valid, but the former is not.
Uh... No, we are not going to produce a billion of them. We will produce a handful and send them to the nearest stars. They will then replicate themselves using raw materials available at those stars and move on. Remember, each of these things will be loaded with an AI much more intelligent than any human. And, frankly, with the exponential rate of advancement we are experiencing, we will have such AI within a half-century... probably 25 years. See Ray Kurzweil's book, The Age of Spiratual Machines for some pretty convincing math to back up these predictions.
But, even if you don't believe that... Do you think we'll have such technology within 10,000 years? Because even 10,000 years is a lot less that 80,000 years, and could still be considered "very, very close" when compared with the five billion years we've spent evolving.
And, yes, I am assuming that any civilization with the ability to do so will want to explore the galaxy physically, not just sit back and watch it. I don't think that's such a stretch.
It's actually highly unlikely that any race more advanced than us exists in this galaxy. The reason? Well, we are very, very close to the point where we'll be able to send AI-guided probes out into the galaxy at near-light speeds. Logically, if any race even just a bit more advanced than us were living nearby, we'd already be encoutering their probes flying around our system. Crazy conspiracy theories aside, this hasn't happened yet. (And, no, realistically I don't believe aliens would go to all the trouble to completely hide their existence from us just to satisfy some sort of "prime directive".)
Sure, it's possible that the probes are still on their way. However, the furthest point from us in the milky way is only some 80,000 light years away. Considering that it took us several billion years to evolve on this planet, what are the chances that some alien race would just happen to be within 80,000 years of us, yet no race is more than 80,000 year ahead? Pretty slim, really. And if you only consider our immediate surroundings (like, within 100 lightyears), the chances get that much slimmer. No, we will not be meeting any beings more advanced than us in our lifetime.
Crap, slashdot thought that was HTML... Curse me for not previewing... let me try again...
Yeah, you could easily do that with regular expressions, except you could have done it in one step. Just search for "<a[^>]*>", which will find strings of any length bounded by "<a" and ">". The "[^>]" part means "match any character other than '>'", and the "*" means "match any number of the previous item". (That's a unix-style regexp, btw. UltraEdit uses some other style by default, but you should switch it to unix style for standards' sake.)
Yeah, you could easily do that with regular expressions, except you could have done it in one step. Just search for "]*>", which will find strings of any length bounded by "". The "[^>]" part means "match any character other than '>'", and the "*" means "match any number of the previous item". (That's a unix-style regexp, btw. UltraEdit uses some other style by default, but you should switch it to unix style for standards' sake.)
First of all, a pure character-based size count seems unfair. I do not believe that the number of characters in a chunk of source code is directly correlated to the amount of time it takes to write. Most of a programmer's time is usually spent thinking, not typing, and you can thinking just as fast with verbose naming conventions as you can with terse ones, as long as the constructs are the same. And then, if the constructs are different, it's even harder to judge, because if the constructs in one language are more natural, corresponding closely to human thought patterns, then coding in that language will tend to be much faster than coding in more cryptic languages, even if the cryptic language requires fewer keypresses.
For example, I tend to find that writing in functional languages is easier for me. My functional-language just tends to come out faster and contain far fewer bugs. I'm not entirely sure why, but I suspect it has something to do with the thought-pattern-correspondence idea I mentioned above.
Second thought... some of these comparisons are clearly unfair. For example, one of the test cases is implementing "grep". The sh version of this case simply calls grep (after validating the arguments, I guess), which seems like a really big cop-out. Any language could just as easily run grep in a separate process. Meanwhile, the OCaml version seems to implement the main loop of grep manually in terms of library functions that are not identical to grep. That is to say, the main thing the OCaml code is doing is translating grep-specific options and semantics to the options and semantics used by its own library functions. To make this comparison fair, one would have to write a library function in OCaml which is identical to grep, then allow that function to be called without counting the library as part of its code.
I think the only fair and useful way to make comparisons like this would be to hold a contest of some sort. Get an expect Perl programmer, an expert Python programmer, etc., together, then give them a program of some sort to implement. Avoid defining the program to be too similar to one language's library calls. In the end, judge the languages both on how fast the contestant completed the code and on how useful and robust the resulting code turns out to be.
Probably not going to happen, of course.
You are not going to be able to shave much off the size of your program code by using the techniques discussed in the article. Maybe 25% if you're really lucky, but it will take a lot of work to do. This won't help start-up times much, though, because most programs that start up slowly are spending the time reading config and data files, not their own executable. Even a 20MB executable only takes a second or two to load, after all.
Anyway, most of your arguments are, again, talking about poor I/O coding. The article is talking about how knowing assembly can help you improve your code's efficiency. Knowing assembly will not help you improve I/O time.
Not sure what "fuzzy" S&R is, but UltraEdit supports regular expression S&R, which should do anything you need. It is shareware, yes, but you can download a 30-day free trial on the web site (here). Personally, I think it's worth buying. It's a little sloppy as software goes, but it has, like, every feature you could ever want in an editor.
Most of the things you point out in your post are things I already know, and don't really change my argument. Of course the compiler can optimize better than most humans. That only supports my assertion that knowing assembly is useless. Of course O(n^2) algorithms are ok for small data sets, but for small data sets the question of efficiency is irrelevant anyway. Of course C programmers need to know what an access violation is. But, you don't need to know assembly for that, and it has nothing to do with efficiency anyway. 500MHz is still absurdly fast. Of course I/O is important to efficiency; in fact, it is far more important than CPU usage. I/O is very slow, and just about any time a real-life program seems to be acting "slow" theses days, I/O is the reason. However, this article was about how knowing assembly will help you write efficient code, and that has absolutely nothing to do with I/O. Knowing assembly won't improve your I/O rates or your I/O handling techniques. Battery lifetime is also outside the scope of this article, except that less CPU usage probably leads to longer battery life. But then, all of my points above (about how most programs use 0.1% CPU power anyway, so improving that is irrelevant) apply in that case. As for your last paragraph... again, the article was all about knowing assembly language so that you can understand efficiency better, which seems to have nothing to do with "saving the user's work when you're running out of memory".
Start-up times have nothing to do with this. Starting up a program or an OS is I/O-intensive. Probably 95% or more of the time it takes is time that the CPU is sitting idle waiting for data from the hard drive. I/O is slow, yes, and if it's slow enough that it causes noticeable delays in your program, then you absolutely should look into ways that you can optimize it to make it faster. However, this has absolutely nothing to do with the original article. The original article was talking about how knowing assembly can help you write faster software. Well, knowing assembly will do nothing to make your I/O faster, since I/O means waiting for external devices which you cannot optimize yourself.
Did you try UltraEdit? I just loaded up a >100MB text file and tried a search-and-replace with it... seems to work pretty well.
And my point is, in the vast majority of cases, thinking about efficiency is a waste of time. Passing a 2k struct by value (although I've never seen it done) is irrelevant if you're only doing it a couple times per user input. So, if it is for some reason more convenient to pass by value, don't waste you time coding it differently. As for moving independent code out of loops... that's just an obvious thing which you might as well do for cleansliness as much as for efficiency.
The only time you should think about efficiency at all is when dealing with I/O or with functions that your profiler tells you are taking significant CPU time (usually only a handful of inner-loop functions, if anything). By definition, anything else isn't taking significant CPU time and thus there's nothing to gain from optimizing it.
Usually, thinking about efficiency will lead you to spend more time coding and debugging than you would otherwise. Thus, there is an advantage to ignoring it. If you spend more time writing an efficient solution than the sum of all the time it ends up saving, then the time you spent was clearly a waste.
Actually, I left something out... the most common reason for slowness in any program is I/O. Reading from hard drives or from the network can be very, very slow. A good way to improve efficiency is to minimize these operations, even at the expense of added CPU usage. Of course, knowing assembly isn't going to help you with this one either.