5 ms·

Hm. Seems very C++ oriented. Talks about specific keywords of C++ and their semantics. Not even mentioned "actor" in the whole document. "immutable" not found.

Hm. Seems very C++ oriented. Talks about specific keywords of C++ and their semantics. Not even mentioned "actor" in the whole document. "immutable" not found. Seems rather like an very incomplete view of a C++ programmer, wanting to raise it to "systems programmer".

ajross 2y ago
To be fair most of the consensus-imposed[1] interface to memory ordering semantics was developed as part of the C++ memory model standardization process. GCC/clang have imported them as extensions for C code, etc... [1] Which is not to say "best". My standard complaint in these threads is that the C++ ordering semantics are a mess designed to make things easier for compiler writers to target architectures with variant ordering guarantees and not for algorithm developers to create correct code. But lockless code is much harder to write than compilers! It's a bad trade. ARM had this right decades ago with simple read/write barriers, which are vastly easier to understand when reading code.
- packetlost 2y ago
  Rust also adopted the C/C++ memory ordering semantics, for better or worse.
  - ajross 2y ago
    Everyone has, even the hardware vendors are treating these rules as the golden standard to which they can optimize and conform. So it's too late. But it's still a shame. The acquire/release semantics make perfect sense for locks, because that's what it was designed for. Designing anything else with them is extremely difficult, and in practice such work tends to lean heavily on the full-barrier "sequentially consistent" primitive instead. The older read/write barrier instructions were much simpler. (And x86 is simpler still, with just one reordering rule to worry about and a single idea of serializing instructions to regulate it).
    - gpderetta 2y ago
      I think it is just a generational/educational difference. I learned lock-free programming around the time c+11 was being standardized, and the acquire/release model seems very natural to me and easier to understand and model algorithms in it than the barrier based model.
    - menaerus 2y ago
      Hardware vendors adhering to C++ memory model to design their chips? I think you got it backwards or I misunderstood your point. Memory barriers exist because of how cache memory hierarchy and coherency protocols are implemented in multi-core chips. And not to "optimize and conform to C++ memory model". C++ memory model is there to make life of a programmer easier across different micro-architectures because memory model of the micro-architecture is what differs.
      - tialaramex 2y ago
        There is an argument, particularly from C++ people, that the CPU architectures designed after C++ 11 shipped with the Acquire/Release model have all chosen to provide features that can do Acquire/Release smoothly. After all, if the software most people execute rewards CPUs which do X and punishes CPUs which do Y instead, it's a tough sell to design your CPU to do Y, that means ordinary users will get the idea it's worse than it really is, and your sales people don't like that, it seems reasonable to argue that the reason modern x86-64 CPUs ignore the weird x87 FPU features is that nobody's programs want those weird features. I remember in the mid-1990s there was a lot of hype for high clock frequency 80486 and clones because they had very good integer performance. However, Intel's Pentium had excellent FP performance at similar or lower clocks. The video game Quake needed floating point, and so Quake on my 100 MHz Pentium was very quick, while on a friend's 100MHz 486 it was pretty nasty. Increased sales of the Pentium were I believe widely attributed to the game Quake showing off the FP performance (it's nothing to look at in today's terms, we did not have GPUs back then). I have never worked for a CPU design firm or CPU manufacturer, so I can't speak to whether this is in practice a meaningful influence.
        2y ago
- immibis 2y ago
  C tries to be everything to everyone. It has to be able to target every architecture, within certain limits. It took them a long time to standardize on two's-complement signed integers - they could only do that after the whole industry had migrated to two's-complement signed integers as they are the technically best way to represent signed integers. The x86 is the weird architecture that tried to keep existing programs working when they moved to multicore. Most other architectures implemented whatever is easier to implement in hardware, and compilers have to target that. And the compiler can't simulate a strong memory model on top of a weak one, because that means lots of overhead for every memory operation and that's not what C does.
