[FX] drumsticks: OSX Release (G5 optimised) - NO MORE

[drumsticks]

20050505 Firefox
20050505 Thunderbird

[|2uso]

What about the use of different SDKs? Will using an older SDK compromise performance? Presumably newer SDKs are better written and are more efficient?

Make a full read of the bug link mento give us, all my doubts are clarified

BTW THANK YOU VERY MUCH mento

I applied the lastest patch and I'm building in Tiger right now... I'll post my results later

[edit]

I'm trying with this:

mk_add_options MOZ_CO_PROJECT=browser
ac_add_options --enable-application=browser
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff

ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-shared

ac_add_options --enable-optimize="-O3 -funroll-loops -fsched-interblock -falign-loops=16 -falign-jumps=16 -falign-functions=16 -falign-jumps-max-skip=15 -falign-loops-max-skip=15 -mpowerpc-gpopt -mpowerpc-gfxopt -ffast-math -fstrict-aliasing -mtune=G5 -mcpu=G5 -mpowerpc64 -faltivec -fno-inline"

ac_add_options --enable-prebinding
ac_add_options --enable-strip
ac_add_options --enable-strip-libs
ac_add_options --enable-static-libs
ac_add_options --enable-static

ac_add_options --with-pthreads
ac_add_options --without-system-nspr
ac_add_options --without-system-zlib
ac_add_options --without-system-jpeg
ac_add_options --without-system-png
ac_add_options --without-system-mng

[/edit]

[mmoy]

I'm curious about -mpowerpc64 (see my thread as to why) as I found that using it results in frequent crashes. Also, not sure why you have no-inline as that should produce faster, though more verbose, code. I may add ffast-math in my builds as this didn't hurt on x86. And I'm a bit surprised that GCC doesn't do loop alignments by default. Should be also interesting to see your resulting image size as most of those options trade size for speed.

[mento]

A few more question: Are there G4 specific code that the G5 cannot run? Or is the G5 a superset of the G4?

The 970 doesn't support "PowerPC Little-Endian" mode, but earlier CPUs do. That's why you couldn't run Virtual PC on G5s when they were first released.

What about the use of different SDKs? Will using an older SDK compromise performance? Presumably newer SDKs are better written and are more efficient?

You use an SDK to target an older system release. If you don't do this, you might wind up producing an application that relies on features not present on older releases. This is an oversimplification, but think about it this way: the SDK defines the maximal OS feature set that an application can use. When you run the application, it will always use the frameworks and libraries installed on the current system, so even if you built an application on 10.2 "Jaguar" against the Jaguar SDK and then copied it to a 10.4 "Tiger" machine, it would use the Tiger libraries, but be limited to making the same kind of calls that it could make on Jaguar. You still realize any internal improvements as long as the improvements support the external interfaces that were used in Jaguar.

In addition to SDKs, you can tweak a few other things that affect the application's compatibility: set the MACOSX_DEPLOYMENT_TARGET environment variable (to 10.2, 10.4, whatever) to specify linker features that the application will use and the minimum system release that it will run on. The default is 10.1.

To enable code in Mozilla specific to more recent systems, use --enable-macos-target option in .mozconfig (again, default is 10.1). This really isn't used in very many places and thus doesn't have a significant impact (or actually any impact at all). In theory, it could be used to elminate runtime checks for features that are only available in later releases.

I'd put both of these options in the "at-your-own-risk" category.

[drumsticks]

I'm curious about -mpowerpc64 (see my thread as to why) as I found that using it results in frequent crashes. Also, not sure why you have no-inline as that should produce faster, though more verbose, code. I may add ffast-math in my builds as this didn't hurt on x86. And I'm a bit surprised that GCC doesn't do loop alignments by default. Should be also interesting to see your resulting image size as most of those options trade size for speed.

Binary size without alignments 25.8MB and with alignments 26.9MB, when compressed, the difference is only 200KB. I didn't do any extensive benchmarking, just what felt faster at the time. Tab switching was quite slow, and I am pretty sure my machine was mostly idle at the time, but I'll test it again soon. I was surprised too by the result.

The 970 doesn't support "PowerPC Little-Endian" mode, but earlier CPUs do. That's why you couldn't run Virtual PC on G5s when they were first released.

Ah yes, forgot about that...

You use an SDK to target an older system release. If you don't do this, you might wind up producing an application that relies on features not present on older releases. This is an oversimplification, but think about it this way: the SDK defines the maximal OS feature set that an application can use. When you run the application, it will always use the frameworks and libraries installed on the current system, so even if you built an application on 10.2 "Jaguar" against the Jaguar SDK and then copied it to a 10.4 "Tiger" machine, it would use the Tiger libraries, but be limited to making the same kind of calls that it could make on Jaguar. You still realize any internal improvements as long as the improvements support the external interfaces that were used in Jaguar.

