Firefox 4's JavaScript Now Faster Than Chrome's 352
An anonymous reader writes "Firefox 4's JavaScript engine is now faster than V8 (used in Chrome) and Nitro (used in Safari) in the SunSpider benchmark on x86. On Mozilla's test system Nitro completes the benchmark in 369.7 milliseconds, V8 in 356.5 milliseconds, and Firefox 4's TraceMonkey and JaegerMonkey combination in 350.3 milliseconds. Conceivably Tech has a brief rundown of some benchmark figures from their test system obtained with the latest JS preview build of Firefox 4: 'Our AMD Phenom X6-based Dell XPS 7100 PC completed the Sunspider test with the latest Firefox JS (4.0 b8-pre) build in 478.6 ms this morning, while Chrome 8.0.560.0 clocked in at 589.8 ms.' On x86-64 Nitro still has the lead over V8 and TraceMonkey+JaegerMonkey in the SunSpider benchmark."
Re:6 milliseconds! Wheee!!! (Score:2, Insightful)
Having good javascript runtimes will help the web go to the next level. This is useful for the gaming industry to tap into the non-gamers and casual gamers pool, e.g. this this port of quake that is able in javascript as a proof of concept:
http://code.google.com/p/quake2-gwt-port/
But this can also be useful for non games usage: applications such as google street view and google earth could soon be embedded in regular webapps without the need for flash plugin for instance.
thats great but.... (Score:2, Insightful)
Benchmarks (Score:4, Insightful)
I am sure this will set off a whole series of arguments over benchmarks, tuning, fairness, etc. But from this article I will just take this: I don't care which one is fastest to the few dozen milliseconds, they are probably all in the same "class" now. Everybody wins. (I can sorta understand not including IE, but wonder why they didn't include Opera?)
Now that Javascript is so much faster, perhaps the browsers can focus on giving some type of automated/intelligent control over when it is used and how so older machines won't come to a CRAWL because of all the cutesy animation and junk spread over most big sites now. (And no, NoScript doesn't cut it- too complicated for most users, not automatic, too easy to break Javascript that is actually needed, etc). Suppress time-delayed actions, disable tight loops, throw artificial delays in loops under user control, visually tag elements to manually "play" on-demand only or stop after X seconds. I know, keep dreaming.
Re:thats great but.... (Score:2, Insightful)
Given that a lot of the browser is implemented in JavaScript, it should also make the browser itself faster.
Re:What's the benefit ? (Score:1, Insightful)
I'm so glad I'm not having to run all web servers at my home. Sure, you load your application on the server, but JavaSCRIPT runs on a browser. This is not server based JAVA but browser based JS. I need it to run faster because I have an application that very much needs JS to run faster on browsers. Why? Because my target audience is the world and not just the US. This means that I want to load applications on the users computer that they can run partially locally. We need this faster, computers faster, and Internet faster everywhere to make applications better for the user.
Re:Benchmarks (Score:3, Insightful)
Flashblock only stops Flash, not Javascript animation. First it was animated GIF, then Flash, and now it is Javascript animation. Animated GIF and Flash are both easy to control. But Javascript animation is a whole different story. And although Adblock helps, a lot of the stuff is not ads.
Web site designers don't seem to give a damn how much horsepower their site need or use. It is apparent when you try to browse the web using an older machine, or a smartphone. And on a portable device, all that extra "crud" eats up the battery fast.
Re:6 milliseconds! Wheee!!! (Score:4, Insightful)
I'm not looking forward to 'the next level' of the web. It will only have more dancing and blinking crap on the page.
Want to make you site fast? You don't need Ajax, Flash, or any other "Hype du Jour". Toss it all out, stick with plain old HTML and make it look decent with simple CSS. Wham, your site is now an order of magnitude faster. You don't need those five load balancers and those twenty application servers just to serve up a page that could easily run on one server when you actually had a clue.
The Web is rapidly going the way of television: once it was about content, then ads came 'to pay for the content' and now it is all ads with the absolute minimum of content. Spreading a two paragraph article over eight pages just to have more ad impressions. Six pictures that just have to be in a slide show. Ads. Profit. Bottomline.
Get me a bucket, I'm going to hurl...
and yet Firefox still can't use 1 core... :( (Score:5, Insightful)
Tell me, mr anderson, what good is javascript performance if you are unable to use multiple cores?
I wish someone would get on this and make firefox work with multiple cores better. As it is I use the "|" character in my home page settings to open about 20 tabs-- forums, review sites, slashdot, economics blogs, etc....and firefox slows to a grinding halt for about the 15 seconds (just timed it) it takes to render all those pages.
Chrome does it in about 4 seconds and pegs all 4 of my cores to 100%.
Please Mozilla, I know this would require a serious redesign, but it's seriously needed. Hitching while scrolling up/down because a tab is loading in the background (I make use of middle click to open tabs in the background extensively) is very annoying.
I can only see one use case for faster JS (Score:2, Insightful)
Really, all this focus on faster Javascript puzzles me. JS, used correctly, should be a thin layer of glue, representing only a fraction of the total run time for a browser. The only real use I could begin to see would be if they could apply the same speed-ups to the Actionscript engine within Flash to improve the decoding of Hulu's encryption system - but since all the client sees is the bytecoded form of the decryption, not the AS source, and since this speedup is in the JS in the browser rather than the AS of Flash, I have to ask, "what good is making JS run faster?"
The biggest "slowdowns" I see with JS are mostly due to poorly written JS doing busy loops waiting for "stuff" to happen, rather than doing completion routines (as in the whole asynchronous part of A JAX?). No speed ups in the engine will make a busy loop run faster or take less CPU time. If we could break programmers of the busy loop habit, perhaps by making JS be truly multithreaded, and providing proper blocking APIs (semaphores, message queues, etc.) it might make a difference.
Quake II was released in 1997. (Score:2, Insightful)
Quake II was released in 1997. That's 13 years ago. At the time of its release, Intel's top-end CPU was the Pentium II running at 233 MHz, and even that had only just been released. Most Quake II players were still using Pentium or high-end 486 systems.
Today, a decade and a half later, we have cell phones that are many hundreds of times faster than those Pentium and Pentium II systems, and desktop systems that are thousands or tens of thousands of times more powerful. Yet with all that raw processing power, JavaScript still barely allows us to do what we could do way back then.
I don't know if you've tried it yet, but that version of Quake II that you've linked to runs quite poorly on very modern hardware when using Chrome (which has the best JavaScript implementation around).
If JavaScript doesn't let us easily do what we could do before, we'll never be able to get further ahead.
Re:I can only see one use case for faster JS (Score:3, Insightful)
Really, all this focus on faster Javascript puzzles me. JS, used correctly, should be a thin layer of glue,
That was the original idea of JS. It's already being used much more heavily in current web apps. But the main point of speeding it up isn't for today's websites, it's so that websites can do entirely new things without bringing the browser to a crawl. Think image processing, online mini-games, and no doubt hundreds of more imaginative uses.
Most of Firefox is written in JavaScript. (Score:3, Insightful)
I know, I know, it's damn near impossible to believe, but the Firefox developers voluntarily chose to write a huge portion of Firefox in JavaScript and XML (XUL). The rendering engine and network stack are written in C++, but just about everything else is implemented using JavaScript and XUL, including all of the UI.
This is why JavaScript performance is so important to Firefox. While other browsers didn't make the same mistake, and wrote the bulk of the browsers in a real language like C++, the Firefox developers chose what is probably the stupidest architecture possible. A slow JavaScript implementation means their entire browser is slow, rather than just any web pages that might use JavaScript in some way.
Re:FF4 has some pretty serious memory leaks still, (Score:2, Insightful)
Fragmentation can certainly cause a program to slow down. If memory is fragmented significantly, you're going to see a lot more page faults as memory is accessed. With an OS like Windows that's aggressive in moving memory out to disk things will certainly slow down.
Re:FF4 has some pretty serious memory leaks still, (Score:5, Insightful)
I think they forget that page caching is not a leak.
Re:FF4 has some pretty serious memory leaks still, (Score:3, Insightful)
Re:What Mozilla giveth, Slashcode taketh away. (Score:4, Insightful)
I actually like d2. I hate loading new pages for comments below my threshold. I just wish d2 worked better on iOS.
Re:FF4 (Score:3, Insightful)
You're an idiot. There's no strict definition of what a beta release is or how often it can be released and, since everybody has a different way of working and putting out releases, there's no way to compare the number of betas to anybody else that produces any meaningful statistic.
Re:Quake II was released in 1997. (Score:3, Insightful)
Hyperbole much? Cell phones aren't many hundreds of times faster than a Pentium or a P2, and desktops aren't thousands, much less tens of thousands of times faster. Hell, the clock is only about 10x faster (2GHz to 3GHz) -- where exactly do you think a 100- to 1000-fold increase in per-clock performance is coming from?
For the record, the Quake 2 software renderer apparently does about 250 fps at 800x600 on todays top-of-the-line Intel CPUs. I still remember how Quake1 was choppy in software mode even at painfully low resolutions (I guess this must have been on a 133 Mhz Cyrix CPU).
Re:FF4 has some pretty serious memory leaks still, (Score:1, Insightful)
Re:What Mozilla giveth, Slashcode taketh away. (Score:4, Insightful)
I think Slashdot's AJAX is pretty poor, certainly not in line with what some of the better AJAXy sites do. That said, and even though I also keep having to look for stuff, I really love being able to things like in-line previewing and replying. I used to open the reply link in another tab, but that's a bad workaround. And changing the treshold without reloading the whole page is also nice, as is opening up "titles only" posts.
Re:Lets move to gopher or whatever (Score:3, Insightful)
Tired of http? Lets move on to gopher..
Re:FF4 (Score:1, Insightful)
Unfortunately for people like you, your appeal to credentials often doesn't make you sound more convincing, but simply causes many to further confirm their own suspicion that PhDs are mostly clueless and out of touch, and 25 years of experience implies old and busted. Neither are valid conclusions, but people like you certainly don't help matters.
I would say it is a safe bet you are an idiot, or at least not the sharpest tool around if you can go for 25 years professionally and yet still think that a dick-size statement like that means anything useful, especially in regards to an admonishment to "be more polite."
Re:6 milliseconds! Wheee!!! (Score:5, Insightful)
1) Nobody uses load balancers and multiple app servers because they're serving "dancing and blinking crap" (Flash and JS heavy) sites. Those things slow down people's browsers, not the servers. Heavy server resources are needed when you need lots of server side processing, which generally comes from delivering customized pages to every user (ie you can't just cache everything). Furthermore, using AJAX helps REDUCE server load, by only requesting snippets of content, instead of complete page requests; you think GMail would be faster and less server-intensive if every click required a full page response? How about Google Maps?
2) You seem to be under the impression that developers actually design sites. Maybe in some tiny one-man-show setup, but in the real world a UX/IA specialist designs the user experience, a designer does the visuals, the client signs off on it, and then the developer makes it all happen using whatever tools and techniques are necessary. They don't have the option to "toss it all out" and make it as simple as they like, much as they'd like to. Heck, I have to fight to make sure there's accessible fallback versions of the fancy JS-enhanced UIs everyone designs these days. "Throw it all out"? You live in a dream world buddy, or you do work of extremely limited scope.
In short, your post is just "get off my lawn!". More and more clients demand rich user experiences, and this will continue to grow. Welcome to 2010.
Please stop moaning! (Score:4, Insightful)