MozillaZine

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

Discussion of third-party/unofficial Firefox/Thunderbird/SeaMonkey builds.
drumsticks
 
Posts: 607
Joined: April 14th, 2005, 4:32 am
Location: Australia

Post Posted May 5th, 2005, 4:57 am


|2uso

User avatar
 
Posts: 67
Joined: March 6th, 2004, 10:37 am
Location: Venezuela

Post Posted May 5th, 2005, 11:17 am

drumsticks wrote: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 :D

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]
Macintosh G5/1800 uniprocessor - 1Gb RAM - 320 Gb SATA soft raid strip mode
Mac OS X 10.4.3 - XCode 2.1 - GCC 4.0
Camino G5 optimized home made

mmoy
 
Posts: 5030
Joined: February 17th, 2004, 9:05 pm
Location: New Hampshire

Post Posted May 5th, 2005, 12:36 pm

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.
Dell E521 X2 5600+ MacBookPro 17'' 2.5 Ghz Penryn Dell M1330 2.0 Ghz Merom 4 GB Vista x64 Compaq r3000z AMD 64 3200+ (Win 32/64) PowerMac G5 1.8 Ghz MMOY-1.5 (OSX 10) Inspiron 8500, 4100, 4000, Dimension 2300 MacBook Pro 2.2 Ghz HP E6600 HP X2 4400+

mento
 
Posts: 180
Joined: April 23rd, 2005, 1:33 pm

Post Posted May 5th, 2005, 12:42 pm

drumsticks wrote: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
 
Posts: 607
Joined: April 14th, 2005, 4:32 am
Location: Australia

Post Posted May 5th, 2005, 1:09 pm

mmoy wrote: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.

mento wrote: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...

mento wrote: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

User avatar
 
Posts: 67
Joined: March 6th, 2004, 10:37 am
Location: Venezuela

Post Posted May 5th, 2005, 1:55 pm

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...
Macintosh G5/1800 uniprocessor - 1Gb RAM - 320 Gb SATA soft raid strip mode
Mac OS X 10.4.3 - XCode 2.1 - GCC 4.0
Camino G5 optimized home made

drumsticks
 
Posts: 607
Joined: April 14th, 2005, 4:32 am
Location: Australia

Post Posted May 5th, 2005, 1:56 pm

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
 
Posts: 180
Joined: April 23rd, 2005, 1:33 pm

Post Posted May 5th, 2005, 2:21 pm

|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
 
Posts: 607
Joined: April 14th, 2005, 4:32 am
Location: Australia

Post Posted May 5th, 2005, 2:34 pm

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
 
Posts: 5030
Joined: February 17th, 2004, 9:05 pm
Location: New Hampshire

Post Posted May 5th, 2005, 2:37 pm

I'd guess that you have long long issues. Maybe related to -mpowerpc64?
Dell E521 X2 5600+ MacBookPro 17'' 2.5 Ghz Penryn Dell M1330 2.0 Ghz Merom 4 GB Vista x64 Compaq r3000z AMD 64 3200+ (Win 32/64) PowerMac G5 1.8 Ghz MMOY-1.5 (OSX 10) Inspiron 8500, 4100, 4000, Dimension 2300 MacBook Pro 2.2 Ghz HP E6600 HP X2 4400+

drumsticks
 
Posts: 607
Joined: April 14th, 2005, 4:32 am
Location: Australia

Post Posted May 5th, 2005, 2:38 pm

mmoy wrote: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

User avatar
 
Posts: 67
Joined: March 6th, 2004, 10:37 am
Location: Venezuela

Post Posted May 5th, 2005, 4:37 pm

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+
Macintosh G5/1800 uniprocessor - 1Gb RAM - 320 Gb SATA soft raid strip mode
Mac OS X 10.4.3 - XCode 2.1 - GCC 4.0
Camino G5 optimized home made

drumsticks
 
Posts: 607
Joined: April 14th, 2005, 4:32 am
Location: Australia

Post Posted May 5th, 2005, 4:42 pm

|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
 
Posts: 5030
Joined: February 17th, 2004, 9:05 pm
Location: New Hampshire

Post Posted May 5th, 2005, 6:05 pm

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?
Dell E521 X2 5600+ MacBookPro 17'' 2.5 Ghz Penryn Dell M1330 2.0 Ghz Merom 4 GB Vista x64 Compaq r3000z AMD 64 3200+ (Win 32/64) PowerMac G5 1.8 Ghz MMOY-1.5 (OSX 10) Inspiron 8500, 4100, 4000, Dimension 2300 MacBook Pro 2.2 Ghz HP E6600 HP X2 4400+

|2uso

User avatar
 
Posts: 67
Joined: March 6th, 2004, 10:37 am
Location: Venezuela

Post Posted May 5th, 2005, 8:13 pm

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.
:oops:

Thank you again
[edit]
Macintosh G5/1800 uniprocessor - 1Gb RAM - 320 Gb SATA soft raid strip mode
Mac OS X 10.4.3 - XCode 2.1 - GCC 4.0
Camino G5 optimized home made

Return to Third Party/Unofficial Builds


Who is online

Users browsing this forum: No registered users and 1 guest