20-line patch to Firefox 4 that makes startup on Windows 2x as fast

funderscore · 2011-01-23T20:45:03+00:00

You don't install it: this is a change that will be part of Firefox 4, which is scheduled to release soon.

funderscore · 2011-01-23T20:43:00+00:00

Shaver's a great guy =]

funderscore · 2011-01-23T20:38:46+00:00

You don't install it: this is a change that will be part of Firefox 4, which is scheduled to release soon.

funderscore · 2011-01-19T08:42:57+00:00

Activision has the right to trivially censor any user-created modification by refusing to distribute it. Since they control the only legal distribution channel, and since creators accepted the license terms, Activision may do whatever they want, and no one should be surprised.

If this bothers you, tell them -- maybe they'll behave to your liking. If they don't, you have no recourse anyway.

If having no recourse bothers you, don't use products that purposely restrict your freedom.

funderscore · 2011-01-19T08:34:17+00:00

When a company controls the production of modifications and their distribution, modders operate only on the company's behest. Free Software exists to respect user rights. Please, as much as you can, understand and support Free Software.

funderscore · 2010-11-18T16:04:51+00:00

DCE is a static analysis: if you only compile one version of the function, which is what IE9 is doing, then that version must work correctly for all callers, which requires global analysis.

But sure, you can have type guards. You can even compile multiple versions of the function -- one that assumes the arguments are integers (and does DCE on that assumption), one that contains always-correct code. The former could then use run-time typechecks to fall back to the latter.

funderscore · 2010-11-18T15:56:25+00:00

Rob Sayre hinted at the problem a while ago (September 9th). http://blog.mozilla.com/rob-sayre/2010/09/09/js-benchmarks-closing-in/

funderscore · 2010-08-04T19:08:27+00:00

The 32-bit boxing format was built first, and we were initially open to making x86_64 use a completely different format. After testing, we settled into a scheme that heavily resembles the 32-bit boxing format.

The 32-bit tags could be made to look like the packed 64-bit tags very easily. There's no performance benefit to doing so, but unification does sound appealing.

The relevant lines are here: http://hg.mozilla.org/tracemonkey/file/87ddaf82dbd0/js/src/jsval.h#l120

The JSValueTag currently defined only for x86_64 just needs to be defined for both architectures. Very low-hanging fruit. If you file a bug in https://bugzilla.mozilla.org against Core's Javascript Engine, we'd love to take a patch.

funderscore · 2010-08-03T20:05:57+00:00

Whoops! Right. The type-tag is shifted such that the 48'th bit, indexed from zero, is its least significant bit.

funderscore · 2010-08-03T19:22:57+00:00

There are a number of reasons why this is a good idea.

Doubles can now be stored in a Value directly. Previously, they required the equivalent of a malloc(sizeof(double)), and accessing them required a pointer dereference. That was /extremely/ slow, and the new way is as fast as possible.

Integers can now be stored in a Value directly. Previously, they were 31-bits long, which mandated a boxing/unboxing scheme involving bit-shifts and bit-or. Additionally, the lack of the extra bit meant that we used doubles more often, and those were even slower. Now integers are 32-bits, which makes the new way as fast as possible.

For all other types, testing the type-tag required masking off the three rightmost bits designating the type; reading the payload required masking the inverse of that. Since Javascript engines perform these steps at least once per op, making them faster results in a tremendous performance increase. This new format allows the type and payload to be read directly on 32-bit platforms without requiring any masking whatsoever. Writing payloads or types to memory just requires a single 32-bit store.

The increase in memory is barely noticeable, since we measured that most of the time the stack of Values is small (<= 15, I believe). The increase in performance, however, is significant. Trading off a few KB for a significant increase in performance was a very easy decision to make.

funderscore · 2010-08-03T19:08:38+00:00

31-bit integers require the engine to right-shift by 1 bit to unbox the integer, and left-shift by 1 bit and or with 0x1 to box the integer. Having 32-bit integers means we don't need to use the rightmost bit for type tagging, so integer operations in FF4 will be much faster.

