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

Three months of Rust

scattered-thoughts.net

Post reply on HN
Print view View original

101–110 of 120 posts

Re: Three months of Rust

#101

Post by pcwalton »

andrewchambers wrote: post #96
pcwalton wrote: post #79

Earlier quoted context omitted.

> 2. Plan9 C/Go does not do heavy optimisation, but does a decent job. That's not good enough for Rust. > 3. The system has less code overall, something like 1 million lines of code for something like gcc seems like bloat to me, They don't remove useless features and dated features as fast as they pile it on. Those GCC optimizations matter . You simply cannot get away with competitive performance with an AST-to-assem…

Imo compilers should only optimize specific functions which are known to be a code hotspot.

That will result in very poorly-performing code. I liked DannyBee's quote (paraphrased): "Most applications have flat profiles. They have flat profiles because people have spent a lot of time optimizing them."

Re: Three months of Rust

#102

Post by lectrick »

ryenus wrote: post #5
d4rkph1b3r wrote: post #4

Earlier quoted context omitted.

Go is shit. Trust me, Rust will suit you better. Coming from C# it will be a lot closer to what you're used to than the bizzaro-world of Go.

I'm not against you, but to convince, you need to tell why, why the sh*t? why to trust you?

Lack of a runtime exception model would be one huge thing. So you basically have to check for errors after every operation, and whatever errors you don't check for just... get lost.

Re: Three months of Rust

#103

Post by andrewchambers »

pcwalton wrote: post #101
andrewchambers wrote: post #96

Earlier quoted context omitted.

Imo compilers should only optimize specific functions which are known to be a code hotspot.

That will result in very poorly-performing code. I liked DannyBee's quote (paraphrased): "Most applications have flat profiles. They have flat profiles because people have spent a lot of time optimizing them."

There are times squeezing every last bit of performance is great. I am saying is in general there is no need to run -O3 on a 500 line function which is run once at initialization compared to a compute kernel. Our compilers and languages don't have the granularity to specify this currently.

I do want more specialized optimization tools however. Things like automatic super optimizers [1] which can be targeted by programmers with special directives.

[1] http://theory.stanford.edu/~sbansal/superoptimizer.html

Re: Three months of Rust

#104

Post by andrewchambers »

pcwalton wrote: post #77
Jweb_Guru wrote: post #69

Earlier quoted context omitted.

Rust could still have a toolchain like DMD devoted to fast compilation with minimal optimization. It just doesn't, yet (and likely won't for quite some time, since the present advantages of having a single toolchain are fairly significant and Rust doesn't have a formal specification yet).

There are C compilers out there that work like this (like, say, the Plan 9 C compiler) and they rarely ever get used in practice, because GCC and clang -O0 are fast enough. I think making a second compiler backend just to eliminate the IR generation step isn't going to be the solution we want in the long run.

I think they are only fast enough because developers have not been exposed to better. In general, I would like to see more aggressive build modes for CI servers, and less aggressive modes for dev.

Re: Three months of Rust

#105

Post by pron »

jamii wrote: post #97
pron wrote: post #94

Earlier quoted context omitted.

