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

Rust 1.24

blog.rust-lang.org

Post reply on HN
Print view View original

191–200 of 215 posts

Re: Rust 1.24

#191

Post by Sindisil »

civility wrote: post #96
nerpderp83 wrote: post #93

Earlier quoted context omitted.

Those languages were Wirthian, and were designed for fast compilation.

Oberon certainly compiles quickly, and I believe Delphi (Pascal-ish) was fast too, but I was thinking of Microsoft's Java compiler before they got spanked.

Most Java compilers are quick because they compile down bytecode, leaving virtually all optimization to the JIT.

AOT Java compilers certainly exist, but I don't recall Microsoft having one -- I fully admit my recollection of their Java dev environment is quite foggy at this point, though.

Regardless, the Java AOT compilers I've tried didn't seem particularly fast in relation to their level of optimization.

Re: Rust 1.24

#192

Post by IshKebab »

jhasse wrote: post #130
steveklabnik wrote: post #58

Earlier quoted context omitted.

The problem is that you have to think about it at all. If you compile on a machine with a new libc, and then try to run it on a machine with an old libc, it won't work. So you end up doing what most people do, even outside of Rust, which is take the oldest CentOS box you can stand and do builds on that.

The Autopackage project had a solution for this problem years ago called apbuild. It would search for the versions of glibc symbols and use the oldest possible ones, which resulted in portable binaries. With some quick googling I found the code here: https://github.com/DeaDBeeF-Player/deadbeef-plugin-builder/t... Probably doesn't work anymore though :/ It's a bit sad that this is still unsolved, probably due to the G…

It's the GNU way:

1. Refuse to do something properly because it will make it too easy... or something.

2. Wait until someone else gets fed up enough and makes a better version.

3. Fade into irrelevance.

See: GCC/Clang, glibc/musl, Bash/??? (someone please make something sane)

Re: Rust 1.24

#193

Post by jhasse »

IshKebab wrote: post #192
jhasse wrote: post #130

Earlier quoted context omitted.

The Autopackage project had a solution for this problem years ago called apbuild. It would search for the versions of glibc symbols and use the oldest possible ones, which resulted in portable binaries. With some quick googling I found the code here: https://github.com/DeaDBeeF-Player/deadbeef-plugin-builder/t... Probably doesn't work anymore though :/ It's a bit sad that this is still unsolved, probably due to the G…

It's the GNU way: 1. Refuse to do something properly because it will make it too easy... or something. 2. Wait until someone else gets fed up enough and makes a better version. 3. Fade into irrelevance. See: GCC/Clang, glibc/musl, Bash/??? (someone please make something sane)

Fish https://fishshell.com/

Re: Rust 1.24

#194

Post by e12e »

Shoop wrote: post #92
steveklabnik wrote: post #76

Earlier quoted context omitted.

It's not a big-O thing. The optimization passes aren't necessarily huge either; right now, 50% of the time is in LLVM compiling IR -> machine code. The static checks, optimization passes, and everything else are minuscule overall. You can see this with -Z time-passes. We have some hunches, but nothing super conclusive yet; basically, right now it's all about how much IR we generate. Don't forget the differences in co…

Is there a way to generate IR which is easier on LLVM? The Jai compiler compiles 60kloc with an llvm backend in seconds. Could performance like this be seen in rustc?

Apparently that's :

https://inductive.no/jai/

Re: Rust 1.24

#195

Post by geofft »

steveklabnik wrote: post #184
geofft wrote: post #173

Earlier quoted context omitted.

If you're referring to the comment starting with "It's not a big-O thing," I think that comment says the opposite. "Generics, lifetimes, and type inference" aren't "static checks and optimization passes" (within rustc)—he says the bulk of the work is LLVM dealing with the quantity of IR rustc generates, which is exactly what you'd expect from having heavy source-level abstractions like generics and type-heavy pattern…

Edit: so, in the bit below about MIR vs non-MIR borrow checking, I went and asked niko. And he told me that -Z time-passes is pretty much misleading now. Gah. I'm leaving the comment below because I put a lot of work into it, but apparently it may not be correct. https://github.com/rust-lang-nursery/rust-forge/blob/master/... is how you're supposed to do this these days. It's a ton of work that I don't have time to d…

> Ultimately, none of this is Rust's checks as a language, this is burning away all of the abstractions into lean, mean code.

Right - my understanding is that Rust generates very large MIR and also LLVM IR because the "zero-cost abstractions" aren't yet zero-cost, and compiling them into zero-cost machine code is inherently expensive.

