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

Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

benchmarksgame.alioth.debian.org

Post reply on HN
Print view View original

51–60 of 132 posts

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#51

Post by Terribledactyl »

nodesocket wrote: post #5

The Go vs JavaScript lineup is quite stunning. Go destroys Node.js in memory usage and performance on every test except regex-redux (edge case?). http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

>regex-redux (edge case?)

It looks like the JS version is using the built in runtime's regex engine.

I don't know exactly why (maybe differences or missing features in go's regex) but the go version is actually using the c FFI to call pcre.h, and without profiling it I'd guess a huge hit is that alone.

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#53

Post by EGreg »

adventured wrote: post #37
Xoros wrote: post #8

So PHP is faster on most of those test than python or ruby ? I'm I missing something ? I thought everyone hating PHP ( also) because it was slow.

PHP 7 is extremely fast. There was some legitimate criticism to be had about PHP 5.x being slow, especially if it wasn't paired with an opcode cache system / accelerator.

PHP is fast, faster than Node.js even.

But in practice, the Node.js ecosystem is all built around evented I/O and PHP has to execute them one at a time.

(Well, actually with libraries like Kraken and ReactPHP and amp, you can have an event loop, but there are not that many I/O options for you.)

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#54

Post by alayne »

Safety1stClyde wrote: post #7
nodesocket wrote: post #5

The Go vs JavaScript lineup is quite stunning. Go destroys Node.js in memory usage and performance on every test except regex-redux (edge case?). http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

> The Go vs JavaScript lineup is quite stunning. Go destroys Node.js in memory usage and performance on every test except regex-redux (edge case?). Why would it be stunning that a programming language compiled to assembler can beat a broken-by-design interpreted language which doesn't even have integers or arrays? The stunning part is that the people behind node.js have managed to get that much performance.

That's not a very fair or accurate description. JavaScript implementations use a JIT which is different than what people usually mean by interpreted. Types can be inferred without explicit type declarations. JavaScript has Array and integer semantics can also be inferred.

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#55

Post by alayne »

Safety1stClyde wrote: post #27
baron816 wrote: post #19

Earlier quoted context omitted.

There's plenty to not like about JS, but being interpreted and not having integers or arrays is not high on its negatives list. The little bit of good far outweighs the whole lot of bad. If you don't enjoy JS, it's because you haven't taken the time to learn what's great about it and have gotten hung up on the stupid things other people do with it or you're copying their mistakes.

> There's plenty to not like about JS, but being interpreted and not having integers or arrays is not high on its negatives list. We are having a discussion is about programming language benchmarks. A benchmark in this case is a measure of how fast a computer program can run. A computer program is a series of instructions for a computer. These instructions are written in something called a programming language . A pr…

JavaScript is compiled to assembly language in modern runtimes like v8. You are confusing a language with the language implementation.

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#56

Post by rurban »

SwellJoe wrote: post #9

Hey, the benchmark game got a new website (at some point in the several years since I looked at it last)! Almost simplistic, but nice to read. As someone that works predominantly in a language long considered passé (Perl), I always kinda relish seeing that it is still faster than Python and Ruby for many problems. As Python and Ruby have gotten faster, I'd sort of assumed they were both notably and clearly faster tha…

Perl is only faster here in nbody because I tricked it. I used a tricky compile-time optimization for faster array index access. You wouldn't do that in the real world, and in the real world PHP, ruby and python are faster. cperl instead is only beaten by PHP. But the benchmark game is not open for faster alternate engines like luajit, nim, crystal, pypy, truffle-graal, ... or even slower ones like Perl6, which limits the impact of those better engines.

Decades ago it was open and written in Perl. Then it was rewritten in Python and closed down. Go figure.

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#57

Post by alayne »

dpratt wrote: post #14

Any benchmark that includes a JVM language always makes me look for a disclaimer that they allowed for proper JIT/warming time by running the benchmark a few times in the same VM instance before collecting the numbers. I may have missed it in this article, but I didn't see it. Yes, startup time is a concern with the JVM, but that's not what it's built for - it's meant for long-runnning repeatable code paths.

He doesn't do warmups for JITted languages.

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#58

Post by rurban »

Xoros wrote: post #8

So PHP is faster on most of those test than python or ruby ? I'm I missing something ? I thought everyone hating PHP ( also) because it was slow.

php7 was threatened by hhvm and was completely rewritten by keeping backcompat. It's now the fastest major old scripting language. js and luajit are in the very fast ballpark, php in the middle and the other 3 far behind.

PHP also has the best language features and IDE integrations, the only remaining problem is the legacy stdlib and devbase. Ruby with an inliner and method cache would catch up, but I don't see it happen. Python is doomed by its architecture. Perl has a faster interpreter loop, but data structure bloat and similar dev problems as the other 2.

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#59

Post by LanceH »

FrozenVoid wrote: post #48

Years ago i was naive enough to believe these benchmarks. Now i know these are Potemkin-village level stunts and political maneuvering by language activists and staff of that site. If you really want actual benchmarking you have to do it yourself and read the .asm output for comparison. Another caveat is that some languages are genuinely faster in one hyperoptimized case(even faster than C) but fail horribly when thi…

I don't find the .asm output to be meaningful at all. The realistic comparison for me is if I write a solution the easiest/most convenient way in each language, which language is naturally more efficient.

Re: Benchmark: Java, Python, PHP, C, JavaScript, Swift, Ruby, Perl, Go, Lua, Rust

#60

Post by mpweiher »

dpratt wrote: post #14

Any benchmark that includes a JVM language always makes me look for a disclaimer that they allowed for proper JIT/warming time by running the benchmark a few times in the same VM instance before collecting the numbers. I may have missed it in this article, but I didn't see it. Yes, startup time is a concern with the JVM, but that's not what it's built for - it's meant for long-runnning repeatable code paths.

> that's not what it's built for

There was nothing in the original design that said "only long running server processes". In fact, Java was originally aimed at set-top boxes, then web applets, then cross platform GUI apps. It was only after it failed in all of these that the server was discovered, despite the fact that "write once, run anywhere" is almost completely pointless when you control the hardware it runs on.

The long startup times are a limitation of the implementation technology, not a principled design choice. See also: Jitterdämmerung ( http://blog.metaobject.com/2015/10/jitterdammerung.html )

Post reply on HN