4 ms·

> Rust can't target the same platforms C can. I keep seeing this argument, but nobody actually names those platforms. Name one platform you need to run a TLS s

> Rust can't target the same platforms C can. I keep seeing this argument, but nobody actually names those platforms. Name one platform you need to run a TLS stack on that LLVM doesn't have support for. > Rust is also (generally) more memory intensive than C for similar programs [citation needed]

oconnor663 10y ago
Maybe falcolas means that in the same way that C++ is more memory intensive than C for similar programs, because both C++ and Rust encourage a lot of Vecs/Strings that implicitly allocate on the heap?
- pcwalton 10y ago
  Rust doesn't encourage that.
  - oconnor663 10y ago
    I suppose everything's a continuum with this stuff, but here's one library I ran into where I was a little disappointed to find a heap allocation: https://dnaq.github.io/sodiumoxide/sodiumoxide/crypto/secretbox/xsalsa20poly1305/fn.seal.html https://dnaq.github.io/sodiumoxide/sodiumoxide/crypto/secret...
reinar 10y ago
> Name one platform you need to run a TLS stack on that LLVM doesn't have support for. MPC55xx there's no proper support even in GCC and we need to work with expensive WindRiver compiler for this target. personally I don't need TLS for my firmware, but someone might - as there's static without runtime alloc implementation available.
- pcwalton 10y ago
  > MPC55xx Google suggests that this is essentially PowerPC. Is that not true?
  - reinar 10y ago
    I wish it was that easy. our e200z6 core has PowerPC ISA, but there's a difference in hardware floating point support (here it's done by SPE) and we also need VLE. First one you could somehow get working, but with the latter - no way, its support was dropped by mainline gcc even after the patches were proposed, since it complicates the other parts of PowerPC port and is needed only by few people like me with deep embedded stuff (source: https://gcc.gnu.org/ml/gcc/2013-03/msg00172.html https://gcc.gnu.org/ml/gcc/2013-03/msg00172.html).
falcolas 10y ago
> [citation needed] With all the usual disclaimers about the inaccuracy of benchmarks: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gcc&lang2=rust https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... As a side note, can you guarantee you are not allocating memory (calling malloc) with Rust? I know how to do it in C, but Rust has another layer of indirection. > Name one platform you need to run a TLS stack on that LLVM doesn't have support for. Have a look yourself: $ llc --version # CPU architectures supported by LLVM vs. https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Architectures https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Archit... Of particular interest to me are the AVR ATMega line of microprocessors, popular in Arduino boards and IoT devices everywhere. I'd personally love to see more IoT communication secured with TLS. I do see a github repo for providing a LLVM backend for AVR processors, but it's not part of the LLVM project, nor is it even passing its own test suite at the point I'm writing this.
- pcwalton 10y ago
  > https://benchmarksgame.alioth.debian.org/u64q/compare.php?la.. https://benchmarksgame.alioth.debian.org/u64q/compare.php?la.... There are so many variables here that using the benchmarks game will not give you an accurate picture. You may well just be benchmarking jemalloc vs. glibc's allocator. jemalloc is tuned for speed of allocation in threaded contexts (with e.g. TLABs), not minimum memory usage. If you want, you can use the system allocator with Rust; for the benchmarks game we use jemalloc since it's faster. > I know how to do it in C, but Rust has another layer of indirection. How? Any function you call from some other library can call malloc under the hood. > $ llc --version # CPU architectures supported by LLVM I know there are architectures out there that LLVM doesn't support, but that doesn't mean anything unless people actually need those architectures. Not having PDP-11 support (one of the architectures on that list) doesn't make Rust a "non-starter". > I do see a github repo for providing a LLVM backend for AVR processors, but it's not part of the LLVM project, nor is it even passing its own test suite at the point I'm writing this. AVR support is coming along well. AVR isn't exactly a first-class citizen among commonly used projects like OpenSSL. The reason why AVR support is immature is that few people need it. Not having that support isn't enough to make Rust a "non-starter", any more than it makes OpenSSL a "non-starter".

oconnor663 10y ago

Maybe falcolas means that in the same way that C++ is more memory intensive than C for similar programs, because both C++ and Rust encourage a lot of Vecs/Strings that implicitly allocate on the heap?

pcwalton 10y ago
Rust doesn't encourage that.
- oconnor663 10y ago
  I suppose everything's a continuum with this stuff, but here's one library I ran into where I was a little disappointed to find a heap allocation: https://dnaq.github.io/sodiumoxide/sodiumoxide/crypto/secretbox/xsalsa20poly1305/fn.seal.html https://dnaq.github.io/sodiumoxide/sodiumoxide/crypto/secret...

reinar 10y ago

> Name one platform you need to run a TLS stack on that LLVM doesn't have support for. MPC55xx there's no proper support even in GCC and we need to work with expensive WindRiver compiler for this target. personally I don't need TLS for my firmware, but someone might - as there's static without runtime alloc implementation available.

pcwalton 10y ago
> MPC55xx Google suggests that this is essentially PowerPC. Is that not true?
- reinar 10y ago
  I wish it was that easy. our e200z6 core has PowerPC ISA, but there's a difference in hardware floating point support (here it's done by SPE) and we also need VLE. First one you could somehow get working, but with the latter - no way, its support was dropped by mainline gcc even after the patches were proposed, since it complicates the other parts of PowerPC port and is needed only by few people like me with deep embedded stuff (source: https://gcc.gnu.org/ml/gcc/2013-03/msg00172.html https://gcc.gnu.org/ml/gcc/2013-03/msg00172.html).

falcolas 10y ago

> [citation needed] With all the usual disclaimers about the inaccuracy of benchmarks: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gcc&lang2=rust https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... As a side note, can you guarantee you are not allocating memory (calling malloc) with Rust? I know how to do it in C, but Rust has another layer of indirection. > Name one platform you need to run a TLS stack on that LLVM doesn't have support for. Have a look yourself: $ llc --version # CPU architectures supported by LLVM vs. https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Architectures https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Archit... Of particular interest to me are the AVR ATMega line of microprocessors, popular in Arduino boards and IoT devices everywhere. I'd personally love to see more IoT communication secured with TLS. I do see a github repo for providing a LLVM backend for AVR processors, but it's not part of the LLVM project, nor is it even passing its own test suite at the point I'm writing this.

pcwalton 10y ago
> https://benchmarksgame.alioth.debian.org/u64q/compare.php?la.. https://benchmarksgame.alioth.debian.org/u64q/compare.php?la.... There are so many variables here that using the benchmarks game will not give you an accurate picture. You may well just be benchmarking jemalloc vs. glibc's allocator. jemalloc is tuned for speed of allocation in threaded contexts (with e.g. TLABs), not minimum memory usage. If you want, you can use the system allocator with Rust; for the benchmarks game we use jemalloc since it's faster. > I know how to do it in C, but Rust has another layer of indirection. How? Any function you call from some other library can call malloc under the hood. > $ llc --version # CPU architectures supported by LLVM I know there are architectures out there that LLVM doesn't support, but that doesn't mean anything unless people actually need those architectures. Not having PDP-11 support (one of the architectures on that list) doesn't make Rust a "non-starter". > I do see a github repo for providing a LLVM backend for AVR processors, but it's not part of the LLVM project, nor is it even passing its own test suite at the point I'm writing this. AVR support is coming along well. AVR isn't exactly a first-class citizen among commonly used projects like OpenSSL. The reason why AVR support is immature is that few people need it. Not having that support isn't enough to make Rust a "non-starter", any more than it makes OpenSSL a "non-starter".