Hacker News Reader

Comment by corresation | Hacker News Reader

While the great sunspider battles will be great for the future, practically does this really matter? Does it really have any impact at all for an average user, where, I suspect, the up-front costs of JIT never actually pay themselves off.

This isn't intended to be Luddism, and these improvements will benefit future apps, but so much is made about JavaScript performance (see the hoopla about JIT being disabled for embedded browsers on iOS), yet I seriously doubt it makes an ounce of difference in the real world, where the overwhelming majority of the performance limitations exist in the DOM.

View on HN

The Baseline JIT will have more of an impact on common web code than highly optimized JITs like Ion. Most web code executes for a few iterations, and runs for short periods of time. Baseline takes over from the interpreter far sooner than either Jaeger or Ion, and compiles far faster than either of them. Much more common web code will end up getting executed under the baseline jit than with the existing jits.

I disagree with your sentiment that it does not make a difference in the real world. The real world is changing. The web now runs on devices which span an order of magnitude in processing power (from low end phones, to high-end workstations). Fast javascript has only been around for a few years or so. Ubiquitous connectivity (everybody connected to the internet all the time) has only just started happening. And full-fledged APIs to make the web a robust development platform (e.g. WebAudio, WebRTC, WebGL, etc.) have only recently come on the scene, or are still being solidified. I think we have yet to see the full potential of all of these technologies tapped.

In a previous life I worked in bioinformatics, and worked on a web-application to allow scientists to invoke and visualize the results of analyses on their tissue samples. Web 2.0 was all the rage back in those days, and V8's optimized JS engine was announced AFTER we developed most of our app. If we had been able to assume that kind of performance at the beginning, our app would have pushed much more of the UI to the frontend. Instead of clunky static server-generated images, we would have built beautiful, dynamic client-side visualization engines.

The last few years of progress in JS execution has opened the web up as a platform target for a large range of apps. And every inch we push that forward opens the door for a few more potential applications to reasonably be moved to the web. That's what it means to me, anyway. Push the line forward a few inches, and it means a few more features that somebody wasn't able to implement before, but are able to now. A few more apps that can target the web.

That means more to some people and less to others. But I can say with certainty that it would have meant a lot to my prior bioinformatician self. And I'm sure there are developers like me, out there, who look at what JS can do, increasing day by day, and ask themselves "now what can I build with that?".

I think it's a good thing to make the answer to that question as open ended as possible :)

Is there some particular reason to want every single application to run in a web browser?

Faster performance enables new types of applications - game, sound decoding/encoding, video rendering/encoding, phone apps, office apps, graphic apps, editors, etc.

Also new JIT can be used in backend systems similar to Node where any performance bump helps.

People have been saying this for well over a decade now. The performance impediment remains the DOM, just as it has always been. And where real benefits come to JavaScript engines, it is through the exposure of native code to the duct-tape of JavaScript: WebGL, SVG, the Media Capture APIs, CSS hardware transforms, and on and on. Where JavaScript is the thinnest veneer over native functionality.

For example, the game logic loop cannot be offloaded to the plug-ins. Simple path-finding is expensive; updating the physical properties of thousands or tens of thousands objects 60 fps is expensive. These kinds of game don't exist because Javascript is not fast enough.

I'll give you another example. That was one game I have in mind that involved simply pixels. 100x100 grid is 10K objects; 400x300 grid is 120K objects. 40fps x 120K is about 5M objects/second. Each object involves however so much processing. Doubling to 800x600 gives 20M objects/second. It adds up fast.

Why do you doubt that it makes a difference in the real world?

One of the things you need to remember is that in general, web app developers need to target yesterday's browser on yesterday's hardware. So they tend to be fairly conservative about the performance requirements. But as browsers and hardware improve, the benefits trickle down until suddenly, it's possible to do something that you never could do before. So sure, the average web app, which is designed to run on old versions of IE on outdate hardware, probably won't see much of an improvement to this. But cutting edge demos absolutely will. And when this version is the "old browser running on old hardware", general purpose web apps will absolutely be able to take advantage of these improvements and do things that would simply be unheard of beforehand.

One of the things you need to remember

I have been building and architecting very rich web applications before most caught onto this web thing. I was an original tester of XmlHttpRequest back when it was a safe-for-scripting ActiveX "abomination". I recently made a ridiculously full featured stop-motion recording studio -- in the browser -- for my children after they were enamored by something similar at the Science Centre.

And JavaScript performance has not been -- remotely -- an issue for a long, long time. The facets that make these apps powerful are technologies like WebGL, Canvas, SVG, CSS, and so on. Things that I wouldn't imagine doing more than simple orchestrations in code.

People use JavaScript performance on a completely artificial benchmark like Sunspider as a proxy for real-world browser performance. Yet it is at most a minor correlation, and has incredibly little to do with causation of a good experience.