Thanks for the clarification.

Will try your patch now to build on Tiger. I have poor Tiger uptime now, never more than 24 hours because I have to boot to Panther. Will let you know how it goes...

Cheers!

[|2uso]

I got the same old crash when I was in Panther:

nsStaticComponents.cpp
ld: warning suggest use of -bind_at_load, as lazy binding may result in errors or different symbols being used
symbol _libVersionPoint used from dynamic library ../../dist/bin/libplc4.dylib(plvrsion.o) not from earlier dynamic library @executable_path/libplds4.dylib(plvrsion.o)
ld: warning prebinding disabled because of undefined symbols
ld: Undefined symbols:
__ZThn4_N17nsHashPropertyBag11GetPropertyERK9nsAStringPP10nsIVariant
__ZThn4_N17nsHashPropertyBag13GetEnumeratorEPP19nsISimpleEnumerator
__ZThn4_N17nsHashPropertyBag17GetPropertyAsBoolERK9nsAStringPi
__ZThn4_N17nsHashPropertyBag17SetPropertyAsBoolERK9nsAStringi
__ZThn4_N17nsHashPropertyBag18GetPropertyAsInt32ERK9nsAStringPi
__ZThn4_N17nsHashPropertyBag18GetPropertyAsInt64ERK9nsAStringPx
__ZThn4_N17nsHashPropertyBag18SetPropertyAsInt32ERK9nsAStringi
__ZThn4_N17nsHashPropertyBag18SetPropertyAsInt64ERK9nsAStringx
__ZThn4_N17nsHashPropertyBag19GetPropertyAsDoubleERK9nsAStringPd
__ZThn4_N17nsHashPropertyBag19GetPropertyAsUint32ERK9nsAStringPj
__ZThn4_N17nsHashPropertyBag19GetPropertyAsUint64ERK9nsAStringPy
__ZThn4_N17nsHashPropertyBag19SetPropertyAsDoubleERK9nsAStringd
__ZThn4_N17nsHashPropertyBag19SetPropertyAsUint32ERK9nsAStringj
__ZThn4_N17nsHashPropertyBag19SetPropertyAsUint64ERK9nsAStringy
__ZThn4_N17nsHashPropertyBag20GetPropertyAsAStringERK9nsAStringRS0_
__ZThn4_N17nsHashPropertyBag20SetPropertyAsAStringERK9nsAStringS2_
__ZThn4_N17nsHashPropertyBag21GetPropertyAsACStringERK9nsAStringR10nsACString
__ZThn4_N17nsHashPropertyBag21SetPropertyAsACStringERK9nsAStringRK10nsACString
__ZThn4_N17nsHashPropertyBag22GetPropertyAsInterfaceERK9nsAStringRK4nsIDPPv
__ZThn4_N17nsHashPropertyBag22SetPropertyAsInterfaceERK9nsAStringP11nsISupports
__ZThn4_N17nsHashPropertyBag24GetPropertyAsAUTF8StringERK9nsAStringR10nsACString
__ZThn4_N17nsHashPropertyBag24SetPropertyAsAUTF8StringERK9nsAStringRK10nsACString
make[4]: *** [firefox-bin] Error 1
make[3]: *** [libs] Error 2
make[2]: *** [tier_99] Error 2
make[1]: *** [default] Error 2
make: *** [build] Error 2

DOH

In Bug 292530 I read -O3 (-finline-functions) cause some troubles so I use -O3 and explicit bypass -finline... Anyway I had build with -finline in the past and no troubles at all, I was just given a try

About -mpowerpc64, the main goal is to build a full G5 optimized FF, am I wrong?

In some tests I made, using of these flags (-ffast-math -mpowerpc-gpopt -mtune=G5 -mcpu=G5 -mpowerpc64 specially) made the difference: around 4~6 sec less in rendering time and when 'preferences menu fading' was introduced with the initial high delay I had not troubles dealing with it. Without these flags the delay was annoying. Again, maybe I'm wrong, maybe was a 'placebo effect', I really don't know...

"-O3 -funroll-loops -fsched-interblock -falign-loops=16 -falign-jumps=16 -falign-functions=16 -falign-jumps-max-skip=15 -falign-loops-max-skip=15 -mpowerpc-gpopt -mpowerpc-gfxopt -ffast-math -fstrict-aliasing" is the same as -fast definition without -maling-natural. That's why I use'em, you know, I'm not a hacker...

