Live data from Hacker News

A possible new back end for Rust

jason-williams.co.uk

201–210 of 224 posts

Re: A possible new back end for Rust

#201
post #34

Earlier quoted context omitted.

While the GP doesn’t state this as an advantage, the Rust community would benefit from a fully Rust toolchain.

Why? Other than to prove it can be done what is the point. If rust was a huge community okay, but face it, they are not. It is better therefore to focus their efforts where they can make a difference. A new x where the existing ones are just fine (this includes well maintained) is a waste of resources. There are many possible good answers to the above question. However I'm not sure they apply, and worse I believe the…

because bootstrapping entire systems without C.

Re: A possible new back end for Rust

#202
post #199

Earlier quoted context omitted.

Playing word games here? "I said C++ is not faster than C" implies that C++ compilers don't beat C compilers, which as many in HPC, HFT and GPGPU computing domains know is false for years now, and no restrict doesn't help that much against template metaprogramming and constexpr .

I'm not playing word games. Template metaprogramming and constexpr doesn't help being faster in HPC or GPGPU, it helps reduce the redundancy of your code, for example if you want a generic algorithm on float, double, int, complex. What helps speed is being able to control memory allocations and having the tool to place the data required on registers, L1 cache or L2 cache as required by your kernel (and similarly for…

Enough theory,

"Scientific Computing: C++ Versus Fortran" (1997)

https://www.drdobbs.com/cpp/scientific-computing-c-versus-fo...

"Micro-Optimisation in C++: HFT and Beyond"

http://research.ma.cx/NDCTechTown_2017_JMMcG_v1_1.pdf

"The Speed Game: Automated Trading Systems in C++"

https://www.youtube.com/watch?v=ulOLGX3HNCI

"When a Microsecond Is an Eternity: High Performance Trading Systems in C++"

https://www.youtube.com/watch?v=NH1Tta7purM

Re: A possible new back end for Rust

#203
post #202

Earlier quoted context omitted.

I'm not playing word games. Template metaprogramming and constexpr doesn't help being faster in HPC or GPGPU, it helps reduce the redundancy of your code, for example if you want a generic algorithm on float, double, int, complex. What helps speed is being able to control memory allocations and having the tool to place the data required on registers, L1 cache or L2 cache as required by your kernel (and similarly for…

Enough theory, "Scientific Computing: C++ Versus Fortran" (1997) https://www.drdobbs.com/cpp/scientific-computing-c-versus-fo... "Micro-Optimisation in C++: HFT and Beyond" http://research.ma.cx/NDCTechTown_2017_JMMcG_v1_1.pdf "The Speed Game: Automated Trading Systems in C++" https://www.youtube.com/watch?v=ulOLGX3HNCI "When a Microsecond Is an Eternity: High Performance Trading Systems in C++" https://www.youtube.c…

It might be Internet and the issue of communicating emotions across but you sound quite taken by this issue.

Anyway, I stand by what I say and I'm backed by my high performance code:

- Writing matrix multiplication that is as fast as Assembly, complete with analysis and control on register allocations, L1 and L2 cache tiling and avoiding TLB cache miss:

- https://github.com/numforge/laser/blob/master/laser/primitiv...

- Code, including caveat about hyperthreading: https://github.com/numforge/laser/blob/master/laser/primitiv...

- The code is all pure Nim and is as fast/faster than OpenBLAS when multithreaded, caveat, the single-threaded kernel are slightly slower but it scales better on multiple cores.

- I've also written my own multithreading runtime. It's scale better and has lower overhead than Intel TBB. There is no constexpr, you need type-erasure to handle everything people can use a multithreading runtime for, same comparison on GEMM: https://github.com/mratsim/weave/tree/v0.4.0/benchmarks/matm...

- More resources on the importance of memory bandwidth: optimization convolutions https://github.com/numforge/laser/wiki/Convolution-optimisat...

- Optimizing matrix multiplication on GPUs: https://github.com/NervanaSystems/maxas/wiki/SGEMM, again it's all about memory and caches optimization

- Let's switch to another domain with critical perf need, cryptography. Even when knowing the bounds of iterating on a bigint at compile-time, compiler are very bad at producing optimized code, see GCC vs Clang https://gcc.godbolt.org/z/2h768y

- And crypto is the one thing where integer templates are very useful since you know the bounds.

- Another domain? VM interpretation. The slowness there is due to function call overhead and/or switch dispatching and not properly using hardware prefetchers. Same thing, C++ constexpr doesn't help it's lower-level, see resources: https://github.com/status-im/nimbus/wiki/Interpreter-optimiz...

Also all the polyhedral research, and deep learning compiler research including the Halide compiler, Taichi, Tiramisu, Legion, DaCE confirm that memory is the big bottleneck.

Now since you want to stop on the theory and you mentioned HPC, pick your algorithm, it could be matrix multiplication, QR decomposition, Cholesky, ... Any fast C++ code (or C, or Fortran or Assembly) that you find will be fast because of careful memory layout and all level of caches, not constexpr.

If you have your own library in one of those domains I would be also very happy to have a look.

As a simple example, let's pick an out-of-place transposition kernel to transpose a matrix. Show me how you use constexpr and template metaprogramming to speed it up. Here is a detailed analysis on the impact of 1D-tiling and 2D tiling: https://github.com/numforge/laser/blob/master/benchmarks/tra..., throughput can be increased 4x with proper usage of memory caches.

Re: A possible new back end for Rust

#204
post #202

Earlier quoted context omitted.

Enough theory, "Scientific Computing: C++ Versus Fortran" (1997) https://www.drdobbs.com/cpp/scientific-computing-c-versus-fo... "Micro-Optimisation in C++: HFT and Beyond" http://research.ma.cx/NDCTechTown_2017_JMMcG_v1_1.pdf "The Speed Game: Automated Trading Systems in C++" https://www.youtube.com/watch?v=ulOLGX3HNCI "When a Microsecond Is an Eternity: High Performance Trading Systems in C++" https://www.youtube.c…

It might be Internet and the issue of communicating emotions across but you sound quite taken by this issue. Anyway, I stand by what I say and I'm backed by my high performance code: - Writing matrix multiplication that is as fast as Assembly, complete with analysis and control on register allocations, L1 and L2 cache tiling and avoiding TLB cache miss: - https://github.com/numforge/laser/blob/master/laser/primitiv..…

Ah now we are into the opinion of experts in the matter don't count, only if I prove it myself?

I guess that is why NVidia has spent 10 years doing hardware design to optimize their cards for C++ execution.

Apparently that was wasted money, they should have kept using C.

Re: A possible new back end for Rust

#205

Earlier quoted context omitted.

> in particular, floating point is done even worse than C Do you mind expanding on this or pointing me to places where I can read more?

There is a hidden floating-point environment that affects, and is affected by, every single floating-point instruction. Predominantly, this is rounding mode control, sticky bits, and exception control (does overflow cause a SIGFPE?), although most processors have some form of flushing denormals or treating them as 0s, which isn't in IEEE 754. LLVM's floating point instructions assume that there is no floating point e…

Is GIMPLE any worse or better in this regards?

Re: A possible new back end for Rust

#206
post #93

This is really great. The world needs more diverse compiler tech. The llvm monoculture is constraining what kind of compiler research folks do to just the things that are practical to do in llvm. I particularly suspect that if something like Cranelift gets evolved more then it will eventually reach throughput parity with llvm, likely without actually implementing all of the optimizations that llvm has. It shouldn’t b…

I still remember when Clang bringing LLVM along was seen as SO OUT THERE and I'm just mentioning it because I find it weird to be old enough to see fads in system languages come and start to go. Just curious, do you have any examples of this "limitations" you speak of? Sounds like a very interesting read.

HN isn't the place to go for conservative opinions on compilers :)

Re: A possible new back end for Rust

#207

The D programming language has 3 compilers, one with LLVM (LDC) one with GCC (GDC) and one with the Digital Mars back end (DMC). It's great to have all three, as they each have different characteristics in terms of speed, generated code, debug support, platform support, etc. Supporting these three also helps maintain proper semantic separation of code gen from front end.

Has the D community been growing or shrinking over the past decade or so? Staying relatively the same size?

Re: A possible new back end for Rust

#208

Earlier quoted context omitted.

I don't mean the code of the Rust compiler, I mean code written in Rust becomes unidiomatic as the idioms change. How fast does that happen, is it a problem, is it being addressed?

Honestly, it’s probably the perfect time to dive in, now that async/await has dropped. During my time in rust, the major changes in idiomatic code have been around Results/Errors, async/futures, and a few macros and syntactic sugar goodies have evolved. None of these evolutions were problematic to migrate to, and all of them were moving in the right direction, IMO.

Is the rust book still the best place to start if you're a veteran c/c++ programmer? https://doc.rust-lang.org/book/

Re: A possible new back end for Rust

#209
post #204

Earlier quoted context omitted.

It might be Internet and the issue of communicating emotions across but you sound quite taken by this issue. Anyway, I stand by what I say and I'm backed by my high performance code: - Writing matrix multiplication that is as fast as Assembly, complete with analysis and control on register allocations, L1 and L2 cache tiling and avoiding TLB cache miss: - https://github.com/numforge/laser/blob/master/laser/primitiv..…

Ah now we are into the opinion of experts in the matter don't count, only if I prove it myself? I guess that is why NVidia has spent 10 years doing hardware design to optimize their cards for C++ execution. Apparently that was wasted money, they should have kept using C.

I mentioned theory and experts, you said enough theory.

I switched to practical applications and walk the talk showing my code, and then you back off and want to go back to opinions.

I see now that you want to back myself with experts since reproducible code and runnable benchmarks is not enough.

Apparently you recognize Nvidia as an expert so let's talk about CuDNN where optimizing convolution is all about memory layout, source: https://github.com/soumith/convnet-benchmarks/issues/93#issu... and it's not about C vs C++ vs PTX.

Or let's hear about what Nvidia says about optimizing GEMM: https://github.com/NVIDIA/cutlass/blob/master/media/docs/eff..., it's all about memory locality and tiling.

Or maybe Stanford, the US government and Nvidia Research are also wrong when pouring significant research in Legion? https://legion.stanford.edu/

> Legion is a data-centric parallel programming system for writing portable high performance programs targeted at distributed heterogeneous architectures. Legion presents abstractions which allow programmers to describe properties of program data (e.g. independence, locality). By making the Legion programming system aware of the structure of program data, it can automate many of the tedious tasks programmers currently face, including correctly extracting task- and data-level parallelism and moving data around complex memory hierarchies. A novel mapping interface provides explicit programmer controlled placement of data in the memory hierarchy and assignment of tasks to processors in a way that is orthogonal to correctness, thereby enabling easy porting and tuning of Legion applications to new architectures.

Are you saying they should have just called it a day once they were done with C++?

Or you can read the DaCE paper on how to beat CuBLAS and CuDNN: https://arxiv.org/pdf/1902.10345.pdf, it's all about data movement. 6.4 Case Study III: Quantum Transport to optimize transistors heat dissipation, Nvidia strided matrix multiplication was improved upon by over 30%, and this part is pure Assembly, the improvement was about better utilizing the hardware caches.

Re: A possible new back end for Rust

#210

Earlier quoted context omitted.

Honestly, it’s probably the perfect time to dive in, now that async/await has dropped. During my time in rust, the major changes in idiomatic code have been around Results/Errors, async/futures, and a few macros and syntactic sugar goodies have evolved. None of these evolutions were problematic to migrate to, and all of them were moving in the right direction, IMO.

Is the rust book still the best place to start if you're a veteran c/c++ programmer? https://doc.rust-lang.org/book/

Depends on opinion; some also really like the O'Reilly book.
Post reply on HN