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

The Road to Rust 1.0

blog.rust-lang.org

Post reply on HN
Print view View original

211–220 of 248 posts

Re: The Road to Rust 1.0

#211

Post by alkonaut »

moonchrome wrote: post #205
alkonaut wrote: post #184

Earlier quoted context omitted.

Both the JVM and the CLR are regularly beaten by C/C++, despite claims that they are "as fast". What gives? In my view the whole problem comes down to whether or not you are using an idiomatic approach or not. In idiomatic C#/Java you use a lot of heap allocations, garbage collection, you may be using dynamic dispatch and so on. If you write a C# program that uses stack allocation only (no classes, only structs and p…

C# lacks the language features to make dealing with such coding style sane and the libraries use the "idiomatic" approach - if you're willing to put on a straitjacket and throw away the libraries then why bother with C# ? That's not saying that C# can't be made more efficient by avoiding allocation in performance critical sections, but overall it's going to perform worse than C++, both idiomatic and non idiomatic ver…

I agree completely. For an "inner loop" scenario in C# you have to use the straight jacket version of C#. Luckily you can use idiomatic C# for the rest of the program.

The option to using "straight jacket C#" is using C/C++ interop for a part of the program. If that part is large enough, such as in most high end games, it's usually worth biting the bullet and go C++ throughout. Luckily again, those programs are rare.

Point is still that C-style C# is almost as fast as C++ (modulo compiler specific optimizations) but for the reasons above, that fact isn't very interesting.

Re: The Road to Rust 1.0

#213

Post by nickik »

alkonaut wrote: post #184
shin_lao wrote: post #155

Earlier quoted context omitted.

The JVM, who is several order of magnitudes better than the Ruby VM, constantly gets smashed in terms of performance and memory usage by a well designed C++ program. Why? Because in theory, a VM should be able to do as well, if not better, than a programer. The limit of a VM is that you are extremely limited in the amount of resources you can allocate to the VM to determine how much resources should be freed. See wha…

Both the JVM and the CLR are regularly beaten by C/C++, despite claims that they are "as fast". What gives? In my view the whole problem comes down to whether or not you are using an idiomatic approach or not. In idiomatic C#/Java you use a lot of heap allocations, garbage collection, you may be using dynamic dispatch and so on. If you write a C# program that uses stack allocation only (no classes, only structs and p…

> What gives?

What gives is this. The people who right these fast C/C++ programs that beat Java/C# are usally far more skilled and trained.

Any programmer who know neither language well and has to write a big application in it will probebly find java/c# far easier.

I remember a long blogpost where somebody set out to test this on himself. And that guy was a very good C++ programmer. He found that his C++ prgrogrammer was slower, but he then set on improving the speed and in the end beat java by quite a bit. However the amount of effort was completly unreasonable for most programmers.

So "What gives" is this, and this has been true for a long time. If you are a expert in a low level language and spend time optimizing you will probebly beat Java/C#.

I would suggest that you should look into what a JIT or GC can and can not do. Some of the performance problems you identivy are really almost never a bottleneck anymore.

Re: The Road to Rust 1.0

#214

Post by pkolaczk »

tomp wrote: post #201
pkolaczk wrote: post #190

Earlier quoted context omitted.

Rust must statically prove lifetime of references to stack allocated variables does not exceed lifetime of the variables they point to at compile time, in order to be 100% memory safe. How is that different than just an advanced escape anlysis? Theoretically a VM could do much more, because it could do speculative escape analysis (I heard Azul guys were working on such experimental thing called escape detection) and…

