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

191–200 of 224 posts

Re: A possible new back end for Rust

#191

Post by Leherenn »

runevault wrote: post #157
Leherenn wrote: post #150

Earlier quoted context omitted.

It's funny, because I do the exact opposite. As a developer I usually have a pretty powerful machine, and I've found that debug mode is a good way to approximate slow computers, and something that is unbearably slow in debug will bother some users later on.

This is an interesting idea, but I guess my one question is how much does the slowness of debug relate to HOW it will be slow in release? Since release optimizations can do pretty radical things to the assembly generated it feels like it wouldn't really be apples to apples.

I thought it would be an issue as well at first, but it has really rarely been an issue.

The performance degradation might not be even, but generally it approximates pretty well a slower system, without having to use a slower system in my experience. You can deal with the few edge cases individually.

If you really care about performance on slower computers, then at some point you'll need to use one for real. But at least this way you have a fast feedback loop.

Re: A possible new back end for Rust

#193

Post by mratsim »

Ididntdothis wrote: post #68
mratsim wrote: post #63

Earlier quoted context omitted.

I would be surprised if optimization was the actual goal. C++ is not faster than C.

It’s not faster but it’s also not much slower. I think some features of C++ Would be hard to optimize by a compiler that doesn’t understand them so a C++ to C compiler may produce slow or bloated code.

In embedded development C++ is often frowned upon because in the past people used C++ features that bloated the code.

Regarding features that may not be properly optimized, there are exceptions and move semantics I guess, but exceptions are often avoided like the plague anyway and code can be refactored to get the same effect as move semantics.

Am I missing something?

Re: A possible new back end for Rust

#194

Post by mratsim »

pjmlp wrote: post #133
mratsim wrote: post #63

Earlier quoted context omitted.

I would be surprised if optimization was the actual goal. C++ is not faster than C.

Not only does C++ provide features that straight C optimizers won't be able to match like templates and constexpr, C++ shares a common subset with C, and libc all major C compilers is actually written in C++ with extern "C" entry points nowadays. This "C is faster than C++" is a bit dated by now.

I didn't say C is faster than C++, I said C++ is not faster than C and so speed is probably not the main driver behind implementing a C++-->Assembly pipeline without intermediate C.

Re: A possible new back end for Rust

#196

Post by bluGill »

MauranKilom wrote: post #170
bluGill wrote: post #134

Earlier quoted context omitted.

Depends on your goals. Writing a front end, optimizer and backend quickly gets to more work. I can write a c++ compiler in a few months. It won't be good and to make it good would be many many years of work. If I write a llvm backend it might take a little longer (I doubt it), but I automatically get all the optimizations llvm has plus a good front end that doesn't have bugs in obscure corner cases. (not claiming llv…

> 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 it back into my register.

There have been write a c++ compiler classes that did it in a semester. I think they also do the standard library. (but that might be a year long course)

Re: A possible new back end for Rust

#197

Post by bluGill »

aseipp wrote: post #161
bluGill wrote: post #130

Earlier quoted context omitted.

Because I don't think the possible good answers apply. Sure it is harder to contribute to the backend, but does it matter? I've been doing c++ for years and never looked at the backend. I'll grant lower coordination costs. However I believe they are not outweighed by the advantages of the other llvm contributions. If they need to fork llvm that is a problem. Either merge it back in and be done (with some tests so wha…

Yes, it does matter, because LLVM is an incredibly complex piece of software. And when you work on a compiler, it turns out you'll have to work on the backend. When I worked on a compiler day-in-and-out, there were single files in LLVM that were bigger than our entire in-house compilation backend put together. Which do you think is more appealing to debug? When a bug in code generation causes compiled programs to seg…

Your points are well taken. Now imagine the rust compiler 15 years from now after great effort has made the backend optimizers great - most of your criticisms to llvm will apply there. It will be rust, and lack some code that isn't needed to optimize rust, but otherwise it will be extremely complex and hard to get into. Merging new fixes will take a long time because it is so hard.

C++ isn't a great language, but learning C++ is the least difficult part of the problem to contributing to llvm.

Re: A possible new back end for Rust

#198

Post by bluGill »

cpeterso wrote: post #140
pizlonator wrote: post #126

Earlier quoted context omitted.

Historically writing a compiler in the language that you’re promoting is a good way to really understand the limitations of your language. I think this works so well because language designers tend to understand compilers better than they understand other software.

I heard Niklaus Wirth would only allow new compiler optimizations (in his compilers for Pascal, Oberson, Modula-2) that proved themselves by speeding up the compiler itself.

Which might or might not be a good idea. When I'm writing code at my desk the faster it builds the better. I just need my unit tests to finish and they are small. When it the same code running on my embedded system with lots of data being thrown at it in real time and the cpu load is near (sometimes over) 100% I'll take every optimization of the final code I can get no matter how long it takes to build.

It would be nice if a gcc replacement compiler made speed of building code the goal. I'll even accept speed of building the compiler after it was compiled with gcc (clang, msvc...) as the benchmark if that is faster.

Re: A possible new back end for Rust

#199

Post by pjmlp »

mratsim wrote: post #194
pjmlp wrote: post #133

Earlier quoted context omitted.

Not only does C++ provide features that straight C optimizers won't be able to match like templates and constexpr, C++ shares a common subset with C, and libc all major C compilers is actually written in C++ with extern "C" entry points nowadays. This "C is faster than C++" is a bit dated by now.

I didn't say C is faster than C++, I said C++ is not faster than C and so speed is probably not the main driver behind implementing a C++-->Assembly pipeline without intermediate C.

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.

Re: A possible new back end for Rust

#200

Post by mratsim »

pjmlp wrote: post #199
mratsim wrote: post #194

Earlier quoted context omitted.

I didn't say C is faster than C++, I said C++ is not faster than C and so speed is probably not the main driver behind implementing a C++-->Assembly pipeline without intermediate C.

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

On current architectures, what is hard to optimize is memory and data movement, if your data is at the wrong place or not prefetched at the right time it will be literally 100 times more costly than a saved addition from constexpr.

Post reply on HN