2 ms·

> it’s not clear if this will be a positive for native dev advocacy I've rewritten a few things in rust. Seems pretty positive to me, because you can mix some

> it’s not clear if this will be a positive for native dev advocacy I've rewritten a few things in rust. Seems pretty positive to me, because you can mix some of the best optimizations and data structures you'd write in C, with much better developer ergonomics. A few years ago I wrote a rope library in C. This is a library for making very fast, arbitrary insert & delete operations in a large string. My C code was about as fast as I could make it at the time. But recently, I took a stab at porting it to Rust to see if I could improve things. Long story short, the rust version is another ~3x faster than the C version. https://crates.io/crates/jumprope https://crates.io/crates/jumprope (Vs C equivalent: https://github.com/josephg/librope https://github.com/josephg/librope ) The competition absolutely isn't fair. In rust, I managed to add another optimization that doesn't exist in the C code. I could add it in C, but it would have been really awkward to weave in. Possible, but awkward in an already very complex bit of C. In rust it was much easier because of the language's ergonomics. In C I'm using lots of complex memory management and I don't want to add complexity in case I add memory corruption bugs. In rust, well, the optimization was entirely safe code. And as for other languages - I challenge anyone to even approach this level of performance in a non-native language. I'm processing ~30M text edit operations per second. A few years ago I tried something similar in JS and got about 100k edits per second. (300x slower) But these sort of performance results probably won't scale for a broader group of programmers. I've seen rust code run slower than equivalent javascript code because the programmers, used to having a GC, just Box<>'ed everything. And all the heap allocations killed performance. If you naively port python line-by-line to rust, you can't expect to magically get 100x the performance. Its like, if you give a top of the line Porsche to an expert driver, they can absolutely drive faster. But I'm not an expert driver, so I'll probably crash the darn thing. I'd take a simple toyota or something any day. I feel like rust is the porsche, and python is the toyota.

unwind 5y ago
Cool! From a very quick look, the sample code prints 'r' instead of 'str' which was confusing. Also, is 'str' leaked or freed with 'r'?
- josephg 5y ago
  In the C example str is heap allocated, so it’s not associated with r and leaked in that example. I should free it to make that clear! After writing a lot of rust code this year it’s sort of weird reading that, and seeing that aspect of the code not be explicit or obvious.
codr7 5y ago
Re-implementations often turn out faster simply because you understand the problem better, which seems to be the case here. The same algorithm not going to run faster in Rust than tuned C, period. Just like C is never going to run faster than tuned Assembly. I wish we could move on to discussing something that matters.
- specialist 5y ago
  Implementation vs performance. And hand-coded assembly would likely be faster still. So what? u/josephg's point is the that implementing equally performant code in 'C' was cost prohibitive for them. This is applying the principle behind "economics of compiler optimizations" writ large. Not a religious battle.
- josephg 5y ago
  > The same algorithm not going to run faster in Rust than tuned C, period. Weirdly enough, before I added that optimization my rust code was ~20% faster than the C code anyway. And I have no idea why - the programs were (as far as I could tell) identical. I was using the same compiler backend (llvm) and before alias analysis was turned on for rust. And -march=native in both cases. Could just be a weird coincidence of the compiler’s inlining decisions - though I suspect not. I tried investigating it but I don’t understand x86_64 assembly enough to understand how the binaries differ.

unwind 5y ago

Cool! From a very quick look, the sample code prints 'r' instead of 'str' which was confusing. Also, is 'str' leaked or freed with 'r'?

josephg 5y ago
In the C example str is heap allocated, so it’s not associated with r and leaked in that example. I should free it to make that clear! After writing a lot of rust code this year it’s sort of weird reading that, and seeing that aspect of the code not be explicit or obvious.

codr7 5y ago

Re-implementations often turn out faster simply because you understand the problem better, which seems to be the case here. The same algorithm not going to run faster in Rust than tuned C, period. Just like C is never going to run faster than tuned Assembly. I wish we could move on to discussing something that matters.

specialist 5y ago
Implementation vs performance. And hand-coded assembly would likely be faster still. So what? u/josephg's point is the that implementing equally performant code in 'C' was cost prohibitive for them. This is applying the principle behind "economics of compiler optimizations" writ large. Not a religious battle.
josephg 5y ago
> The same algorithm not going to run faster in Rust than tuned C, period. Weirdly enough, before I added that optimization my rust code was ~20% faster than the C code anyway. And I have no idea why - the programs were (as far as I could tell) identical. I was using the same compiler backend (llvm) and before alias analysis was turned on for rust. And -march=native in both cases. Could just be a weird coincidence of the compiler’s inlining decisions - though I suspect not. I tried investigating it but I don’t understand x86_64 assembly enough to understand how the binaries differ.