You could do escape analysis equivalent to Rust's only if you inlined all the functions. Sometimes, that's simply not possible, e.g. with separate compilation. On the other hand, Rust is still able to perform its kind of escape analysis (via lifetime-tracking type system), because the relevant facts are embedded in type signatures of Rust functions, and as such must be present even for separate compilation (even if t…

VM could do see all the functions and do whole-program analysis. Inlining is an orthogonal concept.

Re: The Road to Rust 1.0

#215

Post by theavocado »

When I first looked at Rust, I recall being very confused about the distinctions between crate, package, module, and library. It seemed like an area which could use some simplification.

Re: The Road to Rust 1.0

#216

Post by pkolaczk »

moonchrome wrote: post #205
alkonaut wrote: post #184

Earlier quoted context omitted.

Both the JVM and the CLR are regularly beaten by C/C++, despite claims that they are "as fast". What gives? In my view the whole problem comes down to whether or not you are using an idiomatic approach or not. In idiomatic C#/Java you use a lot of heap allocations, garbage collection, you may be using dynamic dispatch and so on. If you write a C# program that uses stack allocation only (no classes, only structs and p…

C# lacks the language features to make dealing with such coding style sane and the libraries use the "idiomatic" approach - if you're willing to put on a straitjacket and throw away the libraries then why bother with C# ? That's not saying that C# can't be made more efficient by avoiding allocation in performance critical sections, but overall it's going to perform worse than C++, both idiomatic and non idiomatic ver…

Java will have value types soon. Also, C++ does some heap allocations behind-the-scenes quite often (e.g. with vector or string) which are hard to get rid of and they are much more expensive than in JVM/CLR. So not always idiomatic C++ smashes JVM/CLR in performance. YMMV and typical differences are small enough to not matter for most of server-side software like web-apps, web-servers or databases.

Re: The Road to Rust 1.0

#217

Post by _pmf_ »

whyever wrote: post #80
egonschiele wrote: post #51

Could someone lay out the advantages of Rust over C/C++/Dart/Go/other languages that cater to a similar space?

AFAIK Rust is the only language that offers memory safety without garbage collection.

C++11's std::unique_ptr and std::shared_ptr are also nice features. Does Rust provide more guarantees?

Re: The Road to Rust 1.0

#218

Post by pcwalton »

pkolaczk wrote: post #214
tomp wrote: post #201

Earlier quoted context omitted.

You could do escape analysis equivalent to Rust's only if you inlined all the functions. Sometimes, that's simply not possible, e.g. with separate compilation. On the other hand, Rust is still able to perform its kind of escape analysis (via lifetime-tracking type system), because the relevant facts are embedded in type signatures of Rust functions, and as such must be present even for separate compilation (even if t…

VM could do see all the functions and do whole-program analysis. Inlining is an orthogonal concept.

You could in theory, but that analysis would likely be really slow.

In any case, without the type system and compiler to enforce the discipline the programmer is going to lose a lot of control and predictability.

Re: The Road to Rust 1.0

#219

Post by ngrilly »

pcwalton wrote: post #72
MoOmer wrote: post #71

> We are removing support for green threading from the standard library and moving it out into an external package. This allows for a closer match between the Rust model and the underlying operating system, which makes for more efficient programs. That's an interesting move in comparison to Go, which multiplexes coroutines onto threads.

It's more systems-like. We don't pay any overhead for calling into C code, and M:N scheduling doesn't really provide advantages over 1:1 scheduling when you don't have a GC (and even when you do, the differences are fairly negligible on modern Linux).

With 1:1 scheduling, how do you limit stack size to something reasonable (a few kB per thread), which is necessary when you need to launch tens of thousands of threads?

Re: The Road to Rust 1.0

#220

Post by wtetzner »

strcat wrote: post #173
3289 wrote: post #18

It seems that 1.0 is going to be a solid release. But the post-1.0 Rust is going to be even more exciting once they have added inheritance and subtyping which enable true polymorphic reuse!

Object inheritance is only useful in rare edge cases so your statement doesn't make much sense. Traits have default methods, inheritance and can be used as bounds on generics (no dynamic dispatch, type not lost) or as objects (dynamic dispatch / type erasure). What makes you think object inheritance is such a sure thing anyway? I don't expect either object inheritance or optional garbage collection to materialize, ev…

I think optional garbage collection might materialize, but I would imagine it would end up being a third-party library.
Post reply on HN