Performance of Rust and Dart in Sudoku Solving • Hacker News Board

Re: Performance of Rust and Dart in Sudoku Solving

#41

Post by pjmlp » Sat, Apr 06, 2013, 1:19 PM UTC

Symmetry wrote: post #34

pjmlp wrote: post #16

Earlier quoted context omitted.

> And deterministic memory management, which is quite rare these days... :) Memory management should be automatic, either by reference counting or GC. I think it is a generation thing until mainstream OS adopt such kind of system programming languages. There are a few OS with such system programming languages, but it only counts when the likes of Apple, Microsoft and Google adopt such languages. Objective-C with ARC,…

Rust's memory management is both (relatively) deterministic and automatic, in that it's easy to figure out exactly when objects are being destroyed if you care but you don't have to do anything yourself to ensure that they're destroyed properly. This is in contrast to C or C++ where you have deterministic destruction but you have to clean up things you have to clean up things on the heap yourself, or Go or Java where…

> This is in contrast to C or C++ where you have deterministic destruction but you have to clean up things you have to clean up things on the heap yourself, or Go or Java where you can't be sure at all when the garbage collector is going to harvest something.

This is a false belief many C and C++ developers have.

If you use the standard malloc()/free() or new/delete pairs, you are only certain at which point the memory is marked as released by the C or C++ runtime library.

At that point in time the memory can still be marked as in use for the OS and only be released at a later point, just like GC does.

This is one of the reasons why HPC makes use of special allocators instead of relying in the standard implementations.

In the end, this is no different than doing performance measurements to optimize the GC behaviour in GC enabled systems languages.

Re: Performance of Rust and Dart in Sudoku Solving

#42

Post by hamax » Sat, Apr 06, 2013, 1:21 PM UTC

melling wrote: post #37

hamax wrote: post #33

My results with newer versions of gcc and go: gcc 4.7.2 o3 0.765s java openjdk 7 1.066s java openjdk 6 1.118s go 1.1b 1.653s rust 0.6 opt 3 1.659s go 1.0.2 2.127s dart 0.4.4.4 2.384s pypy PyPy 1.9.0 5.094s pypy PyPy 2.0b 5.319s (Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz) Edit: Added java

It looks like Go 1.1 might be faster than Java. That might help convince enterprise developers to adopt it.

Added java to the list. It's still faster then go.

Re: Performance of Rust and Dart in Sudoku Solving

#43

Post by jfb » Sat, Apr 06, 2013, 1:39 PM UTC

melling wrote: post #37

hamax wrote: post #33

My results with newer versions of gcc and go: gcc 4.7.2 o3 0.765s java openjdk 7 1.066s java openjdk 6 1.118s go 1.1b 1.653s rust 0.6 opt 3 1.659s go 1.0.2 2.127s dart 0.4.4.4 2.384s pypy PyPy 1.9.0 5.094s pypy PyPy 2.0b 5.319s (Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz) Edit: Added java

It looks like Go 1.1 might be faster than Java. That might help convince enterprise developers to adopt it.

No way would a microbenchmark ever change any responsible person's mind about tooling. There are a lot of reasons (some of them nearly respectable) to use Java; "it's faster than " isn't one of them.

Re: Performance of Rust and Dart in Sudoku Solving

#44

Post by jayflux » Sat, Apr 06, 2013, 1:40 PM UTC

acjohnson55 wrote: post #12

Man, PyPy got destroyed, let alone CPython! As a Python lover, that's pretty disheartening. I'm not an expert in many of these languages, but it would seem as though it should be possible to build a Python interpreter as fast as V8, even without using Numpy to accelerate the math. Anybody have any thoughts as to why PyPy is such a poor performer here?

Python is a High Level language, it was never designed with the intention of being as fast as C or Java or other lower level languages.

As someone else pointed out the V8 has had a lot of backing and full time development, where as pypy, Cpython hasn't had as much. Pypy is still showing massive improvements despite being the slowest on that list.

Re: Performance of Rust and Dart in Sudoku Solving

#45

Post by coldtea » Sat, Apr 06, 2013, 1:48 PM UTC

pjmlp wrote: post #38

coldtea wrote: post #35

Earlier quoted context omitted.