- tialaramex 2y ago
  Because Linux pre-dates that work significantly (over a decade) and even multi-processor Linux pre-dates it by enough that it could not have waited, the Linux ordering rules are actually different from those C got from C++ One of the interesting problems for Rust-for-Linux is what to do about that, Rust has all of the C++ 11 memory ordering except the problematic (and in practice abandoned) Consume ordering, but it doesn't have a convenient way to admit a different model, yet Linus isn't exactly likely to wake up one day and declare now Linux has the C++ 11 ordering model. As to your concern, of course the compiler vendors have to worry about portability. It's all very well to say this works on ARM, but the expectation from a person writing Rust or even C++ is that a correct program should work on all of an ARM, an x86, archaic PowerPC and somebody's cheap in-order embedded CPU. If the vendor only really cares about one architecture (cough, Microsoft) then they might invent weird rules that only really make sense for that architecture and your "correct" programs either don't work, don't compile, or are very slow on every other CPU. But that's hardly a reliable way forward into the future.
  - ajross 2y ago
    > of course the compiler vendors have to worry about portability. Yes, but the point was that "defining a language that doesn't suck" is a competing requirement. Again, C++ just dropped the ball here and solved the wrong problem. And we all suffer for it with repeated blog posts like this one trying desperately to explain exactly what "acquire" means and not how hardware actually works. And yes: Linux has clean and easy (or as easy as these things get) read/write barriers, the implementation of which has now been terribly polluted by the toolchain's incompatible choice of semantics.
cjfd 2y ago
This document seems to be at a lower level. An actor model would be implemented in terms of these primitives. These primitives are available in many languages. Immutable is kind of irrelevant in a discussion of multi-threading because immutable data has no problems in this regard. Which, of course, in a way also makes it relevant because one prevents issues. Ultimately one cannot have just immutable data because the computer would not be allowed to do anything. This document would be about data that cannot be immutable. But the complaint sounds a bit like an article about assembly language getting the complaint that it does not explain how to implement a word processor.
- adrianN 2y ago
  Of course you can have only immutable data, you just need suitable monads.
  - hyperpape 2y ago
    There's disagreement about what exactly makes you a systems programmer, but dealing with the reality that memory is finite is definitely a requirement. You need mutation or garbage collection (and systems programming is the kind of environment where that's not just "someone else's problem").
  - kccqzy 2y ago
    Plenty of languages have immutable data without monads or even being statically typed. Clojure is a fine example. And there is also the somewhat popular https://immutable-js.com/ https://immutable-js.com/ that brings the benefits of immutable data to JavaScript.
  - SideQuark 2y ago
    By that argument, all programming is immutable, with monads only used to update the mutable parts. The point of this article is to detail needs for those monads to interact in a concurrent manner.
- rileymat2 2y ago
  > Immutable is kind of irrelevant in a discussion of multi-threading because immutable data has no problems in this regard. To push back on this, no data is completely immutable, it is mutable on initialization, treating it as immutable between threads is ok after this stage, but if you disregard issues with timing and mutation you will run into problems between threads on initialization.
motorest 2y ago
> Hm. Seems very C++ oriented. Talks about specific keywords of C++ and their semantics. Not even mentioned "actor" in the whole document. "immutable" not found. The term "systems programmer" is right there in the title. They are also the very first words in the article. The examples are in C++, but the whole document focuses on both C and C++. The article clearly focuses on the primitives, as it should. It's undoubtedly a great article on the subject, but nitpickers have to nitpick, and one-uppers have to one-up. I look forward to read your article on the topic.
mattgreenrocks 2y ago
> Seems rather like an very incomplete view of a C++ programmer, wanting to raise it to "systems programmer". I'm not sure I understand this comment. C++ is one of the very few languages that can be used for programming everything from a web server to a garbage collector to firmware. There's no "raising" going on here.
- xslvrxslwt 2y ago
  https://medium.com/nerd-for-tech/linus-torvalds-c-is-really-a-terrible-language-2248b839bee3 https://medium.com/nerd-for-tech/linus-torvalds-c-is-really-...
  - deleted 2y ago
    [deleted]
