Do you have the utility that forces an EXE to bind to one processor? I did not run
that against
this version, but I have in previous ones.
Can you try that?
I'll try to find an SMP machine to check out.
Thanks
Mike Kaply
IBM
Robert Henschel wrote:
> Hi,
>
> I just downloaded the optimized VACPP 0.6 and got the following problem:
>
> I have WSEB with Fixpack 2 on SMP with 2 Intel Celeron. (no kernel
> fixes, just fixpack 2)
>
> It starts loading, displays the "IBM Web Browser" logo and then hangs
> the system. I can not even move the mouse or CAD.
>
> Just to let you know...
>
> Robert Henschel
>
> Michael Kaply schrieb:
> >
> > I have uploaded a fully optimized VACPP Warpzilla 0.6 (aka IBM Web
> > Browser) to mozilla.org:
> >
> >
>ftp://ftp.mozilla.org/pub/mozilla/releases/mozilla0.6/mozilla-i386-pcos2-vacpp-opt-0.6.zip
> >
> > Before you ask, the main reason we chose 0.6 is because we wanted a
> > known stable entity to work with, and all of the concepts are the same.
> > The code we wrote will go into the trunk and future milestones. We also
> > chose it for the more obvious reason that IBM pays my bills :)
> >
> > This build reflects a lot of work that has been done by my team to
> > improve the performance of the VACPP Warpzilla.
> >
> > Here is a quick summary:
> >
> > 1. We have rewritten xptcstubs and xptcinvoke in XPCOM. This was
> > necessary to enable optimization in the compiler. There was code in
> > these functions that did not work when the code was optimized. We also
> > hand tuned these functions to make them faster. Thanks to Jeff Jones and
> > Javier Pedemonte for these changes.
> >
> > 2. NSPR has some atom functions that were either inline assembly or C
> > runtime calls on all platforms except OS/2. On OS/2, we were using the
> > generic NSPR implementation which were VERY slow. We have implemented
> > them in assembly.
> >
> > BIG NOTE - I did NOT include the RAM semaphores in this build. I want to
> > determine whether or not the key performance issue was the
> > PR_Lock/PR_Unlock code itself or the face that the atom code was calling
> > it too much. If you want to try the new atom code AND the ramsems, use
> > the NSPR4.ZIP which is at:
> >
> > ftp://ftp.software.ibm.com/ps/products/warpzilla/nspr4.zip
> >
> > 3. We have modified some of the flags used in the build. We have added
> > the /Gx flag when we compile C++. Because Mozilla does not use C++
> > exceptions, this is not needed, and it reduces code size. Also, we have
> > added the /G5 flag in NSPR - it was missing this optimization. We are
> > using the /Gl function in conjunction with the /OPTFUNC flag on the
> > linker to reduce code size.
> >
> > 4. We have fully optimized the build using the /O+ option. In doing
> > this, we found at least two compiler bugs (probably more). The first one
> > requires a fix for the compiler. You will know that you have this bug if
> > the build hangs compiling nsMsgMD5.cpp in mailnews. The second bug has
> > not been fixed at the time of this writing, so as a result, we are
> > unable to optimize the mozilla/security/nss/lib/freebl directory.
> >
> > 5. We are using the new version of LXLITE (1.3.1) to reduce the size of
> > the DLLs.
> >
> > Please note that THIS VERSION HAS BUGS! Some people have said it is less
> > stable, and we have at least found a problem with the rounding of values
> > when Document Done is displayed.
> >
> > Please DON'T report bugs on this in Bugzilla. Please report them here.
> >
> > We will continue to look at this build to get as many bugs fixed as we
> > can. Most of them will be bugs in the compiler, so we will want to find
> > them as soon as possible since they will most likely affect trunk builds
> > as well.
> >
> > IMPORTANT: You CAN'T share profiles with 0.6 and later builds. Make sure
> > you create a new profile to use this.
> >
> > Thanks for your support.
> >
> > Mike Kaply
> > IBM
