speed improvment is very impressive

orizng · Post by **orizng** » February 25th, 2008, 10:22 am

I dont think PGO is enable for trunk yet, can I expect another 100% javascript improvement with PGO build?

If so, that would be fastest ever recorded. lol

Ted Mielczarek · Post by **Ted Mielczarek** » February 25th, 2008, 12:17 pm

We estimated ~25% faster depending on the profiling data etc. Hoping to get this enabled on trunk soon.

Recall · Post by **Recall** » February 25th, 2008, 12:44 pm

Ted Mielczarek wrote:We estimated ~25% faster depending on the profiling data etc. Hoping to get this enabled on trunk soon.

What is PGO? Do you think you will be able to get to Safari 3.1 performance?

chob · Post by **chob** » February 25th, 2008, 1:36 pm

PGO = profile guided optimization

a build is made, a load of test are done on it, then using that information a super optimized version of firefox gets built. or something like that, anyway.

a;skdjfajf;ak · Post by **a;skdjfajf;ak** » February 25th, 2008, 1:43 pm

PGO has been checked in for Linux - Should be in the the next hourly I assume -

ColeTrickle · Post by **ColeTrickle** » February 25th, 2008, 1:46 pm

so pgo stands for profile guided optimization, but what does it mean?

orizng · Post by **orizng** » February 25th, 2008, 2:00 pm

Recall wrote:
Ted Mielczarek wrote:We estimated ~25% faster depending on the profiling data etc. Hoping to get this enabled on trunk soon.

What is PGO? Do you think you will be able to get to Safari 3.1 performance?

Ted explained that PGO will probably not made into firefox 3 for Mac (It probably will in win/lin). http://forums.mozillazine.org/viewtopic ... 8&start=15

Anyway, its very close to safari "3.1" already, 6000 vs 4600ms, isn't a significant difference in real world. Javascript isn't everything, there are many other stuff as well, e.g., firefox 3 reads cache much faster than safari/webkit, which should give users more impact.

fadsxcv · Post by **fadsxcv** » February 25th, 2008, 2:57 pm

PGO means the compiler puts a ton of checks in the code to see which sections are "hot" (meaning which gets executed more frequently) and which sections are "cold". So after you "profile" the program by running it so these checks have a feel for what the program does in a typical run, it will then use this information to optimize the program better on the next compile.

Then the compiler does various things like rearranging code so nearby code is likely to be in the CPU's cache so it doesn't have to do expensive paging to load far away code, rearranging branches to work better with your CPU's branch prediction logic, unrolling vtable and function pointer lookups to remove levels of indirection, compile the "hot" code optimized for faster speed and compile the "cold" code optimized to minimize space usage, etc.

szhorvat · Post by **szhorvat** » February 25th, 2008, 3:33 pm

Ted Mielczarek wrote:We estimated ~25% faster depending on the profiling data etc. Hoping to get this enabled on trunk soon.

Does this estimate refer to the Windows or the Linux version?

wwhsgrad2002 · Post by **wwhsgrad2002** » February 25th, 2008, 6:33 pm

This is using the SunSpider JavaScript Benchmark on my T60 Laptop

On Firefox 2.0.0.12 (Clean Profile) Total: 17671.2ms +/- 0.9%
On Firefox 3.0 (Clean Profile, Latest Nightly): Total: 5966.2ms +/- 0.5%

Ted Mielczarek · Post by **Ted Mielczarek** » February 26th, 2008, 4:40 am

szhorvat wrote:
Ted Mielczarek wrote:We estimated ~25% faster depending on the profiling data etc. Hoping to get this enabled on trunk soon.

Does this estimate refer to the Windows or the Linux version?

Windows. I don't have numbers for Linux, but I don't think it's quite as spectacular. MSVC generates better code than GCC in general.

chob · Post by **chob** » February 26th, 2008, 5:01 am

wwhsgrad2002 wrote:This is using the SunSpider JavaScript Benchmark on my T60 Laptop

On Firefox 2.0.0.12 (Clean Profile) Total: 17671.2ms +/- 0.9%
On Firefox 3.0 (Clean Profile, Latest Nightly): Total: 5966.2ms +/- 0.5%

I don't know what build you used, but at 2008-02-25 16:59 Bug 419152 landed which is another javascript performance win. And there's still Igor's Specialized GC arena for double values to reland, which last time took Tssunspider tests from 550ms to 525ms. And PGO is still to be turned on, so more speed to come

Recall · Post by **Recall** » February 26th, 2008, 5:22 am

fadsxcv wrote:PGO means the compiler puts a ton of checks in the code to see which sections are "hot" (meaning which gets executed more frequently) and which sections are "cold". So after you "profile" the program by running it so these checks have a feel for what the program does in a typical run, it will then use this information to optimize the program better on the next compile.

Then the compiler does various things like rearranging code so nearby code is likely to be in the CPU's cache so it doesn't have to do expensive paging to load far away code, rearranging branches to work better with your CPU's branch prediction logic, unrolling vtable and function pointer lookups to remove levels of indirection, compile the "hot" code optimized for faster speed and compile the "cold" code optimized to minimize space usage, etc.

Thanks, so each subsequent start will produce a faster firefox?

chob · Post by **chob** » February 26th, 2008, 5:29 am

Recall wrote:Thanks, so each subsequent start will produce a faster firefox?

No, it's done at compile time, not run time.

Recall · Post by **Recall** » February 26th, 2008, 5:31 am

chob wrote:
Recall wrote:Thanks, so each subsequent start will produce a faster firefox?

No, it's done at compile time, not run time.

OK, so only helps if you build firefox yourself?