swatcoder 2y ago
In this context, "systems programmer" means someone who writes software with tight, direct affinity to the underlying system (i.e. hardware, OS). C and C++ still dominate that world by huge measure. Presumably, you're thinking of systems in the more abstract sense: systems of more or less pure software components that model some domain. That's just not what this article is about.
- crabbone 2y ago
  C++ is a very rare guest in that world. Not really worth mentioning. You could probably find more Python in that world than C++. Certainly more Shell than C++. You could absolutely get a job as a system programmer not knowing and never touching C++, but not knowing Shell will not get you anywhere in that field. It doesn't really have to be direct or tight (not even sure what that might mean). I'm guessing you were trying to say that it has to have minimal overhead compared to theoretically possible performance, in which case that's not true at all (a lot of Linux services and management tools are written in Shell, which just isn't known for great performance at all).
  - swatcoder 2y ago
    If it helps: among other examples, systems programming (as used here) characterizes much of what your Python and shell scripts call, whether commands or libraries. C was the overwhelming language of choice for a very long time, but C++ made steady and verysignificant inroads in the last 20 years. Objective-C and Java had/have niches. Rust and Go have traction and continue to gain more. Swift is working towards it. Actors and immutable types, which the GP mentioned, have less signifance here because they largely trade transparent resource management (which is critically important in many of these projects) for correctness guarantees and sophisticated domain modeling. That said, we can expect there to be more room for them, especially where implementations of those features are zero/low-overhead.
    - crabbone 2y ago
      Nah. C++ is still pretty much hated in that field. It's the reason Go or Rust exist, not a complement. C++ has very little (basically nothing) to do with what Python or Shell call. When I mention these languages in the context of system programming, I mean programs like, eg. ifup / ifdown or GRUB configuration, LDAP client utilities and so on. C++ was and still is an unwelcome guest in this area. It's not minimalist enough to be easy to use in constrained environments, but when resources allow it, there are better languages for any task you can think of. In my experience, the only people who insist on using C++ are the Visual C++ Windows programmers. But, overwhelming majority of system jobs aren't for MS Windows, so, the Visual C++ people can be safely ignored. In the same way how you can safely ignore Objective-C, when it comes to system programming. You can work in the field of system programming whole your life, switch dozens of companies and products, and never hit C++ or Objective-C requirement. They are too niche and unimportant in the large scheme of things. If, on the other hand, you were looking for a field where C++ is the most common language, then video games come to mind. Enterprise applications, especially targeting MS Windows, usually with a significant GUI component. It's really not meant, and doesn't work well as a system programming language. It's OK for application development (but there are better alternatives today). It survives due to the existing libraries and compilers, and, of course, expertise accumulated in programming community. But, that expertise and libraries are mostly in the fields mentioned above.

ajross 2y ago

To be fair most of the consensus-imposed[1] interface to memory ordering semantics was developed as part of the C++ memory model standardization process. GCC/clang have imported them as extensions for C code, etc... [1] Which is not to say "best". My standard complaint in these threads is that the C++ ordering semantics are a mess designed to make things easier for compiler writers to target architectures with variant ordering guarantees and not for algorithm developers to create correct code. But lockless code is much harder to write than compilers! It's a bad trade. ARM had this right decades ago with simple read/write barriers, which are vastly easier to understand when reading code.

packetlost 2y ago
Rust also adopted the C/C++ memory ordering semantics, for better or worse.
- ajross 2y ago
  Everyone has, even the hardware vendors are treating these rules as the golden standard to which they can optimize and conform. So it's too late. But it's still a shame. The acquire/release semantics make perfect sense for locks, because that's what it was designed for. Designing anything else with them is extremely difficult, and in practice such work tends to lean heavily on the full-barrier "sequentially consistent" primitive instead. The older read/write barrier instructions were much simpler. (And x86 is simpler still, with just one reordering rule to worry about and a single idea of serializing instructions to regulate it).
  - gpderetta 2y ago
    I think it is just a generational/educational difference. I learned lock-free programming around the time c+11 was being standardized, and the acquire/release model seems very natural to me and easier to understand and model algorithms in it than the barrier based model.
  - menaerus 2y ago
    Hardware vendors adhering to C++ memory model to design their chips? I think you got it backwards or I misunderstood your point. Memory barriers exist because of how cache memory hierarchy and coherency protocols are implemented in multi-core chips. And not to "optimize and conform to C++ memory model". C++ memory model is there to make life of a programmer easier across different micro-architectures because memory model of the micro-architecture is what differs.
    - tialaramex 2y ago
      There is an argument, particularly from C++ people, that the CPU architectures designed after C++ 11 shipped with the Acquire/Release model have all chosen to provide features that can do Acquire/Release smoothly. After all, if the software most people execute rewards CPUs which do X and punishes CPUs which do Y instead, it's a tough sell to design your CPU to do Y, that means ordinary users will get the idea it's worse than it really is, and your sales people don't like that, it seems reasonable to argue that the reason modern x86-64 CPUs ignore the weird x87 FPU features is that nobody's programs want those weird features. I remember in the mid-1990s there was a lot of hype for high clock frequency 80486 and clones because they had very good integer performance. However, Intel's Pentium had excellent FP performance at similar or lower clocks. The video game Quake needed floating point, and so Quake on my 100 MHz Pentium was very quick, while on a friend's 100MHz 486 it was pretty nasty. Increased sales of the Pentium were I believe widely attributed to the game Quake showing off the FP performance (it's nothing to look at in today's terms, we did not have GPUs back then). I have never worked for a CPU design firm or CPU manufacturer, so I can't speak to whether this is in practice a meaningful influence.
      - 2y ago
