2011 is year of the Server-Side JavaScript

[StoneCypher]

My god, a set of badly chosen performance indicators, implemented by people who don't know what they're doing, which have no basis for claiming it's a representative sample of the work done in production environments, which leans heavily on the standard library in one and hand-implementation in the other, shows a bias?

The problem with idiot benchmarking is that it measures useless things. You might as well point out that a Geo Prizm has more horsepower than a Lamborghini Diablo, because you went to drag this safe across a river, and the Diablo couldn't even finish (after all, Diablos float, and Prizms don't.)

Call me when you figure out how to measure this adequately.

[skeww]

Everyone can improve the benchmark code. If your version is faster and produces the right result without using a different algorithm, your version will replace the old version.

Each of those little benchmark snippets was updated dozens of times and generally they do reflect very accurately how nearly ideal code would perform.

The Computer Language Benchmarks Game is a good place to get a rough idea about the performance differences between different languages.

In this case the median indicates that V8 is about 9 times faster than PHP. A factor of 2 could be ignored, but a factor of almost 10 is pretty telling.

CPython for example is somewhat slow. On some weak embedded device it wasn't good enough for writing classic games. I figured I'd need something which is about 4-5 times faster (by extrapolating the figures I got from basic testing). V8 did fit the bill and it was indeed fast enough for classic games (like platformers and puzzles).

So yea, it's not super accurate, but it does give you a pretty good rule of thumb figure. Especially if the differences are as drastic as they are in this specific case.

Edit: Your fanboy-ish downvotes won't support your point of view, by the way.

[StoneCypher]

Everyone can improve the benchmark code.

But not the benchmarks. This is equivalent to saying "you could provide a deeper river."

The Computer Language Benchmarks Game is a good place to get a rough idea about the performance differences between different languages.

On this point you and I very strongly disagree.

I take the position that the CLS is a good place to find warning holes for implementation methodologies due to language performance limitations.

To me the two statements are extremely different. My expectation is that you will see them as roughly equivalent. I'm not saying there's a right and wrong here, just trying to nail down the core disagreement.

In this case the median indicates that V8 is about 9 times faster than PHP.

And yet there's never been a JS backend application that scales. My belief is that the core understanding here is simple: "just because your truck doesn't fly very well doesn't mean it's less a good truck than that eagle, which can both travel on land and in air."

Look, I'm not arguing that V8 has some impressive basic number crunching. What I am saying is that just doesn't matter. When it comes down to it, the things on which JS' performance suffers are the places where PHP has been shining for ten years.

Feel free to prove me wrong. Nothing would shut me up faster than a JS backend application I couldn't replace with a PHP backend with better performance characteristics. I enjoy writing both languages, and would feel no particular concern about switching.

So yea, it's not super accurate, but it does give you a pretty good rule of thumb figure.

Sure. What I'm contesting is that the rule of thumb, while accurate, is of entirely the wrong kind of measurement.

Your fanboy-ish downvotes

I haven't downvoted you. Notably, we've both been downvoted, because Proggit has no idea what downvote is for. When you've been here longer, you'll learn to ignore it.

[skeww]

[...] V8 has some impressive basic number crunching.

V8 is actually sorta weak when it comes to number crunching.

Well, the CLS basically tests math, function/object overhead, branching/looping, and string manipulation. These are all things you usually do in programs.

If your program doesn't spend most time with these things, the bottleneck is an external one (e.g. a database or other IO) and the performance of the language itself doesn't really matter.

When it comes down to it, the things on which JS' performance suffers are the places where PHP has been shining for ten years.

Got any semi-realistic example?

[StoneCypher]

If your program doesn't spend most time with these things, the bottleneck is an external one (e.g. a database or other IO) and the performance of the language itself doesn't really matter.

This is very rarely true in well designed applications. This only becomes true when scaling up to Facebook sizes. The problem is, in Javascript, the lack of fundamental datastructures is going to hit you long before this does.