> I want to form a mental model of what code I should write to get a certain effect And how do you do that with hyperthreading, virtual memory, power management that may decide to power down your core because what you're doing doesn't seem important enough (and that differs greatly from one processor to another) and cache effects on code, data and TLB (all are strongly affected by other threads and processes running…

I think you are taking a very black and white point of view. Yes, hardware is complex and unpredictable. That doesn't mean that we can't reason at all about performance. I take a program, measure it's performance on a wide range of real-world workloads across multiple different machines. Then I change some numeric routine to use unboxed integers instead of boxed integers. I measure it again on a wide range of real-wo…

> I'm not against smart compilers, I'm against smart compilers that don't talk to me.

There are some extremely interesting advances in that area in OpenJDK. Java 9 will contain two relevant changes. The first, JEP 165[1] (fine-grained and method-context dependent control of the JVM compilers), lets you control compilation with metadata depending on context (e.g. inline method foo when called from bar); a much more interesting and powerful enhancement targeted for Java 9 is JEP 243[2] (Java-Level JVM Compiler Interface). It will do the following:

* Allow the JVM to load Java plug-in code to examine and intercept JVM JIT activity.

* Record events related to compilation, including counter overflow, compilation requests, speculation failure, and deoptimization.

* Allow queries to relevant metadata, including loaded classes, method definitions, profile data, dependencies (speculative assertions), and compiled code cache.

* Allow an external module to capture compilation requests and produce code to be used for compiled methods.

This opens the door to what I think is the most impressive compiler of the last decade, and a true breakthrough in (JIT) compiler design: Graal[3]. Graal supports languages of any level (it already has frontends for Java, C, Ruby, Python, R and JavaScript), and then allows complete control over code generation and optimization decisions at runtime. E.g. you tell it what kind of speculations to make, and it tells you which speculations failed. Unlike LLVM, you compile your language into a semantic AST (that may or may not match the language's AST) and feed it to Graal, but each node may contain not just semantics but instructions on speculation and code-gen control at any level you wish. During compilation, Graal interacts with the node and the node gives further instructions. As I understand it, JEP 243 will allow to plug Graal into the standard OpenJDK HotSpot (though at reduced speed), until Graal matures enough to become HotSpot's default compiler.

So what Graal will do is let the developer (if the language designer allows), write simple, high-level code, but tell the compiler, "listen, compile however you like, but when you get to this function, talk to me because I have some ideas on how to compile it just right".

[1]: http://openjdk.java.net/jeps/165

[2]: http://openjdk.java.net/jeps/243

[3]: https://wiki.openjdk.java.net/display/Graal/Publications+and...

Re: Three months of Rust

#106

Post by tarblog »

pjmlp wrote: post #41
pcwalton wrote: post #17

Earlier quoted context omitted.

On debug builds, it's about evenly split between typeck/borrowck and codegen (including LLVM IR construction and LLVM passes). On release builds, LLVM optimization time tends to dominate everything. Niko Matsakis is actively working on improving typechecking time--there should be plenty of tricks we can try once we have enough data as to the lowest-hanging fruit. Felix Klock and others are working on reducing the amo…

I think a big issue is that even if it takes a few more seconds, it is still a big win compared with C and C++ builds, usually measured in hours. But I guess it is a block for those used to programming languages with traditional interpreter implementations. My biggest complain when trying out Rust was the C++ build times of the bootstrapping process. As for using pre-compiled Rust, I think the compile times are prett…

> C and C++ builds, usually measured in hours. Do you have a source or a story about this? I hadn't heard numbers like that before.

Re: Three months of Rust

#107

Post by tarblog »

andrewchambers wrote: post #104
pcwalton wrote: post #77

Earlier quoted context omitted.

There are C compilers out there that work like this (like, say, the Plan 9 C compiler) and they rarely ever get used in practice, because GCC and clang -O0 are fast enough. I think making a second compiler backend just to eliminate the IR generation step isn't going to be the solution we want in the long run.

I think they are only fast enough because developers have not been exposed to better. In general, I would like to see more aggressive build modes for CI servers, and less aggressive modes for dev.

Also, I'm confused by the word "aggressive" here. Could you elaborate please?

Re: Three months of Rust

#108

Post by andrewchambers »

tarblog wrote: post #107
andrewchambers wrote: post #104

Earlier quoted context omitted.

I think they are only fast enough because developers have not been exposed to better. In general, I would like to see more aggressive build modes for CI servers, and less aggressive modes for dev.

Also, I'm confused by the word "aggressive" here. Could you elaborate please?

Aggressive optimization. I just mean on a build server time isn't as much of a factor as local development.

Re: Three months of Rust

#109

Post by the_why_of_y »

shmerl wrote: post #84
glandium wrote: post #20

The take-away for me is this: "Despite the restrictions of the type system, I am more productive in Rust than I am in either Javascript or Haskell. It manages somehow to hit a sweet spot between safety and ease of use." When I toyed with Rust last year (so, I'll admit my knowledge is outdated, I need to refresh it), I had a pleasant experience on the productivity side. The big reward for me, coming from C/C++, is tha…

Doesn't using C++ RAII eliminate some of that? Or you use raw pointers often?

Anything in C++ generally comes with its very own footgun.

The one for RAII looks like this:

  {
    mutex_guard(some_mutex);
    foo();
  }
What does this do? It locks some_mutex, then immediately unlocks it, then calls foo().

Re: Three months of Rust

#110

Post by jamii »

pron wrote: post #105
jamii wrote: post #97

Earlier quoted context omitted.

I think you are taking a very black and white point of view. Yes, hardware is complex and unpredictable. That doesn't mean that we can't reason at all about performance. I take a program, measure it's performance on a wide range of real-world workloads across multiple different machines. Then I change some numeric routine to use unboxed integers instead of boxed integers. I measure it again on a wide range of real-wo…

> I'm not against smart compilers, I'm against smart compilers that don't talk to me. There are some extremely interesting advances in that area in OpenJDK. Java 9 will contain two relevant changes. The first, JEP 165[1] (fine-grained and method-context dependent control of the JVM compilers), lets you control compilation with metadata depending on context (e.g. inline method foo when called from bar); a much more in…

Thanks, that is really interesting. I'll have to look into it.
Post reply on HN