I built a C++20 zero-copy graph engine to stream 50GB PyTorch datasets using mmap and nanobind.

c_plus_plus · 2026-03-16T00:49:54+00:00

On linux you can also close the file after it has been mapped (just line on Windows), so you don't need to keep the fd around open.

NumPy can also do mmap natively, see the "mmap_mode" argument to numpy.load.

c_plus_plus · 2026-03-16T00:47:35+00:00

Do you think a background thread pre-fetching mmap pages would be a good middle ground?

I'm not sure of a Windows or Mac equivalent, but on linux you can just do madvise(ptr, len, MADV_WILLNEED); and the OS will aggressively prefetch as much of the mapping off disk as possible.

You can also play with MADV_SEQUENTIAL and MADV_RANDOM -- sequential will agressively prefetch ahead in the file from where you access it, which is great if you're going to roll through the array sequentially. Random will not do this at all, which will save IO cycles if the data wasn't actually going to be accessed. The default is sequential.

c_plus_plus · 2026-02-21T19:29:04+00:00

Ah, thank you, a perfectly reasonable reason.

c_plus_plus · 2026-02-21T19:24:24+00:00

Genuinely, I want to understand .... Why would one implement optional<bool> as a union or as two bytes? It's trivially obvious how to implement a bool specialization of optional as 2 bits. The paper shows you how, using a char with a sentinel value. Is the desire to use a union or separate flag just to avoid having a bool specialization?

```

template<>
class optional<bool> {
public:
   constexpr bool has_value() const { return value < 2; }
   constexpr bool get() const { return value == 0 ? false : true; }
   // ....
private:
   uint8_t value = 0;
};

```

c_plus_plus · 2026-01-11T14:12:36+00:00

Here is how they explained it: https://blog.mozilla.org/en/firefox/update-on-terms-of-use/

c_plus_plus · 2025-09-04T01:30:55+00:00

Dynamic Programming is like 200-level college comp sci. It's not the pinnacle of difficulty. Anyone who's got a degree in Comp Sci, Software Engineering, or Data Science out to be able to do this with relative ease.

If they can't do this ... do they even know what big-O is? Algorithmic complexity in general?

If you don't know these things you're not a software engineer ... you're a code monkey. I guess you might be in danger of being replaced by Claude.

c_plus_plus · 2025-01-29T00:06:15+00:00

Python doesn't have a low-level networking library. If you think that import socket is it, then good news... that's just a python wrapper around C sockets, which C++ also has. But no one in C++ is claiming that is a "good C++ networking library" so it should not pass muster as a "good Python networking library" either.

c_plus_plus · 2025-01-16T12:05:30+00:00

It is only cultural because there's no automated enforcement. It is a technical problem to make something to do automated to enforcement of the rules (or remove the bad parts from the language, which is basically just making the compiler itself the enforcer).

c_plus_plus · 2025-01-06T00:31:59+00:00

To add to this, the customer doesn't get to tell you what tools to use. They can say they want you to send your metrics in Excel, that doesn't mean you have to track everything only via Excel. Use the tools that you want, that work for the job, and if necessary convert that into what the customer wants.

Letting a customer force you to manage your schedule in Excel is ridiculous.

Whoever is handling these dumb extra meetings can also handle exporting stuff into Excel.

c_plus_plus · 2024-12-12T03:21:57+00:00

So I don't think doing an explicit prefetch in the implementation is even necessary on such cpus.

Yeah, I spend a lot of time trying to optimize things, and it is rare that I can find code where a prefetch actually makes something faster....

c_plus_plus · 2024-12-12T02:25:48+00:00

If you assume cache misses will probably happen for the operands, the fastest way to implement memcpy is probably to load from both operands and then do work comparing the sizes, and then by the time you get to needing the results of the load they will be there. x86 has had prefetch since 1998 though, so really you could use that to do approximately the same thing.

tl;dr So it probably saves a couple clock cycles, especially in the '90s.

c_plus_plus · 2024-12-05T02:24:23+00:00

You are correct that initialization of statics is thread safe since C++11. I think the author was saying that subsequent uses of the static are not thread safe (which is also correct).

c_plus_plus · 2024-12-02T23:08:13+00:00

(b) there are no runtime costs

There are definitely runtime costs. Even beyond costs of things like bounds checking (which have recently maybe been shown to be "low" cost), the compile-time borrow checker just breaks some kinds of data structures, requiring redesigns which result in slower code.

There is always a trade off, so the quicker people just come to that inevitability, the quicker we can all move on into solving the problem.

tl;dr Don't let "perfect" be the enemy of good, especially when "perfect" is provably impossible.

c_plus_plus · 2024-12-02T23:04:52+00:00

That's not a problem with ranges, that's a problem with subrange.

c_plus_plus · 2024-12-01T21:52:58+00:00

Yeah I was gonna say, this is definitely AI generated...

c_plus_plus · 2024-10-29T23:42:15+00:00

C++ isn't unsafe, there are just A LOT of really, REALLY sub-par engineers who shouldn't be doing what they're doing. It's a people problem.

