WebKit Unifies JavaScript Compilation With LLVM Optimizer

An anonymous reader tips this post at Webkit.org: "Just a decade ago, JavaScript – the programming language used to drive web page interactions – was thought to be too slow for serious application development. But thanks to continuous optimization efforts, it's now possible to write sophisticated, high-performance applications – even graphics-intensive games – using portable standards-compliant JavaScript and HTML5. This post describes a new advancement in JavaScript optimization: the WebKit project has unified its existing JavaScript compilation infrastructure with the state-of-the-art LLVM optimizer. This will allow JavaScript programs to leverage sophisticated optimizations that were previously only available to native applications written in languages like C++ or Objective-C. ... I'm happy to report that our LLVM-based just-in-time (JIT) compiler, dubbed the FTL – short for Fourth Tier LLVM – has been enabled by default on the Mac and iOS ports. This post summarizes the FTL engineering that was undertaken over the past year. It first reviews how WebKit's JIT compilers worked prior to the FTL. Then it describes the FTL architecture along with how we solved some of the fundamental challenges of using LLVM as a dynamic language JIT. Finally, this post shows how the FTL enables a couple of JavaScript-specific optimizations."

Comments

Additional benchmarks?

[tlambert]

Additional benchmarks for Safari with this technology vs. Chrome with its JavaScript acceleration would be appreciated; is this a closing of the speed gap, a move ahead, or a lateral move (i.e. faster in some areas than Chrome, slower in others)?

Also: the purpose Chrome has had in adopting JavaScript acceleration is that Google's web properties are JavaScript heavy, and accelerating JavaScript gives them a better overall user experience for Google Docs, GMail, and similar Google products. Was this a "compete with Chrome" move, or are other sites now following Google's lead, with increasingly sophisticated in-browser programs written in JavaScript, and so it was necessary without the Chrome pressure because of widespread increases in JavaScript overhead on average pages?

Re:Additional benchmarks?

[Pieroxy]

are other sites now following Google's lead, with increasingly sophisticated in-browser programs written in JavaScript ?

Do you even have to ask? Do you never go out on the internet?

ALL websites are more loaded than last year in JavaScript, and this is not a new trend. GMail was just pioneering (in the webmail space that is) the webapp that has only one page and everything you do is driven by JavaScript and the DOM.

Re:Additional benchmarks?

[TheRaven64]

Wrong on two counts. First, the WebKit project's JavaScript engine, JavaScriptCore, which this relates to is not used at all by Chrome, which uses V8 instead. Second, Chrome now uses a fork of WebKit, not the upstream project.

Re:Additional benchmarks?

[craigminah]

Safari has become the iTunes of web browsers.

Re:Additional benchmarks?

[jbolden]

You got a good answer from Raven that Chrome is now using a fork. Webkit is used in a bunch of other projects, the best known being Safari.

Re:Additional benchmarks?

[Millennium]

I don't know if I'd go so far as to say "a looong" time ago: it's only been a year since Blink was even announced. But you're fundamentally correct.

Webkit and Blink (the engine behind Chrome and, now, Opera) share a common ancestry, but they are no longer the same engine, and have not been for some months. For that matter, even when Chrome was WebKit based, it never used the same JavaScript engine as other WebKit browsers, and this was one of its strongest initial selling points.

Re:Additional benchmarks?

[laird]

Safari uses WebKit, and the speed increase is enabled by default in WebKit for iOS and Mac OS X, so Safari should benefit from this speedup directly, presumably in the next Safari update.

I agree that Safari doesn't handle many tabs well. Though for me, neither does Chrome. Ever since they went to the "one process per tab" model (admittedly a good idea from the stability and security perspectives) both Chrome and Safari have kinda sucked with many tabs open, because each tab has much more overhead than they used to.

Re:Additional benchmarks?

[BasilBrush]

If your perspective is as a Windows user, it used to be. In that Safari for Windows, like iTunes for Windows was the same code base as the OSX version, run with a library that gave the necessary OSX apis in Windows.

However, Safari for Windows was dropped a year or two ago. It had never got significant marketshare on Windows. So Safari is now only OSX and iOS.

And there is nothing about this particular news of LLVM tech being used for Javascript in WebKit that makes Safari any more like iTunes.

Re:Additional benchmarks?

[craigminah]

I meant, like iTunes, Safari began as a focused and snappy product. Over time it lost focus and became bloated. Not to the extent that iTunes bloated, but still it lost a lot of what made it good.

Don't take postings quite so literally,,,

Re:Additional benchmarks?

[nullchar]

No Chromium builds for your OS?

Re:Additional benchmarks?

[sg_oneill]

I meant, like iTunes, Safari began as a focused and snappy product. Over time it lost focus and became bloated. Not to the extent that iTunes bloated, but still it lost a lot of what made it good.

Nonsense. Safari used to be a dog of a browser but seems to be getting faster and lighter as time goes by.

Re:Additional benchmarks?

[tlambert]

are other sites now following Google's lead, with increasingly sophisticated in-browser programs written in JavaScript ?

Do you even have to ask? Do you never go out on the internet?

ALL websites are more loaded than last year in JavaScript, and this is not a new trend. GMail was just pioneering (in the webmail space that is) the webapp that has only one page and everything you do is driven by JavaScript and the DOM.

Actually, I *do* have to ask. One of Googles blind spots in doing very active UI's with JavaScript is the fundamental assumption that everyone has the same RTT you do, sitting on Google's fiber optic backbone, and that you have very high bandwidth to go with that. Not all companies developing web sites have that blind spot, and I think that it contributes significantly to Google's willingness to make certain assumptions.

I'd say that, other than companies that obviously aren't going to go anywhere, Google has probably *the* singly heaviest browser computation and bandwidth loading of an of the top 20 web sites out there.

So again: I'd really like to know what actually drove the decision to do this work, and whether it was an externality. Thanks.

Re:Additional benchmarks?

[kamathln]

This post is about WebKit . And when it comes to WebKit based browsers, you are not tied down to Chrome

http://en.wikipedia.org/wiki/L...

Re:Additional benchmarks?

[Pieroxy]

I can tell you one thing: When gmail was released, it was the *fastest* webmail out there, bar none, especially on a slow network connection. So no, javascript doesn't mean high bandwidth, and I most certainly don't think that Google has that blindspot.

Re:Additional benchmarks?

[craigminah]

Safari isn't nearly as light/fast as Chrome or Firefox 29. When Safari was initially released it led all browsers in terms of speed.

Re:Additional benchmarks?

[BasilBrush]

I meant, like iTunes, Safari began as a focused and snappy product. Over time it lost focus and became bloated. Not to the extent that iTunes bloated, but still it lost a lot of what made it good.

I don't see that. I use reading list every day. Favourites Bar every hour, Reader about once a week, Web Inspector whenever I'm researching how a web page works. Autofill whenever I'm creating a new account.

All these things are extras over and above basic browser, and are useful to me. Where's the bloat? How did it used to be better?

And it's not in WebKit either. That just gets better, and at least until the fork of Blink was leading the way. And may still be.

