4 ms·

Well, what about small CLI tools, like ripgrep and the like? Does multithreading not matter when we open a large number of files and process them? What about co

by gf000 10mo ago

Well, what about small CLI tools, like ripgrep and the like? Does multithreading not matter when we open a large number of files and process them? What about compilers?

groundzeros2015 10mo ago
Sure. But the more obviously parallel the problem is (visiting N files) the less compelling complex synchronization tools are. To over explain, if you just need to make N forks of the same logic then it’s very easy to do this correctly in C. The cases where I’m going to carefully maintain shared mutable state with locking are cases where the parallelism is less efficient (Ahmdal’s law). Java style apps that just haphazardly start threads are what rust makes safer. But that’s a category of program design I find brittle and painful. The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads.
- gf000 10mo ago
  > The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads. This is a huge limitation of C's compilation model, and basically every other language since then does it differently, so not sure if that's a good example. You do want some "interconnection" between translation units, or at least less fine-grained units.
  - groundzeros2015 10mo ago
    And yet despite that theoretical limit C compiles faster than any other language. Even C++ is very fast if you are not using header-only style. What’s better? Rust? Haskell? Swift? It’s very hard to do multithreading at a more granular level without hitting amdahl’s law and synchronization traps.
    - pjmlp 9mo ago
      No it doesn't, try it against a language with modules support, even the oldie Turbo Pascal for MS-DOS.
      - groundzeros2015 9mo ago
        Turbo pascal compiles faster because of better parallelization?
    - gf000 9mo ago
      It reminds me of the joke that "I can do math very fast", probed with a multiplication and immediately answering some total bollocks answer. - "That's not even close" - "Yeah, but it was fast" Sure, it's not a trivial problem, but why wouldn't we want better compilation results/developer ergonomics at the price of more compiler complexity and some minimal performance penalty? And it's not like the performance doesn't have its own set of negatives, like header-only libraries are a hack directly manifested from this compilation model.
      - groundzeros2015 9mo ago
        your topic is shifting from multi-threading benefits in language compilation, to ergonomics of C headers.

by gf000 10mo ago

Well, what about small CLI tools, like ripgrep and the like? Does multithreading not matter when we open a large number of files and process them? What about compilers?

groundzeros2015 10mo ago

Sure. But the more obviously parallel the problem is (visiting N files) the less compelling complex synchronization tools are. To over explain, if you just need to make N forks of the same logic then it’s very easy to do this correctly in C. The cases where I’m going to carefully maintain shared mutable state with locking are cases where the parallelism is less efficient (Ahmdal’s law). Java style apps that just haphazardly start threads are what rust makes safer. But that’s a category of program design I find brittle and painful. The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads.

gf000 10mo ago
> The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads. This is a huge limitation of C's compilation model, and basically every other language since then does it differently, so not sure if that's a good example. You do want some "interconnection" between translation units, or at least less fine-grained units.
- groundzeros2015 10mo ago
  And yet despite that theoretical limit C compiles faster than any other language. Even C++ is very fast if you are not using header-only style. What’s better? Rust? Haskell? Swift? It’s very hard to do multithreading at a more granular level without hitting amdahl’s law and synchronization traps.
  - pjmlp 9mo ago
    No it doesn't, try it against a language with modules support, even the oldie Turbo Pascal for MS-DOS.
    - groundzeros2015 9mo ago
      Turbo pascal compiles faster because of better parallelization?
  - gf000 9mo ago
    It reminds me of the joke that "I can do math very fast", probed with a multiplication and immediately answering some total bollocks answer. - "That's not even close" - "Yeah, but it was fast" Sure, it's not a trivial problem, but why wouldn't we want better compilation results/developer ergonomics at the price of more compiler complexity and some minimal performance penalty? And it's not like the performance doesn't have its own set of negatives, like header-only libraries are a hack directly manifested from this compilation model.
    - groundzeros2015 9mo ago
      your topic is shifting from multi-threading benefits in language compilation, to ergonomics of C headers.