Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A possible new back end for Rust

jason-williams.co.uk

Post reply on HN
Print view View original

211–220 of 224 posts

Re: A possible new back end for Rust

#211

Post by pcwalton »

Rusky wrote: post #189
pcwalton wrote: post #179

Earlier quoted context omitted.

I think it's actually mostly the language. Rust idioms just generate a lot of code. Clang is in a worse spot than rustc is in terms of emitting good LLVM IR, since it has no IR aside from the AST. By contrast, rustc has MIR which is more amenable to optimizations. At this point I'm fairly sure the problem is just that C code naturally generates less IR than Rust code does. All those function calls that go into iterat…

Modern C++ is in a similar situation with iterators, indexing, etc. and it's still often faster for LLVM to get through. MIR optimization can help close the gap but that still involved generating "garbage" that takes extra time to codegen (in Debug) or optimize out (in Release). Being smarter about generating IR, whether MIR or LLVM IR, is still an area rustc has a lot of room to improve, even given Rust's idioms. E.…

I think people are way too hard on rustc. That linked issue is pretty esoteric and is a good example of the low-hanging fruit being picked. I doubt it'll move the needle much.

Re: A possible new back end for Rust

#212

Post by pjmlp »

mratsim wrote: post #209
pjmlp wrote: post #204

Earlier quoted context omitted.

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 la…

Nah, I was answering the whole "C vs C++" issue.

But then since you saw it was a lousing battle going down that path, you pulled the hardware rabbit trick out of the magician hat.

So we moved from C++ is not faster than C assertion, to memory layouts, hardware design and data representation.

Now you are even asserting that it's not about C vs C++ vs PTX, and going down quantum transport lane?

Yeah, whatever.

Re: A possible new back end for Rust

#213

Post by mratsim »

pjmlp wrote: post #212
mratsim wrote: post #209

Earlier quoted context omitted.

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 la…

Nah, I was answering the whole "C vs C++" issue. But then since you saw it was a lousing battle going down that path, you pulled the hardware rabbit trick out of the magician hat. So we moved from C++ is not faster than C assertion, to memory layouts, hardware design and data representation. Now you are even asserting that it's not about C vs C++ vs PTX, and going down quantum transport lane? Yeah, whatever.

Obviously you didn't read what I posted. The Quantum Transport is compute-intensive physics problem that has a lot of optimization research going behind it. One of the main bottleneck to solve this problem is Strided Matrix Multiplication.

There is no C vs C++ issue, you keep saying that constexpr and template metaprogramming matter in high performance computing and GPGPU, I have given you links, benchmarks and actual code that showed you that what makes a difference is memory locality.

Ergo, as long as your language is low-level enough to control that locality, be it C, C++, Fortran, Rust, Nim, Zig, ... you can achieve speedups by several order of magnitude and it is absolutely required to get high-performance.

Constexpr and template metaprogramming don't matter in high performance computing, prove me wrong, walk the talk, don't drink the kool-aid.

There are plenty of well studied computation kernels you can use: matrix multiplication, convolution, ray-tracing, recurrent neural network, laplacian, video encoding, Cholesky decomposition, Gaussian filter, Jacobi, Heat, Gauss Seidel, ...

Re: A possible new back end for Rust

#214

Post by pjmlp »

dgellow wrote: post #190
pjmlp wrote: post #90

Earlier quoted context omitted.

Haskell, OCaml, SML, Idris also compile quite fast, with complex type systems. Their secret? Multiple backends with different kinds of optimizations. You don't need to compile for the ultimate release performance when in the middle of compile-debug-edit cycle.

Haskell and Idris both have very slow compilation time.

Only when using release mode compilers, they also have interpreters and REPLs to choose from.

Re: A possible new back end for Rust

#215

Post by Rusky »

pcwalton wrote: post #211
Rusky wrote: post #189

Earlier quoted context omitted.

Modern C++ is in a similar situation with iterators, indexing, etc. and it's still often faster for LLVM to get through. MIR optimization can help close the gap but that still involved generating "garbage" that takes extra time to codegen (in Debug) or optimize out (in Release). Being smarter about generating IR, whether MIR or LLVM IR, is still an area rustc has a lot of room to improve, even given Rust's idioms. E.…