Re:Additional benchmarks?

[BasilBrush]

Chromium has the same crappy Windows like UI of Google's Chrome build.

Re:Additional benchmarks?

[nullchar]

I don't know what "crappy UIs" look like as I haven't used windows in about 7 years and own no apple hardware...

Cool but not finished yet

[StripedCow]

Cool stuff, but until one can write an optimized javascript virtual machine in it, I don't consider this project finished.

Re:Cool but not finished yet

[VortexCortex]

Cool stuff, but until one can write an optimized javascript virtual machine in it, I don't consider this project finished.

Done.

Re: Cool but not finished yet

[DaphneDiane]

While V8/Blink are currently faster it was Safari that started the the speed race. Yes chrome (v8) jumped way ahead, so its nice to see Safari catching back up.

As an aside while I understand part of the cause of the WebKit / blink split is Google not letting WebKit merge some of there features back into the main line leading to Apple redoing them for example WebKit 2; the split is a good thing as it leaves two strong teams both focused on improving and competing with each other vs the mono culture that WebKit was becoming.

A script on this page may be shite

[Hognoxious]

Just a decade ago, JavaScript â" the programming language used to drive web page interactions â" was thought to be too slow for serious application development.

Of course know we know better.

It's just too shit.

Re:A script on this page may be shite

[DMUTPeregrine]

That never stopped serious enterprise application development.

Re:A script on this page may be shite

[jellomizer]

JavaScript has a lot of faults... However there isn't a good standard to replace it. The Core Browser Engines. Trident (IE), Mozilla (FireFox), and WebKit (Chrome/Safari) They all support Javascript. Others are plugins that may work in some but not all.

Alternatives would be not using Web Pages for development. Which sounds good, until you get into problems to platform compatibility, deployment, upgrades. Or you got middle approaches such as Flash, Active X, and Java Applets, that have their own issues.

Until we can get the three core Engines to support an other uniformed language. we will be stuck with Javascript.

Re:A script on this page may be shite

[narcc]

JavaScript has a lot of faults.

Yeah. New, constructor functions, and now classes. Thankfully, the language is otherwise well designed and flexible enough that you can avoid those warts.

Of course, every language has a lot of faults. What would you consider to be a better replacement?

Re:A script on this page may be shite

[Anonymous Coward]

> Of course, every language has a lot of faults.

Javascript's faults aren't just in the language, but in the design of the language. I'm not talking about nitpicky things like naming or nulls, I'm talking about a NEEDLESS disparate programming style that you celebrate for some reason.

Web scripting languages fits the lowest common denominator of programmer, in our time. The consequences, in terms of code quality aside, is that most of the code in the world is produced in those languages and that's without much in the way of hard science for best practices. What is the purpose of completely separate paradigms for client-side development? How does that help society? It certainly hasn't resulted in meaningful research into advancing development theory. There's no evidence that multiple programming languages have helped progress computer science (they usually just demonstrate possible difficulties) and they all try to change into a semi-homogeneous pattern. Classes, closures, collections, namespaces, etc. Different languages for different purposes has rarely born out. Outside of the hipster node.js and web development, why would you ever think to use javascript (without webkit prepackaged into some app engine)? Because it's painful. Most of the time we find ourselves using the slower cousin, Lua.

Pick any web scripting language out of this:

Python
Ruby
PHP

You'll see a huge upturn in development speed and create a stronger market. Also, the testers and developers will thank you for simplifying their life.

Re:oh noes

[Cenan]

Serious, non-hyperbolic, gets-stuff-done developers? Shit, I dunno, maybe you're right...

Faster javascript? How about less javascript!

[Anonymous Coward]

Making it faster just encourages the cretins that write web apps to use even more javascript. Epic fail.

Speed space trade-off

[Required Snark]

I read the article, and it's clear that they are trading space for speed. At every step they create multiple versions of JavaScript code, each with a specific optimization goal. As far as I can tell, they are not garbage collected as long as the code is in use, because at any point they can switch from a more optimized version to a less optimized version.

Not only do they have many copies of the code around, they also keep a lot of information about how each version behaves as well as mapping structures so they can switch between the versions while they are running.

I infer that this means a lot of code bloat. I have no sense of how this memory usage compares to the memory used for DOM storage and the like. Does anyone know if code memory is a significant contributor to the overall memory footprint of a WebKit based browser?

Using FIrefox on the Mac, I experience an ever increasing memory footprint if I keep the browser running for a long period of time, i.e. over the course of a few days. This is partly laziness, but it also reflects how I use online references. Often I have multiple pages open at the same time for references, and I don't want to close them until I finish what I am working on (typically coding). After I have found a lot of relevant information online, I really don't want to end the browser session and then restore everything when I return two work.

So how will WebKit perform in this environment? How does it compare to Chrome and Firefox for memory usage? If something besides FF didn't suffer from memory bloat I might consider changing. Any experience or benchmarks would be interesting to hear about.

Re:Speed space trade-off

[GrahamJ]

Just set FF to "Show my windows and tabs from last time" on startup then you don't need to worry about losing your place when you close.

Re:Speed space trade-off

[Wootery]

I really don't want to end the browser session and then restore everything when I return two work.

If restarting Firefox and reloading all the same pages again is enough to significantly drop the memory-consumption, that implies Firefix is leaking memory.

It doesn't sound to me like laziness on your part is to blame (one shouldn't have to constantly be restarting applications to work around memory leaks), nor your browsing habits.

Re: Speed space trade-off

[AvitarX]

Doesn't Firefox RAM cache the history though?

I could easily see x number of tabs times y number of cached pages in history counting for something, and that going away when closed and reopened to the same place.

Re:Speed space trade-off

[BasilBrush]

If restarting Firefox and reloading all the same pages again is enough to significantly drop the memory-consumption, that implies Firefix is leaking memory.

Not necessarily. It could be memory fragmentation or in-memory caching. (Not knowing anything about FF in particular, but remembering a friend who was a developer for another web engine talking about these issues.)

Re:Speed space trade-off

[Daniel Hoffmann]

I am no specialist but I believe that code size these days is negligible compared to data size (unless we are talking about low-memory embedded systems.) Even if you keep multiple copies of the application code around, you only keep one copy of the application data.

Re:Speed space trade-off

[tlhIngan]

I really don't want to end the browser session and then restore everything when I return two work.

If restarting Firefox and reloading all the same pages again is enough to significantly drop the memory-consumption, that implies Firefix is leaking memory.

Actually, Firefox does another optimization on reload that speeds things up - it doesn't restore the entire session. Close Firefox with 10 tabs open and when you restore it, Firefox only reloads the last tab visible. The others merely are placeholders with page content cached on disk. Click them and Firefox takes a moment to reload the cache and render the page.

This can be dramatic on some webpages that cause Firefox to consume gobs of memory - as long as the page is cached, it doesn't take any. But once Firefox loads it from cache, it starts gobbling memory.

Re:Speed space trade-off

[LordLimecat]

