4 ms·

The timing of this is great! I just watched Casey Muratori's lecture, "Simple Code, High Performance"[1] and its follow-up videos[2, 3]. I highly recommend watc

The timing of this is great! I just watched Casey Muratori's lecture, "Simple Code, High Performance"[1] and its follow-up videos[2, 3]. I highly recommend watching it. It is about Software Optimization, and gives practical and high-level understanding of topics like CPU Architecture, SIMD etc. [1]https://www.youtube.com/watch?v=Ge3aKEmZcqY https://www.youtube.com/watch?v=Ge3aKEmZcqY [2]https://www.youtube.com/watch?v=8VakkEFOiJc https://www.youtube.com/watch?v=8VakkEFOiJc [3]https://www.youtube.com/watch?v=1tEqsQ55-8I https://www.youtube.com/watch?v=1tEqsQ55-8I

nickelpro 5y ago
Casey is great but at times a bit... zealous? I distinctly remember him talking about how worthless having a file system is on a server, or for that matter an operating system. His work stands at one extreme of how to architect a program, and is an extremely valuable reference, but he states his opinions as facts and that can be detrimental for the beginners he markets some of this material to.
- sirwhinesalot 5y ago
  He's not wrong on the server end if your goal is maximum performance. That's the whole point of unikernels and they can lead to some impressive speedups. More so when you consider how many servers are running single apps inside docker containers in some Linux VM running on a hypervisor which is usually Xen. Massive inefficiencies that could all be cut down to a unikernel running on the hypervisor directly. Whether that's a good idea or not in practice is a different story, but the performance improvements and energy savings are real. That said, his issue is less on the strength of his convictions (which, as far as performance goes, are at least on-point), but rather his delivery. He has very little patience and is not looking to debate even when it might be beneficial to himself or to others.
  - nickelpro 5y ago
    I don't at all mean to say he is wrong about performance. Casey is brilliant, his approach to writing software is optimal or near optimal when viewed through the lens of performance. And yet this is not the only lens through which to view software development. Correctness, expressiveness, portability, developer hours. There are many possible things to optimize for, and Casey barely gives these an ounce of weight compared to performance. The reason to target a program towards a platform with an operating system and a file system is because writing these things takes time, using them affords flexibility, and minimizes bugs from you're bespoke code. Casey does not view these as problems. Casey writes near-C for bare metal, or when not using bare metal directly against the platform API and if you only learned from him that's the only approach you would view as valid. When talking about his approach to writing code he constantly derides, sometimes very harshly, those who would think about program architecture any other way. I don't think the Rustacean evangelists' obsession with memory safety is the last word is software development, or Linus's assessment of languages other than C, or Jonathon Blow's and Casey's orientation with performance above all else. These are ideas, opinions, and there's some value in representing them as such.
    - sirwhinesalot 5y ago
      100% agreed. I think when it comes to performance, the biggest takeaway from Casey/Jonathan is to just have the computer do less work. If you can get away with just poking at a big buffer then that's what you should do. It keeps the code both simple and efficient, no need for 30 layers of abstractions. But beyond that, IMO, it's fine to use higher-level constructs and target higher-level "platforms" (i.e. electron) to improve portability, developer productivity, etc. Even within that setting you can avoid doing things that pessimize your performance, and that's often enough for a massive improvement. Dogma is the bane of software-development, be it abstraction at all cost, immutability at all cost, or performance at all cost, etc.
      - webmaven 5y ago
        > Dogma is the bane of software-development, be it abstraction at all cost, immutability at all cost, or performance at all cost, etc. You seem very sure of that.
        sirwhinesalot 5y ago
        I do not claim to be enlightened, I am as flawed as my peers ;)
- suyjuris 5y ago
  > I distinctly remember him talking about how worthless having a file system is on a server, or for that matter an operating system. If I recall correctly, his statement can be more charitably summarised as noting that many of the functions of an OS or FS are not useful in the specific use case he had, which was running a single program serving a website. He would therefore prefer to not have the additional complexity, attack surface and performance overhead. I do not think that this is very controversial? There are of course trade-offs involved, and he did mention that he was planning on running Linux as a way to get device drivers and something booting with reasonable effort, at least initially.
  - justin66 5y ago
    Filesystems being a worthless abstraction on, for example, a database server is the rationale for setting up a DBMS to use raw devices. This is not a popular approach and hasn't been for some time (I don't think any of the popular OSS databases have ever offered this approach, and AFAIK even Oracle is moving away from offering it) but it's not as though this is a radical idea. edit: the Linux direct I/O feature that sort of obsoletes this use of raw devices was apparently developed in part by Oracle, which I guess might be interesting https://lwn.net/Articles/348719/ https://lwn.net/Articles/348719/