I think people are way too hard on rustc. That linked issue is pretty esoteric and is a good example of the low-hanging fruit being picked. I doubt it'll move the needle much.

It's hardly esoteric when it affects some of the most common (and commonly-inlined) methods in the entire language, which are a large part of Rust's unique idioms.

Re: A possible new back end for Rust

#216

Post by jcranmer »

brandmeyer wrote: post #205
jcranmer wrote: post #109

Earlier quoted context omitted.

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?

I don't have much experience with GCC innards, but after doing a quick test [1], it seems GCC is as bad as clang in terms of not supporting STDC FENV_ACCESS, so I suspect the answer is that it's pretty much the same.

It looks like the only major compiler that actually supports IEEE 754 correctly is icc. MSVC, gcc, and clang all optimize floating-point operations without considering if the dynamic environment is the same.

[1] https://godbolt.org/z/x2ERVM

Re: A possible new back end for Rust

#217

Post by MauranKilom »

bluGill wrote: post #196
MauranKilom wrote: post #170

Earlier quoted context omitted.

> I can write a c++ compiler in a few months. Not that it substantially distracts from your point, but I strongly doubt this. Or did you mean a heavily restricted subset of C++? A C++ front end alone is so complex to build that these guys make a living off of licensing their front end code: https://www.edg.com/ (Fun fact: Microsoft rebuilt IntelliSense for C++ on the EDG front end. Yes, that Microsoft with the MSVC c…

Edg is writing a good front end. With good error handling and all of the other things that make a commercial program a few hundred times harder than a quick prototype. I'd be writing a brute force front end that is slow, and goes straight to assembly. If there is a syntax error I'll handle it by crashing. When you create a variable is used twice in a row I'll store the intermediate value back into memory and reload i…

I'm still awfully skeptical that you can get even close to understanding all the template, lookup, lifetime, lambda, exception and initialization rules in a semester (I assume that CS students are almost never this deep into C++ at that point). Not to speak of actually implementing all of it.

I'd be curious where these classes draw the line. Do you happen to have a syllabus or so? I don't doubt you can implement a meaningful portion of C++ in a semester, but converting 500 pages of standardese into code within as many hours seems like an impossible goal for a class to me.

Re: A possible new back end for Rust

#218

Post by ufo »

pizlonator wrote: post #174
ufo wrote: post #164

Earlier quoted context omitted.

I think we can all agree that LLVM IR is a more powerful compilation target than C. However, what Pizlo was saying is that generating C can be simpler than generating LLVM IR. A bunch of printfs can get you very far.

There are very few things that you can say in LLVM IR that you can't say in C.

I use C as a target for my own compiler and I agree that there are very few things that I miss. But the ones we do miss do stick out like a sore thumb. One of the main ones for me is a way to get an accurate stack map for precise garbage collection. With C you usually gotta go for a conservative GC, or you need to maintain a shadow stack. (Although I'll admit that the GC story with LLVM isn't super great either)

Re: A possible new back end for Rust

#219

Post by jfkebwjsbx »

pjmlp wrote: post #91
jfkebwjsbx wrote: post #21

Earlier quoted context omitted.

> There is no technical advantage to transforming Rust into C There is a key one: the ability to use any C compiler out there (including proprietary ones). This allows you to target all platforms out there.

A dumb interpreter for the IR as bootstraping stage is a better alternative. Plus very few platforms have only support for C and nothing else, unless we are speaking about esoteric embedded CPUs.

Of course we are talking about embedded CPUs. And no, they are not "esoteric". They are everywhere around you.

Then you can also add custom CPUs and systems, FPGAs, etc. Those are way more rare, but still something people use daily in some industries.

Re: A possible new back end for Rust

#220

Post by ddevault »

dbcurtis wrote: post #172
ddevault wrote: post #37

Earlier quoted context omitted.

It's complete enough to compile C11 programs - to me, that's as good of a benchmark as anything. The main thing qbe is missing for cproc's purposes is inline assembly and VLAs. DWARF support would also be nice, but no one seems to care enough to do the work yet.

Are you saying that qbe does not generate any debug information, or just not DWARF format?

qbe does not generate any debug information. Though you can pass some flags to get some ideas of its internal code generation process.
Post reply on HN