4 ms·
Interesting to see Go benchmarks fall right out of the top 10 on the 10GbE machines while Java/JVM and even Javascript do amazingly well. My guess at 10GbE you
by nemothekid 13y ago
Interesting to see Go benchmarks fall right out of the top 10 on the 10GbE machines while Java/JVM and even Javascript do amazingly well. My guess at 10GbE you are now testing how much the framework spends on the CPU.
- JulienSchmidt 13y agoMy guess is that Go, especially the database/sql package, uses too expensive synchronization. Most of the pool management code uses mutual exclusion which can get really expensive when 40 threads compete for it.
- iends 13y agoIt would be nice if the golang community investigates this further. For a language with high concurrency as a feature it's disappointing that it drops off so much.
- sandGorgon 13y agothere's something funny - for the multiply queries benchmark [1], Go is performing worse than codeigniter, kohana. But cpoll_cppsp-postgres is performing worse than codeigniter-raw . anybody know what's going on .. is a full PHP framework performing better than raw c++ under certain conditions? [1] http://www.techempower.com/benchmarks/#section=data-r9&hw=peak&test=query http://www.techempower.com/benchmarks/#section=data-r9&hw=pe...
- pkroll 13y agoSure: Raw C++ isn't necessarily OPTIMAL C++, and PHP is really, really optimized for the read-multiple-queries-render-to-a-page case (at least for MySQL it is).
- Loic 13y agoPHP is for these tests, nginx and 256 to 512 PHP processes under PHP-FPM. Not a single process. If you put 40 Go processes behind nginx, each one allowed to use only 2 to 4 processors, you will get notably different results. Anyway, the tests show how hard it is to scale to many processors with a single process. It shows that the Java VM is really good at it (to be expected, Sun always had systems with insane numbers of cores).
- agnsaft 13y agoAnyone know why this is? This was quite disappointing...
- lazyjones 13y ago> My guess at 10GbE you are now testing how much the framework spends on the CPU. Not really, it's more a benchmark of the runtime and its networking code probably. It would also be interesting to see a trace / summary of the syscalls for benchmarking runs.
- chrismoos 13y agoIt probably has something to do with NUMA. Java 7 has a NUMA supported allocator that makes it more likely for threads to access memory from their local node. I'd be interested to see the golang test running with multiple processes, with each one running on an individual NUMA node.