Slashdot Mirror
Minefield Shows the (Really) Fast Future of Firefox
zootropole writes "If you are using Firefox 3 (or even Chrome) you should consider taking a look at Mozilla's Minefield. This browser (alpha version yet, but stable) would give a new meaning to 'fast browsing experience.' Some Firefox extensions aren't supported, but riding the fastest javascript engine on the planet definitely worth a try. Minefield's install won't affect your Firefox, so there's no risk trying it. It's fast. Really. And I'm loving it."
Reviews popping up around the web are overwhelmingly positive, calling the upcoming browser crazy fast, blisteringly fast, etc.
These are the nightly builds, once they like how the nightly builds work, they will release them as a "Firefox" update.
"Minefield" is just the development codename for the 3.1 series.
They will, it's an early beta and is therefore considered unstable...
Today's nightly for mac crashes on http://www.pentestmonkey.net/jsbm/index.html which is a javascript benchmark, i was trying to see if it really is as fast as the article claims... Currently the webkit nightlies seem to be the fastest on this benchmark, by quite some considerable margin.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
If it is that much better, why arent they just replacing Firefox with it??
They will, though it will be called Firefox when that happens. "Minefield" is just the code name for Firefox 3 nightlies, and it's called that for a reason: as a developer-intended build, it's prone to blowing up.
It will be released when it is ready. That time isn't yet.
Minefield isn't very different from FF at all.... because Minefield *is* Firefox. The main development code is called Minefield. At different points they branch the code off to become the versions of Firefox that we all know.
So they branched Minefield several months ago to become Firefox 3.0 but continued work on Minefield and now a new branch from Minefield will become Firefox 3.1.
It has the potential to be, at least for interpreting javascript. The gui still feels a lot more sluggish though, and general rendering still seems quite a bit slower as well. Just remember to do the about:config thing, then search for jit, and turn the two options on to get the speed boost.
Everything will be taken away from you.
its fast, its stable, my extensions work ;)
Especially Zotero (SVN) rocks !!!
What the hell kind of codename is that? Maybe an attempt at 'truth in advertising'?
That's exactly what it is. Minefield always refers to the current alpha-release of the upcoming "major" release.
Don't use it unless you know what you're doing. Suggesting end-users use this, without briefing them on why it will crash [frequently], is irresponsible at best and does a disservice to the alternate browser movement.
You won't see a difference because pages are designed for slow browsers (IE6/7, FF2, etc). So they don't tap into the power of javascript as much as they could be, for performance reasons. You'll see the difference in a fully client side (aside for json REST service calls) javascript app made in ExtJS or similar toolkits (there's a few). Then performance matters.
Of course, you have to enable the TraceMonkey JIT JavaScript compiler before you'll see any reasonable speed increase (in theory). Just go to about:config, search for the 2 items with "JIT" in their name, and enable them.
My stress tests have shown it to be 10-50% faster than Chrome *when* JIT works. However, it's still buggy as hell, it eats its own memory heap and grinds to inexplicable halts kinda randomly whenever my code does anything repetitive and strenuous, bringing the average execution speed down to almost FF2 levels, meaning it's faster for me to leave JIT disabled. It's a no-go for me until they fix that.
Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson
People are talking as if Chrome's V8 was the fastest JavaScript engine around, but it wasn't - WebKit's SquirrelFish Extreme was faster. Is Minefield's engine even faster? Ars Technica's tests show that TraceMonkey runs the SunSpider benchmark in between 78% and 84% of V8's time. However, according to earlier tests, SquirelFish Extreme completes the benchmark in 74% of V8's time, making it even faster than the newest TraceMonkey. So it looks like Minefield, though fast, is not the fastest browser in JavaScript.
No it is the name for the unstable trunk, Shiretoko is the code name for Firefox 3.
These people look deep within my soul and assign me a number based upon the order I joined. -Homer Simpson
err 3.1
These people look deep within my soul and assign me a number based upon the order I joined. -Homer Simpson
People. There is A REASON why Mozilla calls these builds "Minefield" rather than "Firefox".
It's because they're not ready for daily use.
They may be faster than the released version of Firefox, but they also may contain major, showstopping bugs, up to and including bugs that can cause data loss.
The only people who should be using them are people who understand this risk and are willing to accept it -- i.e. testers.
Anyone promoting these builds for use by the general public is being irresponsible and exposing anyone who takes their advice to risk.
TFA is bad enough, but it's worse to see major sites like Slashdot parroting this bad advice. You should be telling your friends to avoid Minefield, not to seek it out.
Read my blog.
But has the JIT code been implemented for PPC?
No. They seem to be planning to have PPC support eventually, but work is in very early stages.
Please remember that if you messed with minefield "a few months back" then its been through dozens of iterations since then. It's a nightly build.
It's a codename for the Firefox development branch. Nothing will ever be released with that name, it's a moving target that gets branched out to Firefox for release.
Reading FTW!
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Javascript was not created by the opensource community (it was created by Brendan Eich and ended up becoming part of Netscape, which was not open source at the time). Additionally, Javascript has reasonable structures that don't deteriorate when the software expands to large sizes.
Check out Synchronet, it has IRC servers, NNTP servers, Gopher servers etc. all written in javascript. The code is completely readable (generally not the case with VB when the code reaches that complexity) and cross-platform.
There is nothing fundamentally wrong with the Javascript language, like there is in visual basic.
Change is certain; progress is not obligatory.
Someone cheched the startup time of FF3.1 ? Compared to Chrome FF 3.0 takes ages.
The browser war heated up when Google (and others?) started paying out on ad revenue created by in-browser searches. Apple makes some nice change on Safari. So does the Mozilla Foundation, apparently.
There would be very little competition if there wasn't money to be made.
Actually, that's a Jerry Pournelle quote about AT&T, and it was "Hot Dead Chicken".
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
ffs. This story has been making the rounds about "Firefox Minefield" being an awesome browser. Well the next release of Firefox may be awesome, but this is a nightly build that was given the name Minefield so people might get the idea that, as the parent pointed out, it's unstable.
more of the same on Twitter.
I don't even understand the hype about it being fast. It's *really* slow compared to for example the latest WebKit nightly, here's the benchmarks on my machine:
Sunspider:
FF3.0.3: 2697.2ms
Minefield (jit enabled): 1412.4ms
WebKit: 680.6ms
V8 bench:
FF3.0.3 - 199 runs
Minefield (jit enabled): FAIL (brings up printer dialog rather than actually running javascript)
WebKit: 2342 runs
ACID 3:
FF3.0.3 - 71 and significant laggyness
Minefield (jit enabled): 89 with only a little jitteryness
WebKit: 100 totally smooth.
And what's amazing, and completely against capitalism, none of these web browser makers are charging any money for their products! All this great software is being developed and given away for free!
Capitalism and free markets are about the free exchange of goods and ideas, with the people involved in the exchange (and only them) setting the terms of the exchange.
Whether the terms of the exchange involve money or not does not have much to do with the idea of free exchange.
Presumably, the people who do user support.
Nerd rage is the funniest rage.
They will replace the current FFox with what is in Minefield - when it is ready.
https://wiki.mozilla.org/ReleaseRoadmap
Minefield is just the code-name for the trunk. You see, during development new stuff is submitted to the main branch - the trunk. This is where big changes like a new javascript engine or big changes to the html rendering engine happens.
You can download Minefield today to take a look at what is currently on the main trunk. But this code is often under heavy development and has not gone through all the testing/fixing that an official release gets. That's why they call it Minefield, it can and will blow up now and then.
When the current trunk has all the features one wants for the next version of FFox, they do a branch. They then do stability / security fixes etc on this branch (but no big new features). From his branch you then get the FFox betas/release-candidates and then eventually the shiny new FFox 4 (or 3.5 or whatever they'll call it).
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
Cause we all like benchmarks.... Here is a breakdown of some browsers' times: (all were freshly installed and used http://celtickane.com/webdesign/jsspeed.php for tests) minefield 3.1b2: ~193ms chrome 0.2.149.30: ~234ms opera 9.61: ~203ms internet explorer 7: ~2328ms safari 3.1.2: ~203ms These were all done on the same computer.. this is why we have competition kids..
Which is why one should only use ECMAScipt.. No more confusion. Unfortunately, more people rather just use the Javascript sublanguage (is that even a word? Maybe dialect?).
PowerPC is being added to the Nanojit (backend for Tracemonkey and Tamarin).
Help is welcomed. Hop onto #tamarin for pointers.
Link to nightly Webkit: http://nightly.webkit.org/
I just now tested it on that site:
MD5 Benchmark took 1.188 seconds for 3000 hashes (2525 hashes/second)
MD4 Benchmark took 0.839 seconds for 2700 hashes (3218 hashes/second)
SHA1 Benchmark took 1.201 seconds for 1900 hashes (1582 hashes/second)
I also tested SRware Iron (A variant of Chrome) on the site, and scored significantly higher:
MD5 Benchmark took 0.343 seconds for 3000 hashes (8746 hashes/second)
MD4 Benchmark took 0.232 seconds for 2700 hashes (11638 hashes/second)
SHA1 Benchmark took 0.299 seconds for 1900 hashes (6355 hashes/second)
This space for rent, inquire within.
These benchmark results are a bit debatable - I've seen different suites electing different "winners" and, while SunSpider seems to be the best, it's a long way from a robust benchmark like SPEC* or DaCapo.
In any event, even if SFX is leading the pack right now, that's because it's the most mature competitor, and its advantage won't last too long. I predict (and I write this logged with my account, not AC, so I would be forever glorified when this becomes true in 12 months max) that both V8 and TraceMonkey will take the lead, leaving SFX in a safe third place permanently.
The reason is very simple. All these new JS VMs are JIT compilers, producing native code. But SFX is a context threaded JIT. Context threading is just a step beyond traditional direct-threaded interpreters: functions are 'compiled' into streams of CALLs into routines that implement each bytecode operation, but there is limited inlining (simple operations and branches), with a focus on reducing branch misprediction.
OTOH, both V8 and TraceMonkey are "real compilers" that emit real native code (not CALL streams) for entire functions (or even larger chunks of code, with inlining). This is necessary to enable traditional optimizations like register allocation, instruction scheduling, constant folding, loop unrolling etc. Some of these optimizations can be performed on a high-level intermediate code representation (HIR), but that's typically not worth the effort without real compilation. E.g., loop unrolling will just waste memory an i-cache efficiency if performed by a threaded interpreter/JIT... as the real benefit of unrolling is giving the compiler a much larger basic block to perform other opts like extra folding and bounds-check elimination, or real low-level tricks like exploring using SIMD registers and operations / Instruction-Level Parallelism / prefetching / branch predication etc.
The only reason why V8 and TraceMonkey don't completely 0wn the benchmarks today, is that these JITs are still in their infancy. They have implemented the foundations (like V8's hidden classes or TM's tracing), but they still miss to implement dozens of important optimizations (including very easy ones - they just didn't have the time yet). Check some comments about V8's limitations. TM's developers have also commented on many limitations, quote (Andreas Gal: "If it talks to the DOM during the benchmark, we currently donâ(TM)t compile across such calls (we plan to for Beta2 though)". This and several other improvements are planned for future builds of Firefox 3.1. Notice that items like special support for DOM interactions and event handlers should be critical to some benchmarks - and of course to real-world RIA apps. I'm sure the V8 hackers are also working around the clock to fill in their own gaps. When both VMs are reasonably mature, SFX will have a VERY hard time competing (unless of course, they abandon the context threading model and mutate into a real compiler). Other optimizations, like JITted regex, can be implemented in all VMs and will eventually be ubiquitous.
My results confirm yours
Minefield
MD5 Benchmark took 0.71 seconds for 3000 hashes (4225 hashes/second)
MD4 Benchmark took 0.446 seconds for 2700 hashes (6054 hashes/second)
SHA1 Benchmark took 0.721 seconds for 1900 hashes (2635 hashes/second)
Chrome
MD5 Benchmark took 0.411 seconds for 3000 hashes (7299 hashes/second)
MD4 Benchmark took 0.162 seconds for 2700 hashes (16667 hashes/second)
SHA1 Benchmark took 0.18 seconds for 1900 hashes (10556 hashes/second)
and just to laugh IE 7
MD5 Benchmark took 3.885 seconds for 3000 hashes (772 hashes/second)
MD4 Benchmark took 12.473 seconds for 2700 hashes (216 hashes/second)
SHA1 Benchmark took 3.838 seconds for 1900 hashes (495 hashes/second)
All running on Vista with a Intel Core 2 Duo E4600 @ 2.4 GHz
SVG absolutely rocks.
Opera demo'd awhile back how a few lines of inline SVG can be used to give you a perfectly smooth gradient background.
SVG isnt just an laternative to flash, it could be an alternative to *a lot* of linked images in webpages, and really speed up the whole internet because of it.
Of course though, IE...even IE8, stubbornly dosnt want any part of SVG. (SVG plugins are next to useless as they slow and *overlay* the svg)
I wouldnt be supprised if Microsoft has had an Adobe bribe not to support SVG frankly.
I think the hype is that in the latest nightly builds, apparently you are not using, the JIT has been turned on by default.
There is a spark in every single flame bait point.
The problem with that bug is that the Xorg graphics performance stuff... sucks. A lot. A lot of rendering is actually faster done entirely in software than trying to go through X's "accelerated" stuff. Some of this is due to Render shipping stone-age versions of pixman and actually doing its own software rasterization when you'd think it would use your graphics hardware.
And best of all, the response of the Xorg developers to all this is "once we finish our new acceleration architecture in a few years, all this should be better". They've said it for quite a while now, with at least 2 different acceleration architectures.
So yes, Mozilla does give "a flying ...." about Linux, but that doesn't help much in this situation.
I got a 93 on my ACID3 test with the latest nightly so I'm wondering where you got your numbers. Are you sure that you have the latest minefield?
See: http://acid3.acidtests.org/
check out the best blog ever:
http://oehlberg.com
When it installs it must piggyback off the main firefox profile
That's exactly what happens. When the brilliant zootropole says:
Minefield's install won't affect your Firefox, so there's no risk trying it
...he's means only that unpacking the nightly build archive won't replace your existing Firefox binaries. Running it, however, will immediately step all over your default Firefox profile. I guess zootropole doesn't give a damn when he misleads people.
The safe procedure:
1. Shut down FF. (yeah I know it can be done without shutting down, stfukthx)
2. Run your existing FF from the command line like so
firefox -profilemanager
3. Create a new profile (MyFF31profile, whatever) in the profile manager.
4. Run FF31 like so
The above will isolate FF31 to a distinct profile, on *nix. Windows? My sympathies, no help here.
Lurking at the bottom of the gravity well, getting old