If you think I'm joking or overstating, turn off the JIT in your browser and use it for a day. Is your experience devastated? Can you even tell the difference?

There's a big difference between "my use case" and "all use cases".

Sure, JavaScript is fast enough for a lot of things.

But it's also too slow for many things that reasonable people would like to do on the web.

See Mozilla's pdf.js: it makes perfect sense to have a PDF viewer written in JavaScript (and not a blob of insecure C++ code in the form of the plugin).

pdf.js would not be possible at all "long, long time ago", even though JS was adequate for your use cases at that time.

pdf.js is barely possible today - it works for simple documents but its performance on more complex documents is still so much worse than what C++ plugin gives that many people go back to plugins.

Performance is one of the most important competitive aspects of software. Given 2 products with similar features, people go for the faster, which is a big reason why Chrome was so successful.

We're still far away from making JS speed covering all the important use cases.

Until JavaScript can decode mp4 in JavaScript (at speeds not much slower than optimized C++), JavaScript is not fast enough.

> There's a big difference between "my use case" and "all use cases".

Yes. This is an appropriate response to a significant fraction of the complaints on this site and all other tech sites. I usually think of it as "your experience is not universal".

Given the direction of gaming and streaming, your mp4 example seems apt... I think being able to do a 1080p stream at 30-60fps in JS is an appropriate goal for both hardware, and software. Canvas+JS is likely to be the "thin" client structure or the future... I think if it were possible to do this in JS, we wouldn't need ignorant plugin points for DRM.. encrypted streaming could "just work" on any platform, not that I want more DRM.

I like that we are finally at a point, where legacy emulators in JS are a reality. I do think some attention to worker interaction, and perhaps locking say a canvas, or audio channel to a worker should be something able to be done.

I think being able to do a 1080p stream at 30-60fps in JS is an appropriate goal

Why is that an appropriate goal? How about a video element -- which the browser implements in the ideal manner (which is usually a thin layer over hardware decoding) -- that handles h264? Why in the world would you want to do that in JavaScript, besides as a "because I can" challenge?

Further your notion that DRM would "just work" is really unclear. I don't think you understand the concerns of the DRM folks if you think that you'll just do it in decrypt.js and all will be good.

I'd like to have a meet-up and invite all the dudes like you and all of the kind of dude that complains about how asm.js performance is still so slow that they don't see the point and will just keep writing "native".

You're wading into a discussion that is above you. Generally that isn't a good idea.

JavaScript proper cannot be a high performance language because of fundamental design choices. Asm.js, which I've referenced multiple times, undoes many of those choices, effectively becoming a completely different language (which is why you target it with C/C++ and LLVM, not by writing it directly). The notion that there are going to be legitimate video stream processing or h264 decoders in JavaScript -- that are more than a impractical "if you ignore normal considerations" demo -- is 0%. It makes no sense, and it is using the wrong tool, making everything into a nail because someone "knows JavaScript". This is doubly true on mobile where you want to make every instruction count.

All of the examples in here are a riot. Further gaming in HTML5 thus far has been "welcome to the 80s". It has gone nowhere. Nor has any other "pure JavaScript" high computing adventure. nodejs, which I love, is a wonderful asynchronous glue, but everyone knows that you dare not do any actual computations in it because...JavaScript.

> You're wading into a discussion that is above you. Generally that isn't a good idea.

Making assumptions about the knowledge of people you're responding to is cool though.

> Further gaming in HTML5 thus far has been "welcome to the 80s".

Oh, see I guess I was thinking Unreal 3 and Sauerbraten were released much more recently than that. Oops, silly me.

You're right, the browser should just only ever be for web pages, everything should just stay how it is now and all these damn kids should get off your lawn.

Oh, see I guess I was thinking Unreal 3

The Unreal 3 demo was an entirely different thing. Asm.js is a dramatic rethinking of JavaScript that tosses much of the language, and adds hacked typing metadata, to essentially act as a proxy for C. The single benefit that it brings over just going with C is that existing browsers can limpingly run it in crippled mode.

You're right

And then you boringly completely misrepresent my argument. You should tell the kids to get off your lawn, as you're busy trying to pretend everything is a nail because all you know is your hammer.

It's interesting you truncated my example which was pre-Asm.js but still managed to be playable.

They took a shortcut, sure. Historically JS performance hasn't supported that kind of application, and thus there are few modern or impressive 3d game engines written in it.

You were wondering why we want JS to be faster, there's your answer. I'm not sure what's left to explain.

You seem to be saying "Browsers shouldn't do X because they are too slow." "Barring X, browsers are plenty fast and don't need to be any faster." I'm not sure why you don't see that those cancel out. Also X seems to be a fairly vague set of applications, some of which have working demos.

