RIP Philo

On Windows and nodejs

Sorry, forgot that nodejs is available on Windows.

And Azure

So one fewer excuse to not use nodejs!
Permalink Rick Tang on Nexus S 
February 25th, 2014 4:08am
what's a good reason *to* use it ... ?
Permalink eek 
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.

A document database that stores JSON for the backend, Node.js for the server-side code, Javascript with framework for the front end.  Javascript from top to bottom.  That's pretty impressive.
Permalink Somebody 
February 25th, 2014 7:48am
One(ish) stack to keep in your head.  A certain syntactic and  library unity.  Leaving aside your basic affection (or lack) for javascript....
Permalink Bot Berlin 
February 25th, 2014 8:28am
I did a benchmark test.

C/C++ is the fastest (duh)
Javascript(V8) is 3x slower than C/C++
Java is 5x slower
Python is 80x slower
PHP is 300x slower

So, among all the languages I (and MP) tried in my benchmark test, Javascript came in 2nd performance wise!  This was something with number-crunching, not asynchronous I/O.
Permalink FSK 
February 25th, 2014 8:35am
Cool benchmark FSK.

Another source of those sorts of metrics is

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.
Permalink df 
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.
Permalink df 
February 25th, 2014 9:38am
I've been thinking about Go.  I still haven't seen job ads requesting it.

I'm still looking for a language that has the same performance as C/C++, but the benefits of a higher-level language.  According to my benchmark, Javascript, Java, and Python don't cut it.
Permalink Send private email FSK 
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.
Permalink df 
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.
Permalink Send private email FSK 
February 25th, 2014 10:45am
Your benchmark was very specific, and almost certainly capable of dramatic optimizations. Did you profile it in Java?
Permalink df 
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.
Permalink Send private email FSK 
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.
Permalink Send private email WildRiver 
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.
Permalink Send private email FSK 
February 25th, 2014 11:10am
Yes, however I would say JavaScript is good enough for the front-end in web apps.  Any new improvement has to be made in  the web browsers.
Permalink Send private email WildRiver 
February 25th, 2014 11:13am
If you're writing the front-end for a web-based app, you have no choice but to you Javascript.

Your only choice is to use Javascript, or to use Javascript plus a bloated framework.
Permalink Send private email FSK 
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.
Permalink Send private email FSK 
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.
Permalink df 
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.
Permalink Send private email FSK 
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);

[missing brace]

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.)
Permalink Send private email FSK 
February 25th, 2014 11:58am
So How fast is the Java version with the fix in comparison to C++?
Permalink Me, myself and I 
February 26th, 2014 8:17am
I didn't get a chance to test it yet.
Permalink FSK 
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.
Permalink df 
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.
Permalink FSK 
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.
Permalink df 
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.
Permalink df 
February 26th, 2014 3:15pm

This topic is archived. No further replies will be accepted.

Other topics: February, 2014 Other topics: February, 2014 Recent topics Recent topics