llfio
mold
Our great sponsors
llfio | mold | |
---|---|---|
25 | 179 | |
768 | 13,259 | |
- | - | |
6.3 | 9.7 | |
10 days ago | 8 days ago | |
C++ | C++ | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
llfio
-
File IO question if something is in stdlib or not
The reference library can be found at https://ned14.github.io/llfio/
-
Is there a good cross-platform (Windows / Linux) C or C++ library for file I/O?
Thanks for the suggestions, which I have transposed into https://github.com/ned14/llfio/issues/106
-
Should I use platform dependent file IO instead of basic_fstream when performance matters
There was an effort to get an afio library accepted into boost in the past. I believe the most current work on that library is happening here nowadays : https://github.com/ned14/llfio I'm not sure if it is considered production-ready or not. But I couldn't see any mention of it in the replies so I figured I would fix that!
-
File Handling in C++
It has an implementation: LLFIO
- Proposed Standard Secure Sockets reference implementation complete
-
Getting started with Boost in 2022
I'm a fan of Interprocess, used it for over a decade. But for mmapping I've switched to LLFIO and recommend it highly. (Plugging so Niall doesn't have to.)
-
Networking TS: first impression and questions;
Since that post, I have the reference implementation library very nearly passing its test suite https://github.com/ned14/llfio/pull/89. Once it's done I'll start very slowly writing its proposal paper for WG21 SG4. Should land before this summer.
- P2300 (Sender/Receiver) is DEAD in the water for C++23 !!!
-
IO library for embedded devices - looking for contributor
FYI it doesn't solve quite what you're solving, but I've been careful to ensure https://github.com/ned14/llfio works well on Freestanding and < 64 Kb microcontrollers and I know Victor has been careful to ensure a good subset of std::format could work well on embedded. In other words, the i/o story for embedded C++ may improve greatly in the next few years.
-
Weird fstream behavior after MSVC upgrade
If you want stronger guarantees than iostreams can give you, either use the OS-specific calls or a wrapper of said calls (e.g. https://github.com/ned14/llfio, disclaimer I'm the owner of that). Note that even in LLFIO, there is no concept of "seek to the end" because that's racy so we don't implement that. All you get is atomic append, otherwise you're on your own to coordinate what "end of file" means.
mold
-
I reduced (incremental) Rust compile times by up to 40%
I think this is unlikely to gain traction. I say that no to discourage you, just to explain.
- The community has an instinctive distrust of closed source or a compiler from an untrusted source. If you’re familiar with the Trusting Trust attack you’ll understand why.
- Dev tools in every language ecosystem are almost always free, unless they involve some kind of hosting. People aren’t used to opening their wallets. Look the experience of the guy who built the mold linker(https://github.com/rui314/mold). Far superior to the state of art, improves incremental compiles a lot, widely applicable across ecosystems (C, C++, Rust), CPU architectures and Operating Systems. You don’t even have to modify your compiler, just need to point to his linker. He’s even giving it away for free for personal use. But still, almost no one uses it. The inertia of the established options is really high.
- It’s not complex enough. Think about the complexity involved in the cranelift backend. No one can seriously recreate the efforts of bjorn3. If we could have, we would have. But the idea idea here can be recreated, especially by the experts who already built incremental compilation into rustc.
- But if your solution is truly complex, like the parallel frontend, the burden of maintaining a fork would be too high. You’d have to spend all your time rebasing.
Again I’m not trying to discourage you, just stating the difficulties of making a business in the dev tools space. You would be better off contributing this excellent work to the community and trying a different tack.
-
Mold Course
I initially thought this would be about the mold linker (https://github.com/rui314/mold)
-
Monetizing Developer Tools
I assume this submission is trying to highlight the specific message (2023-01-24) : https://github.com/rui314/mold/issues/190#issuecomment-14028...
Fyi... the author wrote a more expansive blog post about selling dev tools a few months later (2023-06-06) and there was a related HN thread about it: https://news.ycombinator.com/item?id=36225016
-
mold 2.1.0 - rui314/mold
Loongson's LoongArch CPU has been supported. (03b1a1c)
-
Mold 2.0.0
I'm amazed at how quickly the author responds to requests: https://github.com/rui314/mold/issues/1057
From the report to the fix in less than two days.
I'm not sure how competitive it will be with lld, especially if we consider ThinLTO (which takes multiple minutes on 64-core machine) - it can make the advantages of mold insignificant.
- Mold 2.0 released - MIT license
-
Linking many files significantly increases build time. Is there an editor that allows you to write a single file but present the file to the screen as multiple 'virtual' files for better organization?
What other solutions have you tried for the problem of slow linking? You haven't even said which linker and what flags you're using. I haven't actually tried it, but the author of gold has an even faster linker called mold: https://github.com/rui314/mold
- Design and Implementation of the Mold Linker
-
Apple's new library format combines the best of dynamic and static
> Mold did it first, though: https://github.com/rui314/mold
Before LLD?
What are some alternatives?
mio - Cross-platform C++11 header-only library for memory mapped file IO
zld - A faster version of Apple's linker
libunifex - Unified Executors
wasmtime - A fast and secure runtime for WebAssembly
countwords - Playing with counting word frequencies (and performance) in various languages.
osxcross - Mac OS X cross toolchain for Linux, FreeBSD, OpenBSD and Android (Termux)
parallel-hashmap - A family of header-only, very fast and memory-friendly hashmap and btree containers.
zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
corrade - C++11 multiplatform utility library
chibicc - A small C compiler
robin-hood-hashing - Fast & memory efficient hashtable based on robin hood hashing for C++11/14/17/20
sccache - Sccache is a ccache-like tool. It is used as a compiler wrapper and avoids compilation when possible. Sccache has the capability to utilize caching in remote storage environments, including various cloud storage options, or alternatively, in local storage.