Author Topic: Compiler vs the Assembly guy  (Read 13837 times)

CodeDog

  • Guest
Compiler vs the Assembly guy
« on: September 24, 2012, 11:18:51 PM »
How many times have we heard "The compiler can do better work than an assembly coder". If we take this seriously and consider the facts, here are the facts:

1. Someone who codes a compiler have to have great understanding of machine instructions.
2. Someone who codes an optimizing compiler have to have great understanding of optimizing the use of machine instructions.
3. Therefore someone who codes a compiler is by definition "an assembly expert".

4. An assembly programmer is, by definition an assembly programmer.
5. There are no differences between the guy who codes a compiler and the guy who codes manual assembly regularly.

6. The only difference between how both handles machine instructions, is that the compiler-guy have to handle unseen machine instructions in the future
    and the assembly coder deals with machine instructions that appears right before his nose in real-time.

Logically what follows from this is that if we speak of probability (which we have to do in this case), is that the manual assembly coder have much greater chance
of producing better code because he deals with what is seen and can act upon it while the compiler-guy is virtually blind.  :dazzled:

I guess the point is that, the argument that "a compiler is better than the assembly coder" doesn't logically follow if we speak of probability, which we always have to
do unless we are speaking of specific code samples and not about future code.

If a c++ programmer brags about his compiler, next time tell him to remind you to make it better in the future.  :icon_mrgreen:

Gunther

  • Member
  • *****
  • Posts: 4119
  • Forgive your enemies, but never forget their names
Re: Compiler vs the Assembly guy
« Reply #1 on: September 25, 2012, 05:31:35 AM »
Hi CodeDog,

How many times have we heard "The compiler can do better work than an assembly coder". If we take this seriously and consider the facts, here are the facts:

things are not easy. My experience is that: sometimes the compiler does an excellent job, but sometimes there are poor results. Anyway, it's a good idea to have a look at the assembly language output of the compiler. An optimizing compiler will implement nearly all of the general optimisations; it will do them tirelessly, missing nearly nothing. Most of a program is not time-critical; perhaps 10% or less of a program is worth optimising. Therefore: learn the compiler’s tricks; perhaps you can do the compiler’s tricks better.

Gunther
You have to know the facts before you can distort them.

Vortex

  • Member
  • *****
  • Posts: 2724
Re: Compiler vs the Assembly guy
« Reply #2 on: September 25, 2012, 05:49:41 AM »
I agree with Gunther. The main difference between an optimizing compiler and an assembly coder is that the programmer is aware of what he's doing.

Gunther

  • Member
  • *****
  • Posts: 4119
  • Forgive your enemies, but never forget their names
Re: Compiler vs the Assembly guy
« Reply #3 on: September 25, 2012, 06:14:16 AM »
Hi Vortex,

The main difference between an optimizing compiler and an assembly coder is that the programmer is aware of what he's doing.

absolutely right. To look at the compiler's output with the goal to beat the compiler, one may say: "That's not fair". My answer is: that's right, but our world isn't fair.

Gunther
You have to know the facts before you can distort them.

CodeDog

  • Guest
Re: Compiler vs the Assembly guy
« Reply #4 on: September 25, 2012, 06:29:31 AM »
The compiler produces overall optimization even in the parts that doesn't need to be optimized and almost instantly. If your source code is 500k lines and you spent 2 or 3 years on it, the compiler can optimize the entire thing in just half a minute. If you were to optimize it manually you would spend a lot of time achieving the same if you didn't already optimize it from the beginning. One of the things that scare me (as an assembly programmer) is the crazy amount of constants the compiler will put out, magical constants here and there that makes no sense when you look at it, you really have to dig into it to understand the constants used. I've tried to beat the compiler and I fail every time, it may be because I am not really that advanced in assembly programming, but I tried a few times only and last time I tried we were even in speed.

As it is with assembly the same applies to hl languages too, it all boils down to how the programmer lay out his code. You could be producing something really bad and the compiler does the best of its ability to optimize it, the code runs fast but the overall solution is bad, bad algorithm or bad planning and design. I wonder if there will be a revolutionary step for compilers in the future, perhaps compilers will be able to try every combination possible to achieve the peak potential of optimization who knows where it will be heading. There might come a day when compilers will be able to find the ultimate, perhaps not algorithm-wise, but instruction-wise and perhaps even more than that.


K_F

  • Member
  • *****
  • Posts: 1692
  • Anybody out there?
