Slashdot Mirror
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."
Cool stuff, but until one can write an optimized javascript virtual machine in it, I don't consider this project finished.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
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.
Write boring code, not shiny code!
Of course know we know better.
It's just too shit.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
Why is Snark Required?
"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.
SJW n. One who posts facts.
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.
Pretty good is actually pretty bad.
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.
I am TheRaven on Soylent News
The slowness is all in the DOM
What about canvas and WebGL?
Safari has become the iTunes of web browsers.
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.
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.
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.
What idiot would want JavaScript for application development?
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.
Nonsense. Safari used to be a dog of a browser but seems to be getting faster and lighter as time goes by.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.