5 ms·

The reason that C programs often perform well is that it’s so incredibly hard to do anything at all in C (especially something reliable) that one can usually on

The reason that C programs often perform well is that it’s so incredibly hard to do anything at all in C (especially something reliable) that one can usually only do the simplest thing possible and this typically means simple data structures, simple algorithms and arrays. In many ways, modern CPUs are particularly designed to run the machine code generated by C compilers on typical C code like this. Pointers and memory allocation are often painful or fickle so use of pointer-heavy data structures like linked lists is quite uncommon. The reason that C programs often don’t perform as well as an equivalent rust program[1] is that it’s so incredibly hard to do anything at all in C (especially something reliable) that one can usually only do the simplest thing possible and this typically means simple data structures, simple algorithms and arrays [1] suppose the programs are independently created at the same time by programmers of equal ability and are idiomatic in their languages. If a C program is rewritten in rust, it is likely to be faster, but that would likely also be true if it were rewritten in C.

littlestymaar 6y ago
> The reason that C programs often don’t perform as well as an equivalent rust program[1] is that it’s so incredibly hard to do anything at all in C (especially something reliable) that one can usually only do the simplest thing possible and this typically means simple data structures, simple algorithms and arrays Brian Cantrill talks[1] about exactly this: in his C version he was using AVL trees because they are easy to implement, while his Rust version was using B-trees just because he could. And as a result, his naive first attempt in Rust outperformed his long-optimized C code. [1]: https://www.youtube.com/watch?v=HgtRAbE1nBM&t=43m15s https://www.youtube.com/watch?v=HgtRAbE1nBM&t=43m15s
- deleted 6y ago
  [deleted]
- jstimpfle 6y ago
  So he's comparing the AVL tree he wrote himself to a B-tree optimized to death by someone else? Out of interest though, does he mention somewhere which actual implementation he used?
  - aldonius 6y ago
    Yes, and I suppose that's some of the point: a performant library ecosystem is one hell of a feature.
    - jstimpfle 6y ago
      It sure must be a nice feature - for fast results. Counterpoint, though. I barely used Rust, but when I wanted to play with the Xi editor I got to see the bad places that buying into such an ecosystem can get you to - places formerly pioneered by NPM. I had to download 100s of packages, (IIRC?) there were some build problems, all for something where I don't really see the value of noteworthy dependencies. If you really need a Btree (like, if you want to make a fair benchmark for a presentation) then you'll absolutely find a reasonable implementation in C. After all, why would you need dependency management for something that should have 0 dependencies? As an example of library data structures implemented in C - if you want, check out my Red-black tree (not a Btree): https://github.com/jstimpfle/rb3ptr/blob/master/rb3ptr.h https://github.com/jstimpfle/rb3ptr/blob/master/rb3ptr.h . It's really easy to integrate into your project. I think the API (found in rb3ptr.h) is totally usable, and it might also be faster than what you can get with safe Rust - unless you can easily use intrinsically linked data structures in safe Rust.
blackrock 6y ago
Fascinating. I would’ve thought most commercial C programs would have heavily used linked lists, hashes (dictionary), and binary search trees all over the place. I assume most C++ programs heavily use more of these advanced data structures, correct?
- wink 6y ago
  You can't really compare C with a C++ stdlib or boost, or Qt. Well, some organizations surely have their own repo of debugged, tested, and optimized stuff but I guess a lot of them roll everything on their own again and again - and in C++ there is a rich ecosystem, at least for basic data structures.
  - RcouF1uZ4gsC 6y ago
    The other thing that C++ and Rust have for collections and algorithms is that they follow a standard pattern. Because of that, it is usually pretty easy to substitute an optimized algorithm or a container for another one with minimal code changes. In C, because there is no standard for how to do containers and algorithms, it is likely that every library does something a little different in terms of conventions making it harder to swap in implementations.
