That problem is that type of problem that is well suited for a prolog system with a constraint library.
Why is this Go faster than the equivalent Java?
51–60 of 105 posts
Re: Why is this Go faster than the equivalent Java?
#52I 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.
I, on the other hand, get the feeling from reading the article that the author understands that this performance difference was due to implementation differences, but wanted a more attention-grabbing title.
My subjective impression is that this is the first time the author has come across this sort of consideration in implementation and wanted to write about it. There is nothing wrong with that - in fact, I think it's great! It's just that the title leads one to expect, well, quite a bit more.
Re: Why is this Go faster than the equivalent Java?
#53I 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.
Looks like the author gets this, at the end they reveal what the difference was.
Re: Why is this Go faster than the equivalent Java?
#54Wouldn't it be possible to reduce the number of input combinations to all combinations where the proportion of money for each player is the same? For example (1,4,6) should give the same result as (2,8,12), but with different scaling-factor.
Find all random games for those proportions which end after 12 turns, then change the scaling factor to make it less than 255?
Re: Why is this Go faster than the equivalent Java?
#55The 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…
Trouble sleeping, so... rev #3: tighter packing of states -> ~25% run time reduction.
Re: Why is this Go faster than the equivalent Java?
#56Earlier quoted context omitted.
It hasn't been slow since basically 1.3 when HotSpot became default.
Urban legends tend to live forever.
Java is still slow in practice, particularly due to poor startup times, due to things like class scanning and the ecosystem of bloated libraries.
Re: Why is this Go faster than the equivalent Java?
#57Earlier quoted context omitted.
Urban legends tend to live forever.
Java is still slow in practice, particularly due to poor startup times, due to things like class scanning and the ecosystem of bloated libraries.
Only by those that don't have experience in Java tooling.
High startup costs you say? Then don't use OpenJDK.
Get an AOT compiler to native code like Excelsior Jet or switch to a JVM that supports both AOT compilation to native code and JIT code caching like IBM J9 or Azul.
class scanning ? Again stop using OpenJDK and switch to a JVM that supports class sharing across VM instances like IBM J9.
For those that don't want ever to use anything other than OpenJDK, some of those features might eventually come there, like the newly introduced support for AOT compilation of the base module for Linux x64. With everything else planned for Java 10.
Bloated libraries? Well, there are bloated libraries in any programming language.
And by any change you are thinking of JEE, I doubt you had the pleasure to use C or C++ alongside DCOM, CORBA and SUN RPC, at enterprise level to fully understand the relief it was to change to JEE.
Re: Why is this Go faster than the equivalent Java?
#58Earlier quoted context omitted.
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…
Controlling memory layout is one area that is very important for performance, where Java does not exactly shines. You essentially have to store your data in arrays of primitive types, to avoid memory overhead of objects (pointer to class, lock, gc bits) and additional indirection during access. While not exactly impossible, Java makes it quite inconvenient and costly to write code that takes control of memory layout.
Re: Why is this Go faster than the equivalent Java?
#59Earlier quoted context omitted.
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…
Controlling memory layout is one area that is very important for performance, where Java does not exactly shines. You essentially have to store your data in arrays of primitive types, to avoid memory overhead of objects (pointer to class, lock, gc bits) and additional indirection during access. While not exactly impossible, Java makes it quite inconvenient and costly to write code that takes control of memory layout.
Hence why there are ongoing improvements targeted to Java 10, to change exactly that.
Until then there are the IBM and Azul extensions, off heap memory, or optimizing in native code that 1% after using the profiler, where it really matters.
Re: Why is this Go faster than the equivalent Java?
#60Earlier 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.
If you can program well, and like some aspects of sysadmin-ing, then becoming a Site Reliability Engineer (at eg Google) might be for you. There are always looking for people.
(I used to work as an SRE, before I made my way back into functional programming and finance recently.)