> There are a few OS with such system programming languages, but it only counts when the likes of Apple, Microsoft and Google adopt such languages. There are a few OSs written with everything. It only counts when pragmatic, useful OSs are written with a language. Most of those OSs are unusable, slow, proof of concepts.

Native Oberon and AOS were used for real work as desktop workstations at Zurich's Technical University. Sadly no one in the industry decided to invest on them.

Sounds like natural selection.

Re: Performance of Rust and Dart in Sudoku Solving

#46

Post by jeremyjh » Sat, Apr 06, 2013, 2:33 PM UTC

I'm really excited about Rust's performance here, considering how young the compiler and its runtime are. It has to get much faster but that seems likely to be possible.

Re: Performance of Rust and Dart in Sudoku Solving

#47

Post by PuerkitoBio » Sat, Apr 06, 2013, 3:02 PM UTC

coldtea wrote: post #45

pjmlp wrote: post #38

Earlier quoted context omitted.

Native Oberon and AOS were used for real work as desktop workstations at Zurich's Technical University. Sadly no one in the industry decided to invest on them.

Sounds like natural selection.

Selection, yes. Natural? Do you somehow imply that technology that "wins" mass adoption is "better"? Or that it gains mass adoption based on rational analysis of its "value"? There are quite a few unnatural forces at play, here...

Re: Performance of Rust and Dart in Sudoku Solving

#48

Post by saosebastiao » Sat, Apr 06, 2013, 3:19 PM UTC

jfb wrote: post #43

melling wrote: post #37

Earlier quoted context omitted.

It looks like Go 1.1 might be faster than Java. That might help convince enterprise developers to adopt it.

No way would a microbenchmark ever change any responsible person's mind about tooling. There are a lot of reasons (some of them nearly respectable) to use Java; "it's faster than " isn't one of them.

Don't be silly. Java is extensively used for speed. It is an extremely fast language with a few caveats (such as startup/warmup time).

Re: Performance of Rust and Dart in Sudoku Solving

#49

Post by currymesurprise » Sat, Apr 06, 2013, 3:21 PM UTC

yaakov34 wrote: post #20

A small personal peeve: it doesn't make sense to say that Sudoku is NP-hard, as the linked post does (or NP-complete). First of all, this benchmark (as far as I can tell) uses only traditional 9x9 puzzles, of which there is a finite number. Problems with a finite input space are trivial from the point of view of complexity theory; in order to talk about any kind of completeness or hardness results, you need to genera…

The Valiant-Vazirani theorem says that both Unique and Unambiguous SAT are NP-hard under randomized reductions.

While this is not NP-hard under the usual definition, modern complexity theorists believe derandomization to be possible to a degree similar to their belief that P is not NP.

Re: Performance of Rust and Dart in Sudoku Solving

#50

Post by pjmlp » Sat, Apr 06, 2013, 3:54 PM UTC

coldtea wrote: post #45

pjmlp wrote: post #38

Earlier quoted context omitted.

Native Oberon and AOS were used for real work as desktop workstations at Zurich's Technical University. Sadly no one in the industry decided to invest on them.

Sounds like natural selection.

No, it just means so far Apple and Microsoft were not that interested into doing that. I don't count with the commercial UNIX vendors, except Sun, because those only care about C and C++, mainly.

But this is going to change slowly anyway.

Sun did experiment using Java in the Solaris kernel, they just didn't went that far due to what happen to them.

Apple first played with GC in Objective-C, and now you have ARC both in Mac OS X and iOS.

Microsoft played with Singularity, only allowed .NET applications on Windows Phone 7.x and Windows (Phone) 8 uses C++/CX, which uses a reference counting runtime (WinRT). While C is considered legacy for Microsoft (official version).

C++11 has reference counting libraries and a GC API for compiler implementers.

Android has Dalvik and the native applications are actually shared objected loaded into Dalvik. Contrary to what some people think the NDK does not allow for full development of C and C++ code, except for a few restricted system APIs.

Sailfish and Blackberry, Qt makes use of C++ with reference counting and JavaScript.

FirefoxOS and ChromeOS are anyway only browsed based.

If there is natural selection in this, it might just be that manual memory management is going to be restricted to the same set as Assembly. Interacting with hardware or for special cases of code optimization.

So a systems programming language using either GC or reference counting, with the ability of doing manual memory management inside unsafe regions, might eventually be the future.