- Skunkleton 6y ago
  > I would’ve thought most commercial C programs would have heavily used linked lists, hashes (dictionary), and binary search trees all over the place. Every large scale C code base I have worked on has had these things, and they were used as you say all over the place. If I were to encounter a code base that didn't have these things I would wonder why it was written in C in the first place.
  - Leherenn 6y ago
    Conversely, I have only seen arrays being used, and never linked lists/hash maps in the few embedded code bases I have worked on.
typedef_union 6y ago
>The reason that C programs often don’t perform as well as an equivalent rust program[1] is that it’s so incredibly hard to do anything at all in C (especially something reliable) that one can usually only do the simplest thing possible and this typically means simple data structures, simple algorithms and arrays Reliability is very often the name of the game with C, and part of the reason you might see it written in such a simplistic fashion. In embedded systems, we often follow very strict code convention that has strict requirements on how a C program is to be written. This includes everything from how memory is to be allocated, the maximum number of local variables, the maximum number of the arguments, various limits on a function, constraints to handle errors, etc. We do this because it minimizes potential hazards especially when working with limited memory and system resources. C is an unforgiving language in that mistakes can occur silently and on mission critical hardware these mistakes can cost more than just your project milestones. These programs are very specialized and often have complex algorithms associated with them. Most of the systems I've worked with include various kinds of feedback control systems, and accompanying algorithms. If you're familiar with control systems, you'll know these algorithms are certainly not trivial by any means. The challenge with C is more as a developer your C code needs to be perfect. Bugs just aren't an option like they are in other environments. Once a specialized piece of hardware ships it needs to work as intended under a myriad of conditions without powering off for the next 30 years (not always the case but more often than you might think). Sometimes this kind of software is going to be put a position it may have never been designed for. The best we can do is try to add various check/support mechanisms both in software and in hardware, and maintain as safe and hazard free software as possible. In terms of performance, again coming from an embedded environment, there is almost always a spec we are aiming for. It needs to do X tasks in N time for example. Of course high level design questions like whether to poll or wait for interrupt, or how to broker data from shared resources is decided long before you get to the question of how should I, or if I even should, compare two strings. It is nevertheless advised to go with a trivial solution if the ends satisfy the needs. Is C time-consuming to write? Is C a "hard" language? These are subjective and depend on the nature of the project. I would certainly never use C with only libc to write a webserver that's going to be serving SaaS Co's backend API.
- pjmlp 6y ago
deleted 6y ago
[deleted]
jcdentonunatco 6y ago
It's amazing that you could write this much and have it be 100% wrong.
- latexr 6y ago
  From the guidelines[1]: > Be kind. Don't be snarky. > (…) > When disagreeing, please reply to the argument instead of calling names. > (…) > Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something. You’re being downvoted because your comment doesn’t add to the discussion. You’re (rudely) telling the parent poster they are wrong while providing no basis for the assertion. [1]: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

littlestymaar 6y ago

deleted 6y ago
[deleted]
jstimpfle 6y ago
So he's comparing the AVL tree he wrote himself to a B-tree optimized to death by someone else? Out of interest though, does he mention somewhere which actual implementation he used?
- aldonius 6y ago
  Yes, and I suppose that's some of the point: a performant library ecosystem is one hell of a feature.
  - jstimpfle 6y ago
    It sure must be a nice feature - for fast results. Counterpoint, though. I barely used Rust, but when I wanted to play with the Xi editor I got to see the bad places that buying into such an ecosystem can get you to - places formerly pioneered by NPM. I had to download 100s of packages, (IIRC?) there were some build problems, all for something where I don't really see the value of noteworthy dependencies. If you really need a Btree (like, if you want to make a fair benchmark for a presentation) then you'll absolutely find a reasonable implementation in C. After all, why would you need dependency management for something that should have 0 dependencies? As an example of library data structures implemented in C - if you want, check out my Red-black tree (not a Btree): https://github.com/jstimpfle/rb3ptr/blob/master/rb3ptr.h https://github.com/jstimpfle/rb3ptr/blob/master/rb3ptr.h . It's really easy to integrate into your project. I think the API (found in rb3ptr.h) is totally usable, and it might also be faster than what you can get with safe Rust - unless you can easily use intrinsically linked data structures in safe Rust.

