The HN title doesn't match TFA title. HN has a grammatical error.
Why is this Go faster than the equivalent Java?
31–40 of 105 posts
Re: Why is this Go faster than the equivalent Java?
#32Epilogue:
> EDIT - Thanks to Dolda2000 I have modified the Java version. It is now about the same speed as the GoLang version. Indeed the issue was the the games were created causing the Java version to have to simulate more games to determine if the game went long enough. With the changes it is running in about ~6 seconds now and has restored my faith in Java.
http://stackoverflow.com/questions/43082115/why-is-this-gola...
Re: Why is this Go faster than the equivalent Java?
#33Earlier quoted context omitted.
It's illusory to think that we have a choice. Engineers are "dev-ops" now and sysadmins are "site reliability engineers." Everybody has to do everything.
I do hate the 'devops' prefix. It's used indeterminately by everybody unfortunately, including at a recent client that didnt have devs. It's job title inflation, a bit like calling somebody a barista because they press the coffee button.
It's great when used well. I'm a (Java) developer/architect type, but being involved more in infrastructure and deployments makes me a better overall contributor. If I follow your reasoning, my job would have been "deflated", but it doesn't feel that way.
Re: Why is this Go faster than the equivalent Java?
#34Earlier quoted context omitted.
No, it's better. I basically got burned out writing the same code for 5 different financial companies so tried something new. Loved Linux, loved the CLI, loved the power it gave me. I've literally saved a startup when paged in a nightclub at 3am and having to type very carefully to fix their database replication. You need to pivot in work, especially as most of us will be working for 40 years+. I'm getting into the s…
Hmm... I was asking because I am about to graduate in CS. But I think I like Sysadmin stuff more.
Continue with your CS degree. In my experience, all good sysadmins have significant development experience. This is especially useful when working at small companies/startups.
Re: Why is this Go faster than the equivalent Java?
#35Earlier quoted context omitted.
I am a bit confused about what you are referring to. Are you saying that we do not have many choices when it comes to work? I am about to graduate, but a lot of people seem to be saying that once you gain experience it is easy to hop to different jobs.
After a while you get pigeonholed. You can hop jobs easily but it is the same shit, different name on the building. It is often easier to pivot inside a company then jump to a new company.
Personally I would appreciate when those who got pigeonholed into finding their consecutive jobs "the same sh*t" don't foreshadow that onto those yet to graduate. It's good that those coming into the job market newly know what to look out for, but the opportunities mentioned by the previous poster also mean that you can steer away from such shotty (I'm going with the auto-complete here) jobs... if you choose so.
Re: Why is this Go faster than the equivalent Java?
#36I get the sense that the author doesn't know about algorithmic complexity. This has nothing to do with language choice and everything to do with the algorithms used.
Re: Why is this Go faster than the equivalent Java?
#37[deleted]
Re: Why is this Go faster than the equivalent Java?
#38The moment I saw the problem I started coding :-)
https://gist.github.com/depp/3a6f0377284fbb9b33984063856051b...
Rather than brute forcing all possible permutations, we start from all possible final states and BFS backwards towards starting states. There are probably tons of opportunities for further optimization, but this takes ~800 ms on my desktop, and it only uses one core. We don't need to track the number of turns required to end each state, since the frontier will always consist of games which require the same number of turns to end.
Edit: Shrinking my data structures dropped runtime by 50%, and easy & cheap parallelism dropped runtime by another 75% on my four-core desktop. New runtime: 110ms (Intel i5 6600k). The key to the parallelism is that since the total amount of money never changes, we can assign a different total amount of money to each thread, and they'll never have to search the same states.
Re: Why is this Go faster than the equivalent Java?
#39faster then?
Re: Why is this Go faster than the equivalent Java?
#40The moment I saw the problem I started coding :-) https://gist.github.com/depp/3a6f0377284fbb9b33984063856051b... Rather than brute forcing all possible permutations, we start from all possible final states and BFS backwards towards starting states. There are probably tons of opportunities for further optimization, but this takes ~800 ms on my desktop, and it only uses one core. We don't need to track the number of t…
[deleted]