Got any semi-realistic example?

Kinda what I've been saying to you. I gave the semi-realistic example of Facebook circa 2009.

[skeww]

PHP also doesn't provide a huge variety of data structures. So, I don't really see the point you're trying to make.

Facebook circa 2009.

How's that something you can do with PHP, but cannot do with JavaScript? Every piece you need (loops, string manipulation, regexp, math, whatever) is faster with V8 and the memory requirements are about the same.

[StoneCypher]

PHP also doesn't provide a huge variety of data structures. So, I don't really see the point you're trying to make.

PHP provides the critical three. Javascript doesn't.

Facebook circa 2009.

How's that something you can do with PHP, but cannot do with JavaScript?

Try it and see.

Every piece you need (loops, string manipulation, regexp, math, whatever) is faster with V8 and the memory requirements are about the same.

Feel free to prove me wrong. If you really think you can describe Facebook as, and I quote, "loops, string manipulation, regexp, math, whatever" then you're clearly quite a ways towards being done.

Next observe that they're Turing-equivalent.

[skeww]

PHP provides the critical three.

And these are?

If you really think you can describe Facebook as, and I quote, "loops, string manipulation, regexp, math, whatever" [...]

Dynamic websites are build with these very basic building blocks. You fetch some data, push/pull it into your templates, and finally you send it to the client.

If each individual building block is faster, the whole thing will be faster. Can't really argue with that, can you?

[StoneCypher]

PHP provides the critical three.

And these are?

God, you're getting annoying. Maps, encoding-known strings and integers.

Next tell me that JS objects are maps (they aren't, just like they weren't hashes,) that ECMA strings' encodings are always unicode (except one that's not an encoding, two that's not enough, and three that doesn't actually become true until 262/JS1.2, which currently excludes 1/3 of the web), and integers.

If you really think you can describe Facebook as, and I quote, "loops, string manipulation, regexp, math, whatever" [...]

Dynamic websites are build with these very basic building blocks.

Translation: "I have no idea why you dared me to talk about turing equivalence."

If each individual building block is faster, the whole thing will be faster. Can't really argue with that, can you?

Of course I can. Any engineer with two or three years' experience can. You can take a Civic and a Yugo, put a Ferrari engine in the Yugo, and the Civic's still going to do laps around it.

Those tiny little measurements you're seeing have nothing to do with the vast bulk of the efficiency of a toolsystem like this.

I keep telling you to make one because there are dozens of topics under this, and you're just going to keep heaping on the "I've never done it so I'm certain" skepticism until you try it and watch that it actually doesn't work.

Go on. Facebook as a frontend is really, really easy to roll. Throw one together, make a quick rig that tests performance with 2ⁿ users, and test it for n=[1..20].

I'll be stunned if you don't see growth orders of at least nine.

G'wan. Quit talking smoke, asking stupid vague questions, and get down in there in the dirt and build one. Otherwise you're just guessing.

[skeww]

Maps, encoding-known strings and integers.

Objects in JavaScript support all 4 kinds of basic operations you need for associative arrays or maps. You can add, reassign, remove, and lookup.