blackrock 6y ago

Fascinating. I would’ve thought most commercial C programs would have heavily used linked lists, hashes (dictionary), and binary search trees all over the place. I assume most C++ programs heavily use more of these advanced data structures, correct?

wink 6y ago
You can't really compare C with a C++ stdlib or boost, or Qt. Well, some organizations surely have their own repo of debugged, tested, and optimized stuff but I guess a lot of them roll everything on their own again and again - and in C++ there is a rich ecosystem, at least for basic data structures.
- RcouF1uZ4gsC 6y ago
  The other thing that C++ and Rust have for collections and algorithms is that they follow a standard pattern. Because of that, it is usually pretty easy to substitute an optimized algorithm or a container for another one with minimal code changes. In C, because there is no standard for how to do containers and algorithms, it is likely that every library does something a little different in terms of conventions making it harder to swap in implementations.
Skunkleton 6y ago
> I would’ve thought most commercial C programs would have heavily used linked lists, hashes (dictionary), and binary search trees all over the place. Every large scale C code base I have worked on has had these things, and they were used as you say all over the place. If I were to encounter a code base that didn't have these things I would wonder why it was written in C in the first place.
- Leherenn 6y ago
  Conversely, I have only seen arrays being used, and never linked lists/hash maps in the few embedded code bases I have worked on.

typedef_union 6y ago

>The reason that C programs often don’t perform as well as an equivalent rust program[1] is that it’s so incredibly hard to do anything at all in C (especially something reliable) that one can usually only do the simplest thing possible and this typically means simple data structures, simple algorithms and arrays Reliability is very often the name of the game with C, and part of the reason you might see it written in such a simplistic fashion. In embedded systems, we often follow very strict code convention that has strict requirements on how a C program is to be written. This includes everything from how memory is to be allocated, the maximum number of local variables, the maximum number of the arguments, various limits on a function, constraints to handle errors, etc. We do this because it minimizes potential hazards especially when working with limited memory and system resources. C is an unforgiving language in that mistakes can occur silently and on mission critical hardware these mistakes can cost more than just your project milestones. These programs are very specialized and often have complex algorithms associated with them. Most of the systems I've worked with include various kinds of feedback control systems, and accompanying algorithms. If you're familiar with control systems, you'll know these algorithms are certainly not trivial by any means. The challenge with C is more as a developer your C code needs to be perfect. Bugs just aren't an option like they are in other environments. Once a specialized piece of hardware ships it needs to work as intended under a myriad of conditions without powering off for the next 30 years (not always the case but more often than you might think). Sometimes this kind of software is going to be put a position it may have never been designed for. The best we can do is try to add various check/support mechanisms both in software and in hardware, and maintain as safe and hazard free software as possible. In terms of performance, again coming from an embedded environment, there is almost always a spec we are aiming for. It needs to do X tasks in N time for example. Of course high level design questions like whether to poll or wait for interrupt, or how to broker data from shared resources is decided long before you get to the question of how should I, or if I even should, compare two strings. It is nevertheless advised to go with a trivial solution if the ends satisfy the needs. Is C time-consuming to write? Is C a "hard" language? These are subjective and depend on the nature of the project. I would certainly never use C with only libc to write a webserver that's going to be serving SaaS Co's backend API.

pjmlp 6y ago

deleted 6y ago

[deleted]

jcdentonunatco 6y ago

It's amazing that you could write this much and have it be 100% wrong.

latexr 6y ago
From the guidelines[1]: > Be kind. Don't be snarky. > (…) > When disagreeing, please reply to the argument instead of calling names. > (…) > Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something. You’re being downvoted because your comment doesn’t add to the discussion. You’re (rudely) telling the parent poster they are wrong while providing no basis for the assertion. [1]: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html