Waterfox – A fast browser
waterfoxproject.org
waterfoxproject.org
Waterfox was started back in March 2011 by Alex Kontos,
a then 16 year old student. He had a fascination for
the web and wanted to help expand on the ideals of what
Mozilla had for a free and open web.
> wanted to help expand on the ideals of what Mozilla had for a free and open web
At 16(or even at 20) understanding free and open web and the importance of it and take action for consecutive 4 years is really awesome. We need more clones of you. Thanks Alex Kontos.
This doesn't even cover how much "Netscape" code was actually in seamonkey in the first place, and how much was the other way around from Netscape 6 on.
If anything, I could have used stronger words.
Given that most of Firefox is in JS so the actual code that you end up running is the JIT output, I'd be very skeptical it's any faster.
They certainly don't provide any objective data that it is.
(And if it were, I'd assume Mozilla would just Intel C for the official builds, too?)
Most of Firefox is JS? Almost all of the lines of code are C++, as far as I'm aware. Certainly the UI is drawn using XUL/XBL/web-stuff, but how often is web performance bounded by UI performance? It's bounded by the performance of the rendering engine, and that is C++.
> (And if it were, I'd assume Mozilla would just Intel C for the official builds, too?)
Seems unlikely, given the output of ICC is crippled for non-Intel x86 chips (which de-facto means AMD nowadays).
Significant parts of the functionality are written in JS.
>but how often is web performance bounded by UI performance?
It's often bounded by JS performance. JS performance depends on the JIT output, much less so the speed with which the JIT itself runs.
The rendering engine may be a factor, but there HW acceleration also factors in. It's far from being clear cut.
Media decoding already uses optimized assembler, nothing for the compiler to do there.
I'd suppose most of the gain would be in layout?
>Seems unlikely, given the output of ICC is crippled for non-Intel x86 chips (which de-facto means AMD nowadays).
You can patch that out. I'd hope this Waterfox is doing that...
Even so, Mozilla provides a stub installer that downloads the right binary nowadays. It could check the chip vendor and get the appropriate binary.
Such as?
> It's often bounded by JS performance. JS performance depends on the JIT output, much less so the speed with which the JIT itself runs.
On what? Last I looked, even things like FB & Gmail are largely bound by performance of C++ code. Sure, there's a few hot JS functions high-up in the profiles (esp. in the large data structures they build up when initially loading), but by and large time is spent in C++ code, not JS.
Looks for .js and .jsm in the source tree.
Bookmarks, Tab management, all UX, PDF viewer, Search, Prefs, Sync, parts of SafeBrowsing, WebRTC, Update Handling, Login and Form manager, Devtools, Reader Mode, and uh I think I've proven my point.
Not that I'm convinced simply compiling with ICC will actually have a noticeable impact on the day-to-day performance of the browser, but it might speed up layout and other specific CPU-bound tasks. I'd love to see some benchmarks, but I think it's silly to shrug it off by saying that it won't matter because the browser UI is written in JavaScript.
Years ago, I was forced to make a company's product faster by "simply" recompiling it with ICC. It was losing in the benchmarks department and they were told by customer to go away until they could compete. Addicted to easy money they blamed the compiler (VC on Windows, gcc on Linux - how conveniently both were bad at optimizing.) I had a hell of a time getting the compiler to be consistent - it would, for example, ICE on code after re-ordering headers! Their support was atrocious too - but that wasn't entirely their fault, at that level of messiness only a complete rewrite of the compilers by non-PhDs might have saved it.
For us, the performance was worth the effort of working around the bugs. But that's probably not the case for most projects.
For those who don't want to click a link or are using screen-readers (because yay textual content as an image!):
> Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.
Apparently there's a court order, as part of a settlement with the FTC [2], intended to stop the cheating, but apparently as of 2010, Intel still wasn't honouring it.
[1] https://np.reddit.com/r/pcmasterrace/comments/3s5r4d/is_nvid...
[2] https://www.ftc.gov/news-events/press-releases/2010/08/ftc-s...
For numerical code, ICC is amazing. But that's mainly because the automatic vectorization is far beyond anything clang can spit out (which is already better than gcc at automatic vectorization).
Even then, icc really benefits when you use its proprietary pragmas for hints.
The VTUNE profiler is amazing though
Without any benchmarks, it just seems like you want this to be faster, without providing any evidence that it is.
...no thanks, unless they want to share details of their sandboxing tech.
This is a huge claim to make with no evidence to back it up.
It's also a shallow comment. For one program, a compiler could compile faster code than another. Pick another another program and you may get the reverse result.
Plus I imagine the code is going to trail behind Firefox a bit. Is that worth probably a few milliseconds here and there?
I like your website though.
The Microsoft compiler works similarly. This is why "Release mode" builds with optimization on produce bigger binaries than "Debug mode" builds.
But, for end user apps with syscalls everywhere, I don't think the difference is notably different.
[1] A lot of compilers take "liberties" with the standard by default in the name of performance.
See for example, IBM's qstrict and qstrict_induction.
The default at O2 and above is Qstrict and Qnostrict_induction (IE "change the semantics of my program").
So if you really want to compare performance numbers between compilers, you have to normalize them to something first, be it "go crazy and do what you want to my program" or "follow the standard"
People who compare compiler benchmarks rarely actually do this.
Note that the use cases of the compilers are very different, so it's probably reasonable for IBM/Intel/etc to have these as defaults and GCC/LLVM to have different defaults, but it doesn't change what you would want to compare if you want to compare generated code performance.
Aw, snap.
Meh.
Stripping out features that are lazily-loaded JS files and in return being stuck with outdated stuff feels like a very weird tradeoff to me.
Extended Support Release
They're released on a much slower schedule (once a year) and get security fixes backported. They're intended for big organizations that don't want 6-weekly updates and are willing to live with outdated software.
But obviously its also handy if you want to fork and can't deal with re-basing every 6 weeks. Especially if you don't intend to update your fork a lot. You still get the free security fixes.
Rumor: "Pale Moon is just a rebranded rebuild of an old Firefox version"
FALSE
Pale Moon has been on a divergent path with its own code for a long time already. It was a rebuild in 2009, yes. It was a rebuild with minor changes in the Firefox 4.0 era, yes. But we've come a very long way since then with an increasing amount of different code being carried over each time it was re-based on later Firefox code. It's a true fork now and has been employing rapid development (as opposed to rapid release) to solidify this independent direction with its own focus and attempt at keeping the browser sane, lean, and offering users choice and stability.
At the same time, Pale Moon's focus on security and evolving networking standards has added features and kept pace with those developments in other browsers, by e.g. adding TLS 1.1/1.2 support a while back, by offering OCSP-stapling, by keeping a close eye on encryption and the browser's security by continuing to port or re-implement security fixes that apply to Pale Moon as a browser. It is neither old nor outdated, it is not a "rebuild" and it does not use obsolete technologies or have security holes.
Indeed. I'm a Mac user, so that makes it a non-starter. =/
If you're avoiding Firefox because of the crapware specter, you've been badly misinformed. Later versions are going to split out the Pocket nonsense into a separate plugin as well, so the browser goes back to being clean.
This gave me flashbacks to early Firefox download campaigns, and the excitement that surrounded each milestone download count. Seems like such a distant memory now.
Thank you Alex, keep up the good work!
I then went the whole hog to Firefox.
uBlock Origin, Self Destructing Cookies, and a VPN (PrivateInternetAccess) and I figure I'm getting as good as I can.
The lack of Flash is a non-issue nowadays for me, especially now the BBC are trialing HTML5.
(Although I generally use get_iplayer anyway.)
My primary issue with Firefox is it seems to be really poorly optimised for multicore CPUs. That's entirely anecdotal, but Opera runs just fine on a low clockspeed quadcore system whereas FF is unusable for me.
On my main machine, I get one core with moderate to high usage, and next to nothing on the other cores. Even if it's maxing out one core and lagging.
The goal says before the end of 2015... tick tock
Hey, I have a PC! It runs Linux. Care to change the above to "Download for Windows"?
K-Meleon has been around for a while and does subjectively feel much faster than Firefox and Chrome and passes most tests(Acid etc) out of all the alternative browsers.
Unfortunately, I've grown too used to some Chrome and Mozilla plugins so I haven't switched full time.
Features include customizable mouse gestures, tabs on the left/right/top/bottom, tabs with preview, tab stacking, tab page tiling, black color theme, custom shortcut keys, web panels, speed dial, etc.
FALSE
Pale Moon has been on a divergent path with its own code for a long time already. It was a rebuild in 2009, yes. It was a rebuild with minor changes in the Firefox 4.0 era, yes. But we've come a very long way since then with an increasing amount of different code being carried over each time it was re-based on later Firefox code. It's a true fork now and has been employing rapid development (as opposed to rapid release) to solidify this independent direction with its own focus and attempt at keeping the browser sane, lean, and offering users choice and stability.
At the same time, Pale Moon's focus on security and evolving networking standards has added features and kept pace with those developments in other browsers, by e.g. adding TLS 1.1/1.2 support a while back, by offering OCSP-stapling, by keeping a close eye on encryption and the browser's security by continuing to port or re-implement security fixes that apply to Pale Moon as a browser. It is neither old nor outdated, it is not a "rebuild" and it does not use obsolete technologies or have security holes.
Mm-Hm. How's that working out?
https://www.waterfoxproject.org/blog/ "Just a quick heads up why there hasn’t been any news from me in regards to the latest Firefox release. Mozilla have a new tuple header that they’ve created and gets used fairly frequently and unfortunately, this causes an internal compiler error as can be seen here." [Written by Alex Kontos November 9th, 2015]
Always a pleasure to count the number of clicks needed before you can establish that the only platforms are Mac and Windows.
Why so critical? He's making a bold claim, but you're not even responding to that. You're just attacking him because he's using a different compiler suite? If you know of problems with the Intel compiler suite, how about you let us know what they are instead of passively aggressively pointing to a single recent problem which from the bug report I'm not sure is the fault of Intel's compiler not being conformant or not functioning with a recent feature, or GCC accepting a non-conformant structure, and whether being cross-compiler portable in that way is even a goal of the Firefox team.
> Always a pleasure to count the number of clicks needed before you can establish that the only platforms are Mac and Windows.
Would you like to guess how many clicks it takes to determine that for Firefox itself when you aren't currently running Linux? It used to be you could easily get to a directory listing of Firefox builds. Apparently it's harder to find now, and Firefox just starts an auto-download for your OS and architecture based on your user agent, and if you search for how to install on Linux, they make it clear that may not be the best way to install ("Use the method that works best for your distro", which may be through the distro package manager).
"Always a pleasure to count the number of clicks needed before you can establish that the only platforms are Linux, Mac and Windows."
I think FreeBSD is definitely the sweet spot for counting clicks.