Btw, I just saw that these VC 2005 binaries were with profile guided optimizations. Without those the performance was pretty much the same as the Intel compiler but still far better than VC6.
Just wanted to clarify for accuracy. Andi > -----Original Message----- > From: Andi Gutmans [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 06, 2007 6:20 PM > To: 'Edin Kadribasic' > Cc: 'PHP Internals List' > Subject: RE: [PHP-DEV] Windows build > > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
