Comment by devx | Hacker News Reader

Comment by devx | Hacker News Reader

Parent Full thread

If they make their next-gen browser using Rust, I hope they make it 64-bit-only, and optimize it as much as possible for x64 and ARMv8. None of that "support back to Windows XP!" stuff. It wouldn't be necessary (will still have Firefox a few years longer for that), and it would just hold them back in terms development time, maintenance, performance and security.

Then it would be not just great PR for their "highly-optimized no legacy cruft 64-bit browser", but would also give people a reason to switch from Firefox to it. It would also give Mozilla an excuse to not make a 64-bit Firefox anymore.

I assume it's going to take them at least 2-3 years to do it (if they ever plan to release it), and by then Microsoft will probably release a 64-bit only Windows 9, iOS will be 64-only, too (probably not relevant to Mozilla, but could be in the future), and at least half of all Android smartphone users will have ARMv8-based devices.

Mozilla should take full advantage of this, and really push for performance (and security), and they should only make it available from Android 5.0 (probably the first 64-bit Android version) and Windows 7 x64. Support for Linux kernel should probably start with no lower than 3.10 LTS (contains all the ARMv8 support).

You make good points, and the Servo team is doing more or less as you described. Our primary target is 64bit and we plan to leave behind lots of legacy stuff.

The extra parallelism we're after also enables new things too. For example, Servo runs cross-origin and sandboxed iframes in parallel.

You sound interested in this: https://blog.mozilla.org/blog/2013/04/03/mozilla-and-samsung...

And this: http://people.mozilla.org/~roc/Samsung/MozillaRustAndServo.p...

Note that Windows XP 64 bit was a thing. :-)

Very few of today's apps actually benefit from having more than 3GB of address space. Nothing on my desktop PC is using more than 300MB at the moment. All else being equal, 32 bits will be more efficient, particularly on portable devices which tend to have far less memory bandwidth.

All other things are not equal, however.

True, there can be address space fragmentation issues on large 32-bit processes.

What else did you have in mind?

The extra registers and other advancements in instruction sets help a lot.

x86 has some enchancements, but if you think that 64-bit is bad for mobile, I strongly suggest looking at the A7 32 vs 64 benchmarks. ( http://anandtech.com/show/7335/the-iphone-5s-review/4 )

Of course, the performance gains have really nothing to do with 64-bit addressing alone, but ARM took the opportunity to almost completely redesign the ISA, and A64 is in general a better and faster ISA than A32. So all else is not equal.

I actually find this 64-bit-has-better-ISA-than-32-bit situation annoying. I would like to have better ISA, without making pointers larger. There is x32(https://sites.google.com/site/x32abi/), will there be something similar for ARM?

ASLR works much better in a 64-bit process.

mmapping files without blowing out your address space works a lot better in a 64-bit process (and system libraries love to mmap things like fonts, which can quickly take up a bunch of address space).

I just took a look at the address space usage on my Mac, and the spotlight indexer seems to be using about 1.5GB of address space (and 350MB of actual RAM, for some reason?), and a number of other built-in things (WindowServer, Apple80211Agent, Dashboard) are all north of the 500MB address space mark.

ASLR, yep.

But I think most stuff that runs off of soldered-on DDR3L and flash RAM (e.g., apps on phone and tablet OSes) may be better off sticking with 32 bit addresses for another generation.

JavaScript engines particularly benefit from running on 64-bit. Modern JavaScript engines use 64-bit value representation, even on 32-bit.

OK, yeah the fundamental number type of Javascript is the 64-bit floating point double so I could see how the ability of a JIT to emit code to handle 56 bit integers might be useful. But it would still be a tradeoff against the cost of doubling the size of every pointer.

Reply on news.ycombinator.com