On Windows and nodejs
Rick Tang on Nexus S
February 25th, 2014 4:08am
what's a good reason *to* use it ... ?
February 25th, 2014 6:06am
Same as anything else: It fits what you're doing. I honestly like the notion of using one language for basically everything, that's as close to the holy grail as you can get.
February 25th, 2014 7:48am
February 25th, 2014 8:28am
Cool benchmark FSK.
Another source of those sorts of metrics is http://www.techempower.com/benchmarks/
nodejs, like Go, is nice in that it encourages high performance, scalable asynchronous patterns (the C10K becomes boring, and it becomes the C10M problem). C#/.NET, as a comparative, has the potential of being fairly high performance, however for many users it encourages an implementation pattern where you end up with a product that fails when a dozen people hit it at the same time.
I went through a nodejs phase when it was the new shit and the credible alternatives were .NET/PHP/Java/Ruby. Now I'm more onto Go.
February 25th, 2014 9:18am
As an aside, node has been excellently supported on Windows for two and a half years now. The port was sponsored and spearheaded by Microsoft.
February 25th, 2014 9:38am
I've been thinking about Go. I still haven't seen job ads requesting it.
February 25th, 2014 10:23am
Java is a language/platform that I've always been down on (the updater in Windows is *shit*. It doesn't auto-update on my kids' PCs, and to perform the update you actually need a full-desktop admin account -- I can't even just launch the update as myself, but need to fully login), but it just constantly storms to the tops of virtually all performance charts, including those web framework tests.
Great showing by it considering its richness and support.
February 25th, 2014 10:37am
I don't see how "Java is 5x slower than C/C++" is a "good showing". I've had people swear up and down that Java is faster than C/C++ or at most 10% slower.
5x slower is pretty bad. It's like using a computer from 2009 instead of 2014.
February 25th, 2014 10:45am
Your benchmark was very specific, and almost certainly capable of dramatic optimizations. Did you profile it in Java?
February 25th, 2014 10:51am
No, I didn't put any effort into optimizing it. Actually, the Java part was written by one of my commenters and I didn't check it.
If you're going to optimize and tune the Java code then, to be fair, you should optimize and tune the version in each language. Having the exact same algorithm in multiple languages is the fairest comparison.
I don't believe it's possible to tune the Java code to beat the C/C++ version. The source code is on my blog and you're welcome to try.
February 25th, 2014 10:54am
Of course, nothing beats Assembly and C in that order.
King of programming languages:
Everything else is just making things easier by having additional layers.
February 25th, 2014 11:08am
My point is that the extra layers, if it's a 5x or 80x slowdown, may not be worth as much as you think.
February 25th, 2014 11:10am
February 25th, 2014 11:13am
February 25th, 2014 11:17am
Also, in C, I can do inline assembly if I really want. In higher-level languages, inline assembly is much harder or forbidden.
February 25th, 2014 11:33am
The Java version of the code has a critical fault that leads it to do the same work up to 5x more than the C version.
In the loop in evaluate it is supposed to iterate over the cards counting ranks and suits, and then, after that work is done, evaluate the hands.
In the C version that's what it does. In the Java version, courtesy of a misplaced closing brace, for each card as it's determining suit and rank it is then trying to figure out if it's 4 of a kind, full house, etc (obviously just wasted work when it hasn't even figured out the details).
That's just a comment before even looking for specific optimizations or profiling.
February 25th, 2014 11:46am
That's what I get for using someone else's code without checking it. I'll look at it carefully and re-run it myself.
February 25th, 2014 11:55am
I see, this part
for (int i=0; i!=5; ++i)
int card_rank = (int)(hand[i]%13);
int suit_rank = (int)(hand[i]/13);
Not only does that make the performance worse, it causes it to give the wrong answer. (Three Jacks will come out as a pair of Jacks.)
February 25th, 2014 11:58am
So How fast is the Java version with the fix in comparison to C++?
Me, myself and I
February 26th, 2014 8:17am
I didn't get a chance to test it yet.
February 26th, 2014 8:39am
On my machine, the fixed Java version runs in 0.307700 seconds per test iteration, on Sun/Oracle SE 1.7.0_21.
The C++ version, as compiled with /O2 with the Visual Studio 2012 C++ compiler, runs @ 0.3432 seconds per test iteration.
Effectively equivalent, which makes sense given that it is dominated by highly optimizable integer/array operations -- the VM is generating machine code just as the C++ compiler is (and FWIW it inlines almost everything, visible in profiling as the various internal functions disappear).
Obviously this is going to vary dramatically depending upon your Java VM and C++ compiler. FWIW, the incorrect original Java version runs in 0.7087 seconds per test iteration, so 2x slower than the C++ version, albeit incorrect.
As an aside, per your original blog entry FSK, it is worth considering multithreading from the perspective of seeing which languages make concurrency/solving easy (and thus actually done). One of the huge advantages of Go is that it makes it perversely easy to completely saturate all 120 threads on a new E7 v2.
February 26th, 2014 1:10pm
I was using -O3 --fast_math for gcc. Your PC must be faster than mine.
I should also re-check the Python version. I guess I can't trust my commenters.
Actually, Java came in faster than the C/C++ version, when you tried it.
I'm also going to use the program to generate a full strategy table (check every possible hand). That's a good use case for multithreaded, but I'll just leave it running for a week on my Linode.
February 26th, 2014 2:25pm
*I was using -O3 --fast_math for gcc*
On Visual Studio, /O2 is pretty much all optimizations, including auto-vectorizations as appropriate. In comparison the no-optimization build (/Od) runs at a rate of 0.7691 per iteration.
February 26th, 2014 3:13pm
I think Java got a rep for being a slow monstrosity from Java GUI apps. Those clunky pieces of shit were so many layers of abstraction, removed from the native experience, that they just made the whole platform stink.
But Java for services or even platforms has proven itself again and again. Yet I still have my bias that when I see a message bus is Java, for instance, I immediately consider it tainted.
February 26th, 2014 3:15pm