Re: Compiler vs the Assembly guy
« Reply #5 on: September 25, 2012, 07:31:05 PM »
There might come a day when compilers will be able to find the ultimate, perhaps not algorithm-wise, but instruction-wise and perhaps even more than that.
High probability of not occurring...  Trying to make something that automatically satisfies everything is doomed to fail.
Whereas a programmer can always make a library of optimised macros.
As far as I'm concerned compilers/assemblers must just churn out the code 'exactly' as we put in. Optimisation must be done by the stuff between the ears.
 :biggrin:
'Sire, Sire!... the peasants are Revolting !!!'
'Yes, they are.. aren't they....'

satpro

  • Member
  • **
  • Posts: 116
Re: Compiler vs the Assembly guy
« Reply #6 on: September 25, 2012, 10:41:20 PM »
Not sure what (whose) side I'm on here, given the debate, but I believe you can't "beat" assembly no matter how hard you try.  It's never been true--and not even close.  Simple logic proves it so without the obligatory nose-wiping "good compiler beats bad assembly" line used by "compilerologists."


Anyway, the best will always be a tie--and better than that can't happen until compilers figure out a really neat trick not yet developed, such as better than 1 to 1 efficiency.

Ryan

  • Guest
Re: Compiler vs the Assembly guy
« Reply #7 on: September 25, 2012, 10:52:45 PM »
Artificial intelligence?

Gunther

  • Member
  • *****
  • Posts: 4119
  • Forgive your enemies, but never forget their names
Re: Compiler vs the Assembly guy
« Reply #8 on: September 26, 2012, 02:52:42 AM »
High probability of not occurring...  Trying to make something that automatically satisfies everything is doomed to fail.

absolutely true, because that would be a kind of Mac Gyver's Swiss Knife. :lol:

There might come a day when compilers will be able to find the ultimate, perhaps not algorithm-wise, but instruction-wise and perhaps even more than that.

that's to much for a compiler. First: every translator - and a compiler is a translator - is a tool, not more, not less. It should be fit in very different situations, which the compiler builder can't know, and by the way, it's also not the responsibility of the compiler's author. The programmer has to know for what purpose and goal the compiler is used. The compiler builder can't know, for example:
  • how are the data organised
  • how is the actual data alignment
  • how is the data flow
and a lot of other important questions, because that's in most cases part of the underlying algorithms. That makes your statement to wishful thinking of a hole bunch of HL advocates.

Gunther
You have to know the facts before you can distort them.

CodeDog

  • Guest
Re: Compiler vs the Assembly guy
« Reply #9 on: September 26, 2012, 03:22:12 AM »
I am not advocating that compilers will be able to find the "ultimate" in the future. Compilers follow rules, rule-based compilers can't do anything better than the rules allow to. What I am saying is that it just may be that in the future, compilers will be able to brute force all combinations in a virtual environment, or maybe someone comes up with an idea how to avoid brute force in order to find what is optimal in a smart way. It just may be so. In the beginning of 1900's nobody ever though we would go to the moon, and just a few decades later we did exactly that. I'm just saying, can't tell what science brings tomorrow  :P

Compilers go one way -> they become better.

Something is going to happen sooner or later and it will not go backwards.

Gunther: You are describing what today's compilers ARE. And that has got nothing to do with what they might mutate INTO. You are simply referring today's facts and its useless in a discussion of future technology.
It is sort of like talking about bicycles. ManX: "Bicycles might become better next year." ManY: "No, bicycles have always been the way they have been so they can't become better."

I am simply saying that evolution is highly probable and you are saying evolution is not probable and then you refer to the limits of our understanding today. But you forget that today's understanding is not what tomorrow's understanding is. The limits you are talking about is not a natural law, they get solved, and things like this has been solved many times before as well.

CodeDog

  • Guest
Re: Compiler vs the Assembly guy
« Reply #10 on: September 26, 2012, 03:32:32 AM »
Not sure what (whose) side I'm on here, given the debate, but I believe you can't "beat" assembly no matter how hard you try.  It's never been true--and not even close.  Simple logic proves it so without the obligatory nose-wiping "good compiler beats bad assembly" line used by "compilerologists."


Anyway, the best will always be a tie--and better than that can't happen until compilers figure out a really neat trick not yet developed, such as better than 1 to 1 efficiency.

