5 ms·

Not having the kernel locked into a compiler monoculture for one.

by tscs37 9y ago

jhasse 9y ago
Why does that matter?
- tscs37 9y ago
  Monocultures of any kind in software aren't good. It leads to lock-ins, like the current kernel is locked into GCC. Some of those GCC Extensions used are effectively proprietary because "the code is the documentation" so nobody can replicate it for their own compiler. I do not believe that is healthy.
  - jhasse 9y ago
    That's definitely a huge disadvantage! But only supporting one compiler has the advantage that you're aren't limited to the lowest common denominator of compiler features. You'll notice this especially with C++ codebases which try to support GCC, Clang, Intel and Visual C++. You'll need a lot of macros and workarounds for each compiler's quirks.
- stusmall 9y ago
  When I'm doing a new C project I usually go out of my way to make sure it compiles clean with GCC and clang. Each compiler has its strength and weaknesses. GCC tends to produce faster code in some situations where clang has great static code analysis tools and asan is amazing. I've heard GCC has made major improvements in build speed since the last time I've started a new C project from scratch but that used to be on my list of reasons too. C can be a hard to wrangle beast and the more checks I have on my code quality the better I sleep at night.
  - uep 9y ago
    At least from the outside, GCC asan seems comparable to clang's right now. I haven't done back-to-back checking to see if clang finds things it doesn't. I haven't really used the undefined and thread sanitizers though.
    - stusmall 9y ago
      Oh wow. That's exciting news. My current job doesn't have me doing any C so I haven't been following the releases as closely as I used to.
- valarauca1 9y ago
  LLVM is an extremely open backend. So it can be used for many projects a short list of its usages: * Compiling SPIR-V shaders to GPU executables * Compiling C * Compiling C++ * Compiling Rust * Compiling Haskell * Compiling Swift * JIT compilers for databases * JVM JIT Effectively once you translate to LLVM-IR you are basically home free, the LLVM can handle the rest. Which means you have a board range of people providing optimization passes, and catching bugs. --- With the GCC its IR is tightly coupled to the C front end. While there has been some decoupling, this is generally considered a feature as it doesn't allow for a corporation to _run away_ with part of the project. --- The LLVM is more modular, you can pick and take what you need. You can embed it, or call it externally. It is a hybrid BST/MIT/X11 license so it is open source, and embedding it in your project doesn't mean your project becomes GPL'd.
  - floatboth 9y ago
    Also used to be in WebKit's JS engine https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ now replaced with a custom thing https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...

Not having the kernel locked into a compiler monoculture for one.

by tscs37 9y ago

Not having the kernel locked into a compiler monoculture for one.

jhasse 9y ago

Why does that matter?

tscs37 9y ago
Monocultures of any kind in software aren't good. It leads to lock-ins, like the current kernel is locked into GCC. Some of those GCC Extensions used are effectively proprietary because "the code is the documentation" so nobody can replicate it for their own compiler. I do not believe that is healthy.
- jhasse 9y ago
  That's definitely a huge disadvantage! But only supporting one compiler has the advantage that you're aren't limited to the lowest common denominator of compiler features. You'll notice this especially with C++ codebases which try to support GCC, Clang, Intel and Visual C++. You'll need a lot of macros and workarounds for each compiler's quirks.
stusmall 9y ago
When I'm doing a new C project I usually go out of my way to make sure it compiles clean with GCC and clang. Each compiler has its strength and weaknesses. GCC tends to produce faster code in some situations where clang has great static code analysis tools and asan is amazing. I've heard GCC has made major improvements in build speed since the last time I've started a new C project from scratch but that used to be on my list of reasons too. C can be a hard to wrangle beast and the more checks I have on my code quality the better I sleep at night.
- uep 9y ago
  At least from the outside, GCC asan seems comparable to clang's right now. I haven't done back-to-back checking to see if clang finds things it doesn't. I haven't really used the undefined and thread sanitizers though.
  - stusmall 9y ago
    Oh wow. That's exciting news. My current job doesn't have me doing any C so I haven't been following the releases as closely as I used to.
valarauca1 9y ago
LLVM is an extremely open backend. So it can be used for many projects a short list of its usages: * Compiling SPIR-V shaders to GPU executables * Compiling C * Compiling C++ * Compiling Rust * Compiling Haskell * Compiling Swift * JIT compilers for databases * JVM JIT Effectively once you translate to LLVM-IR you are basically home free, the LLVM can handle the rest. Which means you have a board range of people providing optimization passes, and catching bugs. --- With the GCC its IR is tightly coupled to the C front end. While there has been some decoupling, this is generally considered a feature as it doesn't allow for a corporation to _run away_ with part of the project. --- The LLVM is more modular, you can pick and take what you need. You can embed it, or call it externally. It is a hybrid BST/MIT/X11 license so it is open source, and embedding it in your project doesn't mean your project becomes GPL'd.
- floatboth 9y ago
  Also used to be in WebKit's JS engine https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ now replaced with a custom thing https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...