4 ms·

Sorry for the noob question, but here it is anyway. What kind of projects and career paths does this kind of programming enable?

mhh__ 6y ago
My snarky answer to that is that I genuinely think any software engineer should be able to read and write assembly, even if purely to remind them just how far up the stack we usually operate at. If we take "this" to mean low-level programming, it can open doors into anywhere from reverse engineering, to OS development etc (or more boringly, writing toolchains). Some parts of compilers rely heavily on having real problem solving skills at this level - for example most books won't teach you how to integrate ELF into your compiler, let alone DWARF. I am hesitant to say performance optimization because many people have an idea of a CPU just executing one instruction at a time rather than the heavily pipelined and out of order monsters we have today. To become Anger Fog, you must first invent the CPU-niverse. (Agner is a almost mythical figure for many compiler and microarchitecture folks)
- Intermernet 6y ago
  I'm somewhat delighted that your first mention of Agner got auto-corrected to "Anger Fog" :-) I like to think that Agner would appreciate that!
  - mhh__ 6y ago
    Agner Fog becomes Anger Fog when measures Intel Compilers on AMD...
- 2sk21 6y ago
  When I was a CS PhD student, I spent the summer of 1988 writing assembly code on a parallel machine (Encore Multimax) that was running a variant of Unix. I wrote the runtime system (a virtual machine actually) for a parallel programming language. Haven't used assembly language since then!
- fellellor 6y ago
  I still don’t get it. This sounds cool, but it seems like work other people have already done and done well. My impression of the computing world is that once someone does something very well, it shuts the door for new entrants. There’s no more low hanging fruit left. So unless you think this is something cool, there’s not much left here. Tell me how stupidly wrong I am (gently).
  - tiborsaas 6y ago
    Besides understanding better what your language of choice is doing under the hood (vaguely) you can write cool demos like this: https://www.youtube.com/watch?v=sWblpsLZ-O8 https://www.youtube.com/watch?v=sWblpsLZ-O8
    - fellellor 6y ago
      That is insane. 256 bytes!!
  - saagarjha 6y ago
    Someone doing something very well doesn't mean you can't take the time to understand what they did or replicate their work.
KMag 6y ago
The direct uses would be either very specialized portions of the kernel or C/C++ runtime (mutexes, etc.) or performance-critical code, where you'd typically look at C/C++ compiler output, tweak it by hand, and then insert your modifications into the C/C++ code as inline assembly. Though, a small amount of assembly and a small understanding of processor design and implementation (I highly recommend MIT 6.004) go a long way into having a better mental model of what Java/JavaScript/C/C++ are actually doing under the covers and what's going on. I was working on a project where I looked at the Philox4x32 random number generator specification and implemented it in Java. A colleague was trying to speed things up by porting it to C++ and so he just used the liberally licensed reference C++ implementation. He couldn't figure out why my Java implementation was significantly faster than the C++. I had a look, at the C++ implementation, and they missed an optimization to save one register in the inner loop. I didn't disassemble the native binary or have the JVM dissassemble JIT'd code, but I guessed that a register spill (32-bit x86 is pretty register starved) in the inner loop was the problem. Just by applying my optimization, he got the C++ implementation faster than the Java implementation.
- fellellor 6y ago
  Sounds cool. I’m interested in this now.
  - KMag 6y ago
    In my experience, reading assembly, and being able to anticipate roughly what the compiler is going to produce is much more important than writing assembly. Learning to write a bit makes you better at reading it. Next time you have some tricky inner loop showing up in profiles, write a few alternative implementations, benchmark each, and use the -S flag to get gcc/clang to dump out assembly. There are some people who write a lot of assembly language, but I think orders of magnitude more people read assembly regularly while writing it rarely.

mhh__ 6y ago

My snarky answer to that is that I genuinely think any software engineer should be able to read and write assembly, even if purely to remind them just how far up the stack we usually operate at. If we take "this" to mean low-level programming, it can open doors into anywhere from reverse engineering, to OS development etc (or more boringly, writing toolchains). Some parts of compilers rely heavily on having real problem solving skills at this level - for example most books won't teach you how to integrate ELF into your compiler, let alone DWARF. I am hesitant to say performance optimization because many people have an idea of a CPU just executing one instruction at a time rather than the heavily pipelined and out of order monsters we have today. To become Anger Fog, you must first invent the CPU-niverse. (Agner is a almost mythical figure for many compiler and microarchitecture folks)

Intermernet 6y ago
I'm somewhat delighted that your first mention of Agner got auto-corrected to "Anger Fog" :-) I like to think that Agner would appreciate that!
- mhh__ 6y ago
  Agner Fog becomes Anger Fog when measures Intel Compilers on AMD...
2sk21 6y ago
When I was a CS PhD student, I spent the summer of 1988 writing assembly code on a parallel machine (Encore Multimax) that was running a variant of Unix. I wrote the runtime system (a virtual machine actually) for a parallel programming language. Haven't used assembly language since then!
fellellor 6y ago
I still don’t get it. This sounds cool, but it seems like work other people have already done and done well. My impression of the computing world is that once someone does something very well, it shuts the door for new entrants. There’s no more low hanging fruit left. So unless you think this is something cool, there’s not much left here. Tell me how stupidly wrong I am (gently).
- tiborsaas 6y ago
  Besides understanding better what your language of choice is doing under the hood (vaguely) you can write cool demos like this: https://www.youtube.com/watch?v=sWblpsLZ-O8 https://www.youtube.com/watch?v=sWblpsLZ-O8
  - fellellor 6y ago
    That is insane. 256 bytes!!
- saagarjha 6y ago
  Someone doing something very well doesn't mean you can't take the time to understand what they did or replicate their work.

KMag 6y ago

The direct uses would be either very specialized portions of the kernel or C/C++ runtime (mutexes, etc.) or performance-critical code, where you'd typically look at C/C++ compiler output, tweak it by hand, and then insert your modifications into the C/C++ code as inline assembly. Though, a small amount of assembly and a small understanding of processor design and implementation (I highly recommend MIT 6.004) go a long way into having a better mental model of what Java/JavaScript/C/C++ are actually doing under the covers and what's going on. I was working on a project where I looked at the Philox4x32 random number generator specification and implemented it in Java. A colleague was trying to speed things up by porting it to C++ and so he just used the liberally licensed reference C++ implementation. He couldn't figure out why my Java implementation was significantly faster than the C++. I had a look, at the C++ implementation, and they missed an optimization to save one register in the inner loop. I didn't disassemble the native binary or have the JVM dissassemble JIT'd code, but I guessed that a register spill (32-bit x86 is pretty register starved) in the inner loop was the problem. Just by applying my optimization, he got the C++ implementation faster than the Java implementation.

fellellor 6y ago
Sounds cool. I’m interested in this now.
- KMag 6y ago
  In my experience, reading assembly, and being able to anticipate roughly what the compiler is going to produce is much more important than writing assembly. Learning to write a bit makes you better at reading it. Next time you have some tricky inner loop showing up in profiles, write a few alternative implementations, benchmark each, and use the -S flag to get gcc/clang to dump out assembly. There are some people who write a lot of assembly language, but I think orders of magnitude more people read assembly regularly while writing it rarely.