If restarting Firefox and reloading all the same pages again is enough to significantly drop the memory-consumption, that implies Firefix is leaking memory.

Not really, it implies something related to firefox is leaking.

Over the past decade, by far the largest memory leaks with firefox have come from extensions. Adblockers can be particularly bad culprits here.

Just a decade ago.

[serviscope_minor]

"Just a decade ago, JavaScript â" the programming language used to drive web page interactions â" was thought to be too slow for serious application development. ... and now after 10 years of increases in CPU speed, increase in amounts of RAM and fevered development in optimizing it's now got to the stage where new Javascript kinds sorta competes with C++ on a ten year old machine.

As before, people will still write screeds on how it's really as fast as C++ this time, honest.

Interestingly, there's one language out there which regularly benchmarks better than C++, and it's called FORTRAN (suck it '95ers) and that's one of the few where you never see long articles on micro benchmarks claiming how *this* year it's as fast as C++.

Anyway, yeah, in some inner loop micro benchmarks where there's really good information available to the compiler, the dynamic languages (including Java) benchmark similarly to the native ones.

Basically it's all about aliasing and consistency. The more assumptions of independence the compiler can make about what doesn't alias, the better the optimizations it can make. This folds well into consistency: if you have an inner loop diddling a bunch of floats, then due to the aliasing rules this means that usually the loop bounds are fixed, allowing lots of nice optimizations.

FORTRAN does that really, really, really, REALLY well. C++ does it pretty well. C99 does it a bit better than C++11, though in practice pretty much all C++ implementations support the C99ism as an extension. Everything else is much worse, which means that a much smaller range of things can be optimized well.

And then on to memory. Firstly, garbage collected languages can only get with a factor of 2 for memory use (or so) before the computational cost of GC starts to dominate [citation needed]. Really, there are papers studying this. This has an impact on speed because it can make the cache coherency worse, and does also affect scaling on large datasets.

There's also the thing that memory allocation in C++ (and languages with a similar machine model) is largely completely free: unless you hammer the free store, it's all done on the stack which means the memory allocation is pre-computed at compile time as part of the function prolog. Sure, some of the dynamic languages can approach such things with escape analysis, but they can never do as well for the same reason C++ doesn't do as well as FORTRAN. With C++ you promise to never let local variables escape and the compiler can fuck you if you lie. With the dynamicer languages, the compiler has to figure it out to be correct.

Now interestingly, the things like the simple inner loops of something like naive matrix multiplication can be optimized quite well in other languages now, because compielrs are getting quite good at that. However, not much of my stuff is as simple as that. If you have bigger, more complicated inner loops like you often get in computer vision for example (my job), then C++ really shines.

This is why I've never been much of a fan of the "do the logic in python and the inner loop in C" style of things. Unless your inner loop is really simple, you have to do complex things in a not very expressive language otherwise it's slow.

These improvements sort of make that model obsolete: if you have a really simple inner loop, they can optimize as well as C++. It's everythin else where they can't.

TL;DR

Alisaing.

Re:Just a decade ago.

[StripedCow]

The interesting point to take is that with these new javascript improvements, it is now possible to target your language of choice to the browser. So you could write FORTRAN if you like, and have it run in the browser. Or python, or haskell.

Re:Just a decade ago.

[loufoque]

Interestingly, there's one language out there which regularly benchmarks better than C++, and it's called FORTRAN

It doesn't in real life.
In practice, most of the production code written in C++ performs better than code written to solve the same problems in FORTRAN.

I own a business dedicated to optimizing numerical and scientific code (including computer vision, your job), and we can beat FORTRAN any day. For naive code, it might be slightly better, but when you care about performance, you're going to want to be able to describe precisely how to maximize usage of the hardware. FORTRAN lacks both the low-level access needed for low-level optimization and the high-level access necessary to build higher-order parallelization and work distribution algorithms.

FORTRAN capabilities to make the most of modern hardware are relatively poor, in spite of OpenMP or OpenACC solutions.

Re:Just a decade ago.

[GrahamJ]

As before, people will still write screeds on how it's really as fast as C++ this time, honest.

And just as many, if not more, will go on and on about exactly why it's not and how in some specialized use case where it would never be used it might actually matter.

Re:Just a decade ago.

[wonkey_monkey]

Welcome... to the world of tomorrow!

https://github.com/kripken/ems...

Re:Just a decade ago.

[Wootery]

5 years? No, it's already been done.

You can run KDE applications in your browser, right now.

Re:Just a decade ago.

[serviscope_minor]

It doesn't in real life.
In practice, most of the production code written in C++ performs better than code written to solve the same problems in FORTRAN.

Depends. C++ is more expressive, certainly. That makes it faster to write and therefore one can spend more time on tuning the algorithms. Interestingly, this is also the claim of Walter Bright about D: it's not that it's inherently faster, but the expressivity allows you to get faster algorithms developed more quickly. Implying of course that with constrained development resources it is faster.

In terms of other stuff it's a mixed bag. I gather the $$$ commercial compilers are quite a bit ahead of GCC, unlike C++ where it's really catching up. In terms of low level stuff, like intrinsics, that's getting beyond standard C++, and there are more obscure nonstandard FORTRAN extensions as well.

Honestly, I'm not going to switch to FORTRAN. I think my point about the benchmarks is still fair, though: FORTRAN wins (last time I checked) more of the funny language shootout benchmarks than any other single language.

However, I do sometimes notice missing optimizations in C++. Especially if you're working with two float containers, e.g. an image of floats and a vector for storing stuff. There's no easy way of telling C++ that the two don't alias which is deeply irritating. I would love to be able to annotate the language to tell it about aliasing more precisely. You can see sometimes it's missed opportunities by examining the emitted asm code.

But, basically I was being a bit snide: people only compare their performance to C++ when they're blatantly not competitive. For competitive languages (such as FORTRAN), people don't crow about how well it does compared to C++.

In other words, if someone touting a language compares it's performance favourably to C++, they are almost always blowing smoke.

Re:Just a decade ago.

[jbolden]

You have your order a bit wrong. The articles in the 1950s were written about how Fortran in practice wasn't much slower than Assembler. After Fortran the move was to try and do for general programming including systems programming what Fortran does did for numerical computation, ALGOL-60 came out of that movement. C through many more steps evolved from ALGOL-60. Fortran isn't as fast as C, C is as fast as Fortran.

As for the rest of your post... Of course languages designed not to compromise performance for convenience are faster than those that do compromise performance for convenience. As Graham put it, "since the 1950s the goal of computer language theory has been to make LISP as fast as Fortran and Fortran as powerful as LISP". JavaScript is on the LISP side of the fence.

Re:Just a decade ago.

[serviscope_minor]

That's impressive that it works at all.

For fun, I tried running the raycasting demo on Firefox on my eee 900. It's not a sprightly machine by any stretch of the imagination. However, the demo is for Wolf3D era graphics. Well within the capability of my eee, for sure. I know my eee can run QuakeII very well (I used to play that game on a P133). I strongly suspect it would run QIII since it was fine on an 800 MHz P3 with a PCI (not AGP) GeForce 2MX.

In other words, it's impressive that it runs, but the performance is something like 20 years out of date!

Re:Just a decade ago.

[loufoque]

I gather the $$$ commercial compilers are quite a bit ahead of GCC

Of course when I'm speaking of FORTRAN compilers, I mean Intel and SGI.
And they're not even really better than GCC or Clang in many cases.

FORTRAN wins (last time I checked) more of the funny language shootout benchmarks than any other single language.

It wins when you compare trivial syntactically equivalent code.
The point in that when you use C++, you can do more than that.

However, I do sometimes notice missing optimizations in C++. Especially if you're working with two float containers, e.g. an image of floats and a vector for storing stuff. There's no easy way of telling C++ that the two don't alias which is deeply irritating. I would love to be able to annotate the language to tell it about aliasing more precisely. You can see sometimes it's missed opportunities by examining the emitted asm code.

There is a mechanism to annotate aliasing, it's the restrict keyword. It's not usable in all scenarios though. C++ compilers are pretty good at aliasing analysis now, so they should manage to deal with it without any annotation.
  Nevertheless if you really care about this, just perform memory loads and stores explicitly in your code instead of relying on optimizations removing the redundant memory loads you shouldn't have performed in the first place.

Re:Just a decade ago.

[sribe]

And then on to memory. Firstly, garbage collected languages can only get with a factor of 2 for memory use (or so) before the computational cost of GC starts to dominate [citation needed]. Really, there are papers studying this. This has an impact on speed because it can make the cache coherency worse, and does also affect scaling on large datasets.

IIRC, you're wrong about the factor of 2; it's actually much worse than that.

Other than that, yes all good reasons that javascript is not now fast, but is instead now less incredibly slow... And don't forget all the inlining that you get with C++ and templates...

Re:Just a decade ago.

[Wootery]

In ideal conditions, C++ compiled to JavaScript, using asm.js, can be almost as fast as an 'ordinary' build of the C++ code.

Re:Just a decade ago.

[serviscope_minor]

Of course when I'm speaking of FORTRAN compilers, I mean Intel and SGI. And they're not even really better than GCC or Clang in many cases.

Oh, huh. Well, I guess the gap has closed then.

It wins when you compare trivial syntactically equivalent code. The point in that when you use C++, you can do more than that.

Yep: other languages pull close for trivial code. Fortran is one of the few capable of beating C++ for trivial code. The reason I like C++ so much though is it makes the non-trivial code both easy to write and really efficient.

There is a mechanism to annotate aliasing, it's the restrict keyword. It's not usable in all scenarios though. C++ compilers are pretty good at aliasing analysis now, so they should manage to deal with it without any annotation.

As far as I know it only applies to pointers. So if you have two vectors, it's harder for the compiler to figure it out. Interesingly this is one area where C (specifically gcc) was better than C++ (specifically g++), last time I checked.

There seems to be some compiler woo which annotates the return from malloc() as special and not aliasing anything in existence. Somewhat related to stack allocated arrays too, I presume. The same was not done on the result of new[], so the compiler was better at optimizing idiomatic C-style code over idiomatic C++ code. That was a few years back, and I don't know if they've propagated that through to default new yet. I hope they have.

Restrict works OK, but it does lack expressiveness and only seems to work properly if you're bashing pointers.

Nevertheless if you really care about this, just perform memory loads and stores explicitly in your code instead of relying on optimizations removing the redundant memory loads you shouldn't have performed in the first place.

It's not just that: even without redundant loads, the optimizer needs to know about aliasing. For the autovectorizer, the only way of getting around that is to do explicit loads with intrinsics, but that gets into non-portable and irritating territory. It's also necessary for any order altering stuff like autoblocking and strip mining.

Re:Just a decade ago.

[Daniel Hoffmann]

In most applications only a really small part of the code actually yields a significant overall performance gain from having all these optimizations available. Unfortunately many times writing an application is an all or nothing game, either you write everything in language A or everything in language B. The reasons vary, but in the old days things were a little better in this regard, you could write C/Pascal and put assembly code right in the middle of it to get the time-critical parts handled better, these days doing interoperability between languages is a lot harder.

Many games in fact take the hybrid approach, graphics and basic infrastructure is written in C++, game logic and UI is written in a scripting language like Lua or Python. Civilization 4 for example even does all the AI in Python. This approach however is costly since the languages itself were not made to talk with each other. Well Python was made to talk with C code and that helps a lot but it is not very natural, you end up needing to write lots of wrappers, plus you now need to have specialists in both languages on your team.

Re:Just a decade ago.

[Wootery]

This is relevant... how?

My comment was regarding the efficiency of asm.js. At what point did I turn the conversation to the relative merits of JavaScript and C++?

Re:Just a decade ago.

[loufoque]

It's not just that: even without redundant loads, the optimizer needs to know about aliasing.

Just write your code in a way where the compiler does not need to make guesses about who aliases who.
Just load it once explicitly, problem solved.

i.e. instead of

out1[i] = in[i];
out2[i] = in[i];

write

T value = in[i];
out1[i] = value;
out2[i] = value;

This way, even if the compiler doesn't know that in and out1 don't alias, you only load once and not twice.
This is the kind of optimization (it's called scalarization) that FORTRAN compilers will be able to perform reliably, and people have been using it to justify that FORTRAN is a superior language to C++.

For the autovectorizer, the only way of getting around that is to do explicit loads with intrinsics, but that gets into non-portable and irritating territory. It's also necessary for any order altering stuff like autoblocking and strip mining.

You should vectorize, unroll and pipeline explicitly if you really want it to happen. In C++ it's not hard with the proper tools, and it can be done generically and portably.

Re:Just a decade ago.

[Dizzer]

Ahhhh, the obligatory FORTRAN circle jerk. A bunch of performance assertions without substance dashed with a healthy ignorance of the value of developer time vs. machine time.

Just a little example though:

50million particle N-body simulation benchmark (http://benchmarksgame.alioth.debian.org/)
Intel Fortran: 20.34s
G++ C++: 20.25s

Oh my gosh, what is that? The sounds of dozens of bearded-old-man-fortran-programmer jaws dropping?

http://benchmarksgame.alioth.d...
http://benchmarksgame.alioth.d...

Re:Just a decade ago.

[Wootery]

Correct. In short, then: asm.js is working as intended.

I don't think the memory-allocations would be a major concern though. The fact that JavaScript is an all-round nightmare of a dynamic language is the hard-to-get-fast part, as it's very difficult for the compiler to reason about safe optimisations.

(See Lua for a non-nightmare dynamic language: it has a pretty damn fast JIT (LuaJIT), which was developed by just one man. Compare with: V8, which took a whole team of Google's engineers working for quite a while.)

Re:Just a decade ago.

[serviscope_minor]

This way, even if the compiler doesn't know that in and out1 don't alias, you only load once and not twice.

Sure, but that's the most trivial example.

If you have:

out[i] = in[i]

If out and in don't alias, it can batch them up and e.g. use some SSE things to copy faster.

You should vectorize, unroll and pipeline explicitly if you really want it to happen.

Why? often the compiler does a decent job, and I'd rather not do the compiler's job for it.

In C++ it's not hard with the proper tools, and it can be done generically and portably.

What do you recommend?

Re:Just a decade ago.

[loufoque]

If you have:

out[i] = in[i]

If out and in don't alias, it can batch them up and e.g. use some SSE things to copy faster.

I didn't realize this sort of thing prevented vectorization, that might indeed be true.

You still avoid the problem by writing it as this: (verbose, you might want to investigate another option)

T in0 = in[i];
T in1 = in[i+1];
T in2 = in[i+2];
T in3 = in[i+3];
out[i] = in0;
out[i+1] = in1;
out[i+2] = in2;
out[i+3] = in3;

Why? often the compiler does a decent job, and I'd rather not do the compiler's job for it.

It's my opinion that for algorithms to vectorize well, you need to design them with vectorization in mind. It's easier to do that when you program it explicitly.

What do you recommend?

I contribute to a library that provides an abstraction layer for SIMD (SSE, AVX, Altivec, etc.) called Boost.SIMD and that is currently part of the larger NT2 library, with plans of getting it included into Boost.
There are other C++ libraries which provide similar abstraction layers.

Re:Just a decade ago.

[spiralx]

Civ 4 does some of the AI in Python, IIRC mostly evaluating heuristics for moves, but most of it is C++. The SDK for customising the AI came out about six months after the main SDK, it wasn't originally designed to be exposed to Python.

But I agree that the hybrid approach is a good one, especially as I feel you're overstating the cost of using two different languages together - neither Python nor Lua are very hard to integrate with C/C++ at all, even without tools like SWIG that automate a lot of the boilerplate required. And if you're developing games in C++ you should probably be capable of picking up Python/Lua pretty quickly, my first coding job involved writing custom interfaces in Python for our CMS application, exactly the same thing as you're talking about, and I learnt Python as I did it - didn't take long to pick it up.

Re:Just a decade ago.

[Daniel Hoffmann]

Well I am not a specialist in this kind of development so I will take your word for it, but it must be hard to build up the architecture to maintain this kind of environment, for some reason this kind of approach is only taken in games that were meant to be moddable from the start.

Re:Just a decade ago.

[igouy]

I think my point about the benchmarks is still fair, though: FORTRAN wins (last time I checked) more of the funny language shootout benchmarks than any other single language.

Check again:
Someone contributed better C programs -- programmers matter.
Intel Fortran compared to GCC -- language implementations matter.

Re:Just a decade ago.

[spiralx]

Not really, it's more that you can make a game moddable without making it scriptable - for instance, I remember many different "packs" for Civ II which consisted of customised maps, updated graphics for units and terrain features, and its own copy of master XML file that listed all the units, technologies, buildings and more with all their data - costs, attack values, prerequisites etc. It's amazing what can be produced just by changing some data, and most games don't really need to be any more moddable than this.

Re:Faster javascript? How about less javascript!

[dingen]

These kinds op optimisations in Javascript compilation will barely speed up real-world web page performance anyway. The slowness is all in the DOM, the overhead introduced by compiling & running Javascript is already near negligible.

Are you using Adblock Plus in Firefox?

[Anonymous Coward]

If so, analysis of the impact ABP has on Firefox shows how much it bloats Firefox which it does even against any savings there are from not loading ads.

Re:Are you using Adblock Plus in Firefox?

[drinkypoo]

If so, analysis of the impact ABP has on Firefox shows how much it bloats Firefox which it does even against any savings there are from not loading ads.

Even against any savings? What the fuck does that mean? Memory usage is an issue, but it doesn't contradict the function of ABP, which is to reduce ad loading.

LLVM

[vikingpower]

is also the back end behind the Julia Programming Language, and its thoughtful use by the Julia guys has made that language blindingly fast as compared to R, Matlab, Python etc. etc., while still "officially" being an interpreted language. So yes, why not ?

Re:LLVM

[shutdown -p now]

In what sense is Julia "officially an interpreted language"?

Just because it has a REPL, doesn't make it interpreted.

Re:LLVM

[vikingpower]

Julia is a high-level dynamic programming language designed to address the requirements of high-performance numerical and scientific computing while also being effective for general purpose programming.Julia's core is implemented in C and C++, its parser in Scheme, and the LLVM compiler framework is used for just-in-time generation of machine code.

Source: wikipedia entry on "Julia programming language", called on May 15, 08h56m CEST

Walks like an interpreted language, looks like an interpreted language, quacks like an interpreted language... could it be an interpreted language ?

Re:LLVM

[shutdown -p now]

I don't see any mention of the word "interpreted" on that page. It does say "dynamic" (which in this case means dynamically typed, though it has optional static typing with inference, as well), but that does not make it interpreted. In fact, the webpage is pretty specific about what they do:

"Julia’s LLVM-based just-in-time (JIT) compiler combined with the language’s design allow it to approach and often match the performance of C."

And no, "JIT-compiled" is not the same as "interpreted", either.

Of course, programming languages in general aren't really interpreted, specific implementations are. CPython is a bytecode interpreter; IronPython is a JIT compiler.

Re:LLVM

[vikingpower]

Granted, it does not say "interpreted" on that page. Hence the "walks like...looks like... quacks like" analogy. In that sense, Java is "interpreted" as well, although a bytecode interpreter. The interesting thing about Julia is the assembler code generated after the first run of any routine: its performance is compared with that of later runs, and after a couple of runs you can see incredible performance gains.

Good, but...

[TheDarkMaster]

When will implement the "unnecessary" things like proper support to integers, strings and etc.?

Re:Good, but...

[morgauxo]

Probably never. All incentive to replace Javascript with a serious programming language were killed by giving the existing Javascript these more powerful capabilities (even though it is still painful to use).

Re:JIT on iOS?

[RyuuzakiTetsuya]

It's allowed in Safari but not UI web views

http://daringfireball.net/2011...

Re:Faster javascript? How about less javascript!

[Wootery]

The slowness is all in the DOM

What about canvas and WebGL?

Re:Faster javascript? How about less javascript!

[viralburn]

Nope ... ActiveX ;)

Re:Faster javascript? How about less javascript!

[Carewolf]

What about canvas and WebGL?

Spends 99% in painting.

Re:Faster javascript? How about less javascript!

[jbolden]

I don't know much. I do know that the latest WebKit however includes Mozilla's asm.js-optimized Javascript hints and if you turn this on you get huge boosts on hinted Javascript. So it appears there is room for boosts.

That being said the easiest solution would be to standardize more so that JQuery could drop out. There really is no reason that Apple, Google, Mozilla and Microsoft couldn't agree on very aggressive retirement timelines for browsers now that Microsoft is not trying to hold back the web.

Cost of a reload

[tepples]

As I understand the behavior of this option, it doesn't save the DOM, only the URLs, and it reloads them on restart as if the user had pressed F5. So if the web application has loaded a bunch of stuff through AJAX in response to user interaction, it won't reload. For example, if you have collapsed all comments in a Slashdot discussion other than the ones to which you intend to reply, the set of collapsed comments will be lost after a reload. Besides, it won't work at all if your laptop is out of range of Wi-Fi when you reopen the browser.

Re:Cost of a reload

[GrahamJ]

That's true. Ideally the sites themselves should take care of that if they're apps that are likely to be long running or offline, but presumably the ones you're using don't do that, pity. It's certainly annoying that /. doesn't!

Re:Faster javascript? How about less javascript!

[Wootery]

Still, the DOM inefficiencies are avoided. Efficient drawing plus efficient, JIT-compiled JavaScript.

Also, it sounds like 'web workers' can help with the Spends 99% in painting issue.

Re:Faster javascript? How about less javascript!

[Wootery]

That's the same problem.

Well, no, it's very clearly not. If there are issues, they're not related to the DOM.

If Chrome isn't efficiently handling OpenGL calls, that's a problem, and I'm sure they'll fix it. The code produced by the HotSpot JVM's JIT engine can call C code 'natively', so I'm sure V8 can be engineered to do the same.

(Did you really mean Blink rather than V8?)

Re:Faster javascript? How about less javascript!

[FictionPimp]

I really feel like most of what people use jquery for today is already covered by the latest browsers. The last few projects I've done have been without jquery and I didn't write any work around code.

The big push would be just getting users to stop using the outdated operating systems/browsers and just upgrade.

I wonder if OO is really all that great

[walterbyrd]

I was developing before object oriented development took over.

I still don't any great advantage to OO development, and lots of disadvantages.

Re:I wonder if OO is really all that great

[Viol8]

The only true advantage of OO in as far as C++ is concerned is that you don't have to manually manage arrays of function pointers in a struct for inheritence. Other than that, its just a slightly cleaner syntax. Most of the other advantages are overstated and usually advocated by people who can't program in any other way.

Re:I wonder if OO is really all that great

[Viol8]

"If templates in C++ couldn't be used to write awful abominations of undecipherable blobs of code they would be really great"

Agreed. I'm also not a great fan of operator overloading unless its absolutely necessary since it can lead to some extremely hard to follow code unless you have a clever IDE.

Re:I wonder if OO is really all that great

[shutdown -p now]

RAII is a pretty huge advantage, even in the absence of exceptions. I wish this is something that C would tackle in its own simpler way (e.g. by introducing scope guards into the language).

Re:I wonder if OO is really all that great

[Viol8]

Unless everything is on the stack or use the STL for everything you have to manually manage resource anyway in the con/destructor so its not that a big deal. As for exceptions - they're worse than gotos. Used and abused by people too lazy to do proper value checks. "What will happen? Who cares, just let it throw". Bah.

Re:I wonder if OO is really all that great

[shutdown -p now]

Unless everything is on the stack or use the STL for everything you have to manually manage resource anyway in the con/destructor so its not that a big deal.

In a well-written C (or C++) program, the proportion of stack-allocated objects and subobjects should be very significant.

Anyway, the point of RAII is not about memory management. It's about having a single definitive place where you put the code to free your resource - in case of scope guards, it'll be an explicit call to free() or fclose() etc, the point is that you only write it once, and then any control transfer that leaves the guarded scope (such as e.g. early return with an error code) will run that cleanup block. Well-written C code today uses goto heavily for this same purpose, and it's both verbose and easy to mess up - either you have many labels, one per each acquired resource, or a single label where you check every resource that might not have been acquired yet.

Re:I wonder if OO is really all that great

[Viol8]

In most large programs I've worked on the majority of heap resources were global because they're used in a multitude of areas, not just down one particular code path, so freeing them was done ah-hoc. C++ requires RAII because of the obsession with some people of using objects all the time regardless of whether its necessary: eg std::string instead of char*, vector instead of an array even if the max size is already known beforehand. And so on. They don't seem to realise that constant allocation and deallocation of memory absolutely cripples performance. Perhaps they think allocators are magic memory pixies who do it all with fairy dust and it takes no time at all.

Re:I wonder if OO is really all that great

[shutdown -p now]

Why do you keep insisting that RAII is about memory and objects? It's not. Memory is just one resource, and objects and their destructors is just one way to do RAII.

errcode foo() {
  FILE *f = fopen(...);
  scope_guard { fclose(f); }
...
  if (!bar(...)) {
    return err_bar; // scope guard triggered
  }
...
  if (!baz(...)) {
    return err_baz; // scope guard triggered
  }
...
  return 0; // scope guard triggered
}

Now compare this to the mess with gotos that one needs to write to the same effect in C today. Compare to what the mess starts looking like when you have more than one f.

Re:Faster javascript? How about less javascript!

[VortexCortex]

Web workers can only process data, and they can't directly contact the DOM.

It is a pain in the ass to do your vertex operations in a web worker's ArrayBuffer then hand them off to the main thread for renderer, but it does keep the browser responsive. Really though, rendering and UI should be called from separate threads. The JS event driven model is fucked for animation by its very design. Even the ~60hz refresh callback is shitty.

I can ALMOST get all the code to run in the GPU, and just have a few vectors for input states, however, anything networked is hosed.

Really, it's all happening exactly as predicted: Web browsers turn into a slightly slimmer version of Java (JS bytecode compiler), with a crappy version of "dynamic" PostScript (webGL/canvas). They've even started getting a raw audio interface, and local file/storage API. All we've ever needed is a cross platform media engine with sandboxed compiled bytecode language. Fuck all this DOM, HTML, CSS nonsense. Then, you can have HTML/CSS compile down into your PostScript-esque multi-media system... And that way folks could come up with different box models and different markup languages, etc. But, NooooOOO, we'll have to get there by some cluster fuck of a circuitous route which will be duct-taped together and buggy as hell.

I'd rather just scrap this whole WEB shit and just get Android on the desktop, stat. Even fuck Java/Javascript, and use an unencumbered compiled language like C, Lua, Go, hell even Dart (provided the last two are submitted to standards bodies, like the NaCl bytecode is). We're going to wind up with Web Apps actually being Web Apps anyway. Why go through this excruciating process. I swear all humans are masochists. It doesn't have to be Android, shit, strip the browser down to core components of graphics / audio / input / storage / VM and breakout the Lisp. Then Emacs will finally get google docs and be a descent text editor.

Re:Faster javascript? How about less javascript!

[jbolden]

Interesting so your belief is jquery can be avoided. Well that would speed things up hugely.

In terms of the older browsers IMHO Google, Microsoft, Apple and Mozilla Foundation can make that happen. Microsoft was the biggest problem but now they are trying to decrease the amount of time people use older browsers. Bundling newer browsers with service packs and their regular policy of requiring service packs for support should do a pretty good job of driving people to newer browsers. Apple, Mozilla are already pretty aggressive and successful IMHO. Of course they would be more successful if more websites error on old browsers.

The other place to worry about forward going is older versions of Android. Gingerbread is still 16% of the market ( http://www.droid-life.com/tag/... ), as measured by the PlayStore which I suspect is worse than all users of browsers. And I'd expect this problem of lag to get worse not better with time as handsets get more reliable.

This is an Apple project

[MikeMo]

Seems like we're trying awfully hard to not notice that this is an Apple project.

Just because you can do a thing...

[morgauxo]

...doesn't mean you should.

>> it's now possible to write sophisticated, high-performance applications

Why couldn't we have gotten a real object oriented language with real classes instead of souping up this painful, nested function oddity that was original only meant to add a little eye candy to 90s era web pages?!?! OK, yeah I get it https://xkcd.com/927/. But come on! Javascript sucks! Now it sucks with more power! And there is less incentive to ever replace it with something that doesn't suck!

Could it be that so many web application developers are young, started out with web applications, have never developed with better tools and don't know what they are missing?

In 20 years will we have car manufactureres developing engine control computers programmed in the Arduino IDE?

Re:Just because you can do a thing...

[l0ungeb0y]

No, but in 5 years NodeJS will likely be the most prevalent platform for WebApps -- why develop the backend in Ruby, Python, PHP or Java when you can create your whole stack with Javascript?

I hated the choice of ECMAScript 3.1 (now called ECMAScript 5) over ECMAScript 4 which had things like static typing, classes, modules and the like, but the ECMAScript 4 proposal is alive as Harmony which is slated to be dubbed ECMAScript 6 with it's draft finalized by EOY 2014, but who knows when or if it will ever be adopted by the major browsers.

Re:Just because you can do a thing...

[narcc]

Why couldn't we have gotten a real object oriented language with real classes

Because sometimes we win. You'll have a hard time finding anyone who will advocate classes over prototypes. Just google "classes vs prototypes" and you'll find more than enough to convince you.

Stop trying to treat javascript like it's Java and and actually learn the language. You'll quickly discover that javascript doesn't suck.

Re:Just because you can do a thing...

[shutdown -p now]

In 5 years, node.js will likely be in the same place as RoR is today relative to 5 years ago.

Re:Just because you can do a thing...

[shutdown -p now]

You'll have a hard time finding anyone who will advocate classes over prototypes.

You have a hard time finding 99% of developers that tried both things?

Just google "classes vs prototypes" and you'll find more than enough to convince you.

Your methodology is flawed. Vast majority of those articles online are written by proponents of prototype-based OO to justify its existence. Proponents of class-based OO don't need to justify its existence because it's a design proven by decades of experience, and there's no feeling of insecurity attached to it. Simply put, guys who like classes don't need to prove to the world that they are special little snowflakes who are just horribly misunderstood.

Re:Just because you can do a thing...

[narcc]

Nice non-argument. The truth, of course, is that prototypes are simpler and more "powerful". You can try to argue against that, but you'll fail miserably.

If you don't like the google search, please, provide something that makes the opposite case. You'll find it impossible.

Re:Just because you can do a thing...

[l0ungeb0y]

That's a possibility, but on the other hand, NodeJS has several advantages that RoR doesn't have
-- Clusters across Cores
-- Extremely light footprint
-- Can be quickly downloaded, installed and deployed across a variety of devices
-- Can write a full-stack in a single language
-- Multiple form factors: create shell scripts and services with equal ease
-- No webserver dependency, allowing a single instance to create an HTTP Service and a Socket service with Socket.io in a single app layer

I'm not saying it's not possible for another language to fit the bill, but off-hand, I cant think of any other browser based language other than Java (which runs in a VM via a plugin preventing mobile browser usage) from even coming close.

Re:Just because you can do a thing...

[shutdown -p now]

Thing is, I think the present popularity of node has less to do with the things that you've listed, and more to do with it being perceived as "cool". This is further reinforced when you look at the kind of stuff that floats around in the npm registry.

Also, I'm not particularly convinced of the utility of a single-language stack in the case where isolation boundaries are strong and strict, as is the case between server and client in web apps. About the only thing that I can think of being consistently shareable between the two is validation logic.

The real question.

[MouseTheLuckyDog]

What idiot would want JavaScript for application development?

Re:The real question.

[ahoffer0]

What idiot would want JavaScript for application development?

Me. I am one of the idiots. I like prototypes over classes and like I like first-class functions. I'm in good company. Other idiots include Google, DataHero, Facebook, Dow Jones, and Uber.

Re:The real question.

[jez9999]

What about Firefox OS? "Everything's a web app."

Re:The real question.

[H0p313ss]

What idiot would want JavaScript for application development?

Me. I am one of the idiots. I like prototypes over classes and like I like first-class functions. I'm in good company. Other idiots include Google, DataHero, Facebook, Dow Jones, and Uber.

Though this be madness, yet there is method in 't.

Will you walk out of the air, my lord?

Re:The real question.

[MoronGames]

I do. I work for a small company and we write all of our tablet apps in JavaScript and wrap them in Cordova. It lets us deploy on iOS, Android, and Windows all at once with minimal effort and cost, which is great for a small dev team. It even makes testing a breeze because I can write all of my functional tests in CasperJS and be reasonably sure that everything is working right prior to handing things off to the test team. Much easier than messing with some junk software like Appium and and writing tests for each mobile platform individually

Android multitasking

[tepples]

I'd rather just scrap this whole WEB shit and just get Android on the desktop, stat.

With Android on the desktop, how would you work in one application while referring to the output of another application? One example would be writing something while referring to a web page. Even if you dock your phone or tablet to a 1080p monitor, the Android CDD still allows applications to assume that the screen's size won't change after installation. It can only exchange the width for the height. Only applications specifically designed for Samsung tablets' multi-window mode can be displayed beside another application. The web, on the other hand, assumes that the window is resizable.

Re:oh noes

[larry bagina]

gcc is still useful for fortran, ada, and cobol. It also has more backend support for older architectures. That's probably their biggest advantage but at the same time, nobody wants to support them so they get removed over time (and anybody who wanted to support them would probably be better off working with llvm). Some of the BSDs stick with gcc 2.9 (current version is 4.9) for certain architectures.

The answer is no

[mveloso]

My guess is that the amount of space this takes is comparable to a couple of full-sized pngs that the graphics guy forgot to scale down.

Re:Octane Benchmark is 50% faster on Mac OS X

[UnknownSoldier]

I'm seeing similar results:

2.6 GHz i7, MacBook Pro Retina 15-inch Late 2013, OSX 10.9.2

* Chrome 34.0.1847.131: 28699
* Firefox: 29.0.1: 21743
* Firefox 29.0: 21515
* Safari 7.0.3 (9537.75.14): 18303

Test / Chrome / Firefox / Safari
Richards 33336 .. 24856 .. 21234
Deltablue 37568 .. 24166 .. 17283
Crypto 28108 .. 25745 .. 24910
Raytrace 66451 .. 24124 .. 25726
EarleyBoyer 50226 .. 17415 .. 27887
Regexp 4847 .. 2361 .. 1656
Splay 12501 ..13226 .. 11951
SplayLat 21808 .. 9522 ..12525
NavierStokes 27317 .. 30688 .. 20607
pdf.js 24889 .. 15698 .. 12221
Mandreel 30117 .. 29329 .. 15985
MandreelLat 23967 .. 38645 .. 17554
GBEmulator 58589 .. 44601 .. 26002
CodeLode 19132 .. 19636 .. 36069
Box2DWeb 45047 .. 35278 .. 26763
zlib 41246 .. 67528 .. 24031
Typescript 38301 .. 24644 .. 41874

LLVM???

[advocate_one]

would it have gurt the submitter to have spent a few seconds more expanding the first instance of the use of LLVM just like JIT was?

sheesh...

Re:LLVM???

[shutdown -p now]

LLVM is a popular project with many years of history by now, not some new fangled thing that appeared yesterday. It would be expected of a typical /. reader to know what it is without the need for the submitter to explain themselves, just like they don't explain what Linux or JVM is.

Re:Faster javascript? How about less javascript!

[DickBreath]

> Making it faster just encourages the cretins that write web apps to use even more javascript. Epic fail.

Well what do you expect since they took away our <BLINK> tag?

It's just a language

[mveloso]

The main problem with javascript is it's hard to debug. If you can get past that it's a pretty OK language.

The runtimes are so variable that I'd think you'd need to really standardize on one runtime and stick with it forever.

There are times where being able to pass functions around in objects, etc is kind of handy, especially since you can pass them in as json at runtime. Again, that makes debugging really hard. If you persist them you can have objects that look the same with totally different implementations, which can be really confusing.

But as languages go, it's no more horrible than perl.

Re:Faster javascript? How about less javascript!

[Wootery]

In a happier alternative universe, Java wasn't a goddam disaster when it came to applets and desktop GUI.

Even ignoring the horrendous bloat and browser-crashing tendencies of the Java of old, the security model has always been - and will continue to be - a bad joke. The way they conflate a platform in which secure software can be effectively developed and a platform which effectively resists malicious input programs boggles the mind. Java has a really very good track-record in the former, but its horrific track-record in the latter rather mars it...

Sun's reasoning, as far as I can tell, went something like this:

Screen goes wobbly, camera pans to Sun Microsystems strategy meeting

You know how we could make fast, secure software? Efficiently-implemented high-level languages! We know that C-family languages are an awful choice for developing secure programs... Ok then, let's implement a high-performance virtual-machine for our 'Java' virtual platform. We'll write it in C++, because high-level languages are slow. I'm sure the security will be fine, after all, we're calling it a sandbox, and if we call it that, it's sure to be immune from attack by way of malicious bytecode. Most C++ programs are vulnerable to buffer-overflows, but ours is a sandbox, so it's sure to be just fine.

A few years pass

This is going great. Java has been a great success in 'enterprise' web servers, so we'll push most of our resources at that. We'll keep promoting Java applets though, and we'll ignore the unending stream of security flaws in our 'sandbox', because developing a decent server-side JVM is more important. We could put our money where our mouth is and develop a secure JVM, in, say, Java, but no, we'll keep pushing this bug-filled C++ monstrosity, and keep pretending the 'sandbox' is trustworthy. The bloat can stay too, the server crowd don't seem to mind.

What's that? Someone went and built a secure JVM, in Java? Jikes RVM, you say? With a full JIT compiler and all? Nah, we'll carry on pushing our server product as a secure in-browser sandbox. Applets are sure to catch on any day now, security laughing-stock or not.

Re:Faster javascript? How about less javascript!

[Wootery]

The problem lies not in the lack of "native" C calls (you mean in-line C call sequences in jitted code, I presume)

Yes, just so. Getting high-speed calls to C was a big break for HotSpot, as JNI had long been a real performance problem. People would have to optimise their Java/JNI/C programs to minimise the number of calls between the two languages. (Calling Java from C is still somewhat slower, by nature - HotSpot isn't in the business of producing C functions.)

V8 can't inline and inter-procedurally optimize the DOM manipulation methods - because they're opaque blobs of compiled C++ code and not some intermediate form of it.

Deep inlining is nice, of course, but I can't imagine it being a total game-changer for something like this. In a typical C++ program, there's an 'inlining barrier' when you link against a binary library. I could be wrong though, and I don't have any numbers to hand, but if we look at today's C-family compilers, whole-program optimisation is a really great feature, but it's not revolutionary.

I don't see why the same approach should be inapplicable to Canvas and WebGL. Isn't there a lot of Canvas calls that simply change the drawing state for later operations?

I don't get you.

Re:Hosts aren't (doesn't operate in browser)

[LordLimecat]

Hosts files
    * Require administrative access and modification on each computer you use. This is an incredibly bad idea on work computers.
    * Affect far more than the browser and may impact other programs in unexpected ways, such as a game being unable to properly connect
    * Are incredibly difficult to troubleshoot when they contain zillions of entries
    * Do nothing about same-origin ads (nor can they)
    * Are about as subtle and precise as a sledgehammer; they are likely to wholesale break websites rather than just blocking ads.

But then you know this because you've been told about a half dozen times; Im not sure why you would think _I_ of all people would be up for a hosts-based solution, given our post-history.

Also, the I am Legend movie was a poor shadow of the book, and Dr Krippen is the last person you want to go to for quotes. I suppose its a good poster-child for "unintended consequences", tho.

FTL = Faster Than Light

[thisisauniqueid]

In Physics, FTL = Faster Than Light. Nice pun. However, the sheer horrendous complexity of the system they described in the blog post indicates all that is wrong with Javascript as "the assembly language of the Web". Why, oh why, haven't we replaced Javascript with something cleaner, more robust and more efficient? It's 2014, people.

Re:Faster javascript? How about less javascript!

[kamathln]

Its like that for all tech .. Emacs is a text editor OS.

A Mobile phone is a [strike]phone[/strike] a complete pocketable computer.

A Smart TV is a [strike]TV[/strike] Huge tablet computer that you interact with in a slightly different way.

Re:Easily overcoming your objections 1 of 2

[LordLimecat]

You know Im not going to waste time arguing with you point by point because we've been through this before in years past.

Suffice it to say in an enterprise of any size there is zero chance that one could get approval to push out a daily-changing Hosts file to thousands of workstations. If I were to raise the suggestion, it would be immediately denied because it would almost certainly break someone's work setup.

I have a feeling you do not work in an enterprise, so it doesnt really matter how you THINK it should work; in reality this sort of thing causes way more problems than it solves. You want to do filtering? You do it at your DNS servers, your firewalls, your proxies. You do not install zero-routed hosts files with 30,000 entries from a random dude on the internet across several thousand workstations and hope everything goes OK.

If you want to link to a zillion blogs about how "in theory" it should be possible to make this work in an enterprise, thats great, but Im not going to spend time reading them. I am well aware of how Hosts files work, and they are generally considered deprecated for a reason.

Re:Faster javascript? How about less javascript!

[i.kazmi]

please go back to the 1990s :-)...theres quite a few of us who are pretty happy with the way the web has evolved