Hi Edin,
The 2% surprises me a lot. We got very different results but it might be due
to different hardware, OS (we use Windows Server 2003) and different tests.
Here's what we got (all non-threadsafe):
vc2005 intel msvc6
bench 9.326 9.378 10.28
hello 10.48 11.6 11.28
xoops 67.82 69.49 81.34
static 16.97 18.4 21.18
qdig 63.52 67.05 69.57
qdig2 14.4 15.61 19.04
Btw, today I never recommend running mod_php on Windows and always point
people to CGI or existing FastCGI implementations.
That said, I understand that you don't want to break things right now and
stick to VC 6. Although I know it can work in some cases, I agree with you
that running two CRTs is probably not a great idea. While the interfaces of
the CRT functions might be identical, I am not sure all the structures are
the same and that could cause some ugliness if we get structs like file
handlers from the Apache executable passed into PHP and vice-versa.
It's something worth looking into but not something one would want to rush
for a minor version like 5.2.1.
Andi
> -----Original Message-----
> From: Edin Kadribasic [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 06, 2007 1:28 PM
> To: Andi Gutmans
> Cc: 'PHP Internals List'
> Subject: Re: [PHP-DEV] Windows build
>
> Hi Andi,
>
> Turns out the problem is that Apache is building their binaries using
> VC6 so wrong CRT gets loaded. The only solution I found was
> to tell Windows to load Apache with msvcr80.dll instead of
> msvcr.dll by suppling a manifest file in Apache bin
> directory. If you crate Apache.exe.manifest that contains:
>
> <?xml version='1.0' encoding='UTF-8' standalone='yes'?>
> <assembly xmlns='urn:schemas-microsoft-com:asm.v1'
> manifestVersion='1.0'>
> <dependency>
> <dependentAssembly>
> <assemblyIdentity type='win32' name='Microsoft.VC80.CRT'
> version='8.0.50608.0' processorArchitecture='x86'
> publicKeyToken='1fc8b3b9a1e18e3b' />
> </dependentAssembly>
> </dependency>
> </assembly>
>
> The Apache will load PHP and PHP will be able to load
> extensions. It probably isn't good idea to force a different
> C Runtime on Apache like this.
>
> Regarding performance, I found that on Zend/bench.php the
> improvement was only marginal (2%) compared to huge increase
> (25-30%) when disabling thread support.
>
> http://edin.dk/archives/25-Benchmarks.html
>
>
> Edin
>
>
>
> Andi Gutmans wrote:
> > Hi Edin,
> >
> > Thanks for trying to get this to work!
> >
> > I think eventually it'll be the right move to go to VC8 but I agree
> > that if it risks a successful 5.2.1 release then it might
> not be worth
> > doing that right now. If you can share with us a
> reproducing case we
> > can try and look into it and see if we can get it to work.
> So far we
> > have concentrated on CLI/CGI/FastCGi because that's the
> most feasible
> > way of running, but I agree that you also need to get the
> other methods to run.
> >
> > For those who are curious, there are some significant performance
> > improvements in VC8. Our tolower() optimization which is
> significant
> > is only for VC8, the compiler creates significantly faster code (on
> > par with Intel C/C++ compiler), and I believe some of the CRT
> > functions like time() are also much faster. So I think it's
> definitely
> > worth upgrading but it should be well timed.
> >
> > Anyway, let us know and we'll try and dig deeper and help get this
> > puppy ported and update the build. There probably is some work that
> > needs to be done on the 3rd party libs.
> >
> > Thanks.
> >
> > Andi
> >
> >> -----Original Message-----
> >> From: Edin Kadribasic [mailto:[EMAIL PROTECTED]
> >> Sent: Friday, January 05, 2007 7:48 PM
> >> To: PHP Internals List
> >> Subject: [PHP-DEV] Windows build
> >>
> >> Hey,
> >>
> >> It seems that VC++ 8.0 (Visual Studio 2005) brings more
> trouble that
> >> its worth. Mainly the way it deals with the C runtime.
> After spending
> >> hours and hours of trying to figure out the way to make PHP work
> >> under Apache on Windows and be able to load extensions,
> I'm throwing
> >> in the towel.
> >>
> >> I can get PHP to work fine on the command line, both cgi
> and cli. It
> >> also works fine under IIS using fastcgi. But loading sapi
> dll into a
> >> webserver (not using php.exe or php-cgi.exe) works for the sapi
> >> itself, but trying to load any extensions via php.ini fails
> >> miserably. Sometimes you will get an error that the C runtime was
> >> attempted to be loaded in an illegal way, sometime PHP will claim
> >> that the extension does not exist, etc.
> >>
> >> I looked around at other projects and everyone seems to be
> using VC++
> >> 6.0 for their builds (Active state, apache, ...) which
> eliminates all
> >> the hassle with bundling C runtime, etc.
> >>
> >> So I think the best thing for us would be to stick to the
> good old C
> >> compiler for making the Windows distro.
> >>
> >> Edin
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List To
> unsubscribe,
> >> visit: http://www.php.net/unsub.php
> >>
> >
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
