There are alternative ways to utilize a machine with multiple cores, e.g. by running one thread per CPU core, and not sharing state between those threads; in each such thread you then have single-thread "semantics".
That was mostly meant as irony/a joke, but I admit that's not really clear from the text...
For the sake of clarity, if you need thread-safety, probably best to just use std::shared_ptr / std::weak_ptr.
(Author here.) That is a good question. For our use case, we in fact do not use std::shared_ptr in our implementation, but instead a single-threaded shared_ptr-like class that has no atomics (to avoid cross-core contention).
However, when I wrote the blog-post, I replaced that not-so-well-known class by std::shared_ptr for the sake of accessibility of the blogpost for a general c++ audience, but by doing so, it indeed becomes a natural question to ask why one wouldn't use std::weak_ptr (which I hadn't realised when writing the post).
One reason why this design can still be beneficial when using the standard std::shared_ptr in its implementation, is when you do not want to manage the pointee object by a std::shared_ptr (which is a requirement if you want to use std::weak_ptr). E.g., if you want to ensure that multiple objects of that type are laid out next to each other in memory, instead of scattered around the heap.
Another goal of the post is to show this idea, namely to use a shared_ptr<T*> (instead of shared_ptr<T>), which is kind of non-standard, but can be (as I hope I convinced you) sometimes useful.
The author could compile c++ with the sanitizers, i.e. -fsanitize=address,undefined
and make a make_appender function that leverages perfect forwarding...:
Roseman Labs | C++ engineer and front-end/UX specialist | Utrecht, The Netherlands (EU work permit required)
We build a software product that enables parties that manage privacy-sensitive data to collaborate and jointly extract insights without having to mutually share the underlying data. Our product is based on secure multiparty computation (MPC), a mature academic subfield of cryptography; MPC is among the most promising privacy enhancing technologies (PETs).
Roseman Labs was founded in March 2020; meanwhile we have a growing customer base and our team consists of 11 people (+ 1 pet).
We are looking for talent to help us further develop the core of this product (C++20 & Computer Science / Math knowledge), as well as intuitive web-based GUIs (JavaScript, Svelte, etc.) tailored to different user roles (privacy officer, data scientist, business owner, etc.).
Core:
- C++20 development on Linux (gcc, clang, concepts, coroutines, etc.)
- asynchronous networking & disk I/O, cooperative multitasking, multi-core
- high performance networking (zero-copy, RSS, ...)
> [ Hope I am not coming across as too negative, but since you put it in a paper and published it I think it is fair to do some peer review ]
No, not at all, your feedback is highly appreciated!
BTW, the paper is a preprint, it is currently under review.
- I fully agree with the O(N) vs O(1) issue in the evalPartialDerivative. Also, an optimization possibility I considered is to replace string-valued variable names like "Y" by integers, but this adds some bookkeeping-burden for a creator of a message that works in a programming language other than c++ (for which we do not provide convenience methods for building messages)
- I agree with the auto vs (const) auto& point you raised. However, some cap'n proto types (readers / builders) are copyable types ("handles"), hence they should be using with auto. (And, sometimes, the compiler can do better optimizations when you've passed objects (of small size) by value rather than ref, but this might be different for each specific case; one would have to benchmark.)
Regarding expression: "P-10+q^2":
The string encoding is much shorter indeed, and is an alternative way.
However,
- double values potentially lose precision in a string representation (btw, also this "JSON bridge" I mentioned earlier suffers from this problem) and possibly take up more space than 8 bytes.
- the schema also serves as the grammar of the message format; is a compact "manual", in that (almost) everything that can be expressed using the schema will be "valid" and accepted by the interpreter.
If one encodes a string, one has to define this grammar separately (one has to define what is a 'valid' string and what not). Adopting this schema-based solution saved us work.
- there are typically more objects in a message ("advertisement"), so the string would have to be augmented with information about what it represents in the message.
- also: having a schema-based solution helped us in designing the message format (the types defined in the schema let you think in a more abstract way about the message format), and provides evolvability.
Hence, there were certain motivations for choosing this approach that are unrelated to space (bytesize) or runtime performance.
The software is part of a smart (electricity) grid control platform. I agree that on the github project there is also quite some code that is unrelated to the title of this Show HN post.
The application of the code is a networked control system, where, roughly speaking, many resources send messages to a central controller.
In the light of this "many-to-one" topology, the advantage of the approach taken in this project (essentially, sending an abstract syntax tree encoded in capnproto) over just sending a string, is that there is no parsing-step needed at the receiver, which saves time. (It is a real-time system)
The server program (I assume that you're referring to daemon.cpp), was added as a bridge between the more-powerful capnproto-based message format and a less-flexible but easier-to-use-for-non-experts (JSON-based) interface. However, what happens in this daemon should not be viewed as part of this Show HN topic.
There are alternative ways to utilize a machine with multiple cores, e.g. by running one thread per CPU core, and not sharing state between those threads; in each such thread you then have single-thread "semantics".