I know it's a meme, but it really does seem like most C or C++ code would be better off transitioning to Rust at some point. That includes the entire Linux kernel, web browsers, entire OS's...
Rust is now overall faster than C in benchmarks
151–160 of 445 posts
Re: Rust is now overall faster than C in benchmarks
#152Earlier quoted context omitted.
Also lack of generics can make it slow, e.g. qsort() requires a function call for each comparison. So C++'s std::sort() can be significantly faster on an array of integers.
It's more to do with the fact that std::sort's definition is visible to the compiler and qsort() is not. Put qsort() code in stdlib.h, make it static and write a static intcmp() and you'll see the compiler inline that no problem.
I've done this a few times using http://www.corpit.ru/mjt/qsort.html
Re: Rust is now overall faster than C in benchmarks
#153Apart from those benchmark games a lot of real world C is a lot less performant than people think it might be. I spent a fair amount of time reviewing C code in the last 5 years - and things that pop up in nearly every review are costly string operations. Linear counts due to the use of null terminated strings and extra allocations for substrings to attach null terminators, or just deep copies because ownership can’t…
Mostly agree with your comment but linear search through arrays of size less than a few hundred will typically beat more sophisticated structures such as red-black trees or hashtables. This is due to prefetching and avoidance of unpredictable pointer traversals. Asymptotic complexity is only that: asymptotic. In many programs in many domains the sizes of these data structures will rarely exceed this limit.
It might be fast, but it'll load CPU caches with that data and it'll evict another useful data. Which means that while this particular code will be fast or at least not very slow, some other code will be slow because its data have to be fetched again.
I have no idea whether that matters or even easy to measure...
Re: Rust is now overall faster than C in benchmarks
#154It struck me a while ago that the most powerful feature of rust is the strong contracts libraries can and must express. This allows people with much deeper knowledge than me to make awesome stuff I can depend on.
Re: Rust is now overall faster than C in benchmarks
#155Looking at the reverse-complement code, it appears that the Rust and C implementations are using different algorithms: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... On a quick inspection: - The Rust code is about twice as long. - The Rust code has CPU feature detection and SSE intrinsics, while the C code is more idiomatic. - The lookup…
cpu feature detection is way easier in rust. its just built into the core libs.
And?
These are the kind of things that make working in one language different from another.
I'd actually like to see the SSE version in C so I can compare the two implementations and how much grief you have to go through.
Re: Rust is now overall faster than C in benchmarks
#156Earlier quoted context omitted.
comparing apples to apples is pointless, they are both apples. and you can always compare “equivalent” algorithms as some languages may not be able to efficiently express the same algorithm as another. i know what you are after, but trying to have some benchmark that is “fair” according to some spec that is important to your needs will just be seen as pointless to others. benchmark game at least lets us see what the…
I admit I'm destroying the metaphor here but there are a lot of useful comparisons to be made between different cultivars of apple and those comparisons have implications on their applications.
That's the whole point of the metaphor - comparing apples to apples is good, apples to oranges is bad.
Re: Rust is now overall faster than C in benchmarks
#157Earlier quoted context omitted.
> C compilers have to assume that pointers to memory locations can overlap, unless you mark them __restrict... What I don't fully understand is: "GCC has the option -fstrict-aliasing which enables aliasing optimizations globally and expects you to ensure that nothing gets illegally aliased. This optimization is enabled for -O2 and -O3 I believe." (source: https://stackoverflow.com/a/7298596 ) Doesn't this mean that C…
Not for char. Compiler always assumes non-restrict for char pointers and arrays, which is important to remember if you're ever operating on a RGB or YCbCr matrix or something.
Huh.
Does that also hold for a "uint8_t"--which is often just a renamed unsigned char rather than being a genuine type of its own?
Re: Rust is now overall faster than C in benchmarks
#158Apart from those benchmark games a lot of real world C is a lot less performant than people think it might be. I spent a fair amount of time reviewing C code in the last 5 years - and things that pop up in nearly every review are costly string operations. Linear counts due to the use of null terminated strings and extra allocations for substrings to attach null terminators, or just deep copies because ownership can’t…
> null terminated strings feel like idiomatic C to most people Doesn't that mean that null terminated strings is idiomatic C? That is, my understanding of the term idiomatic is that it is defined by whatever is most natural to users of a language regardless of whether it is the most performant.
Null terminated strings are often called cstrings. They’re beyond idiomatic; they’re part of the C standard library.
Re: Rust is now overall faster than C in benchmarks
#159Earlier quoted context omitted.
That kind of tit-for-tat in benchmarks seems like it's counter to the goal of benchmarks: what kind of performance could I expect to see using technology $FOO? Crucially, that question depends on how someone will realistically implement $FOO. I like PyPy as an example: on the surface, implementing a Python runtime in Python and expecting performance gains seems crazy. PyPy manages to outperform CPython because althou…
> I like PyPy as an example: on the surface, implementing a Python runtime in Python and expecting performance gains seems crazy. Not if it includes a JIT compiler, as PyPy does. I don't know much about PyPy, but if most of the time is spent in JITted machine code, the fact that it's written in Python may not affect performance much.
Kind of, PyPy is a metacircular JIT compiler, it uses RPython a Python subset.
Re: Rust is now overall faster than C in benchmarks
#160Earlier quoted context omitted.
> null terminated strings feel like idiomatic C to most people Doesn't that mean that null terminated strings is idiomatic C? That is, my understanding of the term idiomatic is that it is defined by whatever is most natural to users of a language regardless of whether it is the most performant.
Null terminated strings are often called cstrings. They’re beyond idiomatic; they’re part of the C standard library.
Also Unix. Syscalls return null-terminated strings all over the place. So any language running on Unix has to deal with null-terminated strings.
I know because I run a userland that uses length-prefixed strings as far as possible: https://github.com/akkartik/mu