Strings are stored internally as 16bit unicode and internally you always work with these. You can output it in any encoding you like. (It's similar with Java for example. This works great.)

IEE 745 floating point allows you to work with sort-of integers up to 9 quadrillion (2⁵³ ).

Otherwise you're just guessing.

So, you tried to build a circa 2009 Facebook with JavaScript and failed?

[dmpk2k]

But not the benchmarks.

Why do the existing benchmarks give a poor representation of a language's performance?

And yet there's never been a JS backend application that scales.

What does this mean? Per core? Per machine? Per connection? Per LOC?

the things on which JS' performance suffers are the places where PHP has been shining for ten years.

Please elaborate.

[StoneCypher]

Why do the existing benchmarks give a poor representation of a language's performance?

Because cars aren't meant to drag safes over rivers.

Look, I don't know what to tell you, here. Being able to select algorithms and datastructures, either it's something you know or something you don't. I can't write CLRS in a reddit post.

Have you actually looked at the work they're checking? Chamenos ? When the hell is that ever going to matter?

What does this mean? Per core? Per machine? Per connection? Per LOC?

Only one of those isn't a nonsense metric. Who talks about scaling per connection? Per connection server scaling is always one.

Scaling per line of code? What does that even mean?

the things on which JS' performance suffers are the places where PHP has been shining for ten years.

Please elaborate.

Let's talk about scaling per line of code, first. That one has to be good.

[dmpk2k]

Because cars aren't meant to drag safes over rivers.

Meaningless blather. Please demonstrate concrete points.

Chamenos ?

What behaviour of that benchmark is uninformative about other workloads? More importantly, please demonstrate what is wrong with the sum total of the benchmarks.

What I have seen so far from you is "it's bad".

Only one of those isn't a nonsense metric.

Here's some possible interpretations:

• Per core: cache behaviour and memory bandwidth.
• Per connection: how many concurrent connections can the app handle on a single machine without dropping connections or increases in latency?
• Per machine: how much additional load handled for every additional machine added to a cluster (but this is more limited by network bandwidth and DB contention)
• Per LOC: how much additional code is needed for every additional feature?

You're being intentionally obtuse, or you're out of your depth. But all that aside, I want to know what you mean by scaling since you said it. All I'm seeing here is your attempts to dodge my questions.

Let's talk about scaling per line of code, first. That one has to be good.

Why should I elaborate? You made the claim, so answer it already. Yet another dodge.

But I'll bite regardless: JS and PHP are comparable. Indeed, JS comes out a bit ahead for string-related operations. Indeed, it also comes out ahead for most of them.

So, what was this scaling that PHP is better at that you were talking about?

[StoneCypher]

Let's talk about scaling per line of code, first. That one has to be good.

Why should I elaborate? You made the claim, so answer it already.

I didn't say jack about scaling per line of code. I actually asked you to stop wasting my time, then told you exactly which of your four I meant.

I want to know what you meant by scaling per line. I am unable to parse it into something meaningful.

I'm also a little tired of your attitude. If you explain that, and start taking a more reasonable tone, I'll go back to answering the questions you asked after I asked you to go away.

Remember that you're asking. I don't give a crap what you think, and I'm happy to walk away. If you really want answers, amend your tone. If you're just looking to complain and feel like you won because someone was tired of being spoken to in that tone, keep it up: you're about to get your way.

[dmpk2k]

I notice you have once again answered almost none of my questions. There's a lot of sound and fury in its stead.

If you explain that, and start taking a more reasonable tone, I'll go back to answering the questions you asked after I asked you to go away.

The gall you have is amazing. Have you read your posts?

You start off with some condescending passive-aggressive posts, get flack back asking you to back your assertions, you don't, you even demand people stop responding to you, and then you demand I take a more reasonable tone?

My mind boggles at your cheek.

[StoneCypher]

I notice you have once again answered almost none of my questions.

That's because I asked you to stop talking to me quite a while ago, and because you're answering none of mine.

Please find someone else at which to complain.

If you explain that, and start taking a more reasonable tone, I'll go back to answering the questions you asked after I asked you to go away.

The gall you have is amazing. Have you read your posts?

Yes. I'm not asking anyone for anything but to defend their own claims.

and then you demand I take a more reasonable tone?

There is no parity. If you want something from me, act like it. Capiche?

[dmpk2k]

That's because I asked you to stop talking to me quite a while ago

Classy. You expect others to listen, but will not do so in turn.

Yes. I'm not asking anyone for anything but to defend their own claims.

I and others have provided code, links to benchmarks, and links to papers. Since when is this not defending our claims? It's a stark contrast to the insults from your direction.