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

Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

unriskinsight.blogspot.com

Post reply on HN
Print view View original

41–50 of 115 posts

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#41

Post by praseodym »

SoapSeller wrote: post #32
humanrebar wrote: post #15

Earlier quoted context omitted.

The Intel and GNU C++ compilers usually produce even faster code than the compiler used (Clang). Also, if it's business critical, you can do heavy calculations through GPUs or other custom hardware.

Not for this example. On E5-2680 v2(Ivy Bridge): ./magic_forest_gcc 617 655 606 7.22s user 0.36s system 100% cpu 7.580 total ./magic_forest_icc 617 655 606 7.00s user 0.34s system 100% cpu 7.340 total ./magic_forest_clang 617 655 606 5.73s user 0.25s system 100% cpu 5.980 total gcc version 4.8.2 icc version 14.0.1 clang version 3.4 (On 3.14 powered arch linux) It's might be interesting to see what kind of optimisatio…

And then there's the question of what compiler flags you used. Furthermore, one of the compilers could be really good at profile-guided optimisation (PGO), beating the others.

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#43

Post by tagrun »

mtdewcmu wrote: post #8
zik wrote: post #2

It's pretty astonishing how easily C++ trounces everything else including Java. I guess there's still something to be said for compiling directly to optimised binaries.

Supposedly, Java is going to be faster than native code any day now. It's been said for years. The case was somewhat credible at one time, because the opportunity exists to optimize using runtime information. I think the reason it didn't go that way is: 1. CPUs have gotten very good at doing runtime optimization kinds of things on their own, like predicting branches and reducing the cost of virtual function calls. 2.…

I can't see it happening even in a far future except maybe for some artificial microbenchmarks. Java programs use a lot of memory, and since everything is allocated on the heap garbage collection is an issue, impacting real-world programs.

In terms of raw CPU speed, access to vector instructions directly can be game changer in various applications. Also C/C++ compilers are also getting better each day.

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#44

Post by speeder »

bottled_poe wrote: post #21

A message to the blog owner: get rid of that swipe to go forward/backward between posts when viewing on mobile. It looks good, but it is functionally frustrating. Why would a user expect different swipe behaviour in one direction to another?

This... I got kicked out of the post 4 times when scrolling. The first time I did not even knew why, I thought it was a stupid JavaScript redirect.

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#45

Post by FreezerburnV »

panic wrote: post #24
xxs wrote: post #7

Few major points: Using sort to filter duplicates is horribly worse compared to hashing (javascript for instance). Java version has rather poor impl, it's interesting to see the GC+allocation cost and the GC type used. C++ version does not use really use func. prog in find_stable_forests and meal...

Using sort to filter duplicates is horribly worse compared to hashing (javascript for instance). Is this really true? A sort plus a linear scan has very low constant time factors, good cache locality (depending on the sorting algorithm used), and no need to allocate if you're sorting in place. I've seen good results using sort to filter duplicates in my own performance-sensitive code. Are you saying this technique is…

Just to add to the discussion: you're likely correct, based on this SO question:

http://stackoverflow.com/questions/11227809/why-is-processin...

