61–70 of 156 posts
The rust version is using multiple cpus using a pool concept (which looks a lot like the multiprocessing module from python so kudos there). But the C version is single threaded from what I can tell. So rust is safe but threaded to be faster than single threaded C which isn't that much slower. Hmm...
From what I can see the C version is using OpenMP and uses all of the available CPU cores.
When SIMD goes stable rust may dominate that game. Still wish they would use clang so it was apples to apples with c and c++. Edit: actually I wish they would add clang for those languages and leave GCC for comparison. Then I'd want FORTRAN to add gfortran for the same reason.
e.g. felix or pony would dominate it then, over C++ with OpenMP.
Here only a missing fast C/C++ hash table is scewing the picture.
Earlier quoted context omitted.
Right. The only thing C had going for it was that it was the fastest non-assembly language. I'm biased, I want all C development halted and moved over to Rust. If C is no longer the fastest , for some definition of that, then no one should be defending it at this point. Honestly, I want the LLVM optimized C version specifically so that this last argument for C in any context will be taken off the table. I'm sure ther…
I am asking this genuinely, I always thought and heard LLVM optimizer is inferior to GCC's. Am I wrong ? is there any scientific benchmark for this ?
Basically, all you can really say is: LLVM is better at some code; GCC is better at other code. The differences are at the level of highly situational details at this point, not broad strokes.
LLVM IR could squeeze out some more. I should take a crack at it. Did something similar to show DuPont why Criterion rocked.
The hash table is implemented in safe Rust (By using std's Vec). It has some inefficiencies that could maybe have been polished off using `unsafe`.
Earlier quoted context omitted.
Right. The only thing C had going for it was that it was the fastest non-assembly language. I'm biased, I want all C development halted and moved over to Rust. If C is no longer the fastest , for some definition of that, then no one should be defending it at this point. Honestly, I want the LLVM optimized C version specifically so that this last argument for C in any context will be taken off the table. I'm sure ther…
>Right. The only thing C had going for it was that it was the fastest non-assembly language. Not really. C has lots of existing code, lots of developers who know it, and for many platforms it is the only language for which you'll find a compiler. As a language it is a trainwreck, but it does have a sizeable moat.
I've also experimented with just FFI for similar integration, with similar ease.
The point is, even with large code bases in C, you can start to migrate and stop feeding the beast.
quite a decent perf from the ML family at around 19 seconds (F# and Ocaml). Top of the functionals, at least, twice as fast as Haskell. Also look how ginormous the binaries are for all the VM languages. Kinda would have thought it would be the opposite what with not needing to link in as much runtime?
You could even argue that Rust is a member of the ML family seeing as the ML family of languages were major inspirations and furthermore I believe the original implementation of Rust was written in OCaml.
http://science.raphael.poss.name/rust-for-functional-program...
This post was a total revelation to me, even if I assume it's well known in the community, because it is very credible on the Sophie's Choice issue of mathematical purity versus acknowledgement of the reality of the instruction pointer-based imperative machine that exists underneath.
I've looked at other languages that "do" multiprocessing recently. Go is great, but it's essentially about getting large teams of variable-skill people to work together well. It's not an inspiring language, whereas Rust clearly is. Erlang (via Elixir) is very interesting, but the actor model will never be as performant in reality as the shared memory architecture. Julia is just a modern interpretation of matlab. A number of the JVM languages are great, but the "culture" of that ecosystem will always be corporate.
This is why I believe the science crowd could really gravitate to Rust, because it may have the ability, like the functional crowd, to satisfy the "search for beauty" aspect which motivates many academics, scientists, and indeed, programmers, all the while staying just the right side of pragmatism. And clearly targeting "where the puck is going" on massively multicore hardware.
The trial-and-error nature of scientific/data science discovery inevitably requires a REPL. If I had the right compiler/interpreter skills I would gladly contribute to making a Rust REPL happen. Unfortunately I don't. As it stands, all I can say is that if the REPL happens, I would be axed to contribute on the Rust scientific ecosystem with great motivation and pleasure.
The rust version is using multiple cpus using a pool concept (which looks a lot like the multiprocessing module from python so kudos there). But the C version is single threaded from what I can tell. So rust is safe but threaded to be faster than single threaded C which isn't that much slower. Hmm...
That's not true. If you look at the comparisons, the cpu time taken by C is actually more than rust, and the cpu load looks about even. Note the C version uses: #pragma omp parallel sections
Earlier quoted context omitted.
The default hash table has better security against malicious input by using a slower hashing algorithm. Its the right default, but if you really want performance and to compete with C/C++, you have to use an algorithm that makes different tradeoffs, or you would be comparing apples to oranges.
Do the hash tables in use by the C/C++ entries use low-security hash functions? Seems like that needs evidence.
impl Hasher for NaiveHasher {
fn write_u64(&mut self, i: u64) {
self.0 = i ^ i >> 7;
}
}
#define CUSTOM_HASH_FUNCTION(key) (khint32_t)((key) ^ (key)>>7)
struct hash{
uint64_t operator()(const T& t)const{ return t.data; }
};
- Rust: http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
- C: http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
- C++: http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
[46.03 secs] http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...)
and then the hash function was changed to FnvHasher --
[17.10 secs] http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
and then better use of quad core with futures_cpupool --
[9.44 secs] http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
and now use of std::collections::HashMap has been replaced with an experimental hash table inspired by Python 3.6's new dict implementation --
[5.30 secs] http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
afaict comparing #4 to #5 is all about differences between that experimental hash table and std::collections::HashMap --
[9.14 secs] http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
quite a decent perf from the ML family at around 19 seconds (F# and Ocaml). Top of the functionals, at least, twice as fast as Haskell. Also look how ginormous the binaries are for all the VM languages. Kinda would have thought it would be the opposite what with not needing to link in as much runtime?
The size of the binary isn't in that table. I think you're confusing it with the memory consumption numbers.