3 ms·

That so people in this thread argue about the higher-level language (missing the point) shows that few people found access to the underlying machine code. Whic

That so people in this thread argue about the higher-level language (missing the point) shows that few people found access to the underlying machine code. Which is sad, because all code is still executed as machine instructions even when the developer does not see it or does not want to care.

Blikkentrekker 4y ago
“machine code” isn't really the zero point that's special nowadays. The code the programmer wrote is compiled to something such as LLVM IR, LLVM IR is further compiled by LLVM to Assembly, this is further compiled by an assembler into machine code, and then the c.p.u. further compiles this to it's internal code as it executes it. “machine code” really is no more special in this chain of events than, say, LLVM IR.
- blueflow 4y ago
  Machine code is special because its the only thing the CPU can actually execute.
  - clhodapp 4y ago
    ... then the c.p.u. further compiles this to it's internal code as it executes it. “machine code” really is no more special in this chain of events than, say, LLVM IR. I think this is the core point. Even though you are mechanically feeding machine code into the CPU, modern CPUs deeply transform your program before (or even while) running it, with potentially deep performance implications. With modern CPUs, the only choice we truly have is which compiler we trust to optimize our program.
    - iopq 4y ago
      Sometimes it executes it exactly how you think it will execute. But it's still slower because the "less optimized code" fit in its cache.
  - pjmlp 4y ago
    Except if the CPU is microcoded, those instructions might not mean what you think they do, and you need something like Intel's V-Tune to actually understand what the CPU is doing with them.
    - blueflow 4y ago
      > ... to actually understand what the CPU is doing with them. x86 has a developers manual for this purpose.
      - pjmlp 4y ago
        It has, and if you manage to know everything on those pages, for every single processor on the market, while taking into consideration motherboard architectures, and OS workloads you're our hero. We are way beyond MS-DOS days and Michael Abrash's books.
  - izacus 4y ago
    It's slightly different - machine code is special because it's a visible API between our programming work and the CPU sillicon. Microcode is private implementation detail which you usually can't affect as a software developer. Machine code is something you are directly creating by writing things though.
    - Blikkentrekker 4y ago
      Why is that visible a.p.i. different than, say, LLVM i.r. which is also a visible a.p.i.? Why is the c.p.u. special?
- deleted 4y ago
  [deleted]
just_boost_it 4y ago
We're 20 years past the point where you can expect everyone in tech to trace every instruction down to machine instructions. Higher level languages abstract away the need for it, and for the most part, we can rely on the authors of those languages to make many of the decisions that impact performance. The rest of us learn about these details on posts like this. It's not a sad fact, in fact it's probably one of the most useful things that's happened in tech. It frees people to think about other problems.
- metafunctor 4y ago
  Not sure if you were around 20 years ago, but you sure couldn't expect everyone in tech to understand machine instructions as well as the layers above, all the way up to corporate politics. But some people, yeah, they could do it. That has not changed.
- deleted 4y ago
  [deleted]
- TillE 4y ago
  I barely touch assembly in my day to day work, but I do understand on a fairly deep level how a computer works, which I feel is extremely important and very frequently influences how I write high-level code. Certainly one can bang out code their entire career without ever having a clue how machine code works, but I really wouldn't advise it. At worst it leads to total ignorance, and at best you accumulate a disconnected set of "best practices" as inscrutable lore handed down from on high.
  - ZephyrBlu 4y ago
    What do you consider "high-level code" and in what way does deeply understanding how a computer works influence your approach?
    - iopq 4y ago
      In college, I optimized the array removal routine from O(N^2) to O(N) by using INVARIANTS But it probably ran in like 100us anyway
gitonthescene 4y ago
It was just most basic example. Indices are connected with math all the time. Consider implementing circular queues with 1-based arrays. Any arguments about what’s _possible_ miss the point. Arguments about what _feels_ natural purport to know the human mind which I find generally suspect. Mostly I think of computers as tools and am interested in getting the most functionality out as smoothly as possible not as slaves whose job it is to make my life worry free.
tdeck 4y ago
If this were the primary reason, it seems odd that some of the earliest popular languages used 1-based indexing in an era with much slower CPUs (<= 1 MIPS) and less available memory to store instruction code. If the authors of FORTRAN were comfortable with 1-indexing on the IBM 704 (40 KIPS) in 1957, it couldn't have been prohibitive. At the same time, as computer use cases became more interactive there may have been a greater focus on performance, but it likely that the semantics of the high-level language were at least as important.