There are no sides to it. The first message in this topic is not saying that an assembly programmer is better than a compiler. It simply points out probability, which is the only factor you can use when speaking of optimization comparisons without any source to refer to. The point is simply that you can't debate which is better if you don't have a specific source to point to because the assembly programmer can stretch himself to perform better, the compiler can't because it is predetermined. This is a fact you can't take sides on, its a fact and not an opinion. The assembly programmer can stretch himself, a compiler can't go beyond its own set of rules. :biggrin:

Gunther

  • Member
  • *****
  • Posts: 4119
  • Forgive your enemies, but never forget their names
Re: Compiler vs the Assembly guy
« Reply #11 on: September 26, 2012, 05:48:12 AM »
Hi CodeDog,

Gunther: You are describing what today's compilers ARE. And that has got nothing to do with what they might mutate INTO. You are simply referring today's facts and its useless in a discussion of future technology.

Nobody knows what the future will bring. It's possible that the quantum computer is in a few years state of the art. If so, our discussion will become obsolete. But that's not sure.

I am simply saying that evolution is highly probable and you are saying evolution is not probable and then you refer to the limits of our understanding today.

I did never say that an evolution isn't possible. I've seen a lot of "new technology" in the last decades. In the late 70s and early 80s BASIC was the measure; after that came Pascal. The main argument was: Pascal is more structured and will save all problems. But at the end of the 80s was C the gold standard. Then came C++ and now is Java the "New Kid on the block". Or lets have a look at the countless articles about the paperless office in the 80s - nothing as wishful thinking. We can say that at the moment we haven't a RAM problem; the DOS days are over. But the other problems are not solved. The software crisis is now over 40 years old and it's true what Dijkstra pointed out in Garmisch 1968:
Quote
The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.

Edsger Dijkstra, The Humble Programmer (EWD340), Communications of the ACM

Gunther
You have to know the facts before you can distort them.

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 10031
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: Compiler vs the Assembly guy
« Reply #12 on: September 26, 2012, 10:40:03 AM »
I think I have heard too many of these threads over time, I am pretty much a "pick the tool for the job" man. With a range the shifts from shovelling CHYTE at one end to whittling opcodes in HEX at the other end, you pick which does the job either the cheapest, most efficiently or in some cases, the fastest. If the code is only going to be used once, who cares. If alternately it is going to be bashed to death billions of times a day by a massive number of people around the world, then put the effort into tuning it to optimise the task.

Assembler programmers use an assembler because whittling opcodes is hard work.
Low level compiler programmers use a low level compiler because an assembler is hard work.
High level compiler programmers use them because low level compilers are hard work.
Very high level compiler programmers use them because high level compilers are hard work.
Script jockeys use them because very high level compilers don't make much sense.
Paying customers pick what does the job, they don't care how its made as long as it does the job fast enough.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

CodeDog

  • Guest
Re: Compiler vs the Assembly guy
« Reply #13 on: September 26, 2012, 11:27:13 AM »
Paying customers pick what does the job, they don't care how its made as long as it does the job fast enough.

Intel scientists will continue to be deadly accurate and tremendously focused on the task of improving hardware (and software interaction for that matter), lazy customers won't ever change that. Scientists have been killed and threatened over time and not even that could stop the progress. Science will continue like a robot despite any lazy customers or any customers who is not aware of what they are buying. Ignorance will certainly not stop it. You also have to consider competition, company X produces something the customer will be satisfied with, company Y have to do better. After some time they both understand which way is the way that works and it is forward and only forward.  :P

You also have to consider that what customers get today (despite not the best choice) is still a great deal better than what they could get ten years ago, even lazy customers have to follow, not exactly optimized for the best quality but they do get the good stuff too. Customers might not care, but intel scientists are computer enthusiasts and many visionaries. That is why they posess the kind of profession they do is because they belong there, so it naturally follows they are going to provide for the world in that field. They didn't get hired by Intel because they were lazy customers.

CodeDog

  • Guest
Re: Compiler vs the Assembly guy
« Reply #14 on: September 26, 2012, 11:42:09 AM »
Paying customers pick what does the job, they don't care how its made as long as it does the job fast enough.

This is true but not in the way you think of it. Customers are usually satisfied with what they can get UNTIL they experience something that just outperforms it, something that is of better quality. I've seen this many times over how people (when they become aware of something that is better) they pick what is better. What you are really saying here is that ads are useful.

I have to add that even lazy customers do a little bit research too, and if it is not a private person and the guy works for a company and is looking for some piece of software they are usually under pressure and will look for software under limited time.