4 ms·

Why would you be able to do more, or indeed less, with it programmed in assembly rather than a higher level language? There isn't anything about assembly langu

Why would you be able to do more, or indeed less, with it programmed in assembly rather than a higher level language? There isn't anything about assembly language that makes it inherently more effective or efficient than a high level language.

jacquesm 3y ago
Your executables will be a small fraction of the size that you expect, you will likely be able to fit the whole thing in cache and you will consume less power because you will be happy with a smaller cycles budget so you can run the cpu much slower. Of course this all comes at a price: decreased programmer efficiency.
- rafram 3y ago
  I don’t think that’s actually true. Compilers write machine code that’s often much more efficient than anything you could think up by hand, and the bulk of the disk space/memory used by a modern executable is for resources/strings, not instructions. Stereotypical assembly code - extremely lean routines that accept minimal user input and don’t create human-readable output - is indeed smaller than a stereotypical compiled executable, but you’d have trouble beating the compiler 1:1 on the same problem.
  - jacquesm 3y ago
    But you won't be writing the same code as the code that you would write in a high level language, and that is sort of the point. You're going to do your utmost not to write such code because then you might as well break out the C compiler.
    - djur 3y ago
      Assuming that such code is suitable or even feasible for the problem you're attempting to solve. High-level languages were created specifically for the purpose of writing large, complex software systems. We don't see assembly being used for those systems. Isn't there an argument that high-level languages are simply more fit for that purpose?
  - rahen 3y ago
    I don't think so, modern high level languages tend to be linked to huge runtimes that are usually load entirely in memory. Assembly programs don't.
    - djur 3y ago
      If you're not linking to those runtimes and system libraries you're reimplementing them. The functionality has to come from somewhere.
      - rahen 3y ago
        That's what assembly programmers do, they re-use code. They just don't need to ship huge runtimes to be then loaded into memory.
- kwhitefoot 3y ago
  > Your executables will be a small fraction of the size that you expect, No they won't. There is no way that you can write more compact code than a modern optimizing compiler for anything except the most extreme edge cases.
  - charsii 3y ago
    It's trivially easy. One low hanging fruit: Compilers are handicapped by ABIs and language semantics, they must adhere to calling conventions, alignments, paddings, exceptions/stack unwinding, etc. If you don't have to care about any of that you can save a lot of useless instructions. And secondly when it comes to size optimizations, compilers are pretty bad (or they tend to still value some speed over pure size). Wont find any modern compiler emitting lodsb/stosb (the non-rep kind) on x86 for example.
    - kaba0 3y ago
      > Compilers are handicapped by ABIs and language semantics, they must adhere to calling conventions, alignments, paddings, exceptions/stack unwinding, etc. I believe most of these are only at potential “extern C” points. Usually these conventions are upheld because they don’t have a huge cost, but to give you a trivial example: inlining is literally about dropping all that in favor of optimizing at a larger scope.
  - jacquesm 3y ago
    Yes you will. Because you can't afford to write code like a modern optimizing compiler. You're going to have the same kind of linecount that you have in your high level language projects and those lines will compile down to a few bytes each at most. Assembly language binaries tend to be extremely small compared to equivalent code written using a high level language. But: you'll easily spend 10x the time on them. The 'modern optimizing compiler' argument is at the function level: where you write a function using assembly and then write a similar function using a high level language (but still a compiled one, obviously). Yes, the compiler will probably win that race. But an assembly language programmer isn't going to write their code like that at all. They will reduce the task to the point where it is manageable and that alone will save far more code than the compiler can ever remove. Assembly is (and assembly language based applications are) utterly bloat free, you do what you have to do and nothing more. You can use registers in ways that a compiler would never even think of because you can globally optimize. No stack frames if you don't need them. No memory accesses if you don't need them. But code that is hard to maintain and that likely will not be easy to work on with multiple people. 100 KLOC (including comments) -> 16Kb output. No high level language would even begin to approach that.
- kaba0 3y ago
  Many instructions in assembly is simply “logistics” of where should this or that byte go. Machines are eons better at it at large scopes than humans, you surely don’t have enough hair to sit through and carefully examine every register. Also, will you decide on a case by case basis to “inline” a function’s body? What if the function’s body changes? Will you go back to every “inlined” part? What if that makes a more efficient register allocation possible, rewrite the whole function where the inline happened?
rahen 3y ago
In principle, this amounts to giving a gift to society: the programmer spends more time on their work so that society as a whole consumes fewer resources. Often, the opposite happens: the programmer transfers their productivity gain into an additional cost for society (usually by contributing to e-waste and added resource requirements). It's easy to extrapolate this to other domains. Imagine that in order to enhance their productivity, aerospace engineers started buying off-the-shelf generic components and get them assembled as quickly as possible without seeking optimization. The airplanes will consume a lot more fuel, have a worse safety record and require constant upgrades and maintenance, but it doesn't matter much as the manufacturer can now hire fewer engineers, and it's other people's fuel you're wasting anyway. I understand that seeking immediate profit is the norm, but I'm always a little disillusioned when I see selfless initiatives ridiculed.
- djur 3y ago
  I'm not sure how to make sense of this analogy without assuming that assembly language programming self-evidently produces superior programs than programming in high-level languages, and it's exactly that claim that the comment you're replying to is challenging.

