4 ms·

It seems like nlohmann/json is a header-only library, meaning the entire library has to be compiled once for every source file which uses it any time that sourc

by mort96 2y ago

It seems like nlohmann/json is a header-only library, meaning the entire library has to be compiled once for every source file which uses it any time that source file or its includes has updated. So I guess in a JSON-heavy code base or a code base where nlohmann/json has leaked into common headers, you may end up recompiling the library a few dozen times per build where a few dozen of your C++ source files must be recompiled (e.g due to common header changes)... (But don't worry, the linker will then spend a bunch of time throwing away almost all of that work so you only get one copy of the library in your binary)

occz 2y ago
I missed that part. That is a pretty significant downside in that case.
- jart 2y ago
  It places a hard scaling limit on how big an open source project can become. Projects like the Linux Kernel spend enormous amounts of political capital restraining decadent programming practices, since it's the only way a codebase like that can maintain the support of its developers and grow. For example, Linux had a rule until 2018 that everything had to be able to compile with GCC 3.2 from 2003. They're much more laid back these days, since it's difficult to imagine Linux growing bigger than it already has. But I think for a newer project like llama.cpp would be well advised to follow by example what projects like Linux did in their growth phase, rather than following their leadership today. It requires an lot of discipline, toil, and restraint to be a leader in open source, because you're essentially offering the world a pot of gold, and that only works if you keep very little for yourself.
  - occz 2y ago
    Looking at the source code for llama.cpp, it's not strictly speaking set up for success as far as build times are concerned, is it? Having 20k+ lines is a bad idea for many reasons, and this is certainly one of them. I'm sure the authors are brilliant in many ways, but I suspect there's room for improvement in this area.

by mort96 2y ago

occz 2y ago

I missed that part. That is a pretty significant downside in that case.

jart 2y ago
It places a hard scaling limit on how big an open source project can become. Projects like the Linux Kernel spend enormous amounts of political capital restraining decadent programming practices, since it's the only way a codebase like that can maintain the support of its developers and grow. For example, Linux had a rule until 2018 that everything had to be able to compile with GCC 3.2 from 2003. They're much more laid back these days, since it's difficult to imagine Linux growing bigger than it already has. But I think for a newer project like llama.cpp would be well advised to follow by example what projects like Linux did in their growth phase, rather than following their leadership today. It requires an lot of discipline, toil, and restraint to be a leader in open source, because you're essentially offering the world a pot of gold, and that only works if you keep very little for yourself.
- occz 2y ago
  Looking at the source code for llama.cpp, it's not strictly speaking set up for success as far as build times are concerned, is it? Having 20k+ lines is a bad idea for many reasons, and this is certainly one of them. I'm sure the authors are brilliant in many ways, but I suspect there's room for improvement in this area.