So it's not the safety checks per se, but it's things like "there are three wrapper objects here with various generic parameters where C/C++ would have started with just a pointer from the beginning". Those three wrapper objects couldn't have existed without the safety checks, and rustc very quickly identified that everything is in order, but then it monomorphized the generics into lots of tiny functions and LLVM has to optimize all of that into machine code that resembles what the (unsafe) pointer approach would have generated. (Which explains why it's not time taken in rustc proper, but also why we don't see LLVM being equally slow when compiling C/C++.)

Is that interpretation correct?

Re: Rust 1.24

#196

Post by ZenoArrow »

laxd wrote: post #166
ZenoArrow wrote: post #124

Earlier quoted context omitted.

If that's your impression, then I'd suggest Python is used for more than you're currently aware of. Here are two examples of Python being used for "low level stuff": https://micropython.org/ http://www.myhdl.org/

Uh, your examples of low level python are full of C.

If you understood what MyHDL is doing, you'd know that doesn't matter.

Furthermore, most Python implementations are built using C, including the canonical one (CPython). It is possible to have performant Python implementations without using C, if that's what you're getting at.

Re: Rust 1.24

#197

Post by e12e »

dingo_bat wrote: post #165
talson wrote: post #15

Can someone sell me on using rust over python? I am just gernerally curious as to the advantage beyond rust being compiled.

Instead of learning weird new stuff like rust or go, I find that c/c++ and python cover the entire range of problems you will ever need to solve. It takes a lot of time to start being productive in rust/go, and the benefits are vague. Instead I'd rather learn to use C++ and python better.

Hopefully the need for c/c++ will fade, and one will be able to use python and rust.

https://blog.sentry.io/2016/10/19/fixing-python-performance-...

https://github.com/getsentry/milksnake/blob/master/README.md

https://gist.github.com/seanjensengrey/f5d73bbdf22cfa1ad463

Re: Rust 1.24

#198

Post by civility »

coldtea wrote: post #135
civility wrote: post #108

Earlier quoted context omitted.

It means things don't usually get better until you admit they're not as good as they can be.

I hope you see the irony in accusing them of that in a post announcing that the compiler just got better.

It's not ironic. I see this kind of thing all the time. Rather than cleanup and speedup an implementation, engineers will make it multi-threaded or send it off to a GPU, generally achieving limited improvements and greater complexity. In this case, rather than make the compiler faster, they hack it up with incremental compilation. It's still slow, but they apply the slow code to less data and call it a win.

Re: Rust 1.24

#199

Post by steveklabnik »

geofft wrote: post #195
steveklabnik wrote: post #184

Earlier quoted context omitted.

Edit: so, in the bit below about MIR vs non-MIR borrow checking, I went and asked niko. And he told me that -Z time-passes is pretty much misleading now. Gah. I'm leaving the comment below because I put a lot of work into it, but apparently it may not be correct. https://github.com/rust-lang-nursery/rust-forge/blob/master/... is how you're supposed to do this these days. It's a ton of work that I don't have time to d…

> Ultimately, none of this is Rust's checks as a language, this is burning away all of the abstractions into lean, mean code. Right - my understanding is that Rust generates very large MIR and also LLVM IR because the "zero-cost abstractions" aren't yet zero-cost, and compiling them into zero-cost machine code is inherently expensive. So it's not the safety checks per se, but it's things like "there are three wrapper…

Yes.

I might split out C++ from C here though; template-heavy C++ is known to be pretty slow to compile too, for what's basically similar reasons: you end up generating a bunch of code that needs to be crunched down.

There's also some possibly deeper reasons around heavy use of generics: if your code touches something that is generic, and you change the type, it's going to need to recompile that function too. And then anything generic it touches. Etc. Trait objects can help compile times for this reason, but they aren't considered idiomatic, so most Rust code tends to stress the compiler in this way.

Re: Rust 1.24

#200

Post by laxd »

ZenoArrow wrote: post #196
laxd wrote: post #166

Earlier quoted context omitted.

Uh, your examples of low level python are full of C.

If you understood what MyHDL is doing, you'd know that doesn't matter. Furthermore, most Python implementations are built using C, including the canonical one (CPython). It is possible to have performant Python implementations without using C, if that's what you're getting at.

No I am not simply talking about performance. I see you keep refering to Turing completeness in other replies, even condescendingly implying that your HN peers does not understand it, when you are clearly the one whose understanding needs to mature. A turing complete system is one where the rules are powerfull enough that you are able to implement "anything" INSIDE of them. Does'nt mean you are able to break out the system and manipulate the underlying environment, or even infer anything about how it's implemented. Just to bring my point to the extreme: Minecraft is turing complete. Does'nt mean you can bootstrap your cpu with. You can in theory emulate your cpu on top of it though.

Actually you seem to suggest that not even performance is of any hindrance to python. In which case I'm lost for words. You win.

Post reply on HN