Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

WebKit Unifies JavaScript Compilation With LLVM Optimizer

Soulskill posted about 6 months ago | from the like-peanut-butter-and-javascript dept.

Programming 170

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."

Sorry! There are no comments related to the filter you selected.

Additional benchmarks? (1)

tlambert (566799) | about 6 months ago | (#46997287)

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? (2)

Pieroxy (222434) | about 6 months ago | (#46997313)

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? (0)

Anonymous Coward | about 6 months ago | (#46997621)

If you want to benchmark webkit, you're going to have to find another browser. Apple doesn't take Safari seriously anymore. Chrome is like 3 times faster on my Mac now and I don't get the weird scalability issues when I have a bunch of tabs open. I remember when Safari was fast and light weight. I don't know what Apple did to it, but it's pretty slow (or Chrome is just that fast)

Re:Additional benchmarks? (2)

craigminah (1885846) | about 6 months ago | (#46997751)

Safari has become the iTunes of web browsers.

Re:Additional benchmarks? (1)

BasilBrush (643681) | about 6 months ago | (#46998459)

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? (1)

laird (2705) | about 6 months ago | (#46998251)

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? (0)

BasilBrush (643681) | about 6 months ago | (#46998511)

I can't say that I've noticed any problems using multiple tabs with Safari.

For me Chrome isn't an option, partly because I can't bear it's Windows like UI. But mostly because Google is a spyware company.

Re:Additional benchmarks? (-1)

loufoque (1400831) | about 6 months ago | (#46997667)

Huh? Webkit *is* Chrome.

Re:Additional benchmarks? (4, Informative)

TheRaven64 (641858) | about 6 months ago | (#46997675)

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? (0)

Anonymous Coward | about 6 months ago | (#46997707)

That ceased to be the case a looong time ago.

Re:Additional benchmarks? (2)

Millennium (2451) | about 6 months ago | (#46998105)

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? (1)

jbolden (176878) | about 6 months ago | (#46997861)

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? (0)

Anonymous Coward | about 6 months ago | (#46998713)

No. Actually, Apple started the WebKit project along with Safari. They've since been a major developmental force behind it. Google used it for several years with Chrome, but have now forked it again, and do not use WebKit any more.

Cool but not finished yet (3, Interesting)

StripedCow (776465) | about 6 months ago | (#46997289)

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 (0)

hcs_$reboot (1536101) | about 6 months ago | (#46997449)

At least thanks to Webkit, Javascript optimization pushed the main browsers (looking at you, IE) to improve dramatically, in the recent past. Developers may now expect a JS application to run as smoothly on webkit as on the latest IEs for instance. This is a huge progress.

Re:Cool but not finished yet (0)

Anonymous Coward | about 6 months ago | (#46997645)

I think you meant thanks to Chrome.

Re: Cool but not finished yet (1)

DaphneDiane (72889) | about 6 months ago | (#46999989)

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.

Re:Cool but not finished yet (1)

VortexCortex (1117377) | about 6 months ago | (#46998369)

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

Done. [github.com]

Re:Cool but not finished yet (0)

StripedCow (776465) | about 6 months ago | (#46998401)

The resulting javascript VM will be far less efficient than the original one.

Re:Cool but not finished yet (0)

Anonymous Coward | about 6 months ago | (#46998419)

http://bellard.org/jslinux/

A script on this page may be shite (4, Insightful)

Hognoxious (631665) | about 6 months ago | (#46997321)

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 (1, Funny)

DMUTPeregrine (612791) | about 6 months ago | (#46997979)

That never stopped serious enterprise application development.

Re:A script on this page may be shite (-1)

Anonymous Coward | about 6 months ago | (#46998039)

Yep, Java itself is a prime example.

Re:A script on this page may be shite (3, Insightful)

jellomizer (103300) | about 6 months ago | (#46999517)

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.

oh noes (-1)

Anonymous Coward | about 6 months ago | (#46997331)

Now that LLVM does JavaScript who will ever use GCC for anything ever again?

Re:oh noes (1)

Cenan (1892902) | about 6 months ago | (#46997363)

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

Re:oh noes (1)

larry bagina (561269) | about 6 months ago | (#46999745)

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.

Faster javascript? How about less javascript! (1)

Anonymous Coward | about 6 months ago | (#46997395)

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

Re:Faster javascript? How about less javascript! (2)

dingen (958134) | about 6 months ago | (#46997459)

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.

Re:Faster javascript? How about less javascript! (2)

Wootery (1087023) | about 6 months ago | (#46997741)

The slowness is all in the DOM

What about canvas and WebGL?

Re:Faster javascript? How about less javascript! (0)

Anonymous Coward | about 6 months ago | (#46997813)

That's the same problem. Google's Blink is supposed to address JITting these calls. (Honestly, I don't know how using LLVM is supposed to achieve anything in terms of real world performance.)

Re:Faster javascript? How about less javascript! (1)

Wootery (1087023) | about 6 months ago | (#46998131)

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! (1)

Carewolf (581105) | about 6 months ago | (#46997841)

What about canvas and WebGL?

Spends 99% in painting.

Re:Faster javascript? How about less javascript! (1)

Wootery (1087023) | about 6 months ago | (#46998093)

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

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

Re:Faster javascript? How about less javascript! (1)

VortexCortex (1117377) | about 6 months ago | (#46998523)

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.

Android multitasking (2)

tepples (727027) | about 6 months ago | (#46999521)

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 [slashdot.org] . 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:Faster javascript? How about less javascript! (1)

jbolden (176878) | about 6 months ago | (#46997899)

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.

Re:Faster javascript? How about less javascript! (1)

FictionPimp (712802) | about 6 months ago | (#46998167)

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.

Re:Faster javascript? How about less javascript! (1)

jbolden (176878) | about 6 months ago | (#46998665)

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/... [droid-life.com] ), 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.

Re:Faster javascript? How about less javascript! (0)

Anonymous Coward | about 6 months ago | (#46997745)

While the smart guy uses Java Applet???

Re:Faster javascript? How about less javascript! (1)

viralburn (606633) | about 6 months ago | (#46997783)

Nope ... ActiveX ;)

Speed space trade-off (5, Interesting)

Required Snark (1702878) | about 6 months ago | (#46997413)

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.

Are you using Adblock Plus in Firefox? (1)

Anonymous Coward | about 6 months ago | (#46997521)

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

Re:Are you using Adblock Plus in Firefox? (1)

drinkypoo (153816) | about 6 months ago | (#46997851)

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.

Re:Speed space trade-off (1)

GrahamJ (241784) | about 6 months ago | (#46997731)

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.

Cost of a reload (4, Informative)

tepples (727027) | about 6 months ago | (#46997961)

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 (1)

GrahamJ (241784) | about 6 months ago | (#46998141)

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:Speed space trade-off (0)

Anonymous Coward | about 6 months ago | (#47000027)

Which works great, but can make for bad habits like eventually having 500+ [yes five hundred plus and no not duplicates, just easier than scrolling thru that many bookmarks] tabs open in a single window (for my computer a little below FF on Win7 limit).

Re:Speed space trade-off (2)

Wootery (1087023) | about 6 months ago | (#46997777)

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 (1)

AvitarX (172628) | about 6 months ago | (#46997819)

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 (1)

BasilBrush (643681) | about 6 months ago | (#46998577)

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 (1)

tlhIngan (30335) | about 6 months ago | (#46999379)

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 (0)

Anonymous Coward | about 6 months ago | (#47000397)

Not necessarily. It could be that the page/app is leaking memory. The only real way you can detect is to grab a memory snapshot of the currently open set of pages, compare it to a freshly opened set of the same pages, then measuring the physical memory consumption between the two processes, and comparing all that information (taking into account the sizes of JS variables in physical memory). Of course, if FF is leaking any significant amounts of memory, it'd be pretty obvious with simple back of the napkin calculations.

Re:Speed space trade-off (1)

Daniel Hoffmann (2902427) | about 6 months ago | (#46998693)

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.

The answer is no (1)

mveloso (325617) | about 6 months ago | (#47000069)

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:The answer is no (0)

Anonymous Coward | about 6 months ago | (#47000463)

Haha, I'd agree. Unless it's a huge webapp with lots of boxed variables, the code memory footprint should be small. Of course, the VM should be able to make proper tradeoff in what it should and shouldn't optimize. As an FYI (to the rest of the audience), V8 already does type unboxing and type-specific code generation (I think type unboxing yielded the biggest speed gain in JS).

Just a decade ago. (5, Insightful)

serviscope_minor (664417) | about 6 months ago | (#46997439)

"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. (1)

StripedCow (776465) | about 6 months ago | (#46997555)

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. (0)

Anonymous Coward | about 6 months ago | (#46997671)

If Fortran is what you desire, then perhaps Asm.js is for you, rather than vanilla Javascript?

Re:Just a decade ago. (0)

Anonymous Coward | about 6 months ago | (#46997607)

And even with all that, Javascript is still going to be the "native language" of the future. Soon (~5 years) we will have C++ compilers, which compile to Javascript, so that end users can actually run the code written by C++ developers...

Re:Just a decade ago. (1)

Wootery (1087023) | about 6 months ago | (#46997811)

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

You can run KDE applications in your browser, right now [etotheipiplusone.com] .

Re:Just a decade ago. (1)

serviscope_minor (664417) | about 6 months ago | (#46997985)

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. (3, Informative)

Wootery (1087023) | about 6 months ago | (#46998155)

Re:Just a decade ago. (0)

Anonymous Coward | about 6 months ago | (#46998475)

Not everyone knows C++. Javascript is a lot easier. A lot of people only do web development part time. They might primarily be a scientist or engineer, but need to work on a webapp part time. They don't want to bother with C++. Real programmers do not consider academic credit (like being coauthors on publications) to be partial compensation. They want lots of money, money we don't have to pay them.

Re:Just a decade ago. (1)

Wootery (1087023) | about 6 months ago | (#46999137)

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. (1)

loufoque (1400831) | about 6 months ago | (#46997711)

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. (1)

serviscope_minor (664417) | about 6 months ago | (#46997885)

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. (1)

loufoque (1400831) | about 6 months ago | (#46997995)

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. (1)

serviscope_minor (664417) | about 6 months ago | (#46998429)

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. (1)

loufoque (1400831) | about 6 months ago | (#46999505)

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. (1)

GrahamJ (241784) | about 6 months ago | (#46997761)

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. (1)

jbolden (176878) | about 6 months ago | (#46997951)

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. (1)

sribe (304414) | about 6 months ago | (#46998139)

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...

I wonder if OO is really all that great (1)

walterbyrd (182728) | about 6 months ago | (#46998371)

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 (2)

Viol8 (599362) | about 6 months ago | (#46998769)

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 (0)

Anonymous Coward | about 6 months ago | (#46999667)

If templates in C++ couldn't be used to write awful abominations of undecipherable blobs of code they would be really great. However, good type substitution at compiile time can be a great thing to have and often results in good performance

There's some minor stuff as well. For example, the constexpr keyword (C++11) makes sure that something actually is computable into a compile-time constant. It's rarely used, but it helps to prevent surprises.

Other than that? Most features are syntactic sugar and mainly help to structure your codebase - if you use them wisely.

Re:I wonder if OO is really all that great (1)

Viol8 (599362) | about 6 months ago | (#46999953)

"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:Just a decade ago. (1)

Daniel Hoffmann (2902427) | about 6 months ago | (#46998795)

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. (1)

Dizzer (251533) | about 6 months ago | (#46999587)

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... [debian.org]
http://benchmarksgame.alioth.d... [debian.org]

Remember (-1)

Anonymous Coward | about 6 months ago | (#46997507)

Brendan Eich created JavaScript. So if you use it, you're supporting the cisgender heteronormative patriarchy, you disgusting thought criminals.

Re:Remember (0)

Anonymous Coward | about 6 months ago | (#46997771)

Not sure if you have a brain.

JIT on iOS? (0)

Anonymous Coward | about 6 months ago | (#46997701)

Did I miss something? Since when is JIT compilation allowed on iOS? Last I checked it was the AOT way or the highway. So I'm assuming WebKit gets the JIT blessing, while the rest of us peons still gets the short straw?

Half of all the serialization libraries for Mono and .NET, that work in Unity, seem to require JIT somewhere under the hood, which is a pain because I often only notice it (from run-time errors) AFTER it's built it into the project, meaning having to redo the whole thing with a different lib. (or go manual, if I feel like torturing myself) If only people would plainly state how their lib is designed under the hood, and which reflection calls it makes, then all this mess could be avoided.

Of course the biggest culprit is Apple. This and other meaningless and arbitrary rules and restrictions make developing for iOS a royal pain in the behind. I've lost count of the number of times we had trouble building due to bugs in XCode, problems with developer certificates, and provisioning profiles, testflight, needing an OSX machine solely for iOS builds, and all that crap. Nothing wrong with rules in principle, but there's no valid reason for the current mess.

Android may be a different mess, but at least I can test my stuff without jumping through several dozen hoops. /rant

Re:JIT on iOS? (1)

RyuuzakiTetsuya (195424) | about 6 months ago | (#46997735)

It's allowed in Safari but not UI web views

http://daringfireball.net/2011... [daringfireball.net]

Re:JIT on iOS? (0)

Anonymous Coward | about 6 months ago | (#46999867)

uhm..

My rant was about native application development on iOS. Unity is a full fledged game-engine written using c++ and mono, with probably some bits of obj-c glue code. Means we game devs can use c# code and libraries for our games and export to every platform, including iOS. Similar to Xamarin. I sincerely doubt it runs inside a UI web view, though apparently native shares the same rules.

Obviously not everything available in mono will work on a mobile device, which is fine, but some of the current limitations are just so annoying that I get frustrated.

Hell, maybe I should just focus on PC. Mobile is saturated anyway. People don't appreciate the value of a good game, even if they somehow take notice of it between all the crap.

LLVM (1)

vikingpower (768921) | about 6 months ago | (#46997705)

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 ?

Good, but... (1)

TheDarkMaster (1292526) | about 6 months ago | (#46997725)

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

Re:Good, but... (1)

morgauxo (974071) | about 6 months ago | (#46998975)

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).

Octane Benchmark is 50% faster on Mac OS X (0)

Anonymous Coward | about 6 months ago | (#46998081)

On my maschine (i7, MacBookPro 2013, Mac OS 10.9), the Octane Benchmark http://octane-benchmark.googlecode.com/svn/latest/index.html for Webkit Nightly is about 50% faster than Safari 7.0.3.

* Safari Version 7.0.3 (9537.75.14): 10391
* Webkit Nightly Version 7.0.3 (9537.75.14, r168728): 15544
* Chrome 34.0.1847.137: 17508
* Firefox 29.0.1: 14077

For fun, just because: (same maschine, Windows 7 on Parallels 8)

* Internet Explorer 11.0.7: 9627

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

UnknownSoldier (67820) | about 6 months ago | (#47000241)

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

This is an Apple project (1)

MikeMo (521697) | about 6 months ago | (#46998841)

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

Just because you can do a thing... (1)

morgauxo (974071) | about 6 months ago | (#46998955)

...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/ [xkcd.com] . 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... (1)

l0ungeb0y (442022) | about 6 months ago | (#46999473)

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 [wikipedia.org] 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.

Compilation time matters (0)

Anonymous Coward | about 6 months ago | (#46998991)

The really important question is how long does it take to compile? They haven't show how long it takes to fire up gmail, for example. V8 is extremely fast in terms of compilation times.

JavaScript performance (0)

Anonymous Coward | about 6 months ago | (#46999073)

I wrote semi-complex JavaScript applications over ten years ago and the performance was actually pretty good, just so long as the client was not using Internet Explorer. Pages and actions which completed almost instantly on Opera or Netscape/Firefox would take 30 seconds to a minute on IE. I think this is part of what gave JavaScript such a bad name early on, too many peopel were IE users. In fact ,we used to think our code plain did not work on IE because of some of the bug reports we got, but it turned out if the user just waited a minute the script would complete. Again, this code worked almost instantly on Opera and Netscape, which we used for development.

Which raises an important point. With scripted languages, the language is not itself fast or slow, the implementation of the interpreter is fast or slow.

The real question. (3, Insightful)

MouseTheLuckyDog (2752443) | about 6 months ago | (#46999501)

What idiot would want JavaScript for application development?

Re:The real question. (3, Informative)

ahoffer0 (1372847) | about 6 months ago | (#47000105)

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. (1)

jez9999 (618189) | about 6 months ago | (#47000143)

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

LLVM??? (1)

advocate_one (662832) | about 6 months ago | (#47000335)

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...

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?