It will likely get faster the more duplicates you have, as it allows the CPU to predict a branch more reliably several times before being wrong and having to re-do some of its prediction stuff. (note that I'm not experienced with optimizing stuff, dealing with cache optimizations, etc., but I have read a decent amount, and I did take a class about CPU architecture) I would also suspect that hashing might end up messing with memory all over the place, causing the cache to be partly useless.

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#46

Post by aeroevan »

mtdewcmu wrote: post #30
cbsmith wrote: post #26

Earlier quoted context omitted.

> Supposedly, Java is going to be faster than native code any day now. You'll note that the FORTRAN native code is indeed beaten by Java.

It's worth remembering that native code isn't fast automatically. An unskilled programmer, for instance, could easily write C++ that's slower than Java. There are a few possible reasons Fortran wasn't faster: 1. Fortran's compilers haven't advanced at the same rate as other languages due to its lack of popularity. 2. Fortran is inherently harder to optimize. 3. People have forgotten how to write fast Fortran, since n…

This was probably more of a case of 3.

Fortran compilers have been making quite some progress (particularly ifort, but gfortran isn't bad recently).

And due to the way multidimentional arrays are built into the language, aliasing isn't nearly as much of an issue for aggressive optimizations.

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#48

Post by rdtsc »

tagrun wrote: post #43
mtdewcmu wrote: post #8

Earlier quoted context omitted.

Supposedly, Java is going to be faster than native code any day now. It's been said for years. The case was somewhat credible at one time, because the opportunity exists to optimize using runtime information. I think the reason it didn't go that way is: 1. CPUs have gotten very good at doing runtime optimization kinds of things on their own, like predicting branches and reducing the cost of virtual function calls. 2.…

I can't see it happening even in a far future except maybe for some artificial microbenchmarks. Java programs use a lot of memory, and since everything is allocated on the heap garbage collection is an issue, impacting real-world programs. In terms of raw CPU speed, access to vector instructions directly can be game changer in various applications. Also C/C++ compilers are also getting better each day.

> Java programs use a lot of memory, and since everything is allocated on the heap garbage collection is an issue, impacting real-world programs.

That is a very good observation. Looking at back in the past at some point memory speed wasn't that much slower than CPU speed (rather because CPU speeds were not that fast then).

So then throwing more memory at something seems like a very good way improve performance. Like say following long chains of pointers through some nested structure or long linked list was ok. At some point CPU speed went through the roof and left memory access speeds behinds.

So then caches became very important. Cache aware programming was a "thing".

That, coupled with lots having virtualized/cloud machines everywhere that have limited memory kind of turned that initial thinking on its head. Small memory footprint became a desirable trait. Just like in the old MS-DOS & Turbo Pascal days.

Java sort of flourished and grew in that time period where "throw more ram at it to get performance" was a very obvious thing to do. Now I think it is less obvious that is the best way.

(And perhaps Java's current or future GC and JIT strategies will start to take into account caches and memory frugality better).

Now that said I am still amazed at how it can achieve such great performance given all the stuff it does behind the scenes. It is not faster than C but heck, it is very fast still.

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#49

Post by kmavm »

Afforess wrote: post #10
mtdewcmu wrote: post #8

Earlier quoted context omitted.

Supposedly, Java is going to be faster than native code any day now. It's been said for years. The case was somewhat credible at one time, because the opportunity exists to optimize using runtime information. I think the reason it didn't go that way is: 1. CPUs have gotten very good at doing runtime optimization kinds of things on their own, like predicting branches and reducing the cost of virtual function calls. 2.…

I have never seen Sun or Oracle make that claim. You seem to simply be ranting on about a strawman argument, with a rather strange java-hate obsession. I mean, Fortran did worse than Java. Where is your writeup for that?

Cliff Click, a smart man in whom I see many admirable qualities, than whom there are few more complete experts on the JVM, gave a tech talk at Facebook about how Java is faster than C++ just a few months ago. Tons of perfectly smart engineers sat and took it seriously. Much of the content was a rehash of this older discussion: http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-p...

There are plenty of serious, technically deep people trying to convince their colleagues that Java is as fast as C.

Re: Performance comparison of Functional C++ 11, Java 8, JavaScript and Wolfram

#50

Post by SoapSeller »

praseodym wrote: post #41
SoapSeller wrote: post #32

Earlier quoted context omitted.

Not for this example. On E5-2680 v2(Ivy Bridge): ./magic_forest_gcc 617 655 606 7.22s user 0.36s system 100% cpu 7.580 total ./magic_forest_icc 617 655 606 7.00s user 0.34s system 100% cpu 7.340 total ./magic_forest_clang 617 655 606 5.73s user 0.25s system 100% cpu 5.980 total gcc version 4.8.2 icc version 14.0.1 clang version 3.4 (On 3.14 powered arch linux) It's might be interesting to see what kind of optimisatio…

And then there's the question of what compiler flags you used. Furthermore, one of the compilers could be really good at profile-guided optimisation (PGO), beating the others.

I've used the same flags like the OP have suggested in the source header comment.
Post reply on HN