jacquesm 3y ago

Your executables will be a small fraction of the size that you expect, you will likely be able to fit the whole thing in cache and you will consume less power because you will be happy with a smaller cycles budget so you can run the cpu much slower. Of course this all comes at a price: decreased programmer efficiency.

rafram 3y ago
I don’t think that’s actually true. Compilers write machine code that’s often much more efficient than anything you could think up by hand, and the bulk of the disk space/memory used by a modern executable is for resources/strings, not instructions. Stereotypical assembly code - extremely lean routines that accept minimal user input and don’t create human-readable output - is indeed smaller than a stereotypical compiled executable, but you’d have trouble beating the compiler 1:1 on the same problem.
- jacquesm 3y ago
  But you won't be writing the same code as the code that you would write in a high level language, and that is sort of the point. You're going to do your utmost not to write such code because then you might as well break out the C compiler.
  - djur 3y ago
    Assuming that such code is suitable or even feasible for the problem you're attempting to solve. High-level languages were created specifically for the purpose of writing large, complex software systems. We don't see assembly being used for those systems. Isn't there an argument that high-level languages are simply more fit for that purpose?
- rahen 3y ago
  I don't think so, modern high level languages tend to be linked to huge runtimes that are usually load entirely in memory. Assembly programs don't.
  - djur 3y ago
    If you're not linking to those runtimes and system libraries you're reimplementing them. The functionality has to come from somewhere.
    - rahen 3y ago
      That's what assembly programmers do, they re-use code. They just don't need to ship huge runtimes to be then loaded into memory.
kwhitefoot 3y ago
> Your executables will be a small fraction of the size that you expect, No they won't. There is no way that you can write more compact code than a modern optimizing compiler for anything except the most extreme edge cases.
- charsii 3y ago
  It's trivially easy. One low hanging fruit: Compilers are handicapped by ABIs and language semantics, they must adhere to calling conventions, alignments, paddings, exceptions/stack unwinding, etc. If you don't have to care about any of that you can save a lot of useless instructions. And secondly when it comes to size optimizations, compilers are pretty bad (or they tend to still value some speed over pure size). Wont find any modern compiler emitting lodsb/stosb (the non-rep kind) on x86 for example.
  - kaba0 3y ago
    > Compilers are handicapped by ABIs and language semantics, they must adhere to calling conventions, alignments, paddings, exceptions/stack unwinding, etc. I believe most of these are only at potential “extern C” points. Usually these conventions are upheld because they don’t have a huge cost, but to give you a trivial example: inlining is literally about dropping all that in favor of optimizing at a larger scope.
- jacquesm 3y ago
  Yes you will. Because you can't afford to write code like a modern optimizing compiler. You're going to have the same kind of linecount that you have in your high level language projects and those lines will compile down to a few bytes each at most. Assembly language binaries tend to be extremely small compared to equivalent code written using a high level language. But: you'll easily spend 10x the time on them. The 'modern optimizing compiler' argument is at the function level: where you write a function using assembly and then write a similar function using a high level language (but still a compiled one, obviously). Yes, the compiler will probably win that race. But an assembly language programmer isn't going to write their code like that at all. They will reduce the task to the point where it is manageable and that alone will save far more code than the compiler can ever remove. Assembly is (and assembly language based applications are) utterly bloat free, you do what you have to do and nothing more. You can use registers in ways that a compiler would never even think of because you can globally optimize. No stack frames if you don't need them. No memory accesses if you don't need them. But code that is hard to maintain and that likely will not be easy to work on with multiple people. 100 KLOC (including comments) -> 16Kb output. No high level language would even begin to approach that.
kaba0 3y ago
Many instructions in assembly is simply “logistics” of where should this or that byte go. Machines are eons better at it at large scopes than humans, you surely don’t have enough hair to sit through and carefully examine every register. Also, will you decide on a case by case basis to “inline” a function’s body? What if the function’s body changes? Will you go back to every “inlined” part? What if that makes a more efficient register allocation possible, rewrite the whole function where the inline happened?

rahen 3y ago

In principle, this amounts to giving a gift to society: the programmer spends more time on their work so that society as a whole consumes fewer resources. Often, the opposite happens: the programmer transfers their productivity gain into an additional cost for society (usually by contributing to e-waste and added resource requirements). It's easy to extrapolate this to other domains. Imagine that in order to enhance their productivity, aerospace engineers started buying off-the-shelf generic components and get them assembled as quickly as possible without seeking optimization. The airplanes will consume a lot more fuel, have a worse safety record and require constant upgrades and maintenance, but it doesn't matter much as the manufacturer can now hire fewer engineers, and it's other people's fuel you're wasting anyway. I understand that seeking immediate profit is the norm, but I'm always a little disillusioned when I see selfless initiatives ridiculed.

djur 3y ago
I'm not sure how to make sense of this analogy without assuming that assembly language programming self-evidently produces superior programs than programming in high-level languages, and it's exactly that claim that the comment you're replying to is challenging.