3 ms·

> 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 opt

> 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
  > They will reduce the task to the point where it is manageable If they don’t even solve the problem, then it is no competition.
mjan22640 3y ago
I remember claims that compilers are going to emit better machine code than humans when pipelined and speculative execution was first implemented in intel processors. It turned out to not be true. It is still not true as of today. Humans are still better at this, and still by humongous margin. LLMs are going to change that soon however.
- kaba0 3y ago
  Lol at both of these claims. Humans are better at tiny hot loops. Not at all at anything larger than that. And call me back once LLMs successfully solve a Sudoku first, before they attempt at spewing out code.
shrubble 3y ago
Rather than argue about it, why don't you find an equivalent demo bit of code in both ASM and any other language you choose, and compile both into a static (no linking of libraries) binary? You should be able to use the Rosetta Code web site to find equivalents written in ASM and say, Rust or C++... then you can easily demonstrate that what you say is factually correct.
- kwhitefoot 3y ago
  Surely we are talking about real applications not toy educational snippets. Or are you claiming that what works for the dozen or so lines in a typical Rosetta code example works just as well for million line, multi-user, multithreaded, object oriented simulators and optimizers of electrical machines? At risk of moving the goal posts, I suspect that actually writing such a program in assembler might well be impossible simply because it would probably take too long to write and debug. If assembler tooling were improved perhaps this could change but who will do it. There have been assemblers with object oriented extensions, perhaps other developer aids could be created. But who will expend the effort?

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
> They will reduce the task to the point where it is manageable If they don’t even solve the problem, then it is no competition.

mjan22640 3y ago

I remember claims that compilers are going to emit better machine code than humans when pipelined and speculative execution was first implemented in intel processors. It turned out to not be true. It is still not true as of today. Humans are still better at this, and still by humongous margin. LLMs are going to change that soon however.

kaba0 3y ago
Lol at both of these claims. Humans are better at tiny hot loops. Not at all at anything larger than that. And call me back once LLMs successfully solve a Sudoku first, before they attempt at spewing out code.

shrubble 3y ago

Rather than argue about it, why don't you find an equivalent demo bit of code in both ASM and any other language you choose, and compile both into a static (no linking of libraries) binary? You should be able to use the Rosetta Code web site to find equivalents written in ASM and say, Rust or C++... then you can easily demonstrate that what you say is factually correct.

kwhitefoot 3y ago
Surely we are talking about real applications not toy educational snippets. Or are you claiming that what works for the dozen or so lines in a typical Rosetta code example works just as well for million line, multi-user, multithreaded, object oriented simulators and optimizers of electrical machines? At risk of moving the goal posts, I suspect that actually writing such a program in assembler might well be impossible simply because it would probably take too long to write and debug. If assembler tooling were improved perhaps this could change but who will do it. There have been assemblers with object oriented extensions, perhaps other developer aids could be created. But who will expend the effort?