Live data from Hacker News

New Rust hash table leads Benchmarks Game

benchmarksgame.alioth.debian.org

91–100 of 156 posts

Re: New Rust hash table leads Benchmarks Game

#91

Java is showing quite impressive numbers! 50% overhead over native C implementations was often cited as a good guess for the ultimate efficiency of JIT code generation back in the Self Hotspot days. People who were trying to castigate Go early on as having "Java-like speeds" were really just showing their ignorance of the state of the art of JIT compilation for managed languages and the JVM. Such outdated folk knowle…

There are lots of folk programming like the impact of bounds checking or that all game consoles except for XBox use OpenGL.

Also many younger developers believe that C was always fast, and are unaware that early 8 and 16 bit compilers for home computers were like managed languages. The compilers generated way worse code than hobby Assembly developers.

Re: New Rust hash table leads Benchmarks Game

#92

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.

Sure, but I'm less worried about absolute rank and more interested in whether the language I'm using is on the order of C/C++/Fortran. I can sell a 2x slowdown to my boss if I can show that that's the only cost of a significantly more elegant and productive language, but at 100x that's a much harder sell.

Just be careful to remember that good performance on microbenchmarks does not necessarily translate to good performance on large applications. Some factors to consider are:

1. Cache performance and locality may differ considerably for large applications. For example, a microbenchmark may perform well because it can monopolize the L1 cache in a way that is not possible for larger applications.

2. Aggressive inlining, a common factor in microbenchmark performance, may not scale well for large code bases. The tradeoffs here can be rather complex: https://webkit.org/blog/2826/unusual-speed-boost-size-matter...

3. Microbenchmarks often avoid abstraction in order to achieve high performance. This can create unacceptable software engineering costs.

Re: New Rust hash table leads Benchmarks Game

#93
post #41

Earlier quoted context omitted.

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 ther…

> The only thing C had going for it was that it was the fastest non-assembly language.

Which only happened after the widespread of UNIX clones into the industry.

Back in the 80's and early 90's, the C compilers for 8 and 16 bit home computers generated pretty crappy code, versus what humans were able to write in Assembly.

Re: New Rust hash table leads Benchmarks Game

#94
post #41

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…

> it is 2017 and we don't have single good IDE for them

What are your criteria for a good IDE for C/C++?

Re: New Rust hash table leads Benchmarks Game

#95
post #47

Earlier quoted context omitted.

That's why they call it a game.

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

Huh, I could have sworn at the time that that was the reason but C2 backs it up: http://wiki.c2.com/?GreatComputerLanguageShootout

Maybe they should remove 'game' from the title if they need an FAQ for it. Or even better they should acknowledge that it is a game.

Re: New Rust hash table leads Benchmarks Game

#96

Earlier quoted context omitted.

Sure, but I'm less worried about absolute rank and more interested in whether the language I'm using is on the order of C/C++/Fortran. I can sell a 2x slowdown to my boss if I can show that that's the only cost of a significantly more elegant and productive language, but at 100x that's a much harder sell.

Just be careful to remember that good performance on microbenchmarks does not necessarily translate to good performance on large applications. Some factors to consider are: 1. Cache performance and locality may differ considerably for large applications. For example, a microbenchmark may perform well because it can monopolize the L1 cache in a way that is not possible for larger applications. 2. Aggressive inlining,…

It's still useful as a potential filter. If someone's implemented your microbenchmark in langB and it's within 2x of langA, then maybe they're worth comparing. If on the other hand langB is 20x away from langA in microbenchmarks, you can be pretty sure that it won't ever be a good replacement.

Re: New Rust hash table leads Benchmarks Game

#97

Java is showing quite impressive numbers! 50% overhead over native C implementations was often cited as a good guess for the ultimate efficiency of JIT code generation back in the Self Hotspot days. People who were trying to castigate Go early on as having "Java-like speeds" were really just showing their ignorance of the state of the art of JIT compilation for managed languages and the JVM. Such outdated folk knowle…

HotSpot has had great speeds for numeric computation at least since 2005. I was doing financial software in Java in my first job out of college, our CTO was an ex-Sun architect who literally wrote the book on Java, and the speeds we got on numerical computations were basically equivalent to C.