[drumsticks]

Yeah! Both Firefox and Thunderbird builds fine on Tiger. No need to reboot! Heheh Thanks mento, you're the best!

However, I still find that building without alignment produces faster code, or at least faster tab switching and font resizing. I don't mind a slight benchmark rendering performance hit, but the above is very noticeable. Strange indeed...

[mento]

|2uso: that's bug 289586. -fno-inline doesn't disable -finline-functions, it just disables recognition of the inline keyword. You shouldn't need and should avoid -fno-inline. -O3 -fno-inline-functions may work, but no guarantees. It's a compiler bug and it's not a priority to fix.

drumsticks: glad to help!

[drumsticks]

Cripes. I spoke too soon I think... I tried building with an empty object directory and it won't compile now (I was using a 'dirty' object directory before. I'm now getting

Code: Select all

In file included from /not-telling-you-this/mozilla/config/asdecode.cpp:40:
/usr/include/gcc/darwin/3.3/c++/cstdio:156: error: `vfscanf' not declared
/usr/include/gcc/darwin/3.3/c++/cstdio:165: error: `vfscanf' not declared
In file included from /not-telling-you-this/mozilla/config/asdecode.cpp:41:
/usr/include/gcc/darwin/3.3/c++/cstdlib:138: error: `lldiv_t' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:139: error: `_Exit' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:148: error: syntax error before `('
   token
/usr/include/gcc/darwin/3.3/c++/cstdlib:149: error: syntax error before `.'
   token
/usr/include/gcc/darwin/3.3/c++/cstdlib:149: error: syntax error before `.'
   token
/usr/include/gcc/darwin/3.3/c++/cstdlib:152: error: syntax error before `('
   token
/usr/include/gcc/darwin/3.3/c++/cstdlib:153: error: syntax error before `.'
   token
/usr/include/gcc/darwin/3.3/c++/cstdlib:153: error: syntax error before `.'
   token
/usr/include/gcc/darwin/3.3/c++/cstdlib:155: error: `atoll' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:156: error: `strtof' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:159: error: `strtold' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:160: error: parse error before `}'
   token
/usr/include/gcc/darwin/3.3/c++/cstdlib:164: error: `lldiv_t' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:165: error: `_Exit' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:168: error: `div' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:169: error: `lldiv' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:170: error: `atoll' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:171: error: `strtof' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:172: error: `strtoll' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:173: error: `strtoull' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:174: error: `strtold' not declared
/not-telling-you-this/mozilla/config/asdecode.cpp: In function `int
   main(int, char**)':
/not-telling-you-this/mozilla/config/asdecode.cpp:114: warning: comparison
   between signed and unsigned integer expressions
/not-telling-you-this/mozilla/config/asdecode.cpp: At top level:
/not-telling-you-this/mozilla/config/asdecode.cpp:58: warning: `int
   read_int(FILE*)' defined but not used
make[2]: *** [asdecode.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [default] Error 2
make: *** [build] Error 2


[mmoy]

I'd guess that you have long long issues. Maybe related to -mpowerpc64?

[drumsticks]

I'd guess that you have long long issues. Maybe related to -mpowerpc64?

But I'm not using -mpowerpc64! I'm using -mpowerpc. See my mozconfig

I tried building with no optimizations and it fails with the same error. *sigh*

[|2uso]

VICTORY!

about:buildconfig

Trying now with -mpowerpc64

BTW is a nice date:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050505 Firefox/1.0+

[drumsticks]

|2uso: which version of fink are you using? I'm guessing my compile problems are because I'm using an old version of fink. Can't check right now, am away from my machine at the moment.

[mmoy]

I guessed long long as there are some long long routines in the list. Did you take a look at the header file that croaked?

[|2uso]

I'm using Fink 0.7.1 with a fresh install when I installed Tiger. Sorry for delay dude I was out of home the moment you wrote the question

Flawless VICTORY!

powerpc-apple-darwin8.0.0
-O2 -mcpu=G5 -mtune=G5 -mpowerpc64 -funroll-loops -mpowerpc-gpopt -mpowerpc-gfxopt -faltivec -ffast-math

[edit]

|2uso: that's bug 289586. -fno-inline doesn't disable -finline-functions, it just disables recognition of the inline keyword. You shouldn't need and should avoid -fno-inline. -O3 -fno-inline-functions may work, but no guarantees. It's a compiler bug and it's not a priority to fix.

Thank you again
[edit]