Next-Gen JavaScript Interpreter Speeds Up WebKit 193
JavaScript is everywhere these days. Now WebKit, the framework behind (among others) Safari and Safari Mobile, as well as the yet-unreleased Android, is getting a new JavaScript engine called Squirrelfish, which the developers claim provides massive speedups over the previous one. The current iteration of the engine is "just the beginning," they claim; in the near future, six planned optimizations should bring even greater speed. With JavaScript surviving as a Web-page mainstay despite many early gripes, and now integral to some low-powered mobile devices, this may mean many fewer wasted seconds in the world.
The real question is.... (Score:5, Interesting)
Of course, anything that improves JS performance in browsers (making some of the libraries faster and/or hardware accelerated always helps... hint, hint!) is a win for the consumer. And from that perspective this sounds very interesting.
Re:squirrelfish? (Score:4, Interesting)
Usually what happens is a development team uses themed codenames to easily distinguish product versions. In this case, they're probably using fish names. I worked somewhere with the same theme. We had all sorts of fish names and eventually they got a bit wacky (aquaman). The problem is when in OSS or other open development models, those names become public instead of a properly chosen name. With OSS, this happens because name recognition builds up as people discuss the unfinished software. We only had this happen once, where Man-O-War was demoed for the defense department and they liked the name so much we had to keep it for PR reasons.
Re:The real question is.... (Score:5, Interesting)
The iPhone is the one to really benefit from this, because it's where the pauses are currently noticeable.
And IE really, really suffers in comparison. Microsoft has to be wincing about all this, if only for pride's sake... I'd love to see speed improvements to IE 8 beyond the what's known already [ejohn.org], though the DOM speed improvements will help a lot for parity.
plug-and-play javascript engine (Score:2, Interesting)
Re:plug-and-play javascript engine (Score:5, Interesting)
Re:iPhone Safari (Score:2, Interesting)
Wouldn't the effect of such compliance threaten the fabric of the space-time continuum or something?
Re:Javascript grows up (Score:3, Interesting)
I think early gripes were due to the fact that practically nobody was using JavaScript in a productive way. No, we don't want bouncing images, no, we don't want insane drop-down menus that don't behave right, and no, we don't want the web page to break back/forward buttons by doing some underhanded sly scripting work. Or worse! We don't want no stupid popups that ask me for my name.
I think JavaScript has proven now that it has *some* redeeming qualities and legitimate uses :)
Squirrelfish bytecode... use in Parrotcode? (Score:3, Interesting)
Re:The real question is.... (Score:5, Interesting)
Re:Javascript grows up (Score:1, Interesting)
Even Javascript creator Brendan Eich doesn't think much of it as a programming language :
http://weblogs.mozillazine.org/roadmap/archives/2008/04/popularity.html#more
Read what He has to say about it :
"I was recruited to Netscape with the promise of "doing Scheme" in the browser."[...]"Whether any existing language could be used, instead of inventing a new one, was also not something I decided. The diktat from upper engineering management was that the language must "look like Java". That ruled out Perl, Python, and Tcl, along with Scheme. Later, in 1996, John Ousterhout came by to pitch Tk and lament the missed opportunity for Tcl.
I'm not proud, but I'm happy that I chose Scheme-ish first-class functions and Self-ish (albeit singular) prototypes as the main ingredients. The Java influences, especially y2k Date bugs but also the primitive vs. object distinction (e.g., string vs. String), were unfortunate."
[...]
"Is JavaScript popular? It's hard to say. Some Ajax developers profess (and demonstrate) love for it. Yet many curse it, including me. I still think of it as a quickie love-child of C and Self. Dr. Johnson's words come to mind: "the part that is good is not original, and the part that is original is not good.""
The only reason Brendan Eich created that damned language was because Netscape wished to create their own language so they could stranglehold the web, instead of using something that was already standard. That much they did, indeed, looking at the state of the web today, we only somewhat recovered because of a Microsoft invention (XmlHttpRequest was created at Microsoft !) and Javascript prototyped object orientation allowed to work around its language deficiencies with powerful libraries. But they are ugly hacks, not work of art.
Frankly, only someone who doesn't know there are languages like Lisp, Smalltalk, Scheme, Haskell, Ocaml, Ruby, Python and so on would think Javascript is any good. Javascript sucks. The end. Nearly all implementations were of the slowest dynamic language implementations possible (ruby notwithstanding), all had lots warts, the language itself grew with lots of warts (after all in the beginning javascript was intended to be used as a toy to add little bits of dynamism in the browser) and it has no standard library any good.
Re:Javascript grows up (Score:5, Interesting)
http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html [blogspot.com]
"Why JavaScript? Well, it was Ajax. See, what happened was... Lemme tell ya how it was supposed to be. JavaScript was going away. It doesn't matter whether you were Sun or Microsoft or anybody, right? JavaScript was going away, and it was gonna get replaced with... heh. Whatever your favorite language was.
I mean, it wasn't actually the same for everybody. It might have been C#, it might have been Java, it might have been some new language, but it was going to be a modern language. A fast language. It was gonna be a scalable language, in the sense of large-scale engineering. Building desktop apps. That's the way it was gonna be.
The way it's really gonna be, is JavaScript is gonna become one of the smokin'-est fast languages out there. And I mean smokin' fast."
Re:Real question: (Score:4, Interesting)
no, konqueror is using KHTML and will use it in the foreseeable future. There is a google summer of code to work on the webkit kpart [google.com] so that konqueror will be able to use webkit by the end of the summer, but it will probably wont be mainstream for a while:
A while ago, konqueror developers posted a FAQ [froglogic.com] describing the future of KHTML. As of today, it still applies
A posibility is that, a new browser may be added to kde, that will be tunned for web browsing as opposed to konqueror which is a swiss army knife. Kind of what Dolphin did for file management. There is already a webkit based browser [google.com] in the works that could achieve this in the future.
no mention of konqueror then (Score:4, Interesting)
It's bad enough that web developers ignore my minority browser (rather than defaulting it to the same template as safari), but ignoring the history of webkit completely must be hugely insulting to the authors of khtml. Give them some credit.
Re:no mention of konqueror then (Score:2, Interesting)
Yes, interpreters are usually bad (Score:2, Interesting)
I don't know anything about Javascript interpreters in particular, but as a general rule, interpreters for any sort of "scripting" or "dynamic" languages tend to be pretty simplistic and weak. There are a lot of techniques for making language implementations run faster, but they almost always get applied to systems that emphasize compilation.
Even when people implement dynamic languages by compiling to bytecode, they tend to write very simple VMs where the operations are at a fairly high level, and are all costly to execute. The "compilers" tend to do very simple and quick translations to bytecode, without much optimization, because when compilation happens at runtime, you want to minimize compilation time. The bytecode VMs also usually do very little to optimize bytecode; there's hardly ever any type or data flow analysis of bytecode, bytecode-to-bytecode transformations, etc.
Nearly every interpreter out there could be made a lot faster without a lot of work.
Still seems slow... (Score:5, Interesting)
Re:The real question is.... (Score:5, Interesting)
I have to disagree with you about Smalltalk. Before it in performance are LISP and on the great benchmark shootout even LuaJIT (!) is faster than VisualWorks smalltalk -- vw is pretty fast for a smalltalk. Smalltalk has been optimized a lot, but it's not really a 'fast' language.
Re:The real question is.... (Score:4, Interesting)
Compare something like TCC to GCC. TCC can compile and run a short program in two seconds, although it does hardly any optimisation. GCC will still be in the middle of running optimisations by the time TCC has finished running the program. On the other hand, compare a server-side component of a web app. GCC may take a few minutes to compile it while TCC would take a few seconds, but the version compiled with GCC will be able to service twice as many clients on the same hardware. Something like Google Spreadsheet, or browser-based games, are the same. They use enough CPU power that adding a little compiler overhead for better code is a net gain. Things like dynamic menus and the Slashdot background comment loader aren't - they run fast enough on a crappy JS implementation, and on a faster one they are speed-limited by the network, not the CPU. For these, a fast bytecode interpreter will always be (or, at least, seem) faster than an aggressive JIT, because the time they spend executing is so small.
Re:The real question is.... (Score:3, Interesting)
I try not to be a Java apologist on Slashdot, but the latest JDK6 (especially in -server mode) and public builds of JDK7 are awfully fast. Considering Objective-C's dynamic lookup overhead and lack of inlining opportunities, is it really much faster? Especially when you're running it on a chip architecture other than the one it was compiled for, such as moving between some of the Atom, Core, AMD, and virtual machines. (Although I suspect the LLVM stuff will bring Objective-C up to Java performance in the latter case.) And, of course, Java runs very fast on chips that have native Java bytecode execution capabilities-- like the one in the iPhone (although Apple refuses to activate it and lets it go to waste.)
Also, as someone else pointed out, the "newer" Java VMs have been re-optimizing commonly executed code for a decade now, so that's not really very new. I think your Java news may be a little out of date.
Finally, I'd like to point out that the language choice also affects the selection of algorithmic efficiency. I think this is where Objective-C really falls down compared to Java. Java's simple syntax and rich standard library lead to a very large algorithmic selection available at many points in coding. Cocoa on the Mac somewhat makes up for this lack in Objective-C, but it's still catching up.
Re:no mention of konqueror then (Score:2, Interesting)
Apple forked because (Score:1, Interesting)
b) it was open source, so they could grab it
c) they could develop Safari in secret
Whether or not this is good for the rest of us is debatable. If you aren't a KDE user, it doesn't matter. If you are, then you can be sad at some of the community infighting. And that it will make some things harder:
Its worth noting that in the time since they forked, they diverged the codebase enough to make a merge problematic.
It would also make open source developers unpaid apple employees, if they were to switch from khtml to webkit. khtml developers do it because they want to help kde, not because they want to help apple/todays's cell phone company/etc make a profit. They care about their users and they do it because it's interesting.