6 ms·

That’s not a counter-argument, because most Java developers can’t write such C-like code and more importantly they don’t want to. The debate was always about i

by blub 5y ago

That’s not a counter-argument, because most Java developers can’t write such C-like code and more importantly they don’t want to. The debate was always about idiomatic Java vs. idiomatic C. What’s amazing to me is that I’ve had such discussions 15 years ago, 10 years ago, etc. I would have hoped that the Java community would have accepted the reality by now :-) Still, there’s also an interesting new development happening in this area: the members of the Rust community have picked up the mantle of native vs. managed performance. By now they’ve spent so much social capital on “rewrite it in Rust”, that it’s not clear if this will be a positive for native dev advocacy, but the show will definitely be fun to watch.

pjmlp 5y ago
Applying the same argument to C, C isn't a system programming language, because the use cases where it is used as such rely on compiler extensions not required for ISO C compliance.
kaba0 5y ago
But nor does most code require that sort of control over memory. Eg. would a program with very diverse code paths improve that much from fitting data into L1 cache better? I am genuinely asking it. Because of course for things like pipewire handling audio streams it is very important and Java would not be a good fit. But for a web application I really don’t see C beating Java by much if by any (and the techempower benchmark shows native languages at top only when those are heavily optimized very specifically eg. depending on the exact format of HTTP requests)
josephg 5y ago
> 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.

by blub 5y ago

pjmlp 5y ago

Applying the same argument to C, C isn't a system programming language, because the use cases where it is used as such rely on compiler extensions not required for ISO C compliance.

kaba0 5y ago

But nor does most code require that sort of control over memory. Eg. would a program with very diverse code paths improve that much from fitting data into L1 cache better? I am genuinely asking it. Because of course for things like pipewire handling audio streams it is very important and Java would not be a good fit. But for a web application I really don’t see C beating Java by much if by any (and the techempower benchmark shows native languages at top only when those are heavily optimized very specifically eg. depending on the exact format of HTTP requests)

josephg 5y ago

> 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.