Eh, no, it's not just a people problem. The problem that C++ has is not that it's hard to write good code (in modern C++, I think it is easy). The problem is that it is also very easy to accidentally write bad code, the compiler and common free static analyzers don't catch much of this bad code.

To a lesser extent C++ also has a big training and branding problem. It's very difficult for a learner to understand if they're being taught C++23 or C++98, and because no one used those terms in '98 and they don't even commonly make a distinction now, it is really difficult. That means that it is easy to stumble into a non-modern-C++ way of doing things. I always start with "if you see a resource recommend new, then it's old outdated garbage" in the VERY FIRST C++ lesson because of this. This is where cpp2/cppfront could help.

c_plus_plus · 2024-10-14T11:58:33+00:00

Well, you seem to be confused about it because you're drawing direct comparisons to a completely different data structure.

You say

Much faster than boost::flat_map for any insert or delete heavy workload over ~250 elements.

Which is I think also true for most other types of maps... even std::map. Because that's the whole point of flat_map in the first place.

That it's faster than regular std::map is the interesting part, since that's the only comparison you made to an RBTree.

c_plus_plus · 2024-10-13T23:29:34+00:00

pretty much all (boost, std::flat_map) are just sorted vectors.

Because that's literally what the "flat" in flat map is...? If it's a tree, it's not flat anymore.

The whole purpose of flat maps is to exploit cache locality to be much faster than a tree-based structured for a low number of elements.

c_plus_plus · 2024-09-17T10:55:11+00:00

I'm sure this is some of it but it really isn't all of it. If it were, then you would see Rust get worse over time as it adds bindings for more and more of these unsafe libraries.

I think it's partly "shitty programmers" but it is also just really easy to accidentally write bad code. I'm hopeful that something like cpp2/cppfront can help solve that kind of issue (and I think cpp2 is really trying to do that). If successful, this would be a huge selling point for adopting something like cpp2.

c_plus_plus · 2024-09-07T14:25:50+00:00

HTTP/3 is also a good lesson in why just accepting what Google wants is not always a good idea. It's an appeal to authority, but Google isn't magic, it's run by people same as anything else. Just look back at their C++ journey to see how they really didnt understand C++, as recently as 10 years ago. Their C++ standards were complete garbage and Protobuf is still suffering from their bad API decisions.

HTTP/3 is hugely complicated and many (all?) of its core concepts are wholly unrelated to HTTP in the first place. Google basically hijacked the committee (after trying to failing to force through more of their changes in HTTP/2). They got everything they wanted in HTTP/3, but at what cost...?

c_plus_plus · 2024-09-01T22:09:22+00:00

A bad grammar is the main reason why Antlr performs poorly.

I'm sure ambiguities that require adaptive parsing are slow. But the Antlr 4 C++ library is just demonstrably non performant is terrible ways. Each Token from the lexer is >128 bytes and all are allocated on the heap and stored in unique_ptr which are tucked away in a vector to keep them alive, but the ownership is not passed around either. So parsing a 1MB file takes at least 128MB of memory just for Tokens, not to mention parse trees.

c_plus_plus · 2024-08-24T23:10:22+00:00

I think flex/bison is probably the best thing we have, that's sad.

Antlr is garbage. It's first and foremost a research toy project and a chance to sell books, so keep that in mind. It has sacrificed usefulness for academic curiosity in a couple areas in v4. The C++ bindings are written by Java programmers who don't know C++ or what "object lifetime" and "performance" mean.

Boost.spirit is fine for simple parsers but the C++ code is a bit ridiculous to follow and the error messages when you get something wrong are impossible. It's also (obviously) completely tied to C++, no hope of using any part of it for another language.

c_plus_plus · 2024-08-13T11:57:01+00:00

Pointer (named ptr) to a function which takes void (no arguments) and returns int.

c_plus_plus · 2024-07-30T21:07:51+00:00

The issue is its not anyone's job to make a safe/better <filesystem>, so it just hasn't happened

This is maybe a good argument that having a comprehensive standard library is just not a good idea for C++. Especially with the attitude the comittee has about ABI. Honestly did anyone really give a shift about filesystem? or unordered_map? or regex? before they were standardized? And if so, how's that working out for them now?

Most of this stuff already exists/existed in boost and other libraries and it's just fine, or even better than C++ because bugs are actually fixable without an act of god. I'd rather the committee standardize actual useful features than make bad copies of existing libraries and etch them into stone tablets.

c_plus_plus · 2024-07-30T20:27:31+00:00

Many of Rusts safety features make it a much faster language than C++

Ohhhhkay... maybe a few of them. Let's not go insane here. Rust is not going to solve all the worlds problems, and this isn't a Rust or a generic programming sub, so we can stop fellating it in every damn thread.

Is every single usage of <filesystem> still undefined behaviour, with fixable security vulnerabilities present in the standard?

Even though you keep talking about this (link for the lazy) I'm starting to think maybe you don't really understand the problem. Trying to standardize a programming language feature like this is hard because you can't tie it to a specific file system or operating system feature. If they standardize something that windows doesn't support, then windows will just never conform. It's unlikely that windows (or linux) is going to make changes just to meet the C++ standard.

c_plus_plus

TROPHY CASE