The part where Java really falls down is in memory use & management, which you can see on the binary-tree & mandelbrot benchmarks, where it's roughly 4x slower than C. There are inherent penalties to pointer chasing that you can't get around. While HotSpot is often (amazingly) smart enough to inline & stack-allocate small private structs, typical Java coding style relies on complex object graphs. In C++ or Rust these would all have well-defined object ownership and be contained within a single block of memory, so access is just "add a constant to this pointer, and load". In Java, you often need to trace a graph of pointers 4-5 levels deep, each of which may cause a cache miss.

Rule of thumb while I was at Google was to figure on real-world Java being about 2-3x slower than real-world C++.

Re: New Rust hash table leads Benchmarks Game

#98
post #91

Java is showing quite impressive numbers! 50% overhead over native C implementations was often cited as a good guess for the ultimate efficiency of JIT code generation back in the Self Hotspot days. People who were trying to castigate Go early on as having "Java-like speeds" were really just showing their ignorance of the state of the art of JIT compilation for managed languages and the JVM. Such outdated folk knowle…

There are lots of folk programming like the impact of bounds checking or that all game consoles except for XBox use OpenGL. Also many younger developers believe that C was always fast, and are unaware that early 8 and 16 bit compilers for home computers were like managed languages. The compilers generated way worse code than hobby Assembly developers.

> early 8 and 16 bit compilers for home computers were like managed languages

Yeah, I wrote several published games entirely in assembly back when that was really the only reasonable option.

Of course some of the things we had to deal with meant that even the compilers were good, they couldn't have been good enough.

Extreme limited memory is the obvious one, but pages that need to be swapped out at runtime is the other one. An example: The Game Boy had 64k of memory addressing, but would ship with 128k and larger cartridges. 32k of the memory space was reserved for video memory, RAM, and hardware registers (if I remember correctly). The first 16k of memory was always mapped to the first 16k of ROM, but the second 16k of memory was mapped to arbitrary 16k blocks of ROM. 16k wasn't enough space to hold your entire game, so some code would leak into other pages (hopefully not more than ONE other page), but you also had to be able to swap other ROM pages into that second 16k memory region to, e.g., load graphics and game data.

There isn't a compiler around even today that can juggle all of that automatically. At a minimum you'd need to be marking different functions as belonging to different memory regions, but you'd still have to manually keep track of which function was where and ensure you don't try to call a region-2 function from a region-1 function when region-2 is some arbitrary ROM page instead of the extra code page. But often something in region-2 needs to call region-1 to load graphics into sprite registers and then restore region-2 so that the stack frame becomes valid again. :)

And 32k is SUCH a small amount of memory that being able to chip away at every single function was important. You have a function that does two things, but sometimes you just need to do the second? Put a label halfway through and call directly into the middle. You can save a byte here by loading one register into another, because you know that the registers will have the right values? Or you can save another byte there because you've realized that a particular constant is loaded a lot, and you can store that constant into one of the 128 cheap-memory locations? Do it! We need every byte...

Yes it would be possible to write such a compiler, but the level of effort to customize it to the specific architecture would be extreme. Easier to just make programmers do the hard work.

Re: New Rust hash table leads Benchmarks Game

#99

Earlier quoted context omitted.

Just be careful to remember that good performance on microbenchmarks does not necessarily translate to good performance on large applications. Some factors to consider are: 1. Cache performance and locality may differ considerably for large applications. For example, a microbenchmark may perform well because it can monopolize the L1 cache in a way that is not possible for larger applications. 2. Aggressive inlining,…

It's still useful as a potential filter. If someone's implemented your microbenchmark in langB and it's within 2x of langA, then maybe they're worth comparing. If on the other hand langB is 20x away from langA in microbenchmarks, you can be pretty sure that it won't ever be a good replacement.

As long as you have people of roughly equivalent skill level within their language implementing the microbenchmarks. It's not that hard to get a 10x or even 100x speed improvement in the same language when an expert rewrites the naive code that a newbie wrote.

Re: New Rust hash table leads Benchmarks Game

#100
post #69

Previously std::collections::HashMap was used with the default hash function -- [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…

> experimental hash table

When discussing whether or not to use this at least someone mentioned that there company was using it in production. I don't think it really counts as experimental.

Post reply on HN