27 ms·

C/C++ vs. Rust Performance

102 points by krizhanovsky 6y ago

steveklabnik 6y ago
This was pretty heavily discussed on /r/programming a few days ago https://www.reddit.com/r/programming/comments/jjtobp/fast_programming_languages_c_c_rust_and_assembly/ https://www.reddit.com/r/programming/comments/jjtobp/fast_pr...
- AlchemistCamp 6y ago
  Thank you!
- jeff-davis 6y ago
  That thread brings up per-container memory allocators, and mentions Vec. What's going on there? I have been trying to find a good way to deal with hybrid memory/disk structures. One example is external sort, but there are a whole class of such structures used for databases (Hash Join, Hash Aggregation, etc.). The idea is to constrain the memory footprint of a structure and efficiently use the disk. One challenge is simlly knowing how much memory is being used. Another is supporting multiple heaps/arenas/whatever and allocating in the right one. And a third is safely clearing parts of the structure that have been written to disk for later processing (I guess calling the destructors if necessary?). Is there any work in this area?
  - CyberDildonics 6y ago
    Wouldn't memory mapping take care of a lot of these scenarios? The OS will do all the caching. If you make a data structure that is meant to use one contiguous chunk of memory and access memory linearly and/or with locality when possible, I would think it would make explicit disk/hybrid scenarios much less necessary.
    - jeff-davis 6y ago
      Consider a hash table. Access is basically random, so if 25% fits in memory and 75% is paged-out at any given time, then 75% of the lookups will be a page fault and require a page-in. Very costly. Compare that to a Grace HashJoin (https://en.m.wikipedia.org/wiki/Hash_join https://en.m.wikipedia.org/wiki/Hash_join) which partitions both sides (lookup side and hash table side) into matching partition pairs. The partitioning step and reading the partitions from disk are both sequential access. Then, pick up and process one pair of partitions at a time, which will only require a small hash table in memory. Note that this is still way more efficient even when on an SSD, because an SSD is still block-oriented, and paging entire blocks in/out for a single lookup is still inefficient. It even helps when the data fits into memory sometimes, because you can size the partitions small enough to fit in cache, which will make lookups even faster. You can say "don't use hash tables", but that's not a great amswer for a low-level high-performance language like Rust.
      - CyberDildonics 6y ago
        I would never say "don't use hash table" but I do think that a lot of the benefits from special data structures like these are more due to the organization of memory than being explicit about memory loading and disk writing. In this case it seems like the downsides you mentioned are the downsides of keeping things on disk, not memory mapping (which would only hit the disk on the first load and would automatically use any available memory). Organization to use disk pages effectively would benefit memory mapping as well.
        jeff-davis 6y ago
        But to organize memory you need some idea of how much you are using (e.g. how big the in-memory hash table is), and be able to free it in a reasonable pattern (e.g. deallocate the whole heap/arena at once). Both things are difficult in rust currently, and memory mapping doesn't help with either. Memory mapping serves a similar purpose as temp files: a way to tell the OS that it can freely page that out to avoid uncontrolled swapping. But you need to do the organization yourself to keep that access sequential, which is hard to do in rust for the reasons that I mentioned. If you memory map a hash table and have memory pressure, you'll go into the crazy bad scenario of a page-in for every lookup, which is avoidable with better organization. I think we are basically in agreement but perhaps my point was not clear.
  - steveklabnik 6y ago
    > What's going on there? Box and Vec are starting to gain the ability to be parameterized over an allocator. > Is there any work in this area? Kind of, but it's slow going. You can support multiple heaps/arenas/whatever, but it means you have to implement your own. As the ecosystem standardizes around the allocator traits (only the global one is stable yet), there will be easier interop.
  - aw1621107 6y ago
    > That thread brings up per-container memory allocators, and mentions Vec. What's going on there? I believe they're talking about custom allocator support for Box [0, 1]. The author of the PR says that they intend to add per-container allocator support once support for Box lands, starting with Vec [2]. [0]: https://www.reddit.com/r/rust/comments/jgxgpu/box_will_have_custom_allocator_support_soon_tm/ https://www.reddit.com/r/rust/comments/jgxgpu/box_will_have_... [1]: https://github.com/rust-lang/rust/pull/77187 https://github.com/rust-lang/rust/pull/77187 [2]: https://www.reddit.com/r/rust/comments/jgxgpu/box_will_have_custom_allocator_support_soon_tm/g9turat/ https://www.reddit.com/r/rust/comments/jgxgpu/box_will_have_...
zamalek 6y ago
> Rust doesn't provide stack allocations at all. What? Rust allocates on the stack by default.
- mbrubeck 6y ago
  It means dynamically-sized stack allocations, e.g. `alloca`.
- akiselev 6y ago
  He's talking about variable length arrays, which would be an unsized type in Rust and thus can't be stack allocated. For example, the following is valid C99: `void foo(int n) { int values[n]; }` I don't know that that's a bad thing. AFAIK the implementation details are underspecified even in C and compilers kind of do whatever they want (i.e. I've seen some embedded compilers that monomorphize it in multiples of 2 up to a limit and just hope the user doesn't exhaust the stack). Edit: I'm pretty sure you can create a hacky version using iterators and a recursive function: `fn vla<T>(iter: impl Iter<Item=T>, init: T, index: usize, count: usize) { ... }` Edit2: Actually he's talking about `alloca` which is a whole other "here be dragons" feature. See the reddit thread steveklabnik linked for some of the pitfalls
  - masklinn 6y ago
    > Edit2: Actually he's talking about `alloca` which is a whole other "here be dragons" feature. See the reddit thread steveklabnik linked for some of the pitfalls AFAIK VLA is already that, didn't Linux de-VLA the kernel a few years back because they were a common security issue and the code they generate is bad / slow?
    - gpderetta 6y ago
      At least in gcc, vla and alloca prevent inlining.
  - vvanders 6y ago
    Even then last I looked C++ doesn't have it either, it's exclusively a C99 feature. For me the downsides outweigh the upsides of alloca and I usually find other approaches(free list, arenas, etc).
identity0 6y ago
> Secondly, the killing feature of C++ is that it is C. If you don't want to use exceptions or RTTI, then you can just switch the features off. Most of C programs can be just compiled with a C++ compiler with very small changes or without any changes at all. If your C code happens to be compileable with a C++ compiler, then either your program is very small or you are writing really shitty C.
- dathinab 6y ago
  Idk about "shitty C" but indeed C++ being a super set of C is a common misconception, followed by the misconception that it's nearly a superset of C. ;=) Simplest example is that a `void func()` decl in C and C++ have different semantic meanings.
  - simias 6y ago
    I think "nearly a superset" is correct, the empty argument list doesn't really make enough of a difference to really make it a completely different language. I also don't think I've ever seen this "feature" of C used productively in modern codebases, except maybe to declare generic function pointers in something like dlfunc. In general it's just that people are too lazy to type `void func(void)` (or don't know the difference). You can also tell that the C++ standard committee agrees with this to some extent since they tend to add C novelties into the C++ standards whenever possible to make it easier to write compatible code, for instance: https://en.wikipedia.org/wiki/C%2B%2B11#Improved_C_compatibility https://en.wikipedia.org/wiki/C%2B%2B11#Improved_C_compatibi...
    - Gibbon1 6y ago
      I feel like treating C as a subset of C++ has done real harm to the language.
      - rrdharan 6y ago
        Which one?
pizza234 6y ago
> It's also worth mentioning that the memory garbage collection (GC) in Java leads to high tail latencies and it's hard or even impossible to do anything with the problem This is amusing, because a few days ago, there was an article¹ reporting that the C4 garbage collector solved this problem. ¹=https://news.ycombinator.com/item?id=24895395 https://news.ycombinator.com/item?id=24895395
- vips7L 6y ago
  Hopefully ZGC will solve this in HotSpot so no one has to rely on a custom jvm.
- ncmncm 6y ago
  People can report anything. Solutions to pervasive, debilitating GC problems are as perennial as the Spring rain. Every year, we get a new crop, but the problems are still there the year after.
speedgoose 6y ago
> There are a lot of poor programs misusing goto, so they just removed the operator: good for juniors, but too limited for professionals. It's a bit condescending. I think the article would have been better without that kind of comment.
- virgilp 6y ago
  Yeah, I caught that too; it's more than a bit condescending and is also completely false. Complexity makes all people trip up, not just "juniors".
  - deleted 6y ago
    [deleted]
- tornato7 6y ago
  Especially because a "professional" programmer should be able to get along just fine without goto. Goto is bad practice in many languages where it does exist, too, like Go.
  - deleted 6y ago
    [deleted]
  - berkut 6y ago
    How do you break out of nested loops without an extra variable set/check to break on in the outer one otherwise? goto is nasty, but in my experience writing HPC code, it does have some uses that can't be solved as efficiently (i.e. without extra branching) otherwise in some situations.
    - tomjakubowski 6y ago
      Rust has special syntax to name loops, and to refer to them by name when breaking. 'foo: loop { 'bar: loop { break 'foo } }
      - 6y ago
vvanders 6y ago
I've written my share of systems level C++ in performance constrained environments professionally (gamedev, embedded systems). Never touched goto, alloca and branching usually stayed out of hot code through DOD approaches. Not really sure I agree with the conclusion. Alternatively they didn't talk at all about aliasing/restrict which is one really neat area of Rust because &mut guarantees one of the key aliasing constraints.
- creata 6y ago
  Isn't it still unable to actually make those aliasing optimizations because LLVM doesn't compile them correctly? https://github.com/rust-lang/rust/issues/54878 https://github.com/rust-lang/rust/issues/54878
- klyrs 6y ago
  I've used goto a handful of times over my 20 year professional history with c and c++. A few were used for simplifying cleanup code (actually this is quite common in c, less so in c++); a few were used in weird state machines and were accompanied by a page of documentation.
andy_ppp 6y ago
Won’t rust continue to get faster? And does it matter much given the speed of hardware these days, I mean O(n) will still be the same.
- deleted 6y ago
  [deleted]
- kzrdude 6y ago
  Why shouldn't C++ continue to get faster, too?
- ncmncm 6y ago
  In principle, Rust could get faster if optimizers took advantage of latitude enabled by stronger semantic guarantees. In practice, turning on such optimizations introduces debilitating bugs, because the optimizations are poorly exercised by other languages, and Rust core developers are fully occupied with other problems. O(n) is the starting point of optimization. Improvement by factors of two or ten are commonplace, relying on details of how modern machines are implemented, and often lately by farming work out to multiple cores or to GPU cores. Speed of the code is getting increasingly important as memory and storage sizes grow while clock speed stubbornly does not. Until Dennard scaling died, code got faster just by waiting. Now, making code faster takes work.
simias 6y ago
>The Rust's generics and macros are much weaker than provided by C++ templates coupled with C macros. Although, this is also not so crucial. That's a very strange way to put it IMO, I'm not sure what is meant by "weaker" here. They are stricter and as such can require more work to use effectively, but weaker is a weird way to put it.
- wtetzner 6y ago
  I would say Rust macros are considerably stronger, given it supports procedural macros.
- steveklabnik 6y ago
  I think that the way they mean is that there are less restrictions, which means you can do more with them, which makes them more powerful, in a sense. Words are hard.
- Karliss 6y ago
  C++ template provides features that rust generics don't. I am not a Rust developer so correct me of some of these have been recently added. Rust generics being stricter would be something like them allowing to use only methods provided by trait, but I would call all of following design limitations making rust generics weaker. * passing integer as template argument - from what I understand some of rust standard library functions can't handle arrays with more than 64 or 32 elements due to this or something similar. And there is active work for adding const generics to rust. * variadic templates - there is a RFC for this * passing template as template argument * template specialization - C++ is somewhat moving away from this
  - steveklabnik 6y ago
    The first point has had its restriction lifted as of the current version of Rust, 1.47.0. Or rather, the standard library and arrays bit is fixed; the underlying feature is not in stable Rust, and so other libraries still can't make this work properly yet. Variadrics are desired by some folks, but aren't a particularly high priority. Template template parameters are unlikely to land directly in Rust; GATs will be roughly equivalent. And specialization has a nightly implementation, and is highly desired, but isn't done yet.
Subsentient 6y ago
Just occurred to me, since Rust has LLVM IR asm directives, can't you write a portable goto in an inline function that jumps directly to pointers? Publish that crate to crates.io? Problem solved.
- steveklabnik 6y ago
  Rust stable still does not have inline assembly. Additionally, we have moved away from the "whatever LLVM does" feature, and built our own. There are significant language issues with doing something like this. Yes, in theory, you could do something. But it's going to be very unsafe, and very error prone.
  - Subsentient 6y ago
    I do see that the LLVM IR thing isn't being used anymore. I hope asm! ends up in stable Rust soon, seems like a pretty big oversight. Then again, MSVC dropped inline ASM altogether, which seems really dumb. One of these days I'm going to write a crate that easily enables doing all the unsafe, dangerous, stupid things that C programmers want to do, including gotos, with no safety checks or variable lifespan verification of any kind. And I'm going to name it "evil". :^) I will do it, eventually. ^^
    - taxcoder 6y ago
      As long as you don't name it evil-mode.
- tijsvd 6y ago
  Just write your parser as a collection of functions that can use tail calls. You should end up with a similar structure, i.e. a block of code with jumps instead of calls. Even in C++ I'd prefer that over a goto-based system (unless generated).
virgilp 6y ago
> Thus, in this single case when a Rust implementation is more or less faster than C, the performance difference is not about better compiler, but about more efficient structure of the program, which allows a compiler to optimize code better. This is strange takeaway.... I would say that's almost the only thing that matters. They compared one Rust compiler to 3 C++ compilers and picked the best result? Who does that in practice - who compiles their codebase with 3 different compilers and picks the most efficient one for each object file? Also, the compiler can often improve, where as the language itself is much more difficult to improve - the fact that the language lets you to write a more efficient (and more readable!) structure is crucial. Also, they seem to misunderstand the point of Rust entirely. The main point of Rust is "safety" (w/o sacrificing performance, yes - but safety was the primary design goal). And for a good reason! Systems programming is more about safe systems than it is about fast systems - fast buggy system programs are useless. The authors decry the loss of goto saying it's "good for juniors but too limiting for professionals" - as if professionals aren't humans too! I'm sorry to say that, but whenever I saw that attitude before - it was with programmers that greatly overestimated their skill level.
- jrimbault 6y ago
  Strong upvote for : > The authors decry the loss of goto saying it's "good for juniors but too limiting for professionals" - as if professionals aren't humans too! I'm sorry to say that, but whenever I saw that attitude before - it was with programmers that greatly overestimated their skill level. The "I know how to use goto [replace with any feature] everyone else is just stupid" reasoning upsets me so much.
- krizhanovsky 6y ago
  While I addressed safety in a separate section in the article, I wouldn't argue about that: it seems Rust designers made the perfect work in safety. However, C++ is moving in this directly, bu there is the "gap" as it was described in the cited talk from the CppCon 2020. However, there article is about FAST programming languages. Which means, and I stated this explicitly at the beginning of the article, that the main factor for the article is the speed of the generated code. This is why I compared the single Rust implementation with 3 C/C++ implementations. The question was: whether Rust does something unreachable for C/C++? And the answer is "NOT". Also please keep in mind that all the benchmark programs, using the same algorithms, are still coded in bit different ways. And the differences impact performance significantly. I analyzed two programs, in Rust and C, to show the differences.
lr1970 6y ago
Too bad they did not try Nim [1]. IMHO, Nim is better than Rust for C/C++ expats. [1] https://nim-lang.org/ https://nim-lang.org/
- vips7L 6y ago
  Isn't nim garbage collected? That seems like a big no-op for the authors use cases.
  - metasyn 6y ago
    It's optional (so you can turn it off if you'd like) https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html
    - vips7L 6y ago
      How do you manage memory then? Linking to libc and malloc/free?
      - lr1970 6y ago
        Yes, if you want to operate in "unsafe" mode you can manage memory yourself with pointers and malloc/free. But it is rarely needed in practice. Also, Nim compiles to C or C++ (and also to Javascript). Because of that Nim's C/C++ FFI is natural ans wrapper-free.
      - kupopuffs 6y ago
        --gc:arc. Plain reference counting with move semantic optimizations, offers a shared heap. It offers deterministic performance for hard realtime systems. Reference cycles cause memory leaks, beware. --gc:orc. Same as -gc:arc but adds a cycle collector based on "trial deletion". Unfortunately that makes its performance profile hard to reason about so it is less useful for hard realtime systems. --gc:none. No memory management strategy nor garbage collector. Allocated memory is simply never freed. You should use --gc:arc instead. Nim offers alloc, dealloc, allocShared, deallocShared
loeg 6y ago
Fact-check: > FreeBSD has been supporting C++ modules for a while. No, we don't. The link provided is to a user forum where someone asks about it, and the first response is "I don't believe that this is a good idea." I don't know why the author would just make up this false statement, but IMO it really hurts their credibility.
- dllthomas 6y ago
  The first response starts "I don't believe that this is a good idea", then makes some suggestions as to how to make it work anyway. There is plenty of room, at this point in consideration, for the thread to have reached a conclusion very different than that implied by the first sentence of the first comment. I read the whole thing. It doesn't.
  - loeg 6y ago
    Sure. I also skimmed through more of the thread than the first comment; it just made a nice sound-bite. I happen to know TFA's sentence is bunk from first-hand experience with the FreeBSD kernel and C++ proposals, but wanted to show that even the linked forum post doesn't really support the author's claim.
- krizhanovsky 6y ago
  But did you? My FreeBSD knowledge is quite outdated, I believe the last version I worked with is 7, but I believe at some point, it was possible to compile C++ kernel modules for FreeBSD. This time I can not find the proof, but plus to that post I also found links like https://lists.freebsd.org/pipermail/freebsd-hackers/2009-February/027706.html https://lists.freebsd.org/pipermail/freebsd-hackers/2009-Feb... https://lists.freebsd.org/pipermail/freebsd-hackers/2006-July/017161.html https://lists.freebsd.org/pipermail/freebsd-hackers/2006-Jul... The last one mentions: "There's actually a fair amount of experience with people doing C++ in FreeBSD kernels. People have been doing things with it for about 8 years now."
  - loeg 6y ago
    People have always played around with C++ kernel modules outside the project (e.g., https://github.com/adamlsd/libcpp.ko https://github.com/adamlsd/libcpp.ko ), but that is very different from saying the project supports C++ modules. There are no C++ kernel modules in FreeBSD itself. There is no support for C++ kernel modules in FreeBSD itself (neither build system nor source code). Developer response to C++ kernel proposals (the most recent on private internal mailing lists I cannot share) is cold.
ordu 6y ago
> A real high-level system programming language must be compatible with C. I cannot agree with this. After I learned rust and tried to mix it with C code I believe that Stroustrup made a mistake by making C++ compatible with C on a syntax level. Strictly defined FFI boundary is a good thing. It liberates. It allow to track precisely what boundary APIs are, it makes boundary APIs the separate documented thing. > An opposite example to use Rust for an Nginx module is CloudFlare's Quiche, an Nginx extension to support QUIC and HTTP/3 protocols. While it's definitely possible to use Rust for such kind of tasks, the guys, besides the FFI code for C/C++ bindings, still had to write some C code to patch Nginx. I took a look at the patch, and it is not clear to me, that the patch was needed because rust wouldn't allow to do it the other way. It seems that cloudflare split their code into rust and C for some other reason, because there is a LOT of C code, it doesn't seem to me as a glue code at all. I believe it does more than just glue rust module and nginx. I'm not sure what the reason, but I could guess that the idea was to add possibility to use different implementations of QUIC and HTTP/3 in nginx, not just this particular rust implementation. So they extended nginx for this, and then implemented rust module.
- vips7L 6y ago
  I like zig's compatibility with C. You can directly import C headers and the compiler will generate headers for your zig code as well.
  - xedrac 6y ago
    I think Zig will make a great C replacement eventually. I pick it over C any day of the week. But I'd prefer Rust over either of them. Zig's management of heap-allocated memory is very similar to C, which makes it less than ideal for large projects.
- gpderetta 6y ago
  if Stroupstrup hadn't made the mistake, today we wouldn't be talking about c++ in the first place.
dhanna 6y ago
> Golang can not be considered for high performance programming also due to the GC. People repeat this like Go isn’t designed for use in resource constrained environments.
- bfrog 6y ago
  I don't see Go running cortex-m level devices, atmega level devices. So no, it's really not.
  - coder543 6y ago
    It seems you haven’t looked around. Go runs on both Cortex-M and AVR: https://tinygo.org/ https://tinygo.org/ AVR support is more of a work in progress than the Cortex-M support, but it does exist.
    - bfrog 6y ago
      Neat!
- kupopuffs 6y ago
  Performance requirements have a huuuuuuuuuge range and Go can't really be considered for extreme cases. Like the latest, hottest, prettiest video gamez in VR HDR 8K resolution
- Daishiman 6y ago
  "resource constrained" is a very subjective interpretation. OP is talking about SIMD intrinsics and compiler micro optimizations. Go is definitely out.
timClicks 6y ago
Rust would be compelling even if it didn't offer comparable performance to C. Its safety guarantees mean that much easier for "mediocre" programmers to feel like they can contribute meaningfully to large codebases without introducing massive memory leaks/unsound behavior/...
legulere 6y ago
Exception epilogues also make optimization harder/impossible for compilers if I remember correctly. Rust suffers from this too though because panics use the same mechanism.
matklad 6y ago
This is an exceptionally great article, which indeed discusses strong Rust limitations. I have one question: the parser in the article uses computed goto, which, as far as I know, is not standard C. Are there many cases where even the standard goto yields significantly better performance?
- ncmncm 6y ago
  This is an exceptionally bad article, packed to the brim with unambiguous falsehoods. It is very unlikely that the computed gotos make the parser faster than using standard features of a more powerful language.
  - alok-g 6y ago
    >> It is very unlikely that the computed gotos make the parser faster than using standard features of a more powerful language. Can you explain more on how? Use case I have in mind is bytecode interpretation where computed goto should be a big help.
    - ncmncm 6y ago
      Optimized tail calls are effectively the same as computed goto, but are a Standard feature. Or, rather, don't require non-standard syntax. A program that relies on the optimization built by a compiler that failed to implement it--which is allowed--would not be expected to run well. https://github.com/ncm/computed-goto https://github.com/ncm/computed-goto The "more powerful language" part is to get language-level tools to compose parser combinators, ultimately resolving down to tail calls.
      - krizhanovsky 6y ago
        The benchmarks https://github.com/ncm/computed-goto/blob/master/benchmarks/trivial.cpp https://github.com/ncm/computed-goto/blob/master/benchmarks/... benchmark is not applicable to this discussion because it compares _too_ small state machines. I reference my talk and presentation once more: http://www.tempesta-tech.com/research/http_str.pdf http://www.tempesta-tech.com/research/http_str.pdf - slide 23 discusses that the goto FSM makes sense for _hundreds_ of states.
andy_threos_io 6y ago
The article brings up some good points, but there are several misconception. You can't compare normal user program execution with operating system kernel code execution. Total different beasts. There are reasons, that most operating system kernels are written in C and assembly. And also there is a reason why kernel code seldom use any FPU or SIMD instructions beside saving and restoring the FPU and SIMD context on context switch for user threads. ( The size of the SIMD registers in byte x86_64 SSE (256) x86_64 AVX (512) x86_64 AVX-512 (2048)) Ex. You don't want your interrupt server code use any FPU/SIMD instructions, as you don't want to save and restore the register file for the FPU/SIMD registers for the kernel code. It's just takes to much time. And there are other architectural execution penalty on some CPUs when using large SIMD instruction codes. We measured simple operating system functions, like page clear with SIMD, and it's just does not worth it even if we only use SIMD instructions in that function and save/restore only the necessary SIMD registers. Also heavy inter operation between low level assembly and higher level system code ( C ) are essential in kernel. You have to be able to handle the same structures in assembly and C without any misalignment and misaddressing. ( we use special macros to write down kernel structures, that are used in both assembly and C, all of the assembly files are C preprocessed) And there are other several issues with OS kernel codes (handling special registers, changing address spaces (virtual), invalidating/flushing caches (specially on ARM), managing any kind of exception (hard and soft, page fault, invalid instructions etc. ), real-time handling, kernel context handling if any, etc.).
- krizhanovsky 6y ago
  I still don't see any misconceptions. The reason why the kernel uses SIMD with FPU save/restore is to optimize context switches. We addressed the topic in https://netdevconf.info/0x12/session.html?kernel-tls-handshakes-for-https-ddos-mitigation https://netdevconf.info/0x12/session.html?kernel-tls-handsha... . I guess early versions of WireGuard used the same approach: save FPU context at the beginning of softirq, process may packets with SIMD in one shot, and restore FPU state. There are also other issues with the kernel code and I addressed them in the article, why it doesn't makes sense (while still possible) to use C++ in the kernel code.
ncmncm 6y ago
Almost everything the article says about the prospects for using C++ in an OS kernel is wrong. It is hard to understand how someone could know so many basic facts about the language and still be so thoroughly confused. None of the reasons cited for not using C++ in kernel code is valid. None of the things claimed to be impossible are. Example: RTTI. Really, RTTI is hardly ever used in good code. (I used in once in 10 years.) Despite its low use-value, nothing interferes with using it in a kernel. Name mangling is absolutely no problem; neither would using `extern "C"`, if you wanted to. Operator new is wholly compatible with kernel allocators. The Standard Library does have read-write locks, although it is usually foolish to use such a lock in real code. It is trivial to wrap any synchronization primitive you like with a zero-overhead abstraction. Kernels tend to have their own anyway. Exceptions in kernel threads would work identically the same as in user-level threads. Static ctor sections could be run by kernel startup code as easily as they are run in regular programs. (Probably one would not bother running static dtor sections.) I could go on and on, but enough. This article joins others packed to the brim with out-and-out falsehoods. When you need to rally so many falsehoods to make your case, you end up making the opposite case--except where your audience is easily fooled.
- krizhanovsky 6y ago
  Please read the discussion in https://www.reddit.com/r/Cplusplus/comments/jjtn5v/fast_programming_languages_c_c_rust_and_assembly/ https://www.reddit.com/r/Cplusplus/comments/jjtn5v/fast_prog... . In short, everything is doable, but before starting your project, which you're paid for, you have to grow quite a large C++ infrastructure, which double the native Linux kernel API in many ways. > Operator new is wholly compatible with kernel allocators. Please read the referenced thread. The things aren't so simple.
  - ncmncm 6y ago
    People coding OS kernels don't ask for simple. They should demand powerful, but too often fail to.
  - ncmncm 6y ago
    OK, I have read it. The Linux kernel is a large system. Things needed to work in Linux are not unusual for customizations needed for any large system, that we do routinely. If you think this is a problem, it can only be from lack of experience of large C++ systems. When people complain about the complexity of C++, it is generally because they have no experience of large systems that demand all kinds of specializations. C++ can be used in a simple way to write simple programs, and then you get to ignore all the knobs and switches. It can also be used in all varieties of specialized environments, and then you find knob and switch settings to make it work for that environment.
ph2082 6y ago
> Not only Rust is immature, but it seems the language designers intentionally limited the language. I am learning rust but what criteria any language must meet to call itself mature?
ezekiel68 6y ago
Thinly veiled slashvertizement by software services company stirs up conflict among programmer communities to raise awareness. News at 11.

102 points by krizhanovsky 6y ago

This was pretty heavily discussed on /r/programming a few days ago https://www.reddit.com/r/programming/comments/jjtobp/fast_programming_languages_c_c_rust_and_assembly/ https://www.reddit.com/r/programming/comments/jjtobp/fast_pr...

AlchemistCamp 6y ago
Thank you!
jeff-davis 6y ago
That thread brings up per-container memory allocators, and mentions Vec. What's going on there? I have been trying to find a good way to deal with hybrid memory/disk structures. One example is external sort, but there are a whole class of such structures used for databases (Hash Join, Hash Aggregation, etc.). The idea is to constrain the memory footprint of a structure and efficiently use the disk. One challenge is simlly knowing how much memory is being used. Another is supporting multiple heaps/arenas/whatever and allocating in the right one. And a third is safely clearing parts of the structure that have been written to disk for later processing (I guess calling the destructors if necessary?). Is there any work in this area?
- CyberDildonics 6y ago
  Wouldn't memory mapping take care of a lot of these scenarios? The OS will do all the caching. If you make a data structure that is meant to use one contiguous chunk of memory and access memory linearly and/or with locality when possible, I would think it would make explicit disk/hybrid scenarios much less necessary.
  - jeff-davis 6y ago
    Consider a hash table. Access is basically random, so if 25% fits in memory and 75% is paged-out at any given time, then 75% of the lookups will be a page fault and require a page-in. Very costly. Compare that to a Grace HashJoin (https://en.m.wikipedia.org/wiki/Hash_join https://en.m.wikipedia.org/wiki/Hash_join) which partitions both sides (lookup side and hash table side) into matching partition pairs. The partitioning step and reading the partitions from disk are both sequential access. Then, pick up and process one pair of partitions at a time, which will only require a small hash table in memory. Note that this is still way more efficient even when on an SSD, because an SSD is still block-oriented, and paging entire blocks in/out for a single lookup is still inefficient. It even helps when the data fits into memory sometimes, because you can size the partitions small enough to fit in cache, which will make lookups even faster. You can say "don't use hash tables", but that's not a great amswer for a low-level high-performance language like Rust.
    - CyberDildonics 6y ago
      I would never say "don't use hash table" but I do think that a lot of the benefits from special data structures like these are more due to the organization of memory than being explicit about memory loading and disk writing. In this case it seems like the downsides you mentioned are the downsides of keeping things on disk, not memory mapping (which would only hit the disk on the first load and would automatically use any available memory). Organization to use disk pages effectively would benefit memory mapping as well.
      - jeff-davis 6y ago
        But to organize memory you need some idea of how much you are using (e.g. how big the in-memory hash table is), and be able to free it in a reasonable pattern (e.g. deallocate the whole heap/arena at once). Both things are difficult in rust currently, and memory mapping doesn't help with either. Memory mapping serves a similar purpose as temp files: a way to tell the OS that it can freely page that out to avoid uncontrolled swapping. But you need to do the organization yourself to keep that access sequential, which is hard to do in rust for the reasons that I mentioned. If you memory map a hash table and have memory pressure, you'll go into the crazy bad scenario of a page-in for every lookup, which is avoidable with better organization. I think we are basically in agreement but perhaps my point was not clear.
- steveklabnik 6y ago
  > What's going on there? Box and Vec are starting to gain the ability to be parameterized over an allocator. > Is there any work in this area? Kind of, but it's slow going. You can support multiple heaps/arenas/whatever, but it means you have to implement your own. As the ecosystem standardizes around the allocator traits (only the global one is stable yet), there will be easier interop.
- aw1621107 6y ago
  > That thread brings up per-container memory allocators, and mentions Vec. What's going on there? I believe they're talking about custom allocator support for Box [0, 1]. The author of the PR says that they intend to add per-container allocator support once support for Box lands, starting with Vec [2]. [0]: https://www.reddit.com/r/rust/comments/jgxgpu/box_will_have_custom_allocator_support_soon_tm/ https://www.reddit.com/r/rust/comments/jgxgpu/box_will_have_... [1]: https://github.com/rust-lang/rust/pull/77187 https://github.com/rust-lang/rust/pull/77187 [2]: https://www.reddit.com/r/rust/comments/jgxgpu/box_will_have_custom_allocator_support_soon_tm/g9turat/ https://www.reddit.com/r/rust/comments/jgxgpu/box_will_have_...

zamalek 6y ago

> Rust doesn't provide stack allocations at all. What? Rust allocates on the stack by default.

mbrubeck 6y ago
It means dynamically-sized stack allocations, e.g. `alloca`.
akiselev 6y ago
He's talking about variable length arrays, which would be an unsized type in Rust and thus can't be stack allocated. For example, the following is valid C99: `void foo(int n) { int values[n]; }` I don't know that that's a bad thing. AFAIK the implementation details are underspecified even in C and compilers kind of do whatever they want (i.e. I've seen some embedded compilers that monomorphize it in multiples of 2 up to a limit and just hope the user doesn't exhaust the stack). Edit: I'm pretty sure you can create a hacky version using iterators and a recursive function: `fn vla<T>(iter: impl Iter<Item=T>, init: T, index: usize, count: usize) { ... }` Edit2: Actually he's talking about `alloca` which is a whole other "here be dragons" feature. See the reddit thread steveklabnik linked for some of the pitfalls
- masklinn 6y ago
  > Edit2: Actually he's talking about `alloca` which is a whole other "here be dragons" feature. See the reddit thread steveklabnik linked for some of the pitfalls AFAIK VLA is already that, didn't Linux de-VLA the kernel a few years back because they were a common security issue and the code they generate is bad / slow?
  - gpderetta 6y ago
    At least in gcc, vla and alloca prevent inlining.
- vvanders 6y ago
  Even then last I looked C++ doesn't have it either, it's exclusively a C99 feature. For me the downsides outweigh the upsides of alloca and I usually find other approaches(free list, arenas, etc).

identity0 6y ago

> Secondly, the killing feature of C++ is that it is C. If you don't want to use exceptions or RTTI, then you can just switch the features off. Most of C programs can be just compiled with a C++ compiler with very small changes or without any changes at all. If your C code happens to be compileable with a C++ compiler, then either your program is very small or you are writing really shitty C.

dathinab 6y ago
Idk about "shitty C" but indeed C++ being a super set of C is a common misconception, followed by the misconception that it's nearly a superset of C. ;=) Simplest example is that a `void func()` decl in C and C++ have different semantic meanings.
- simias 6y ago
  I think "nearly a superset" is correct, the empty argument list doesn't really make enough of a difference to really make it a completely different language. I also don't think I've ever seen this "feature" of C used productively in modern codebases, except maybe to declare generic function pointers in something like dlfunc. In general it's just that people are too lazy to type `void func(void)` (or don't know the difference). You can also tell that the C++ standard committee agrees with this to some extent since they tend to add C novelties into the C++ standards whenever possible to make it easier to write compatible code, for instance: https://en.wikipedia.org/wiki/C%2B%2B11#Improved_C_compatibility https://en.wikipedia.org/wiki/C%2B%2B11#Improved_C_compatibi...
  - Gibbon1 6y ago
    I feel like treating C as a subset of C++ has done real harm to the language.
    - rrdharan 6y ago
      Which one?

pizza234 6y ago

> It's also worth mentioning that the memory garbage collection (GC) in Java leads to high tail latencies and it's hard or even impossible to do anything with the problem This is amusing, because a few days ago, there was an article¹ reporting that the C4 garbage collector solved this problem. ¹=https://news.ycombinator.com/item?id=24895395 https://news.ycombinator.com/item?id=24895395

vips7L 6y ago
Hopefully ZGC will solve this in HotSpot so no one has to rely on a custom jvm.
ncmncm 6y ago
People can report anything. Solutions to pervasive, debilitating GC problems are as perennial as the Spring rain. Every year, we get a new crop, but the problems are still there the year after.

speedgoose 6y ago

> There are a lot of poor programs misusing goto, so they just removed the operator: good for juniors, but too limited for professionals. It's a bit condescending. I think the article would have been better without that kind of comment.

virgilp 6y ago
Yeah, I caught that too; it's more than a bit condescending and is also completely false. Complexity makes all people trip up, not just "juniors".
- deleted 6y ago
  [deleted]
tornato7 6y ago
Especially because a "professional" programmer should be able to get along just fine without goto. Goto is bad practice in many languages where it does exist, too, like Go.
- deleted 6y ago
  [deleted]
- berkut 6y ago
  How do you break out of nested loops without an extra variable set/check to break on in the outer one otherwise? goto is nasty, but in my experience writing HPC code, it does have some uses that can't be solved as efficiently (i.e. without extra branching) otherwise in some situations.
  - tomjakubowski 6y ago
    Rust has special syntax to name loops, and to refer to them by name when breaking. 'foo: loop { 'bar: loop { break 'foo } }
    - 6y ago

vvanders 6y ago

I've written my share of systems level C++ in performance constrained environments professionally (gamedev, embedded systems). Never touched goto, alloca and branching usually stayed out of hot code through DOD approaches. Not really sure I agree with the conclusion. Alternatively they didn't talk at all about aliasing/restrict which is one really neat area of Rust because &mut guarantees one of the key aliasing constraints.

creata 6y ago
Isn't it still unable to actually make those aliasing optimizations because LLVM doesn't compile them correctly? https://github.com/rust-lang/rust/issues/54878 https://github.com/rust-lang/rust/issues/54878
klyrs 6y ago
I've used goto a handful of times over my 20 year professional history with c and c++. A few were used for simplifying cleanup code (actually this is quite common in c, less so in c++); a few were used in weird state machines and were accompanied by a page of documentation.

andy_ppp 6y ago

Won’t rust continue to get faster? And does it matter much given the speed of hardware these days, I mean O(n) will still be the same.

deleted 6y ago
[deleted]
kzrdude 6y ago
Why shouldn't C++ continue to get faster, too?
ncmncm 6y ago
In principle, Rust could get faster if optimizers took advantage of latitude enabled by stronger semantic guarantees. In practice, turning on such optimizations introduces debilitating bugs, because the optimizations are poorly exercised by other languages, and Rust core developers are fully occupied with other problems. O(n) is the starting point of optimization. Improvement by factors of two or ten are commonplace, relying on details of how modern machines are implemented, and often lately by farming work out to multiple cores or to GPU cores. Speed of the code is getting increasingly important as memory and storage sizes grow while clock speed stubbornly does not. Until Dennard scaling died, code got faster just by waiting. Now, making code faster takes work.

simias 6y ago

>The Rust's generics and macros are much weaker than provided by C++ templates coupled with C macros. Although, this is also not so crucial. That's a very strange way to put it IMO, I'm not sure what is meant by "weaker" here. They are stricter and as such can require more work to use effectively, but weaker is a weird way to put it.

wtetzner 6y ago
I would say Rust macros are considerably stronger, given it supports procedural macros.
steveklabnik 6y ago
I think that the way they mean is that there are less restrictions, which means you can do more with them, which makes them more powerful, in a sense. Words are hard.
Karliss 6y ago
C++ template provides features that rust generics don't. I am not a Rust developer so correct me of some of these have been recently added. Rust generics being stricter would be something like them allowing to use only methods provided by trait, but I would call all of following design limitations making rust generics weaker. * passing integer as template argument - from what I understand some of rust standard library functions can't handle arrays with more than 64 or 32 elements due to this or something similar. And there is active work for adding const generics to rust. * variadic templates - there is a RFC for this * passing template as template argument * template specialization - C++ is somewhat moving away from this
- steveklabnik 6y ago
  The first point has had its restriction lifted as of the current version of Rust, 1.47.0. Or rather, the standard library and arrays bit is fixed; the underlying feature is not in stable Rust, and so other libraries still can't make this work properly yet. Variadrics are desired by some folks, but aren't a particularly high priority. Template template parameters are unlikely to land directly in Rust; GATs will be roughly equivalent. And specialization has a nightly implementation, and is highly desired, but isn't done yet.

Subsentient 6y ago

Just occurred to me, since Rust has LLVM IR asm directives, can't you write a portable goto in an inline function that jumps directly to pointers? Publish that crate to crates.io? Problem solved.

steveklabnik 6y ago
Rust stable still does not have inline assembly. Additionally, we have moved away from the "whatever LLVM does" feature, and built our own. There are significant language issues with doing something like this. Yes, in theory, you could do something. But it's going to be very unsafe, and very error prone.
- Subsentient 6y ago
  I do see that the LLVM IR thing isn't being used anymore. I hope asm! ends up in stable Rust soon, seems like a pretty big oversight. Then again, MSVC dropped inline ASM altogether, which seems really dumb. One of these days I'm going to write a crate that easily enables doing all the unsafe, dangerous, stupid things that C programmers want to do, including gotos, with no safety checks or variable lifespan verification of any kind. And I'm going to name it "evil". :^) I will do it, eventually. ^^
  - taxcoder 6y ago
    As long as you don't name it evil-mode.
tijsvd 6y ago
Just write your parser as a collection of functions that can use tail calls. You should end up with a similar structure, i.e. a block of code with jumps instead of calls. Even in C++ I'd prefer that over a goto-based system (unless generated).

virgilp 6y ago

> Thus, in this single case when a Rust implementation is more or less faster than C, the performance difference is not about better compiler, but about more efficient structure of the program, which allows a compiler to optimize code better. This is strange takeaway.... I would say that's almost the only thing that matters. They compared one Rust compiler to 3 C++ compilers and picked the best result? Who does that in practice - who compiles their codebase with 3 different compilers and picks the most efficient one for each object file? Also, the compiler can often improve, where as the language itself is much more difficult to improve - the fact that the language lets you to write a more efficient (and more readable!) structure is crucial. Also, they seem to misunderstand the point of Rust entirely. The main point of Rust is "safety" (w/o sacrificing performance, yes - but safety was the primary design goal). And for a good reason! Systems programming is more about safe systems than it is about fast systems - fast buggy system programs are useless. The authors decry the loss of goto saying it's "good for juniors but too limiting for professionals" - as if professionals aren't humans too! I'm sorry to say that, but whenever I saw that attitude before - it was with programmers that greatly overestimated their skill level.

jrimbault 6y ago
Strong upvote for : > The authors decry the loss of goto saying it's "good for juniors but too limiting for professionals" - as if professionals aren't humans too! I'm sorry to say that, but whenever I saw that attitude before - it was with programmers that greatly overestimated their skill level. The "I know how to use goto [replace with any feature] everyone else is just stupid" reasoning upsets me so much.
krizhanovsky 6y ago
While I addressed safety in a separate section in the article, I wouldn't argue about that: it seems Rust designers made the perfect work in safety. However, C++ is moving in this directly, bu there is the "gap" as it was described in the cited talk from the CppCon 2020. However, there article is about FAST programming languages. Which means, and I stated this explicitly at the beginning of the article, that the main factor for the article is the speed of the generated code. This is why I compared the single Rust implementation with 3 C/C++ implementations. The question was: whether Rust does something unreachable for C/C++? And the answer is "NOT". Also please keep in mind that all the benchmark programs, using the same algorithms, are still coded in bit different ways. And the differences impact performance significantly. I analyzed two programs, in Rust and C, to show the differences.

lr1970 6y ago

Too bad they did not try Nim [1]. IMHO, Nim is better than Rust for C/C++ expats. [1] https://nim-lang.org/ https://nim-lang.org/

vips7L 6y ago
Isn't nim garbage collected? That seems like a big no-op for the authors use cases.
- metasyn 6y ago
  It's optional (so you can turn it off if you'd like) https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html
  - vips7L 6y ago
    How do you manage memory then? Linking to libc and malloc/free?
    - lr1970 6y ago
      Yes, if you want to operate in "unsafe" mode you can manage memory yourself with pointers and malloc/free. But it is rarely needed in practice. Also, Nim compiles to C or C++ (and also to Javascript). Because of that Nim's C/C++ FFI is natural ans wrapper-free.
    - kupopuffs 6y ago
      --gc:arc. Plain reference counting with move semantic optimizations, offers a shared heap. It offers deterministic performance for hard realtime systems. Reference cycles cause memory leaks, beware. --gc:orc. Same as -gc:arc but adds a cycle collector based on "trial deletion". Unfortunately that makes its performance profile hard to reason about so it is less useful for hard realtime systems. --gc:none. No memory management strategy nor garbage collector. Allocated memory is simply never freed. You should use --gc:arc instead. Nim offers alloc, dealloc, allocShared, deallocShared

loeg 6y ago

Fact-check: > FreeBSD has been supporting C++ modules for a while. No, we don't. The link provided is to a user forum where someone asks about it, and the first response is "I don't believe that this is a good idea." I don't know why the author would just make up this false statement, but IMO it really hurts their credibility.

dllthomas 6y ago
The first response starts "I don't believe that this is a good idea", then makes some suggestions as to how to make it work anyway. There is plenty of room, at this point in consideration, for the thread to have reached a conclusion very different than that implied by the first sentence of the first comment. I read the whole thing. It doesn't.
- loeg 6y ago
  Sure. I also skimmed through more of the thread than the first comment; it just made a nice sound-bite. I happen to know TFA's sentence is bunk from first-hand experience with the FreeBSD kernel and C++ proposals, but wanted to show that even the linked forum post doesn't really support the author's claim.
krizhanovsky 6y ago
But did you? My FreeBSD knowledge is quite outdated, I believe the last version I worked with is 7, but I believe at some point, it was possible to compile C++ kernel modules for FreeBSD. This time I can not find the proof, but plus to that post I also found links like https://lists.freebsd.org/pipermail/freebsd-hackers/2009-February/027706.html https://lists.freebsd.org/pipermail/freebsd-hackers/2009-Feb... https://lists.freebsd.org/pipermail/freebsd-hackers/2006-July/017161.html https://lists.freebsd.org/pipermail/freebsd-hackers/2006-Jul... The last one mentions: "There's actually a fair amount of experience with people doing C++ in FreeBSD kernels. People have been doing things with it for about 8 years now."
- loeg 6y ago
  People have always played around with C++ kernel modules outside the project (e.g., https://github.com/adamlsd/libcpp.ko https://github.com/adamlsd/libcpp.ko ), but that is very different from saying the project supports C++ modules. There are no C++ kernel modules in FreeBSD itself. There is no support for C++ kernel modules in FreeBSD itself (neither build system nor source code). Developer response to C++ kernel proposals (the most recent on private internal mailing lists I cannot share) is cold.

ordu 6y ago

> A real high-level system programming language must be compatible with C. I cannot agree with this. After I learned rust and tried to mix it with C code I believe that Stroustrup made a mistake by making C++ compatible with C on a syntax level. Strictly defined FFI boundary is a good thing. It liberates. It allow to track precisely what boundary APIs are, it makes boundary APIs the separate documented thing. > An opposite example to use Rust for an Nginx module is CloudFlare's Quiche, an Nginx extension to support QUIC and HTTP/3 protocols. While it's definitely possible to use Rust for such kind of tasks, the guys, besides the FFI code for C/C++ bindings, still had to write some C code to patch Nginx. I took a look at the patch, and it is not clear to me, that the patch was needed because rust wouldn't allow to do it the other way. It seems that cloudflare split their code into rust and C for some other reason, because there is a LOT of C code, it doesn't seem to me as a glue code at all. I believe it does more than just glue rust module and nginx. I'm not sure what the reason, but I could guess that the idea was to add possibility to use different implementations of QUIC and HTTP/3 in nginx, not just this particular rust implementation. So they extended nginx for this, and then implemented rust module.

vips7L 6y ago
I like zig's compatibility with C. You can directly import C headers and the compiler will generate headers for your zig code as well.
- xedrac 6y ago
  I think Zig will make a great C replacement eventually. I pick it over C any day of the week. But I'd prefer Rust over either of them. Zig's management of heap-allocated memory is very similar to C, which makes it less than ideal for large projects.
gpderetta 6y ago
if Stroupstrup hadn't made the mistake, today we wouldn't be talking about c++ in the first place.

dhanna 6y ago

> Golang can not be considered for high performance programming also due to the GC. People repeat this like Go isn’t designed for use in resource constrained environments.

bfrog 6y ago
I don't see Go running cortex-m level devices, atmega level devices. So no, it's really not.
- coder543 6y ago
  It seems you haven’t looked around. Go runs on both Cortex-M and AVR: https://tinygo.org/ https://tinygo.org/ AVR support is more of a work in progress than the Cortex-M support, but it does exist.
  - bfrog 6y ago
    Neat!
kupopuffs 6y ago
Performance requirements have a huuuuuuuuuge range and Go can't really be considered for extreme cases. Like the latest, hottest, prettiest video gamez in VR HDR 8K resolution
Daishiman 6y ago
"resource constrained" is a very subjective interpretation. OP is talking about SIMD intrinsics and compiler micro optimizations. Go is definitely out.

timClicks 6y ago

Rust would be compelling even if it didn't offer comparable performance to C. Its safety guarantees mean that much easier for "mediocre" programmers to feel like they can contribute meaningfully to large codebases without introducing massive memory leaks/unsound behavior/...

legulere 6y ago

Exception epilogues also make optimization harder/impossible for compilers if I remember correctly. Rust suffers from this too though because panics use the same mechanism.

matklad 6y ago

This is an exceptionally great article, which indeed discusses strong Rust limitations. I have one question: the parser in the article uses computed goto, which, as far as I know, is not standard C. Are there many cases where even the standard goto yields significantly better performance?

ncmncm 6y ago
This is an exceptionally bad article, packed to the brim with unambiguous falsehoods. It is very unlikely that the computed gotos make the parser faster than using standard features of a more powerful language.
- alok-g 6y ago
  >> It is very unlikely that the computed gotos make the parser faster than using standard features of a more powerful language. Can you explain more on how? Use case I have in mind is bytecode interpretation where computed goto should be a big help.
  - ncmncm 6y ago
    Optimized tail calls are effectively the same as computed goto, but are a Standard feature. Or, rather, don't require non-standard syntax. A program that relies on the optimization built by a compiler that failed to implement it--which is allowed--would not be expected to run well. https://github.com/ncm/computed-goto https://github.com/ncm/computed-goto The "more powerful language" part is to get language-level tools to compose parser combinators, ultimately resolving down to tail calls.
    - krizhanovsky 6y ago
      The benchmarks https://github.com/ncm/computed-goto/blob/master/benchmarks/trivial.cpp https://github.com/ncm/computed-goto/blob/master/benchmarks/... benchmark is not applicable to this discussion because it compares _too_ small state machines. I reference my talk and presentation once more: http://www.tempesta-tech.com/research/http_str.pdf http://www.tempesta-tech.com/research/http_str.pdf - slide 23 discusses that the goto FSM makes sense for _hundreds_ of states.

andy_threos_io 6y ago

The article brings up some good points, but there are several misconception. You can't compare normal user program execution with operating system kernel code execution. Total different beasts. There are reasons, that most operating system kernels are written in C and assembly. And also there is a reason why kernel code seldom use any FPU or SIMD instructions beside saving and restoring the FPU and SIMD context on context switch for user threads. ( The size of the SIMD registers in byte x86_64 SSE (256) x86_64 AVX (512) x86_64 AVX-512 (2048)) Ex. You don't want your interrupt server code use any FPU/SIMD instructions, as you don't want to save and restore the register file for the FPU/SIMD registers for the kernel code. It's just takes to much time. And there are other architectural execution penalty on some CPUs when using large SIMD instruction codes. We measured simple operating system functions, like page clear with SIMD, and it's just does not worth it even if we only use SIMD instructions in that function and save/restore only the necessary SIMD registers. Also heavy inter operation between low level assembly and higher level system code ( C ) are essential in kernel. You have to be able to handle the same structures in assembly and C without any misalignment and misaddressing. ( we use special macros to write down kernel structures, that are used in both assembly and C, all of the assembly files are C preprocessed) And there are other several issues with OS kernel codes (handling special registers, changing address spaces (virtual), invalidating/flushing caches (specially on ARM), managing any kind of exception (hard and soft, page fault, invalid instructions etc. ), real-time handling, kernel context handling if any, etc.).

krizhanovsky 6y ago
I still don't see any misconceptions. The reason why the kernel uses SIMD with FPU save/restore is to optimize context switches. We addressed the topic in https://netdevconf.info/0x12/session.html?kernel-tls-handshakes-for-https-ddos-mitigation https://netdevconf.info/0x12/session.html?kernel-tls-handsha... . I guess early versions of WireGuard used the same approach: save FPU context at the beginning of softirq, process may packets with SIMD in one shot, and restore FPU state. There are also other issues with the kernel code and I addressed them in the article, why it doesn't makes sense (while still possible) to use C++ in the kernel code.

ncmncm 6y ago

Almost everything the article says about the prospects for using C++ in an OS kernel is wrong. It is hard to understand how someone could know so many basic facts about the language and still be so thoroughly confused. None of the reasons cited for not using C++ in kernel code is valid. None of the things claimed to be impossible are. Example: RTTI. Really, RTTI is hardly ever used in good code. (I used in once in 10 years.) Despite its low use-value, nothing interferes with using it in a kernel. Name mangling is absolutely no problem; neither would using `extern "C"`, if you wanted to. Operator new is wholly compatible with kernel allocators. The Standard Library does have read-write locks, although it is usually foolish to use such a lock in real code. It is trivial to wrap any synchronization primitive you like with a zero-overhead abstraction. Kernels tend to have their own anyway. Exceptions in kernel threads would work identically the same as in user-level threads. Static ctor sections could be run by kernel startup code as easily as they are run in regular programs. (Probably one would not bother running static dtor sections.) I could go on and on, but enough. This article joins others packed to the brim with out-and-out falsehoods. When you need to rally so many falsehoods to make your case, you end up making the opposite case--except where your audience is easily fooled.

krizhanovsky 6y ago
Please read the discussion in https://www.reddit.com/r/Cplusplus/comments/jjtn5v/fast_programming_languages_c_c_rust_and_assembly/ https://www.reddit.com/r/Cplusplus/comments/jjtn5v/fast_prog... . In short, everything is doable, but before starting your project, which you're paid for, you have to grow quite a large C++ infrastructure, which double the native Linux kernel API in many ways. > Operator new is wholly compatible with kernel allocators. Please read the referenced thread. The things aren't so simple.
- ncmncm 6y ago
  People coding OS kernels don't ask for simple. They should demand powerful, but too often fail to.
- ncmncm 6y ago
  OK, I have read it. The Linux kernel is a large system. Things needed to work in Linux are not unusual for customizations needed for any large system, that we do routinely. If you think this is a problem, it can only be from lack of experience of large C++ systems. When people complain about the complexity of C++, it is generally because they have no experience of large systems that demand all kinds of specializations. C++ can be used in a simple way to write simple programs, and then you get to ignore all the knobs and switches. It can also be used in all varieties of specialized environments, and then you find knob and switch settings to make it work for that environment.

ph2082 6y ago

> Not only Rust is immature, but it seems the language designers intentionally limited the language. I am learning rust but what criteria any language must meet to call itself mature?

ezekiel68 6y ago

Thinly veiled slashvertizement by software services company stirs up conflict among programmer communities to raise awareness. News at 11.