Regarding "my" nails and hammers, I'm actually not a huge fan of much of the tech involved in modern browsers. I'm just not able to ignore what Mozilla and Google are accomplishing here nor the interest that it garners from developers as a cross-platform VM. Can we stop trying to insult me out of having a valid opinion?

If we want make this personal - personally, I don't really care about any platform besides the ones I use, and those (deliberately) tend to be easy targets for portable C/C++.

That's apparently too much work though; people want (to at least believe they have) a single target. The browser is coming to be an option for that, whether anyone likes it or not.

JIT doesn't kick in until a part of the code has already become hot, as determined by watching it. That event handler that only gets run once in a while won't get JITted; it'll continue to be interpreted, ebcause it's not a hot spot.

when it comes to complex web apps, it makes a huge difference. big data is coming to browsers in the form of massive typed Arrays from canvas and maybe soon, audio and video. We're talking about hotspots that get executed 10M+ times. These aren't your grandma's onclick handlers.

when it comes to complex web apps, it makes a huge difference.

Such as what? Give some examples. Further -- as a developer -- I cannot fathom "big data coming to browsers".

This is racing tires on street cars: Theoretically useful, but of absolutely zero relevance for the overwhelming majority of users.

Never has there been an actually practical benchmark of javascript engines and legitimate, real-world websites. Instead it's all nonsense like Sunspider. And don't misunderstand -- this actually can be a net negative for users because what benefits a 10M iteration loop is of negative consequence to an occasionally run event handler.

i'm doing interactive image analysis in canvas. i have pixel iteration/algo loops that easily hit 10M. my canvases are typically 1550x2006.

mozilla also demoed js decoding H.264 video in realtime, the utility of which is of course questionable...

the point is, though, that typed arrays are already a reality, and they are enormous. you can argue about how good an idea that was, but now that they're here, JITs are absolutely necessary.

Fun project, but how many users of your app are there? One, including you?

Such "high intensity" apps see incredibly limited marketplace success because it generally isn't the ideal platform for them, and the marginal gains from JavaScript engine to JavaScript engine (without a major reboot like asm.js) makes them completely non-competitive to alternative platforms.

Talk about goalpost-moving. First you ask for apps that benefit from these kinds of optimizations. Then someone gives you an example and you say it isn't important because it probably doesn't have many users?

That's a catch-22. Apps like that can't have many users because the improvements they depend on aren't widely deployed. However, those improvements will never be widely deployed if people persuasively argue against their importance using evidence like a small user base...

Goalpost-moving? You mean in my OP where I asked whether it benefits the average user? Where I said that the majority of performance issues remain in the DOM?

I moved no goalpost. I am saying exactly what I always said. What the GP said that they are doing is almost certainly an ill-conceived project because JavaScript -- without a major change like asm.js -- simply cannot offer competitive performance as a facet of the language. Which is why we don't build a renderer in JavaScript, but instead layer it over WebGL, for instance.

yes, it's an internal tool for several people at the moment. your characterization of "real-world websites" is somewhat misguided, I think. JITs, by design are targeted towards compute-heavy applications built for the web platform, not "typical" websites. so to say they will have little effect on websites is probably accurate, but misplaced. mozilla is building Firefox OS, where these JITs will play a critical role in smoothness of interaction and almost certainly fewer cpu cycles on mobile devices to save battery life.

Photoshop, GIMP, or photo touchup kind of apps are for the mass. The GP's app is the first stage of such app. Photo effect update and photo editing involve processing all the pixels. 10M per pass is the norm. Make that interactive and updating in real time with multiple passes.

The next wave will be audio and video processing and editing. Applying effects like cleaning up the colors in every frame is very expensive.

btw, here's the source code for Broadway.js, the JavaScript H.264 decoder:

https://github.com/mbebenita/Broadway

I actually have an example not long ago. There are some long backend job processing that I want to display the status log, beyond just the progress bar. The log records are polled in via Ajax. When it got pretty big, like couple hundreds K, Chrome crawled to its knee, freezing hard. I thought it was the DOM updates but it was the Javascript code. Firefox has no problem. I ended up having to re-structure the feature to not showing the whole log.

The long log problem I experienced as well in Chrome, didn't know it was JS related though, I also assumed the DOM to be culpable!

I commented out the DOM update portion of the code and left just the Javascript code running. It still hung Chrome, so it's Javascript related, at least on Chrome's version of Javascript.

Aren't people starting to use it for writing games now?

>practically does this really matter?

JavaScript is also a compiler target. Even smaller less heavy applications can benefit from these optimizations.

>up-front costs of JIT

You have to reach some threshold. The code is optimized as-needed.

Reply on news.ycombinator.com