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

New Rust hash table leads Benchmarks Game

benchmarksgame.alioth.debian.org

Post reply on HN
Print view View original

41–50 of 156 posts

Re: New Rust hash table leads Benchmarks Game

#41

Post by 0xFFC »

bluejekyll wrote: post #34
masklinn wrote: post #30

Earlier quoted context omitted.

Circa 2011 the maintainer of the benchmark game decided to mostly only allow one implementation of each language[0] following pypy developers trying to get program alternatives which weren't pypy-pessimal. [0] some languages get a bye for some reason e.g. MRI and JRuby, but no pypy, and which implementation is blessed is also arbitrary e.g. javascript is v8 but lua is lua.

2011 didn't have as widespread Clang/LLVM usage. Now that it is so ubiquitous, probably a good time to revisit for C... C needs to defend its reputation now!

I am saying this as someone who loved C for my entire life, when I was in college I did implement most of the assignments in C when prof said python is okay, but I did in C because I loved it and I thought I would learn more by doing them in C.

So no hard feeling involved.

There is no reputation to defend. You mean security problems everywhere ? do you mean old, broken, nasty build systems ? Do you mean not having single good package management ? The language (C/C++) is clearly intractable (parsing wise), it is 2017 and we don't have single good IDE for them (I don't use IDE at all, but I am sure you agree with me how much an IDE is important for newcomers)

If that is the case I think writing assembly would outperform C like shit, and with that logic asm is much better than C.

And to be honest, I am in job finding phase and preparing for jobs, if this wasn't my plan right now, I would abandoned C and C++ (even C++{11,14}) for Rust in heartbeat.

The language (Rust) clearly is awesome language, well designed, does have perfect build system (have you seen Cargo ? it is wonderful), flexible language design (you can write OS in rust -not having runtime- and you can write web app in Rust). I am stuck with C and C++ for now, but if my opinion counts , Rust is superior in every aspect to C/C++.

Even if Rust were slower a little bit (+/- 10%) I wouldn't mind. Because its ecosystem is so healthy I would trade 10% of my program performance to having something as nice as Rust.

Re: New Rust hash table leads Benchmarks Game

#42

Post by igouy »

masklinn wrote: post #30
Sean1708 wrote: post #12

Earlier quoted context omitted.

Is there any reason why we can't have a "C clang"? Or has just nobody bothered yet?

Circa 2011 the maintainer of the benchmark game decided to mostly only allow one implementation of each language[0] following pypy developers trying to get program alternatives which weren't pypy-pessimal. [0] some languages get a bye for some reason e.g. MRI and JRuby, but no pypy, and which implementation is blessed is also arbitrary e.g. javascript is v8 but lua is lua.

> alternatives which weren't pypy-pessimal

Not true.

Back-in-the-day Joe LaFata contributed specially written-for PyPy pi-digits, spectral-norm, mandelbrot programs and they were all shown on the website side-by-side with the CPython programs.

Back-in-the-day I noticed the Python n-body program failed with PyPy, I asked about the problem and was told "we have nbody_modified in our benchmarks" and then I asked them to contribute the specially modified for PyPy program -- and it was displayed on the website within 3 hours.

https://morepypy.blogspot.com/2010/03/introducing-pypy-12-re...

Re: New Rust hash table leads Benchmarks Game

#43

Post by igouy »

Sean1708 wrote: post #12
staticassertion wrote: post #8

Earlier quoted context omitted.

Yeah, I think SIMD will be the next big jump for these benchmarks. I also wish we could see clang used with the C/C++ cases.

Is there any reason why we can't have a "C clang"? Or has just nobody bothered yet?

"If you're interested in something not shown on the benchmarks game website then please take the program source code and the measurement scripts and publish your own measurements."

http://benchmarksgame.alioth.debian.org/play.html#languagex

Re: New Rust hash table leads Benchmarks Game

#44

Post by masklinn »

sanxiyn wrote: post #25
santaclaus wrote: post #11

Cool! Is Rust's hash table open addressed?

Yes. It's open addressing, linear probing, Robin Hood hashing. https://doc.rust-lang.org/std/collections/struct.HashMap.htm...

The program which reached the top of k-n does not use the standard library's hashmap, it uses ordermap: https://github.com/bluss/ordermap

Though that's also an open addressed map.

Re: New Rust hash table leads Benchmarks Game

#46

Post by bluejekyll »

0xFFC wrote: post #41
bluejekyll wrote: post #34

Earlier quoted context omitted.

2011 didn't have as widespread Clang/LLVM usage. Now that it is so ubiquitous, probably a good time to revisit for C... C needs to defend its reputation now!

I am saying this as someone who loved C for my entire life, when I was in college I did implement most of the assignments in C when prof said python is okay, but I did in C because I loved it and I thought I would learn more by doing them in C. So no hard feeling involved. There is no reputation to defend. You mean security problems everywhere ? do you mean old, broken, nasty build systems ? Do you mean not having si…

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 there are some people saying, "but it's not using the same compiler backend and optimizer...", I want this to counter that.

Rust all the things.

Re: New Rust hash table leads Benchmarks Game

#47

Post by igouy »

IshKebab wrote: post #21
chris_overseas wrote: post #17

It seems to me that there are a lot of apples-to-oranges comparisons here? Some implementations are using the language's standard library hashtable implementation while others are using 3rd party version (with different algorithms and data structures across all of them), some are using multiple threads while others are single threaded etc. As a result, I wouldn't read too much into the rankings you see here.

That's why they call it a game.

http://benchmarksgame.alioth.debian.org/sometimes-people-jus...

Re: New Rust hash table leads Benchmarks Game

#48

Post by igouy »

chris_overseas wrote: post #17

It seems to me that there are a lot of apples-to-oranges comparisons here? Some implementations are using the language's standard library hashtable implementation while others are using 3rd party version (with different algorithms and data structures across all of them), some are using multiple threads while others are single threaded etc. As a result, I wouldn't read too much into the rankings you see here.

Correct!

http://benchmarksgame.alioth.debian.org/u64q/knucleotide-des...

Re: New Rust hash table leads Benchmarks Game

#49

Post by infogulch »

gens wrote: post #39
infogulch wrote: post #19

Earlier quoted context omitted.

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

>.. and the cpu load looks about even. 318% is 20% bigger then 265%.

And 5.30s is about 20% faster than 6.46s. We're just throwing around numbers now.

My point was that the cpu load is "about even" compared to if the C version was single-threaded, in which case it would look more like 200-300% bigger cpu load instead of merely 20%.

Re: New Rust hash table leads Benchmarks Game

#50

Post by igouy »

galangalalgol wrote: post #2

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.

"If you're interested in something not shown on the benchmarks game website then please take the program source code and the measurement scripts and publish your own measurements."

http://benchmarksgame.alioth.debian.org/play.html#languagex

Post reply on HN