|17 Apr 2021|
|kosshi||oh cmon why is the replacement, nanosleep undeclared as well?||12:18:28|
|photodiode|| Add ||12:21:52|
|kosshi||_XOPEN_SOURCE works too which i also need||12:29:06|
|anthragon||How did Rust become so fast?!||14:24:21|
|bkilm||The Rust version uses SIMD and the gcc version uses memcpy, I think that's pretty clear cut. As the both compile to machine code, I would be hard pressed to believe that you could implement something faster in Rust than in gcc.||19:23:39|
|bkilm||However, as declared on the main page, these comparisons are only meaningful to test machines, compiler and such, but if the underlying algorithm is different, it doesn't make sense. And anyway the best comparison is when doing idiomatic implementations on both sides - i.e., those that you will see and implement in the wild.||19:24:54|
|bkilm||By the way, it is hard coded for x86 and AMD64 - that's why it would be great to do comparisons on ARM or MIPS as well.||19:26:53|
|anthragon||Maybe I should write something medium-sized in C and in Rust and then test the speed.||19:27:38|
|anthragon||What could I write? Does anyone have an idea?||19:27:53|
|bkilm||Whatever makes you happy.||19:27:55|
|anthragon||I've got lots of time.||19:28:05|
|bkilm||Then could you perhaps implement a lighter Matrix client that uses FLTK for older machines?||19:28:37|
|bkilm||It doesn't matter to me much whether you use C++, C or Rust.||19:28:57|
|anthragon||That's a good idea! But isn't the specification for Matrix a bit long?||19:29:42|
|anthragon||But is it possible (and easy) to write good-looking UIs with FLTK?||19:31:29|
|bkilm||It only depends on your capabilities. It also has at least one rapid application designed that helps (FLUID)||19:50:13|
In reply to @bkil:matrix.orgMost memcpy implementations I have seen use SIMD, I believe most standard libs for C also use SIMD for memcpy and most string.h functions where they can
|tthom||I'll agree that seeing what is idiomatic typically reveals the affordances in those languages for writing code like this, however, for this case, it might be possible that the reason the rust version is performing faster is that certain constraints the language entails could allow the compiler to apply some optimisations||20:06:27|
|kosshi||yep thats it, rust does enforce lots of things about memory safety that allows it to do things C cannot thats what ive heard anyway||20:07:57|
|kosshi||* yep thats it, rust does enforce lots of things about memory safety that allows it to do things C cannot thats what ive heard anyway||20:10:23|
|tthom||AFAIK, the LLVM backend has been a bit of a problem for Rust as certain performance properties have not been realised until recently as certain features from LLVM have been unable to be used by rustc due to those features cobtaining bugse||20:10:40|
In reply to @tthom:ahtoms.xyzNope, please open the link. It uses SIMD for its computations, hence it is way faster. The fact that the C code also uses some extra memory accesses doesn't exactly help, but this is a completely separate issue.
|18 Apr 2021|
|rawbrisket set a profile picture.||01:26:52|
bkilm: Really? That's the thing that is impacting it the most and your "Nope" doesn't even respond to anything really besides apparently saying statement about memcpy being implemented with simd is false.
Just out of curiosity, have you considered that it could be a one or a combination of the following?
It could be that SIMD is actually providing a performance benefit over the C version and I'd be happy to agree with you if you can show it is the case with a perf report. However, I'd need more than your "That's because it is" statement.
|jorgarga||Maybe those differences can be seen using the compiler explorer (https://godbolt.org/)||08:01:37|
In reply to @tthom:ahtoms.xyzThis is your mission, not mine. I tried to give you hints and pointers, but that's how far I will go this time. Have fun!
|bkilm||Gcc also has assembly output, I'm sure Rust also has it, but I agree that a perf output would be more useful.||10:52:14|