Slashdot Mirror
Firefox Gets Massive JavaScript Performance Boost
monkeymonkey writes "Mozilla has integrated tracing optimization into SpiderMonkey, the JavaScript interpreter in Firefox. This improvement has boosted JavaScript performance by a factor of 20 to 40 in certain contexts. Ars Technica interviewed Mozilla CTO Brendan Eich (the original creator of JavaScript) and Mozilla's vice president of engineering, Mike Shaver. They say that tracing optimization will 'take JavaScript performance into the next tier' and 'get people thinking about JavaScript as a more general-purpose language.' The eventual goal is to make JavaScript run as fast as C code. Ars reports: 'Mozilla is leveraging an impressive new optimization technique to bring a big performance boost to the Firefox JavaScript engine. ...They aim to improve execution speed so that it is comparable to that of native code. This will redefine the boundaries of client-side performance and enable the development of a whole new generation of more computationally-intensive web applications.' Mozilla has also published a video that demonstrates the performance difference."
An anonymous reader contributes links the blogs of Eich and Shaver, where they have some further benchmarks.
Correct me if I'm wrong, but generally speaking, I was always under the impression that, as an interpreted language, javascript will never be able to run 100% as fast as natively compiled C code.
Script kiddies will be able to infect a Windows user in record time! Seriously,I install Noscript automatically with every new build and show the customer how to use it. It has just gotten too easy to infect Windows with JavaScript and it seems like everyday you're reading of a new JavaScript exploit. So it is safer just to kill it than to take the chance. So for me and my users at least it doesn't matter how fast FF renders JScript,because it has just gotten too dangerous to use. It is like saying "We've increased the speed of ActiveX by 300%!". But as always this is my 02c,YMMV
ACs don't waste your time replying, your posts are never seen by me.
Interestingly, one of the linked blogs talks about how this could lead to more of Firefox being written in Javascript. I haven't done much non-web related Javascript programming, and I haven't really used those new frameworks, but it seems to me like application programming in Javascript is like trying to hammer a nail with the handle of a screwdriver. Sure, it might work, but there are much better tools for the job. What do you guys think?
All your base are belong to Wii.
Now if we can just stop all the xss. Now it's just xss 20-40 times faster (in certain contexts).
Actually, if JS gets fast enough, it could rival Flash. This is a good thing.
THL phish sticks
Expect this discussion to be full of astroturf, red herrings and trolls.
Isn't that like dividing by zero?
Experience teaches only the teachable. -AH
Will it make my Sony Bluray player take less than 10 minutes to boot and play a disc?
Firefox 3 already gave quite a nice performance boost to Javascript, enough to actually impress me (google maps is a great demonstration of this). It's good to see they haven't stopped there and are busy improving it further, a lot of software developers tend to spend too much time on making new features and not enough time fixing/optimising the existing one, but I think after the backlash from FF2's memory usage, Mozilla has rethought their priorities and I'm glad to say they're doing things right.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
What does the scouter say about its power level?!
Javascript still has its quirks because it works its magic client side. I am moving to use it as little as possible and never as a required piece of the site. PHP and other server side languages can do many of the things javascript can but with better support and accessibility.
"They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety" Franklin
Most of my experience with Javascript has been adversarial just because one of my hobbies is screen scraping for raw data. For normal purposes though it seems like a near perfect solution. I have only a passing knowledge of its capabilities, but it seems that it's the rare technology that both hardcore comp-sci people and entry level developers can like. It's a custom purpose language, but doesn't it have first class functions? (They say every feature added to a language in the last 20 years is a less good version of something that's in Lisp, but I get the impression that the Javascript people really got it right.)
... also, I can kill you with my brain.
The theories behind tracing optimization were pioneered by Dr. Michael Franz and Dr. Andreas Gal, research scientists at the University of California, Irvine.
Hey that's my old compilers professor and my school!
This PDF looks like the paper the article is referencing.
What does Java have to do with this story?
Climate Progress - Hell and High Water
I've written my share of JS-heavy apps and the boost will be nice for that. However, my complaints with JS don't lie with performance.
I think that's enough. I'm sure you could easily argue back but this is my rant about why this boost is not the saving grace to JavaScript.
Basically my point is that performance does not bring JS up another tier. It just prolongs the pain of having a grossly inadequate language for rich application development. JS does have some nice things about it (first-class functions, closures, for(..in..), etc.) but in no way would I consider it "good" for application development.
Step back and realize the movement is pushing applications into the browser. Yes, the same apps that currently use threading; the same apps that have more than 4 input widgets (input, select, radio, checkbox); the same apps that run slow even when written in native code; the same apps that depends on libraries of code; etc. JavaScript, as is, is not The Answer and this performance boost is just a Bluepill in disguise.
:wq
Wait 'til they see my new PlatypusLobster [tm] VM!
WHOOPIE!!!
Digg.com will almost be usable now...hehe.
-- Given enough time and money, Microsoft will eventualy invent UNIX.
In general, JIT systems can really provide CPU performance near C speed, or even faster for some benchmarks, once the application gets going. The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.
Even dynamic languages like Python can have a JIT - it specializes a function for various combinations of argument types, and then provides a catchall generic version for general objects. The catchall version is not much faster than the interpreter, usually (in fact it could *be* the interpreter), but the specialized versions can be much, much faster. (Also blocks can be specialized within any of the function versions.) But all those specialized versions take up memory. So the JIT keeps stats and tries to make only the ones that really help.
Expect this discussion to be full of astroturf, red herrings and trolls
Ah, no problem. Just give the red herring to the troll and he'll let you pass the bridge :)
It would nice to see some demos of this with John Resig's Processing.js. It could definitely use the kind performance boost being discussed here.
In addition to a performance considerations, it would also be nice to have addtional some additional bit depth in JavaScript.
I anticipate JavaScript will continue to be very popular, but there are alot a lot of reasons other than performance that people won't want to use the language for writing desktop applications over C/C++/Java. That said, there have been alot of recent developments that have made me cautiously optimistic about the future of the language along these lines.
I am rubber, you are glue.
It's true that for applications where a Javascript function takes a long time to execute, that translation overhead can be neglected, yielding comparable speed with C, however such functions are rare enough in ordinary web applications that the point is moot.
They are? Really! So you're saying Google Maps and gmail just fire off a bit of Javascript and then stop?
Oh, and you are aware that a significant portion of Firefox, itself, is written in Javascript?
It won't be just from the Windows side - a good chunk of Linux-heads hate anything but static black text on plain white backgrounds. So this should get interesting...
Goes to show what you know. Real Linux-heads hate anything but static white or green text on plain black backgrounds.
Exactly. Most of the user waiting time consists of socket communications and library calls. The actual computing time needed to interpret Javascript code is a small fraction of that, which occurs in bursts.
With the major work done by native libraries. So what's your point?
Exactly. Most of the user waiting time consists of socket communications and library calls. The actual computing time needed to interpret Javascript code is a small fraction of that, which occurs in bursts.
You should probably let the Mozilla guys know this. I'm sure they'd love to hear they've been wasting their time optimizing Firefox's Javascript engine. I'm sure the marked improvements in performance of JS-heavy sites like gmaps are just a coincidence...
Ever since the matrix, it's been green text on black background. That movie was 10 years ago, get with the times man!
However, I never said that improving JS performance is undesirable. It's the old scripting vs low level programming debate: Low level is faster, but needs more expertise and programmer time. Pick the best tool, etc.
The Mozilla architecture is a case in point. The UI is controlled by JS functions, which delegate all the hard work to XPCOM objects. That's more overhead than controlling the UI in C++ directly, but has the _huge_ advantage of being easier to modify and adapt the code for developers.
Did you used to work for Sierra back in the 80s?
Until linux can run Windows games with a "clicky clicky,next next next" installer,and I can install those damned Lexmark all-in-ones that everyone seems to have there is just no way i can survive selling Linux boxes.
Then offer a bundle with an HP or Epson all-in-one, and possibly a Nintendo DS ;-)
What does Java have to do with this story?
This article is about using a JIT to bring the speed of long-running JavaScript up to the speed of long-running Java. (I say "long-running" to duck the issue of VM startup time.)
It's true that for applications where a Javascript function takes a long time to execute, that translation overhead can be neglected, yielding comparable speed with C, however such functions are rare enough in ordinary web applications that the point is moot.
They're becoming increasingly less rare as people write more complex applications for the web. There are Javascript libraries that do complex layouts not possible in CSS/HTML which dynamically resize when you drag and drop items around. Someone a Keynote workalike, which chugs badly on slower machines -- while you could probably blame a lot of it on DOM, the Javascript and the Objective-C-like abstraction layer and windowing library probably doesn't help.
So it might be that it "only" takes 400 ms to update the layout after you drag a slider to resize a divider, but it'd be great if it only took 100 ms, especially on old hardware. If you only compile code that actually gets executed, the translation overhead might be less than you think. In particular, the method mentioned in the article uses a less expensive type of JIT than traditional JIT compilers.
Just make sure that you have use for the astroturf too!
Anyway - improved performance is never wrong. It's all too common today to rely on the performance of the computer instead of better coding.
Good coding can improve performance a lot more than better hardware.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Sharepoint 2007 is a good example. Editing of the content is via a browser-based interface, which is quite script heavy. What's interesting is just how script heavy it is. While testing on an old laptop we have connected to an external link, I was a bit dismayed at how slow loading our site was. I got the impression that the browser was pausing before displaying the page for some reason.
Opening up task manager, I saw that before IE displayed the page, it would spin on 50% CPU (on an old hyperthreaded P4) for over 5 seconds before finally rendering the page. After some experimenting which yielded consistent results, I tried Firefox and the difference was dramatic, to say the least.
The upshot of all this is that we may need to recommend to our clients that they use Firefox to edit their Sharepoint 2007 sites, because it provides a significantly better experience than IE does if you have older hardware. On my own desktop at work (a reasonably modern Core 2 Duo) IE does spike the CPU usage, but generally it's for less than a second or two so it's not really distracting. Firefox is faster, but both are quick enough that it doesn't make a real difference to a human.
Completely off-topic: I used refreshes of the task manager process listing to judge how long IE was spinning for. I always assumed the default setting was to refresh the list once per second, and some quick testing now confirms that that is what it does. If you go to View -> Update Speed, the default setting is "Normal". The status tip for this setting says "Updates the display every two seconds". Clearly a lie - or is it? If you select "Normal", then the display does in fact update every two seconds, and there doesn't seem to be any way to get it to go back to refreshing once per second.
About the memory, you are correct (for now).
About the speed:
I made a benchmark written in a pure C subset of C/C++/C#/Java in all of these languages. A simple benchmark involving calculations with integers (primes) and floating point numbers (sums of products of square roots of primes). The result, when running a bazillion iterations:
C# and Java took 50 seconds, C++ took 49 seconds and C took 51 seconds. Other benchmarks I made showed similar results.
So for pure calculating, C#/Java + JIT is equally fast. For big real-life systems involving a lot of other stuff, the results might be different.
But it is a long time ago that Java et. al. were 3 times slower than native code.
Expect this discussion to be full of astroturf, red herrings and trolls
Ah, no problem. Just give the red herring to the troll and he'll let you pass the bridge :)
...and save the astroturf for the knights in the forest! Yes, it's not a shrubbery, but it's all we have. :)
When Javascript is deployed, after the source text is downloaded from a web site, it must first be converted into executable form suitable for a VM. That extra translation step is an overhead which must be amortized over the execution time of the code. Since most Javascript code takes very little time to execute in the first place, this translation overhead is a significant fraction of total computing time in typical applications.
Because, obviously, caching whatever is pointed to by URLs doesn't work, so you can't cache any pre-transformed JavaScript. Right?
When properly done (both on the client and on the server side), the translation overhead will be O(1) the second time you visit a page.
Besides, the fact that improving stuff other than translation overhead (just tight loops!) has helped so much, means that on a good proportion of sites your assumptions simply don't hold.
I don't think that the goal of making JS "as fast as" C is impossible -- heck, I presume that due to the way the optimization is done, it can actually generate better code than gcc does now. The trivial example would be a function that calls a function passed as a pointer-to-a-function as an argument. I've checked a few months ago and gcc flatly refuses to optimize cases where a function is called with a constant pointer-to-function as an argument. OCaml native compiler from a few months ago didn't optimize this either.
As far as I understand it, the TraceMonkey either does it already or will do it very soon. Of course TraceMonkey's native code is not quite up to par yet, when compared with gcc, but it's an issue orthogonal to the optimizations obtained by the trace itself.
Cheers, Kuba
I think they've done something very interesting, and I read the article that describes the trace trees. But I'm really curious -- with all the trouble that it takes to do this sort of interpretation, wouldn't it actually be faster and easier to compile the code into native machine code and then execute it? The compiler wouldn't just happily spit out machine code. It would take security into consideration. Most operations would be implemented by calls to well-defined functions implemented in the browser itself. Regarding security, the fact that code is compiled or interpreted really doesn't make that much difference. You can program a bash script to do a lot of damage, or you can write such a program in C. So I think the security issue isn't any different in this context. The compilation would happen the instant the code comes down the pipe, and unless the code is very long and complicated, I think it would be almost instantaneous. On a modern computer, GCC can pump through thousands of lines in a matter of a split second. A JavaScript compiler optimized to compile very quickly for acceptable results (with perhaps a nice optimization applied to inner loops) would do this beautifully. After the single compilation, you wouldn't need to keep track of all kinds of trees and trampolines and whatnot. The code would be executed as a function call from the browser into the produced object code. I think this could truly provide C-like speeds without the memory and algorithm requirements.
McCain/Palin '08. Now THAT's hope and change!
The "screencast" still looks horribly slow compared to what native code did 10 years ago. Hard to believe this is now fast.
Let me know when IE stops being a stick in the mud so this will actually matter. No one in their right mind would bring a Firefox only web app to market.
And stay off the chans.
At runtime you can tell what you should be optimizing for based on how the program is actually being used, something you cannot do at compile time.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Good JS can be faster than bad C, but that's only word playing. The parent has a point, Jitted languages are conceptually slower than native ones, there's no way to eliminate the extra-overhead in 'strictu sense' (you need to restric 'faster' to some specific asumptions).
I could also say than 'C can be faster than assembler', but it's not true.
What's in a sig?
Maybe I am wrong, but when I see that cpu-usage goes up, just for reading slashdot posts, I think there's something fundamentally wrong.
Bloat is taking the web, optimizations will not help, just make-it worse.
What's in a sig?
I guess the GP was right about the trolls.
This improvement has boosted JavaScript performance by a factor of 20 to 40 in certain contexts
So it's clear, that boost factor is only in certain contexts. If you boos IE's string concatenation you only boost ONE context and you get a JS parser faster than FF's and Opera's. When FF3 came out there was a lot of buzz about how slow IE is compared to everything else but that was only because of string concatenation and the tests were only considering overall performance.
I can't find any of the URLs with the statistics but who doesn't believe this could do a bit of digging before modding this down: removing string concatenation from the tests clearly proves IE7 is faster than FF3 and Opera.
Expect this discussion to be full of astroturf, red herrings and trolls
Ah, no problem. Just give the red herring to the troll and he'll let you pass the bridge :)
And if you're feeling nasty you can poison the fish before giving it to him (well, it doesn't make any in-game difference, but it's a red herring after all!) Also remember that you can learn an insult from the troll before bribing him, which greatly speeds up the later battles.
Ah, good times. :)
As a state gets corrupt, its laws multiply; the most corrupt states have the most numerous laws. (Tacitus, Annales 3:27)
It has long been shown (well, at least 10 years), at least theoretically, than run time optimized code /can/ be faster than compile time only optimized code.
That's because there's only so much a static optimizer can work on, because without some super advanced AI from the future it can't really tell what the code is actually going to be used for.
Runtime optimization of C is impractical (although it's been done) and not that useful anyway (the gains are not dramatic), while for interpreted code it's ideal and the results are impressive.
So in the end, yes, there are cases where this optimized JavaScript will be faster than the same C code.
So basically you suggest doing the exact opposite of what has been shown experimentally to work very in the article?
Pretty much, yes. I'm suspecting that they made
some sort of error in their JIT implementation.
Having done optimization work on a JIT before,
I happen to know that an interpreter can be bad.
A decent JIT runs **very** fast.
JIT until the next branch, execute, repeat.
Careful profiling of the JIT result can help
to avoid trouble.
So this means the javascript exploit of the week will be executed 20-40 times faster?
yeah, like before you could stop its execution in the middle before it's too late...
Great post, I'd mod you up if you had points.
I think the belief that C is the de-facto fastest language is the misconception that it can be simply translated directly into assembler. On many operations, this is correct - there are assembler equivalents on many architectures for many language constructs (looping, arithmetic and so forth) and its low-level approach to arrays, memory usage and such mimic how assembler programs are written. However, it is not always the case, particularly when you start to use more complex language constructs. Filesystem calls, templates, structs, anybody?
C has the same problems as other languages. In some cases, it has MORE problems - as has been pointed out already, strict typing for instance can help a LOT in optimisation at compile time, something C cannot always benefit from. The one thing C lacks is a JIT compiler - runtime compilation can have some serious benefits, as we've seen with other languages.
NB: My experience in this comes from 68k assembler, writing relatively simple C on the Amiga and noticing how little work the compiler often had to do ;)
I know JavaScript is the future of everything only because it's the only language that is available on "The Cloud" access devices (read "web browser" for you non web3.0 equipped reader) and it's good it get some optimization but when I see image manipulation software written in javascript and running inside a browser I mentally form the image of a giant rubber hammer trying to force a screw into a concrete wall.
:)
I've done *a lot* of javascript dev over the last 10 years, and I can tell one thing, execution speed of javascript has never really been my most important issue. In order network communications, DOM manipulation and that retarded single thread execution model where way higher on my annoyance list.
My hope is that someone will come up with a "pluggable" script engine that can be updated on demand so that I actually use those latest feature instead of having to target 5 years old tech if I don't want to lose potential clients. And yes I imply they should port their engine to IE.
.
Using JavaScript as a general purpose language is a good thing?
Why?
>I do however use Flash. Any word on a flash fix?
Go to tools->add-ons. Click on the 'Plugins' tab. Now scroll down to the plugins containing the string 'Flash' and press the button marked 'disable'. HTH. HAND.
Belief is the currency of delusion.
On the off-topic note: Don't even bother thinking about the task manager, just download the Process Explorer and set it to replace the task manager. It's light weight and vastly superior to the task manager in every way. One of the utils I miss in Linux.
Switch back to Slashdot's D1 system.
tip: don't use Task Manager, for investigating performance issues, use PerfMon (under administrative tools on your start menu).
Open a performance report, add the %CPU counter for just IE (it'll be under the Process counter set).
You can get it to update faster than 1 second default, and get it to log to a file instead so you can view it later. Add a network counter and memory counter too for more insight.
Does that also mean it's NOT as fast as native C/C++ code because C# is blatantly not and thus is part of the marketing guff that you were gulliable to believe?
First of all, both C# implementations and C/C++ implementations generally generate native code.
Now, you have to separate languages and implementations. C/C++ implementations are still somewhat faster than C# implementations. Why? Because people have been optimizing compilers and processors for C/C++ for 20 years.
However, intrinsically, C# is the "faster language": C/C++ is a bitch to optimize, and equivalent C# code tends to have more opportunities for optimization.
Furthermore, a JIT implementation is intrinsically the faster implementation for long-running, compute-intensive software: C/C++ batch compilers lack information about runtime types and runtime statistics.
C/C++ have always been horrible from the point of efficiency. One of the most "efficient languages" (in the sense of being able to compile it into efficient code) is Fortran. However, numerical software may be moving to JIT-based systems because it's so much more efficient.
The catch is that you pay two penalties: startup time and memory.
That's a problem with the JVM, not JITs in general. The reason the JVM is slow is because of Java's bloated libraries and Java's idiotic way of storing and organizing libraries.
You are ABSOLUTELY wrong! C# by its very nature can not be as fast as C.
The C# JIT has all the information that a C compiler has (essentially, the entire source code). In addition, it has a lot of global program information and it has runtime statistics. And, the C# language has better defined semantics. All of this taken together means that C# can be optimized better than C.
In terms of performance, C is a lousy language; Fortran is a "faster language" than C.
The only reason C even runs as well as it does is because people have invested 20 years in making compilers squeeze out the last cycle, because C compilers play fast and loose with C semantics at high optimization, and because even CPUs have been tuned to accommodate its semantics.
> In terms of total runtime, the common case is that the Javascript is inner loop code.
Indeed, and the idea is that once you run a loop a few times you jit it.
> Even if the JIT translator is slower than a few passes through the interpreter, why are
> you caring so much about code that barely matters?
Because there is memory overhead to jitting everything, even things you don't hit.
Also, jitting evething (standard function-level jit) means you have to actually keep the function calls. Tracing effectively inlines everything.
It's not obvious which is better, I agree. At least at first glance. It would be best to have both done and compare!
I believe that the type checks are in fact done when the type might change, not on read.
I am rubber, you are glue.
You mean goo..
With great power comes great electricity bills.
Nope, I do mean glue.
1) Never do anything you don't need to.
Applied properly, this gets into all kinds of code assessment that is trivial to do but needs tracking.
Think of it as filling a sparse matrix of unknown dimensions when doing step 2.
2) Never do anything twice, (right down to the iron.)
Applied properly, this gets into all kinds of execution assessment that is trivial to do but needs tracking.
3) Repeat 1 and 2 until you run out of RAM.
Then you need to get judicious on its ass.(By pruning the sparse matrix [when the only penalty is refilling the matrix.])
JIT compilation gets things out of the way by not 'going there' (the 80/20 rule applies nicely to code execution/optimization,) or gets things over with 'once and for all, (the 99/1 rule applies when you've got the right kinds of memory structures [handles as opposed to references,]) and can result in stuff you wouldn't want to decipher since the optimization depends on the actual order of execution.
But it can run almost as fast as the iron can handle.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
I am curious as to how this new engine performs on older computers. I want to know, is it the evolution for this kind of software rooted in the capabilities of newer computers, or is it evolution of logic concepts based on R&D that is also easily accessible to old hardware still?
Some of us prefer green text.
... has a cost, in terms of cpu cycles and memory.
For compiled code, that cost is paid at compile time.
For interpreted code -- JIT or any other sort -- those costs are paid at run time.
Let's try to be at least a LITTLE analytical about this.
if M (the amount of memory required) consists of m1 + m2 + m3, where:
m1 is the amount of memory required by the compiled code
m2 is the amount of memory required by the compiler/interpreter/optimizer
m3 is the amount of memory required by the problem data
Then it is pretty easy to see that m2 is zero at runtime for compiled code, and that the difference (if any) in m1 for the (supposedly) superior real-time optimization will be far, FAR less than m2 (which will be zero at runtime for compiled code).
Similarly, if we look at P, the amount of processor resource required, we can break it down into p1 and p2, with:
p1 being the cycles used to perform the problem
p2 being the cycles used to optimize the code
Again, p2 is done in real time with interpreted languages, JIT or not, and is done at compile time for compiled code. At runtime, the amount saved in p1 by (supposedly) superior optimization will only exceed p2 in the case of repetitive problems executed for long periods of time. Remember, at execution time (which is what we care about), p2 is ZERO for previously compiled code.
It takes a very long-running, highly repetitive program for the improvements in efficiency from superior optimization to overcome the overhead of realtime compilation.
For short, non-repetitive executions, interpretive execution is HIGHLY unlikely to prove superior to previously compiled code.
In a very large fraction of the computer programs run today, the compile time exceeds the run time of the program. When you consider interpretive code as requiring "compilation" every time it is loaded, you begin to see the advantage of previously compiled code.
The major reasons for using interpretive languages have always been the improvements in the development cycle. Raw execution performance of interpretive code (JIT or otherwise) is unlikely to ever exceed that of compiled code, for C or any other language, for exactly the reasons outlined above.
http://people.mozilla.com/~schrep/tm-image-adjustment.swf
Microsoft absolutely needs fast cross-platform Javascript for some of the stuff they are developing.
Javascript has no hope of being comparable to C speedwise in ordinary use
Funny, since another dynamically dynamic language SBCL Lisp, gets within a factor of 2.0 of C.
Being the same speed? Never.
Being close enough that programmer performance matters more than program performance? Easy.
In short, it's hardly worth to optimize engine specifically for the piece of crap that is SharePoint JS code. There are certainly better examples around :)
Javascript is, fundamentally, just as good as Java (and the qualities of Java as a language are, of course, highly debatable).
While that may be true, it's not particularly relevant. Javascript and Java have nothing to do with each other besides the name.
Yes, they both have C-derived syntax, but they are not otherwise related in any way.
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
I'm out of my mod points today, but that is truly amazing!
The graphs shown in TFA indicated a 22.2x performance increase in 'function call' 37.5x increase in 'global loop', and 20.8x increase in 'empty loop'.
Then, they turn around and show a Sunspider performance boost of 1.8x - which is still awesome, but nowhere near the factor of 'twenty to forty' that is being carelessly bandied about by those who appear to misunderstand what is being represented.
What the PP seems to suggest is 'don't interpret and then JIT the slow parts, JIT everything'. His rationale is that the time wasted interpreting the code in order to figure out what needs optimizing makes up for the time spent optimizing everything.
For example, if your inner loop takes 3 seconds to execute, the JIT compiler will see that it's taken 3 seconds, and optimize it - if it ever runs again. If your code only takes 4 seconds to run, then 75% of your time is spent in the unoptimized inner loop.
Instead, he seems to propose that you optimize everything immediately, and then execute it. If it takes 1 second to optimize and you can shave 2 seconds off your inner loop in this case, you've saved 1 second overall. If your inner loop takes 9 seconds, you save 5 seconds overall. In essence, pre-compiling pays for itself in most cases.
At least, that was what I got out of it, though I'm open to correction.
I love it when people try to defend "Web 2.0" by claiming that anyone who thinks web development is misguided is just a technophobe who wants to return computers to the state they were in in 1991. Yes, if someone says, "AJAX is bad," clearly they are also against GUIs, the Internet, and personal computers. After all, there is clearly no use for computers except as web clients or servers in this day and age, in their eyes.
Palm trees and 8
javascript:var a=document.getElementsByTagName("br"),i;for(i=0;i<a.length;i++)a[i].style.display="none";void(0);
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
> In terms of total runtime, the common case is that the Javascript is inner loop code.
Indeed, and the idea is that once you run a loop a few times you jit it.
Ah, but you've already burned up lots of time in the interpreter. Translating is not (should not be) much slower than interpreting. If the Javascript executes once, pure JIT is nearly as fast as interpreting. If the Javascript executes more than once, pure JIT is better.
> Even if the JIT translator is slower than a few passes through the interpreter, why are
> you caring so much about code that barely matters?
Because there is memory overhead to jitting everything, even things you don't hit.
Uh, why do you have any significant memory overhead? Even badly optimized code should be pretty compact.
Also, jitting evething (standard function-level jit) means you have to actually keep the function calls. Tracing effectively inlines everything.
True, but modern processors handle call/ret well.
On the Mac you would have a hard time finding another browser that is so steadily going down the tubes, with every so-called new release or update (whatever buzzword they're using now
It failed to load the css stylesheet for Slashdot, just now, but a refresh, coming from another link on the style-butchered page brought up the CSS. If you're on another platform you cannot imagine what a huge pain in the ass it is.
So why use it, right? I mean, if you don't like it, use something you think is better. I know that, and I feel bad bitching, but I use the Web Developer add-on all the time, and on Qwest dsl, it's convenient to use FlashBlock.
The versions of web developer-like plugins for Safari, just suck; it's as simple as that. Otherwise I'd be on Safari. But it's far more proprietary-behaving than Firefox.
Let's face it, they set out to make a better browser that would feel 'comfy' to Windows Internet Explorer users, and they seem to have succeeded, I guess. But it is not a Mac thing, at all. I tend to gravitate towards apps that, if they are supposedly designed to work on multiple platforms, they try to pay at least some minor attention to the platform's API. Firefox fails on this count. I'd rather use IE in Windows 2000 Pro, any day of the week. And I would, if it wasn't for a shitload of Adobe apps on my Mac setup.
Why don't the Firefox developers just borrow somebody else's balls and say, "The Macintosh is too small of an installed footprint, so we don't give a shit." And that would be fine with me. I use an Apple, I, myself, am NOT Apple. And besides that, wanna know what I think? If Mozila/Firebox borrowed those balls and said, "We're sorry, we're really a Windows app..." I'll bet they'd have several hundred million more downloads, globally, for Windows OS. Think about it
If the new version is better on Linux and Windows, well I say congratulations. And I mean it, because I don't want other people's experience with software to be shitty, because I know what that's like. I get enough of that with fucking Apple OS.
> Uh, why do you have any significant memory overhead?
Because you have to have the original bytecode as well as the jitted code?
> Even badly optimized code should be pretty compact
I think you're severely underestimating the amount of JS modern web pages serve up and how big it ends up when jitted...
> True, but modern processors handle call/ret well.
Perhaps, but pushing all the args and popping the return values takes time.
In any case, as I said the true test would be doing both approaches and comparing.
I'm surprised the paper doesn't discuss these tradeoffs, though. Or does it?
1.) Turn on the developer menu under advanced preferences. This gives you DOM and CSS inspection, network activity monitor, user agent selection, JavaScript console and other basic web dev tools.
2.) Download Drosera. The download instructions for Safari 3.1/3.0 have you download a version of WebKit, but you don't need to install it. Just install the version of Drosera that comes in the DMG. You'll also need to enter the command to enable WebKit script debugging (provided in the link), restart Safari and you're ready to go.
I think FireBug still beats the Web Inspector/Drosera combo in a few areas (e.g. I'm not sure if you can dynamically alter CSS like you can in FireBug) but these tools get you most of what you're accustomed to in FireBug.
I didn't answer your post because you clearly didn't read mine, or at least failed to comprehend it. It is not a Javascript issue, it is a browser security issue. Yes, turning off Javascript eliminates the problem. But that's merely treating a symptom, not the disease.
As I said, if more browsers than IE supported multiple scripting languages you would see these exact same attacks in other languages. It's like claiming that because Windows is written in C/C++, and Windows has lots of virus problems, therefore C/C++ are at fault (well, C++ is for being a shoddy language >_>), not Windows security.
Does this make sense to you now or is it still flying right over your head?
Look at the nanojit code! Thank you for nothing... really.
No, I get your point. It's just flawed. This is pointless.
Yes, turning off Javascript eliminates the problem. But that's merely treating a symptom, not the disease.
Then, apparently since you AGREE WITH ME? Your point was flawed - it's pretty simple to fix, in that IF you don't use javascript, then you ARE SAFE vs. attacks that involved the use of javascript... period.
So I take it is your opinion that if browsers used Python instead of Javascript as their page scripting language that we would not see XSS attacks?
Now you're just being disingenuous. Offtopic my ass...
You're right. I was trying to point out that the problem is not contained specifically to, nor inherently caused by, Javascript. Silly me.
I browsed the first twenty or so comments here and saw nothing but "Microsoft", "pig anuses" and other troll stuff!
Can we maybe forget these Javascript discussions and perhaps go back to civilized talk about COBOL?
Like in the olden days?
...
.
- aqk
F U