immibis 2y ago
C tries to be everything to everyone. It has to be able to target every architecture, within certain limits. It took them a long time to standardize on two's-complement signed integers - they could only do that after the whole industry had migrated to two's-complement signed integers as they are the technically best way to represent signed integers. The x86 is the weird architecture that tried to keep existing programs working when they moved to multicore. Most other architectures implemented whatever is easier to implement in hardware, and compilers have to target that. And the compiler can't simulate a strong memory model on top of a weak one, because that means lots of overhead for every memory operation and that's not what C does.
tialaramex 2y ago
Because Linux pre-dates that work significantly (over a decade) and even multi-processor Linux pre-dates it by enough that it could not have waited, the Linux ordering rules are actually different from those C got from C++ One of the interesting problems for Rust-for-Linux is what to do about that, Rust has all of the C++ 11 memory ordering except the problematic (and in practice abandoned) Consume ordering, but it doesn't have a convenient way to admit a different model, yet Linus isn't exactly likely to wake up one day and declare now Linux has the C++ 11 ordering model. As to your concern, of course the compiler vendors have to worry about portability. It's all very well to say this works on ARM, but the expectation from a person writing Rust or even C++ is that a correct program should work on all of an ARM, an x86, archaic PowerPC and somebody's cheap in-order embedded CPU. If the vendor only really cares about one architecture (cough, Microsoft) then they might invent weird rules that only really make sense for that architecture and your "correct" programs either don't work, don't compile, or are very slow on every other CPU. But that's hardly a reliable way forward into the future.
- ajross 2y ago
  > of course the compiler vendors have to worry about portability. Yes, but the point was that "defining a language that doesn't suck" is a competing requirement. Again, C++ just dropped the ball here and solved the wrong problem. And we all suffer for it with repeated blog posts like this one trying desperately to explain exactly what "acquire" means and not how hardware actually works. And yes: Linux has clean and easy (or as easy as these things get) read/write barriers, the implementation of which has now been terribly polluted by the toolchain's incompatible choice of semantics.

cjfd 2y ago

This document seems to be at a lower level. An actor model would be implemented in terms of these primitives. These primitives are available in many languages. Immutable is kind of irrelevant in a discussion of multi-threading because immutable data has no problems in this regard. Which, of course, in a way also makes it relevant because one prevents issues. Ultimately one cannot have just immutable data because the computer would not be allowed to do anything. This document would be about data that cannot be immutable. But the complaint sounds a bit like an article about assembly language getting the complaint that it does not explain how to implement a word processor.

adrianN 2y ago
Of course you can have only immutable data, you just need suitable monads.
- hyperpape 2y ago
  There's disagreement about what exactly makes you a systems programmer, but dealing with the reality that memory is finite is definitely a requirement. You need mutation or garbage collection (and systems programming is the kind of environment where that's not just "someone else's problem").
- kccqzy 2y ago
  Plenty of languages have immutable data without monads or even being statically typed. Clojure is a fine example. And there is also the somewhat popular https://immutable-js.com/ https://immutable-js.com/ that brings the benefits of immutable data to JavaScript.
