The HN title doesn't match TFA title. HN has a grammatical error.
Yes! Fixed. Sorry, we usually don't miss those for that long.
Why is this Go faster than the equivalent Java?
41–50 of 105 posts
Re: Why is this Go faster than the equivalent Java?
#42Epilogue: > 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-…
This is great, this comment deserves to be at the top. Let's not criticize the original article, and instead celebrate that its publication resulted in a crowdsourced solution. I love to see the community coming together to provide knowledge to us all. :)
Re: Why is this Go faster than the equivalent Java?
#43I 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.
Just like many squabbles over programming languages, not all, but many to most.
Re: Why is this Go faster than the equivalent Java?
#44The 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…
Hah I knew there was a better way to solve it! I was sort of sick of the problem by this point and didn't feel like picking it up again :) Glad to see someone else found it and implemented as well and proved that it produces a much faster calculation.
I added this at the end with a link to your solution and your post. Honestly I never expected this post to make it to the front page so thank you so much for taking some time out to do so.
Re: Why is this Go faster than the equivalent Java?
#45Earlier quoted context omitted.
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.
Yes. I can always change to sysadmin later on or just do both at once in a way.
Re: Why is this Go faster than the equivalent Java?
#46Earlier quoted context omitted.
And the final result was that the two languages had roughly the same performance, which may surprise folks that believe Java is still a slow language.
It hasn't been slow since basically 1.3 when HotSpot became default.
Urban legends tend to live forever.
Re: Why is this Go faster than the equivalent Java?
#47Earlier quoted context omitted.
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.
Agreed. I've been a sysadmin, tech support nerd, developer, architect and now product manager. With each switch the value you bring jumps.
Next switch is likely starting a business.
37 y.o., still not tired of this!
I can see how someone could get bitter if they stayed in the same role/position most of their career, but in my experience this has tended to be people with a negative outlook/attitude/chip on shoulder in general... It really is what you make of it, people are people wherever you go, some are dicks, some are not.
Just accept the reality of the game and deal with it.
You don't need to spread your aura of doom everywhere you go.
Re: Why is this Go faster than the equivalent Java?
#48Earlier quoted context omitted.
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.
I'd like to counter (but not disagree) with: in my experience, all good developers have significant sysadmin experience, whether professionally or self-taught.
As a tech lead of a team that is largely junior, I keep running into places where a lack of sysadmin-type knowledge seriously harms the ability of a CS degree holder (anywhere from BSc to PhD) to do real-world software engineering work unless they have either been self-taught in sysadmin sort of things or have had a couple years experience that has forced that sort of experience on them.
To give an example, a fresh-out-of-school CS degree holder that never played with Linux servers for fun in his own time might be able to implement some software and then easily learn to Dockerize it, but may be stuck for three days on getting it to talk to other services both locally and in a test environment because of essentially zero exposure to ideas in networking - and yet the fix to the problem takes about 5 minutes for someone with exposure to how networking works. ("What's a bridge?")
Another example comes from general familiarity with the server/client model: the rule of thumb to have a max number of worker threads equal to twice the cores available unless there is a reason to re-evaluate that.
All that said, I would still favor sticking with the CS degree as well. Basic practical familiarity with sysadmin concerns can be more or less picked up over time via personal projects and then as needed on the job, but the formal knowledge accumulated over a CS degree would be much harder to do that with. I would only suggest to make sure to spend time on personal projects that, for lack of a better term, are full-stack.
Re: Why is this Go faster than the equivalent Java?
#49Earlier quoted context omitted.
It's illusory to think that we have a choice. It's hard to avoid becoming obsolete over a long timespan.
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 disagree with this sentiment.
>Everybody has to do everything.
Everybody needs to have _at least some degree of familiarity_ with everything, yes. But that has always been the case. There is not and there never has been a job posting for someone to design algorithms and do nothing else, nor to deploy HTTP servers and nothing else.
I expect that if you pick any part of any software/hardware stack, anyone with a reasonable amount of experience would be able to give real-world examples where familiarity with several (and sometimes all) other parts of that stack are not only beneficial but sometimes necessary. I also expect that illustrations would be able to found from any point in the history of computing, up to and including now.
Re: Why is this Go faster than the equivalent Java?
#50Earlier quoted context omitted.
It hasn't been slow since basically 1.3 when HotSpot became default.
Urban legends tend to live forever.
I think that there is probably a large overlap between the population of people who believe this and the population of people that don't really know what bytecode or JIT compilation are.
In fact, I have asked a number of people under the impression that Java is slow to explain why they think it is slow. The answers have two flavors:
1. Its high level abstractions are computationally expensive. Sometimes this idea is supported by saying that garbage collection is very slow, sometimes by saying that the inability to directly manage memory means that it is done inefficiently, perhaps even inescapably so.
2. Compiling a program to an intermediary language that is not assembly but must be instead executed by something else (in this case, the JVM) must be slow.