nickelpro 5y ago

Casey is great but at times a bit... zealous? I distinctly remember him talking about how worthless having a file system is on a server, or for that matter an operating system. His work stands at one extreme of how to architect a program, and is an extremely valuable reference, but he states his opinions as facts and that can be detrimental for the beginners he markets some of this material to.

sirwhinesalot 5y ago
He's not wrong on the server end if your goal is maximum performance. That's the whole point of unikernels and they can lead to some impressive speedups. More so when you consider how many servers are running single apps inside docker containers in some Linux VM running on a hypervisor which is usually Xen. Massive inefficiencies that could all be cut down to a unikernel running on the hypervisor directly. Whether that's a good idea or not in practice is a different story, but the performance improvements and energy savings are real. That said, his issue is less on the strength of his convictions (which, as far as performance goes, are at least on-point), but rather his delivery. He has very little patience and is not looking to debate even when it might be beneficial to himself or to others.
- nickelpro 5y ago
  I don't at all mean to say he is wrong about performance. Casey is brilliant, his approach to writing software is optimal or near optimal when viewed through the lens of performance. And yet this is not the only lens through which to view software development. Correctness, expressiveness, portability, developer hours. There are many possible things to optimize for, and Casey barely gives these an ounce of weight compared to performance. The reason to target a program towards a platform with an operating system and a file system is because writing these things takes time, using them affords flexibility, and minimizes bugs from you're bespoke code. Casey does not view these as problems. Casey writes near-C for bare metal, or when not using bare metal directly against the platform API and if you only learned from him that's the only approach you would view as valid. When talking about his approach to writing code he constantly derides, sometimes very harshly, those who would think about program architecture any other way. I don't think the Rustacean evangelists' obsession with memory safety is the last word is software development, or Linus's assessment of languages other than C, or Jonathon Blow's and Casey's orientation with performance above all else. These are ideas, opinions, and there's some value in representing them as such.
  - sirwhinesalot 5y ago
    100% agreed. I think when it comes to performance, the biggest takeaway from Casey/Jonathan is to just have the computer do less work. If you can get away with just poking at a big buffer then that's what you should do. It keeps the code both simple and efficient, no need for 30 layers of abstractions. But beyond that, IMO, it's fine to use higher-level constructs and target higher-level "platforms" (i.e. electron) to improve portability, developer productivity, etc. Even within that setting you can avoid doing things that pessimize your performance, and that's often enough for a massive improvement. Dogma is the bane of software-development, be it abstraction at all cost, immutability at all cost, or performance at all cost, etc.
    - webmaven 5y ago
      > Dogma is the bane of software-development, be it abstraction at all cost, immutability at all cost, or performance at all cost, etc. You seem very sure of that.
      - sirwhinesalot 5y ago
        I do not claim to be enlightened, I am as flawed as my peers ;)
suyjuris 5y ago
> I distinctly remember him talking about how worthless having a file system is on a server, or for that matter an operating system. If I recall correctly, his statement can be more charitably summarised as noting that many of the functions of an OS or FS are not useful in the specific use case he had, which was running a single program serving a website. He would therefore prefer to not have the additional complexity, attack surface and performance overhead. I do not think that this is very controversial? There are of course trade-offs involved, and he did mention that he was planning on running Linux as a way to get device drivers and something booting with reasonable effort, at least initially.
- justin66 5y ago
  Filesystems being a worthless abstraction on, for example, a database server is the rationale for setting up a DBMS to use raw devices. This is not a popular approach and hasn't been for some time (I don't think any of the popular OSS databases have ever offered this approach, and AFAIK even Oracle is moving away from offering it) but it's not as though this is a radical idea. edit: the Linux direct I/O feature that sort of obsoletes this use of raw devices was apparently developed in part by Oracle, which I guess might be interesting https://lwn.net/Articles/348719/ https://lwn.net/Articles/348719/