Java vs. Go performance • Hacker News Board

Re: Java vs. Go performance

#51

Post by xtrumanx » Fri, Apr 24, 2015, 1:09 PM UTC

CookWithMe wrote: post #47

xtrumanx wrote: post #30

Earlier quoted context omitted.

What's wrong with having six lifecycle stages? I don't use JSF (or Java) but I can understand the usefulness of having several lifecycle methods assuming you can hook into them and add your own custom logic. The more lifecycle stages the more precisely you can choose when during the request processing your custom logic should be invoked.

You're right, there isn't anything wrong with the six stages per se. The root cause is really that (a) they're forcing a stateful model onto the web and (b) that the way they're keeping/restoring the state is expensive. The lifecycle stages are more a sympton of that. Most web framework these days go with a stateless approach. One notable exception is the lift framework for scala (although I'm not sure if it's really…

Oh sure, the stateful model thing you mention definitely sucks which is why I hate using asp.net web forms and prefer asp.net mvc at the office.

Both of them have lifecycle methods, (for app start, request start, request end, etc.) and for the most part I completely ignore them until the day I need to use them and I'm glad they exist because the alternative would have been writing a code in every endpoint of my application.

Re: Java vs. Go performance

#52

Post by mmf » Fri, Apr 24, 2015, 1:48 PM UTC

The way I read the results Java is basically faster only on the regex benchmark and it is known fact that today go has a slow regex library. Everything else the results show Java to be slower with larger code and larger memory footprint.

Why are all the Java fans psyched by these results?

Re: Java vs. Go performance

#53

Post by bcg1 » Fri, Apr 24, 2015, 2:31 PM UTC

lmm wrote: post #38

bcg1 wrote: post #6

Look, Java is my right hand language, and I've never written a single line of Go in my life. But this is kind of unfair I think... the OpenJDK JVM has 20 years of development behind it, and has probably had mountains of money sunk into tuning f* out of it by the biggest most enterprisy players in the game. I'm sure that there is a lot of low hanging fruit for Go to grab at to improve performance, and most likely will…

"Fair" to the Go designers? No. Go may indeed improve as time goes by. "Fair" to companies considering Go right now? Absolutely. If you're deploying a production system, you go to war with the army you have.

To clarify, I was making a point about the implication inherent in a "This vs. That" comparison... IMHO it is a total distraction, especially with contrived benchmarks, no matter how good they are.

A few years back I remember Brian Goetz (I think) wrote in an article that object creation in Sun's JVM was down to like 10 machine instructions (I assume on x86). How much effort will it take to get that down to 9, 8, 7?

On the other hand, choosing a language like Go that (I assume) still has a good deal of room from optimization could over time make applications run faster/better/cheaper without changing a single line of code.

As for the "you go to war with the army you have" idea... that's fine, but by far the biggest performance problems in nearly every application I've seen are the result of programming errors/laziness/deadlines, and there is nothing that any platform can do to optimize away those problems

Re: Java vs. Go performance

#54

Post by igouy » Fri, Apr 24, 2015, 4:22 PM UTC

chvid wrote: post #16

I find these benchmarks slightly dubious because everytime I look into the actual code I find that is written some obscure manner. For example - here is the code of the Java "knucleotide" benchmark: http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... (If I understand the website correctly.) Look at the way data is read (scanPastHeader, readRestIntoByteArray, fullSequence). Or how the result of calculateHa…

Currently 7 Java k-nucleotide programs are shown.

> the most natural or performant way of solving the problem in Java

"How to contribute programs"

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

Re: Java vs. Go performance

#55

Post by igouy » Fri, Apr 24, 2015, 4:39 PM UTC

bcg1 wrote: post #6

Look, Java is my right hand language, and I've never written a single line of Go in my life. But this is kind of unfair I think... the OpenJDK JVM has 20 years of development behind it, and has probably had mountains of money sunk into tuning f* out of it by the biggest most enterprisy players in the game. I'm sure that there is a lot of low hanging fruit for Go to grab at to improve performance, and most likely will…

> I'm sure that there is a lot of low hanging fruit for Go to grab at to improve performance, and most likely will.

If potential improvement becomes actual improvement, you'll most likely see that result when the measurements shown on this website are updated for that version of Go.

To-date the measurements for Go have been updated 9 times since Go 1.0 (3 years ago) and another 50 times in the 2 years before Go 1.0.

Re: Java vs. Go performance

#56

Post by igouy » Fri, Apr 24, 2015, 4:58 PM UTC

unoti wrote: post #18

Go has a significantly smaller memory usage in all of the benchmarks, often by a factor of 10x. For most workloads, this can have a huge impact on when you need to spend more money to support your business.

"Huge differences in default memory allocation don't necessarily mean there'll be huge differences in Memory-used for tasks that require memory to be allocated."

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

Re: Java vs. Go performance

#57

Post by igouy » Fri, Apr 24, 2015, 5:04 PM UTC

nextw33k wrote: post #29

This benchmark is out of date almost immediately because of the patch level of the Java runtime and the Golang compilers change frequently. I was half thinking of creating a VB6 module for LLVM just as a tongue in cheek joke of taking a language with a slow runtime and effectively strapping a V8 engine to it, but I saw someone already did most of the work: https://github.com/microcai/llvm-qbasic

> This benchmark is out of date almost immediately

Why do you think that matters?

Re: Java vs. Go performance

#58

Post by igouy » Fri, Apr 24, 2015, 5:07 PM UTC

mmf wrote: post #52

The way I read the results Java is basically faster only on the regex benchmark and it is known fact that today go has a slow regex library. Everything else the results show Java to be slower with larger code and larger memory footprint. Why are all the Java fans psyched by these results?

> faster only on the regex benchmark

fwiw Also binary-trees, pidigits, n-body.

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

Re: Java vs. Go performance

#59

Post by igouy » Fri, Apr 24, 2015, 5:16 PM UTC

obituary_latte wrote: post #2

There are also many options available to compare different languages. Very cool tool.

Also you can dive-into the source code and see the different ways people have written programs in the same language --

http://benchmarksgame.alioth.debian.org/u64q/performance.php...

Also for an overview --

http://benchmarksgame.alioth.debian.org/u64/which-programs-a...

Also for a different overview --

http://benchmarksgame.alioth.debian.org/u64/code-used-time-u...

Re: Java vs. Go performance

#60

Post by igouy » Fri, Apr 24, 2015, 5:19 PM UTC

karmakaze wrote: post #8

Interesting that the 32-bit speed is skewed more in Java's favor. I suppose the JVM was first 32-bit optimized where Go needn't be.

iirc The programs compiled with Go 8g for x86 have always shown slower than those compiled with Go 6g for x64.