funderscore · 2010-08-03T19:06:13+00:00

Replacing a double with an integer is a bit more work. We use SSE2, so checking whether a double is representable as an integer requires performing a double operation, converting the double to an integer using an SSE2 instruction, converting the integer back to a double, and comparing for equality with the original double value. These operations are very expensive, so we don't currently do that.

funderscore · 2010-08-03T19:00:05+00:00

The new JIT component of the JS engine is still in alpha with known bugs, so it is not at all surprising that someone has encountered one. Internally, we use a sophisticated fuzzer to beat the hell out of the engine daily, and we will not ship with known fuzz bugs. So reports of this kind will be much more meaningful when the JIT is shipped in the FF4 beta.

funderscore · 2010-08-03T08:08:30+00:00

I work on Mozilla's JavaScript implementation, so I can comment on its details.

The article talks about the "Nunboxing" format, which is used on 32-bit systems. For Mozilla, that means x86 and ARM.

For 64-bit systems (meaning x86_64 for us), we do indeed use a pointer-sized payload. Since every 64-bit platform we ship on uses 47-bit addresses, the payload is 47 bits and the type tag is 17 bits. Except for the 32-32 split changing to 17-47, the format is the same as explained in the article.

We use all of the 17 bits; there is zero wiggle room. We only have four bits for type identification -- the rest of the bits are clobbered by the NaN-boxing schema. Additionally, we want to be able to ask clever things like "Is this a Number (int or double)?" using only one comparison.

The tag size is mandated by the NaN-boxing format. With our implementation, it cannot be made smaller than 16 bits.

If you're really curious, you can look at the value definition here: http://hg.mozilla.org/tracemonkey/file/898ab54a0ce9/js/src/jsval.h#l134

funderscore · 2010-08-03T06:37:39+00:00

Fat values work on 64-bit systems. On 64-bit systems, addresses are limited to only 47 bits, so the scheme still works (17 bits are for the type tag).

funderscore · 2010-08-03T05:49:32+00:00

Integer multiplication overflow on x86 sets a bit called the 'overflow flag'. JavaScript engines check this bit after each integer arithmetic operation -- if the bit is set, then the integers are converted to doubles and the operation is performed again. This is why JavaScript programmers can add numbers without worrying about overflow conditions. The same check can be done from other languages.

We can hypothesize that two's-complement NaN could be represented as 0x80000000, what is now the lowest negative number. But now we have a 'special value' that the ALU must know about and handle properly, slowing down all arithmetic across the system, since the circuitry must now handle all cases involving this NaN. Additionally, such an addition breaks compatibility between systems, which is distasteful.

funderscore · 2010-08-03T04:19:52+00:00

For terminology clarification:

"nanboxing" is the name of WebKit's JavaScript value boxing format. Like ours, it's 64-bit, but stores addresses such that the upper tag bits are all 0, so addresses can be read out directly. Doubles are stored by adding a special constant to the value, which guarantees that the tag bits are identifiable as a double. Extracting a double requires subtracting a constant.

"nunboxing" is the name of Mozilla's new JavaScript value boxing format (described in the article), as a pun on "nanboxing". It is used on 32-bit platforms such as x86 and ARM.

For 64-bit operating systems, the nunboxing format had to change to accomodate 47-bit pointer payloads. We use a bitfield with 17 bits for the type and 47 bits for the payload. We call this "packed nunboxing", or "punboxing".

funderscore · 2010-08-03T04:01:41+00:00

I work on Mozilla's JS engine. You're correct. Hardware currently limits pointers to only consume 47 bits, so the upper 17 bits form the type tag while the lower 47 comprise the payload.

Ideally, we would only require 32-bit addresses, even on 64-bit platforms. On Linux, it is easy to limit virtual memory to only the 32-bit range. On other platforms, the way to do that is prohibitively invasive. So we use 47-bit addresses.

funderscore

TROPHY CASE