- SideQuark 2y ago
  By that argument, all programming is immutable, with monads only used to update the mutable parts. The point of this article is to detail needs for those monads to interact in a concurrent manner.
rileymat2 2y ago
> Immutable is kind of irrelevant in a discussion of multi-threading because immutable data has no problems in this regard. To push back on this, no data is completely immutable, it is mutable on initialization, treating it as immutable between threads is ok after this stage, but if you disregard issues with timing and mutation you will run into problems between threads on initialization.

motorest 2y ago

> Hm. Seems very C++ oriented. Talks about specific keywords of C++ and their semantics. Not even mentioned "actor" in the whole document. "immutable" not found. The term "systems programmer" is right there in the title. They are also the very first words in the article. The examples are in C++, but the whole document focuses on both C and C++. The article clearly focuses on the primitives, as it should. It's undoubtedly a great article on the subject, but nitpickers have to nitpick, and one-uppers have to one-up. I look forward to read your article on the topic.

mattgreenrocks 2y ago

> Seems rather like an very incomplete view of a C++ programmer, wanting to raise it to "systems programmer". I'm not sure I understand this comment. C++ is one of the very few languages that can be used for programming everything from a web server to a garbage collector to firmware. There's no "raising" going on here.

xslvrxslwt 2y ago
https://medium.com/nerd-for-tech/linus-torvalds-c-is-really-a-terrible-language-2248b839bee3 https://medium.com/nerd-for-tech/linus-torvalds-c-is-really-...
- deleted 2y ago
  [deleted]

swatcoder 2y ago

In this context, "systems programmer" means someone who writes software with tight, direct affinity to the underlying system (i.e. hardware, OS). C and C++ still dominate that world by huge measure. Presumably, you're thinking of systems in the more abstract sense: systems of more or less pure software components that model some domain. That's just not what this article is about.

crabbone 2y ago
C++ is a very rare guest in that world. Not really worth mentioning. You could probably find more Python in that world than C++. Certainly more Shell than C++. You could absolutely get a job as a system programmer not knowing and never touching C++, but not knowing Shell will not get you anywhere in that field. It doesn't really have to be direct or tight (not even sure what that might mean). I'm guessing you were trying to say that it has to have minimal overhead compared to theoretically possible performance, in which case that's not true at all (a lot of Linux services and management tools are written in Shell, which just isn't known for great performance at all).
- swatcoder 2y ago
  If it helps: among other examples, systems programming (as used here) characterizes much of what your Python and shell scripts call, whether commands or libraries. C was the overwhelming language of choice for a very long time, but C++ made steady and verysignificant inroads in the last 20 years. Objective-C and Java had/have niches. Rust and Go have traction and continue to gain more. Swift is working towards it. Actors and immutable types, which the GP mentioned, have less signifance here because they largely trade transparent resource management (which is critically important in many of these projects) for correctness guarantees and sophisticated domain modeling. That said, we can expect there to be more room for them, especially where implementations of those features are zero/low-overhead.
  - crabbone 2y ago
    Nah. C++ is still pretty much hated in that field. It's the reason Go or Rust exist, not a complement. C++ has very little (basically nothing) to do with what Python or Shell call. When I mention these languages in the context of system programming, I mean programs like, eg. ifup / ifdown or GRUB configuration, LDAP client utilities and so on. C++ was and still is an unwelcome guest in this area. It's not minimalist enough to be easy to use in constrained environments, but when resources allow it, there are better languages for any task you can think of. In my experience, the only people who insist on using C++ are the Visual C++ Windows programmers. But, overwhelming majority of system jobs aren't for MS Windows, so, the Visual C++ people can be safely ignored. In the same way how you can safely ignore Objective-C, when it comes to system programming. You can work in the field of system programming whole your life, switch dozens of companies and products, and never hit C++ or Objective-C requirement. They are too niche and unimportant in the large scheme of things. If, on the other hand, you were looking for a field where C++ is the most common language, then video games come to mind. Enterprise applications, especially targeting MS Windows, usually with a significant GUI component. It's really not meant, and doesn't work well as a system programming language. It's OK for application development (but there are better alternatives today). It survives due to the existing libraries and compilers, and, of course, expertise accumulated in programming community. But, that expertise and libraries are mostly in the fields mentioned above.