Blikkentrekker 4y ago

“machine code” isn't really the zero point that's special nowadays. The code the programmer wrote is compiled to something such as LLVM IR, LLVM IR is further compiled by LLVM to Assembly, this is further compiled by an assembler into machine code, and then the c.p.u. further compiles this to it's internal code as it executes it. “machine code” really is no more special in this chain of events than, say, LLVM IR.

blueflow 4y ago
Machine code is special because its the only thing the CPU can actually execute.
- clhodapp 4y ago
  ... then the c.p.u. further compiles this to it's internal code as it executes it. “machine code” really is no more special in this chain of events than, say, LLVM IR. I think this is the core point. Even though you are mechanically feeding machine code into the CPU, modern CPUs deeply transform your program before (or even while) running it, with potentially deep performance implications. With modern CPUs, the only choice we truly have is which compiler we trust to optimize our program.
  - iopq 4y ago
    Sometimes it executes it exactly how you think it will execute. But it's still slower because the "less optimized code" fit in its cache.
- pjmlp 4y ago
  Except if the CPU is microcoded, those instructions might not mean what you think they do, and you need something like Intel's V-Tune to actually understand what the CPU is doing with them.
  - blueflow 4y ago
    > ... to actually understand what the CPU is doing with them. x86 has a developers manual for this purpose.
    - pjmlp 4y ago
      It has, and if you manage to know everything on those pages, for every single processor on the market, while taking into consideration motherboard architectures, and OS workloads you're our hero. We are way beyond MS-DOS days and Michael Abrash's books.
- izacus 4y ago
  It's slightly different - machine code is special because it's a visible API between our programming work and the CPU sillicon. Microcode is private implementation detail which you usually can't affect as a software developer. Machine code is something you are directly creating by writing things though.
  - Blikkentrekker 4y ago
    Why is that visible a.p.i. different than, say, LLVM i.r. which is also a visible a.p.i.? Why is the c.p.u. special?
deleted 4y ago
[deleted]

just_boost_it 4y ago

We're 20 years past the point where you can expect everyone in tech to trace every instruction down to machine instructions. Higher level languages abstract away the need for it, and for the most part, we can rely on the authors of those languages to make many of the decisions that impact performance. The rest of us learn about these details on posts like this. It's not a sad fact, in fact it's probably one of the most useful things that's happened in tech. It frees people to think about other problems.

metafunctor 4y ago
Not sure if you were around 20 years ago, but you sure couldn't expect everyone in tech to understand machine instructions as well as the layers above, all the way up to corporate politics. But some people, yeah, they could do it. That has not changed.
deleted 4y ago
[deleted]
TillE 4y ago
I barely touch assembly in my day to day work, but I do understand on a fairly deep level how a computer works, which I feel is extremely important and very frequently influences how I write high-level code. Certainly one can bang out code their entire career without ever having a clue how machine code works, but I really wouldn't advise it. At worst it leads to total ignorance, and at best you accumulate a disconnected set of "best practices" as inscrutable lore handed down from on high.
- ZephyrBlu 4y ago
  What do you consider "high-level code" and in what way does deeply understanding how a computer works influence your approach?
  - iopq 4y ago
    In college, I optimized the array removal routine from O(N^2) to O(N) by using INVARIANTS But it probably ran in like 100us anyway

gitonthescene 4y ago

It was just most basic example. Indices are connected with math all the time. Consider implementing circular queues with 1-based arrays. Any arguments about what’s _possible_ miss the point. Arguments about what _feels_ natural purport to know the human mind which I find generally suspect. Mostly I think of computers as tools and am interested in getting the most functionality out as smoothly as possible not as slaves whose job it is to make my life worry free.

tdeck 4y ago

If this were the primary reason, it seems odd that some of the earliest popular languages used 1-based indexing in an era with much slower CPUs (<= 1 MIPS) and less available memory to store instruction code. If the authors of FORTRAN were comfortable with 1-indexing on the IBM 704 (40 KIPS) in 1957, it couldn't have been prohibitive. At the same time, as computer use cases became more interactive there may have been a greater focus on performance, but it likely that the semantics of the high-level language were at least as important.