Just took a quick peek at the binary-trees C code. Why using openmp while the others don't? why use recursive functions? The C implementation is not correctly optimized. People just paid more attention to Rust and other languages. Rust can be as fast as C, but "faster" is really misleading. BTW, I use clang all the time since it's better than GCC.
Rust is now overall faster than C in benchmarks
321–330 of 445 posts
Re: Rust is now overall faster than C in benchmarks
#322Nodejs is incredible fast for a interpreted language. It is only ~4 times slower than Rust and only a bit slower than Go or Java (compiled GC languages) in the benchmarks. Compare that with Python 3, also interpreted but ~30 times slower than Rust. I know that Python 3 can do some runtime stuff that Nodejs can't, but I wonder whether that's worth so much performance. Maybe if the answer is that you would include C mo…
Node uses V8, which does JIT compilation, while CPython is a straight bytecode interpreter. A better point of comparison would be PyPy
[deleted]
Re: Rust is now overall faster than C in benchmarks
#323Earlier quoted context omitted.
> If C# and Go preclude 95% of the errors found in Python and JS Well Go and C#[1] still suffer from the billion dollar mistake (null pointers), which represents at least 1/3 of errors I've witnessed in JavaScript code, so I'd say they at best removes 70% of errors. And there's also logic errors, for which neither Go's or C#'s type system helps either, so maybe we're at 50% error reductions with Go and C# compared to…
> for C#, at least last time I used it, which was 2011 Since then, C# added nullable reference types: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... In projects with complete NRT coverage, it's extremely rare I ever get a null ref, as the compiler will warn/error me if I'm using a possibly null value in an unsafe way.
Thanks. I suspected it since they added them to TypeScript, and I'm glad they did!
Re: Rust is now overall faster than C in benchmarks
#324Earlier 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.
One of my long standing complaints about modern programming is how rarely people read code. We don't encourage it in school, and in the workplace most people only read code written by their coworkers. It would be the equivalent of teaching people to write books without encouraging them to read anything. To break myself of the habit I started reading some well regarded programs for fun. And oh boy, have I learned a lo…
This feels like a wrapper around an equivalent of the Linux container_of construct (https://radek.io/2012/11/10/magical-container_of-macro/). I have no idea whether there's further prior art in that respect.
Re: Rust is now overall faster than C in benchmarks
#325Earlier quoted context omitted.
Yeah, `unsafe` is the developer signing a contract to uphold all the guarantees that safe rustc provided (at least from the perspective of the public interface, the invariants can be broken in private code). That's why Rust developers don't take kindly to unnecessary unsafe usage, because the audit surface area (and interaction complexity) increases.
But this is the crux. What sorts of aliasing are permitted in unsafe Rust? I think we kind of don't know; that's what the "stacked borrow" effort is trying to answer.
We know pretty well for the vast majority of patterns whether it violates the aliasing rules or not. There may be some corner cases that are not yet decided on, but if you just consider those as UB for now, you are perfectly fine.
Re: Rust is now overall faster than C in benchmarks
#326Earlier quoted context omitted.
Honestly I have no idea. You can try it yourself, or put it through godbolt: https://gist.github.com/ityonemo/f34e0d3b4891f481863980a3142... Note it could also be platform dependent. I'll give it a whirl on my own (new) machine.
Do you think that it may be caused by use of comptime? I have not looked at the benchmark implementations, but that kind of struck me as a reason
Well, I ran it again and now it's 10% slower than rust (the best rust impls have gotten better since I last tried); I think there's a simd optimization I'm missing, I'm not doing simd operations in the "pairs" phase
Re: Rust is now overall faster than C in benchmarks
#327Earlier quoted context omitted.
Have you ever used restrict in anger? I've done it when we really needed that performance for an inner loop(particle system). It can be a real bastard to keep the non-alias constraint held constant in a large, multi-person codebase and the error cases are really gnarly to chase down. Compare that to Rust which has this knowledge built in since it naturally falls out of the ownership model.
When people use the unsafe keyword are they always taking into account aliasing? At least you can audit only those places though.
I mean obviously there are people who write incorrect unsafe code, but it is certainly something people take seriously.
Re: Rust is now overall faster than C in benchmarks
#328Earlier 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.
One of my long standing complaints about modern programming is how rarely people read code. We don't encourage it in school, and in the workplace most people only read code written by their coworkers. It would be the equivalent of teaching people to write books without encouraging them to read anything. To break myself of the habit I started reading some well regarded programs for fun. And oh boy, have I learned a lo…
do you have any recommended entry points for reading dovecot's code? I opened it up on github and it's a very large library! thanks for any help you can provide.
Re: Rust is now overall faster than C in benchmarks
#329Earlier quoted context omitted.
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...
Conversely, more sophisticated algorithms, and particularly monomorphization, may bloat the code size, causing icache, L2/L3 cache, and TLB misses. (Also slows compilation.) I think this is under-appreciated because it doesn't show in microbenchmarks. (I wish I knew of an easy way to measure how much cache pressure you're causing from a microbenchmark.) I suspect for this reason it'd be better in Rust to use a Go-lik…
Thank you for mentioning monomorphization - I wasn't aware of this concept.
Would you maybe if there's any source discussing how this is solved in different languages and performance consequences of it?
Re: Rust is now overall faster than C in benchmarks
#330Earlier quoted context omitted.
While nothing prevents you from writing C that will generate the equivalent code, it requires several times more lines of C than the equivalent C++. At which point, it becomes an economics discussion. C is usually a choice when pure performance is secondary to other considerations like portability. Most C++ code I see has few vtables, and what vtables exist are mostly removed by the compiler. Java-style inheritance h…
Just a small, correction, you mean 90's style C++ GUI frameworks inheritance are no longer idiomatic in modern C++. Naturally we have to ignore that wxWidgets, Gtkmm, MFC, ATL, Qt, COM, DirectX, IO Kit, DriverKit, Skia are still around.
Probably fairer to say that the virtual inheritance architecture is idiomatic to GUI libraries rather than any particular language? You even mention GTKmm, a C++ wrapper around a C library that leverages inheritance.